rfc/wip ttm get rid of binding branch
Spent today trying to straighten out some of the ideas I had for dropping bind/unbind paths into drivers. https://github.com/airlied/linux/commits/ttm-no-more-bind I think it mostly trends to the right place, the bind/unbind paths all end up in drivers, you get a move/invalidate_notify or move_notify in drivers (only drm_gem_vram, still uses move_notify). I've only booted nouveau with this so far, just looking to see if it's a good idea or maybe I've gone too far :-P Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm/ttm: add ttm_bo_pin()/ttm_bo_unpin() v2
On Tue, Sep 22, 2020 at 09:31:58PM +0800, Christian König wrote:
> As an alternative to the placement flag add a
> pin count to the ttm buffer object.
>
> v2: add dma_resv_assert_help() calls
>
> Signed-off-by: Christian König
Series look good for me as well.
Reviewed-by: Huang Rui
Only one comment:
We can modify the TOPDOWN offset as 21 since the NO_EVICT is removed.
#define TTM_PL_FLAG_UNCACHED(1 << 17)
#define TTM_PL_FLAG_WC (1 << 18)
#define TTM_PL_FLAG_CONTIGUOUS (1 << 19)
-#define TTM_PL_FLAG_NO_EVICT(1 << 21)
#define TTM_PL_FLAG_TOPDOWN (1 << 22)
Thanks,
Ray
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 9 ++---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
> include/drm/ttm/ttm_bo_api.h | 26 ++
> 3 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 70b3bee27850..b82b49d43942 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -115,7 +115,7 @@ static void ttm_bo_add_mem_to_lru(struct
> ttm_buffer_object *bo,
> struct ttm_bo_device *bdev = bo->bdev;
> struct ttm_resource_manager *man;
>
> - if (!list_empty(&bo->lru))
> + if (!list_empty(&bo->lru) || bo->pin_count)
> return;
>
> if (mem->placement & TTM_PL_FLAG_NO_EVICT)
> @@ -165,7 +165,8 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
> ttm_bo_del_from_lru(bo);
> ttm_bo_add_mem_to_lru(bo, &bo->mem);
>
> - if (bulk && !(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
> + if (bulk && !(bo->mem.placement & TTM_PL_FLAG_NO_EVICT) &&
> + !bo->pin_count) {
> switch (bo->mem.mem_type) {
> case TTM_PL_TT:
> ttm_bo_bulk_move_set_pos(&bulk->tt[bo->priority], bo);
> @@ -544,8 +545,9 @@ static void ttm_bo_release(struct kref *kref)
>* shrinkers, now that they are queued for
>* destruction.
>*/
> - if (bo->mem.placement & TTM_PL_FLAG_NO_EVICT) {
> + if (bo->mem.placement & TTM_PL_FLAG_NO_EVICT || bo->pin_count) {
> bo->mem.placement &= ~TTM_PL_FLAG_NO_EVICT;
> + bo->pin_count = 0;
> ttm_bo_del_from_lru(bo);
> ttm_bo_add_mem_to_lru(bo, &bo->mem);
> }
> @@ -1172,6 +1174,7 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
> bo->moving = NULL;
> bo->mem.placement = TTM_PL_FLAG_CACHED;
> bo->acc_size = acc_size;
> + bo->pin_count = 0;
> bo->sg = sg;
> if (resv) {
> bo->base.resv = resv;
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index fb2a25f8408f..1968df9743fc 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -352,7 +352,6 @@ static int ttm_buffer_object_transfer(struct
> ttm_buffer_object *bo,
> return -ENOMEM;
>
> fbo->base = *bo;
> - fbo->base.mem.placement |= TTM_PL_FLAG_NO_EVICT;
>
> ttm_bo_get(bo);
> fbo->bo = bo;
> @@ -372,6 +371,7 @@ static int ttm_buffer_object_transfer(struct
> ttm_buffer_object *bo,
> kref_init(&fbo->base.kref);
> fbo->base.destroy = &ttm_transfered_destroy;
> fbo->base.acc_size = 0;
> + fbo->base.pin_count = 1;
> if (bo->type != ttm_bo_type_sg)
> fbo->base.base.resv = &fbo->base.base._resv;
>
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 0f7cd21d6d74..33aca60870e2 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -157,6 +157,7 @@ struct ttm_buffer_object {
>
> struct dma_fence *moving;
> unsigned priority;
> + unsigned pin_count;
>
> /**
>* Special members that are protected by the reserve lock
> @@ -606,6 +607,31 @@ static inline bool
> ttm_bo_uses_embedded_gem_object(struct ttm_buffer_object *bo)
> return bo->base.dev != NULL;
> }
>
> +/**
> + * ttm_bo_pin - Pin the buffer object.
> + * @bo: The buffer object to pin
> + *
> + * Make sure the buffer is not evicted any more during memory pressure.
> + */
> +static inline void ttm_bo_pin(struct ttm_buffer_object *bo)
> +{
> + dma_resv_assert_held(bo->base.resv);
> + ++bo->pin_count;
> +}
> +
> +/**
> + * ttm_bo_unpin - Unpin the buffer object.
> + * @bo: The buffer object to unpin
> + *
> + * Allows the buffer object to be evicted again during memory pressure.
> + */
> +static inline void ttm_bo_unpin(struct ttm_buffer_object *bo)
> +{
> + dma_resv_assert_held(bo->base.resv);
> + WARN_ON_ONCE(!bo->pin_count);
> + --bo->pin_count;
> +}
> +
> int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> struct ttm_resource_manager *man,
> const struct ttm_place *place,
> --
> 2.17.1
>
linux-next: build warning after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
'cdns_mhdp_fw_activate':
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: conversion
from 'long unsigned int' to 'unsigned int' changes value from
'18446744073709551613' to '4294967293' [-Woverflow]
751 | writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
'cdns_mhdp_attach':
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:1692:10: warning:
conversion from 'long unsigned int' to 'unsigned int' changes value from
'18446744073709551613' to '4294967293' [-Woverflow]
1692 | writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
'cdns_mhdp_bridge_hpd_enable':
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:2125:10: warning:
conversion from 'long unsigned int' to 'unsigned int' changes value from
'18446744073709551613' to '4294967293' [-Woverflow]
2125 | writel(~CDNS_APB_INT_MASK_SW_EVENT_INT,
Introduced by commit
fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge")
--
Cheers,
Stephen Rothwell
pgpSckH_2eHu0.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Why can't ttm_tt_swapout() handle uncached or WC BOs?
On Fri, 18 Sep 2020 at 00:49, Christian König wrote: > > Am 17.09.20 um 16:44 schrieb Michel Dänzer: > > On 2020-09-17 2:20 p.m., Christian König wrote: > >> Hi guys, > >> > >> Michel once submitted a patch to fix triggering this BUG_ON in > >> ttm_tt_swapout(): > >> > >>> BUG_ON(ttm->caching_state != tt_cached); > >> > >> Now my question is does anybody know why we have that in the first > >> place? > >> > >> The only problematic thing I can see is calling copy_highpage() and > >> that one is just doing a kmap_atomic()/kunmap_atomic() on the source > >> and destination. > >> > >> I can't see why it should be problematic for this temporary mapping > >> to be cached instead of uncached or WC? > >> > >> Does anybody has any idea? > > > > One thing is that AFAIK some (ARM?) CPUs can get very upset when > > there's both a cached and uncacheable mapping for the same physical page. > > Good point, but I already considered this. > > If there is another mapping for that page left we are completely busted > anyway since we are currently changing the underlying storage. > It's not just ARM of course, x86 PAT also has many issues about multiple mappings of the same backing page with different attributes. The only mappings might be in the linear mapping, since not all pages we get here will necessarily be high pages I assume and therefore could have a linear mapping. If we've changed the linear mapping to non-cached, then create a cached kmap I'm not 100% that won't cause issues. but this is a definite maze of twisty passages and I'd probably need to sit down and break it a bit more. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/10] drm/ttm: reverse move calling pattern.
From: Dave Airlie
Call the driver move function if it exists, otherwise use the
fallback ttm/memcpy paths.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 993a87443c37..3d9c62cdf38d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -229,6 +229,23 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
}
EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
+static int ttm_bo_move_fallback(struct ttm_buffer_object *bo,
+ struct ttm_operation_ctx *ctx,
+ struct ttm_resource *mem)
+{
+ struct ttm_resource_manager *old_man = ttm_manager_type(bo->bdev,
bo->mem.mem_type);
+ struct ttm_resource_manager *new_man = ttm_manager_type(bo->bdev,
mem->mem_type);
+
+ if (old_man->use_tt && new_man->use_tt) {
+ if (bo->mem.mem_type == TTM_PL_SYSTEM) {
+ ttm_bo_assign_mem(bo, mem);
+ return 0;
+ } else
+ return ttm_bo_move_ttm(bo, ctx, mem);
+ } else
+ return ttm_bo_move_memcpy(bo, ctx, mem);
+}
+
static int ttm_bo_handle_move_mem(struct ttm_buffer_object *bo,
struct ttm_resource *mem, bool evict,
struct ttm_operation_ctx *ctx)
@@ -270,17 +287,10 @@ 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->use_tt && new_man->use_tt) {
- if (bo->mem.mem_type == TTM_PL_SYSTEM) {
- ttm_bo_assign_mem(bo, mem);
- ret = 0;
- } else
- ret = ttm_bo_move_ttm(bo, ctx, mem);
- }
- else if (bdev->driver->move)
+ if (bdev->driver->move)
ret = bdev->driver->move(bo, evict, ctx, mem);
else
- ret = ttm_bo_move_memcpy(bo, ctx, mem);
+ ret = ttm_bo_move_fallback(bo, ctx, mem);
if (ret) {
if (bdev->driver->move_notify) {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/10] drm/radeon/ttm: handle ttm moves properly
From: Dave Airlie
The core move code currently handles use_tt moves, for radeon
this was being handled also in the driver, but not using the same
paths.
If moving between TT/SYSTEM (all the use_tt paths on radeon) use
the core move function.
Eventually the core will be flipped over to calling the driver.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_ttm.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index ea9ffa6198da..df5cedb2b632 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -316,14 +316,16 @@ static int radeon_bo_move(struct ttm_buffer_object *bo,
bool evict,
ttm_bo_move_null(bo, new_mem);
return 0;
}
- if ((old_mem->mem_type == TTM_PL_TT &&
-new_mem->mem_type == TTM_PL_SYSTEM) ||
- (old_mem->mem_type == TTM_PL_SYSTEM &&
-new_mem->mem_type == TTM_PL_TT)) {
- /* bind is enough */
+ if (old_mem->mem_type == TTM_PL_SYSTEM &&
+ new_mem->mem_type == TTM_PL_TT) {
ttm_bo_move_null(bo, new_mem);
return 0;
}
+
+ if (old_mem->mem_type == TTM_PL_TT &&
+ new_mem->mem_type == TTM_PL_SYSTEM)
+ return ttm_bo_move_ttm(bo, ctx, new_mem);
+
if (!rdev->ring[radeon_copy_ring_index(rdev)].ready ||
rdev->asic->copy.copy == NULL) {
/* use memcpy */
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/10] drm/amdgpu/ttm: handle tt moves properly.
From: Dave Airlie
The core move code currently handles use_tt moves, for amdgpu
this was being handled also in the driver, but not using the same
paths.
If moving between TT/SYSTEM (all the use_tt paths on amdgpu) use
the core move function.
Eventually the core will be flipped over to calling the driver.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index db5f761f37ec..d3bd2fd448be 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -671,14 +671,16 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo,
bool evict,
ttm_bo_move_null(bo, new_mem);
return 0;
}
- if ((old_mem->mem_type == TTM_PL_TT &&
-new_mem->mem_type == TTM_PL_SYSTEM) ||
- (old_mem->mem_type == TTM_PL_SYSTEM &&
-new_mem->mem_type == TTM_PL_TT)) {
- /* bind is enough */
+ if (old_mem->mem_type == TTM_PL_SYSTEM &&
+ new_mem->mem_type == TTM_PL_TT) {
ttm_bo_move_null(bo, new_mem);
return 0;
}
+
+ if (old_mem->mem_type == TTM_PL_TT &&
+ new_mem->mem_type == TTM_PL_SYSTEM)
+ return ttm_bo_move_ttm(bo, ctx, new_mem);
+
if (old_mem->mem_type == AMDGPU_PL_GDS ||
old_mem->mem_type == AMDGPU_PL_GWS ||
old_mem->mem_type == AMDGPU_PL_OA ||
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/10] drm/nouveau/ttm: handle ttm moves properly.
From: Dave Airlie
The idea is to flip the core over to calling the driver always,
so add support for moves here.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8d51cfca07c8..2c10a84b2cc0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1057,6 +1057,18 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
goto out;
}
+ if (old_reg->mem_type == TTM_PL_SYSTEM &&
+ new_reg->mem_type == TTM_PL_TT) {
+ ttm_bo_move_null(bo, new_reg);
+ goto out;
+ }
+
+ if (old_reg->mem_type == TTM_PL_TT &&
+ new_reg->mem_type == TTM_PL_SYSTEM) {
+ ret = ttm_bo_move_ttm(bo, ctx, new_reg);
+ goto out;
+ }
+
/* Hardware assisted copy. */
if (drm->ttm.move) {
if (new_reg->mem_type == TTM_PL_SYSTEM)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/10] ttm driver cleanups and invert move
The first 5 patches are just cleanups to remove unused functions and handle ttm operation ctx nicer in driver move paths. The last 5 patches have the goal to invert the operation of the move driver callback. Currently the core does some tt related moves itself and pass the drivers the rest. I'd like to have the driver decide things instead, so only use the fallback paths when a driver has no move callback. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/10] drm/ttm: handle the SYSTEM->TT path in same place as others.
From: Dave Airlie
This just consolidates the code making the flow easier to understand
and also helps when moving move to the driver side.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 5737b3fae1b3..993a87443c37 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -265,20 +265,18 @@ static int ttm_bo_handle_move_mem(struct
ttm_buffer_object *bo,
if (ret)
goto out_err;
}
-
- if (bo->mem.mem_type == TTM_PL_SYSTEM) {
- if (bdev->driver->move_notify)
- bdev->driver->move_notify(bo, evict, mem);
- bo->mem = *mem;
- goto moved;
- }
}
if (bdev->driver->move_notify)
bdev->driver->move_notify(bo, evict, mem);
- if (old_man->use_tt && new_man->use_tt)
- ret = ttm_bo_move_ttm(bo, ctx, mem);
+ if (old_man->use_tt && new_man->use_tt) {
+ if (bo->mem.mem_type == TTM_PL_SYSTEM) {
+ ttm_bo_assign_mem(bo, mem);
+ ret = 0;
+ } else
+ ret = ttm_bo_move_ttm(bo, ctx, mem);
+ }
else if (bdev->driver->move)
ret = bdev->driver->move(bo, evict, ctx, mem);
else
@@ -294,7 +292,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
goto out_err;
}
-moved:
ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
return 0;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/10] drm/nouveau/ttm: plumb ctx through move functions.
From: Dave Airlie
This just uses the ctx instead of passing bools and recreating it.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +---
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index bcae4514952f..8a90b07f17a4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -772,8 +772,9 @@ nouveau_bo_move_prep(struct nouveau_drm *drm, struct
ttm_buffer_object *bo,
}
static int
-nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict, bool intr,
-bool no_wait_gpu, struct ttm_resource *new_reg)
+nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
+struct ttm_operation_ctx *ctx,
+struct ttm_resource *new_reg)
{
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
struct nouveau_channel *chan = drm->ttm.chan;
@@ -792,7 +793,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict, bool intr,
}
mutex_lock_nested(&cli->mutex, SINGLE_DEPTH_NESTING);
- ret = nouveau_fence_sync(nouveau_bo(bo), chan, true, intr);
+ ret = nouveau_fence_sync(nouveau_bo(bo), chan, true,
ctx->interruptible);
if (ret == 0) {
ret = drm->ttm.move(chan, bo, &bo->mem, new_reg);
if (ret == 0) {
@@ -879,10 +880,10 @@ nouveau_bo_move_init(struct nouveau_drm *drm)
}
static int
-nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool evict, bool intr,
- bool no_wait_gpu, struct ttm_resource *new_reg)
+nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool evict,
+ struct ttm_operation_ctx *ctx,
+ struct ttm_resource *new_reg)
{
- struct ttm_operation_ctx ctx = { intr, no_wait_gpu };
struct ttm_place placement_memtype = {
.fpfn = 0,
.lpfn = 0,
@@ -898,11 +899,11 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool
evict, bool intr,
tmp_reg = *new_reg;
tmp_reg.mm_node = NULL;
- ret = ttm_bo_mem_space(bo, &placement, &tmp_reg, &ctx);
+ ret = ttm_bo_mem_space(bo, &placement, &tmp_reg, ctx);
if (ret)
return ret;
- ret = ttm_tt_populate(bo->bdev, bo->ttm, &ctx);
+ ret = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
if (ret)
goto out;
@@ -910,21 +911,21 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool
evict, bool intr,
if (ret)
goto out;
- ret = nouveau_bo_move_m2mf(bo, true, intr, no_wait_gpu, &tmp_reg);
+ ret = nouveau_bo_move_m2mf(bo, true, ctx, &tmp_reg);
if (ret)
goto out;
- ret = ttm_bo_move_ttm(bo, &ctx, new_reg);
+ ret = ttm_bo_move_ttm(bo, ctx, new_reg);
out:
ttm_resource_free(bo, &tmp_reg);
return ret;
}
static int
-nouveau_bo_move_flips(struct ttm_buffer_object *bo, bool evict, bool intr,
- bool no_wait_gpu, struct ttm_resource *new_reg)
+nouveau_bo_move_flips(struct ttm_buffer_object *bo, bool evict,
+ struct ttm_operation_ctx *ctx,
+ struct ttm_resource *new_reg)
{
- struct ttm_operation_ctx ctx = { intr, no_wait_gpu };
struct ttm_place placement_memtype = {
.fpfn = 0,
.lpfn = 0,
@@ -940,15 +941,15 @@ nouveau_bo_move_flips(struct ttm_buffer_object *bo, bool
evict, bool intr,
tmp_reg = *new_reg;
tmp_reg.mm_node = NULL;
- ret = ttm_bo_mem_space(bo, &placement, &tmp_reg, &ctx);
+ ret = ttm_bo_mem_space(bo, &placement, &tmp_reg, ctx);
if (ret)
return ret;
- ret = ttm_bo_move_ttm(bo, &ctx, &tmp_reg);
+ ret = ttm_bo_move_ttm(bo, ctx, &tmp_reg);
if (ret)
goto out;
- ret = nouveau_bo_move_m2mf(bo, true, intr, no_wait_gpu, new_reg);
+ ret = nouveau_bo_move_m2mf(bo, true, ctx, new_reg);
if (ret)
goto out;
@@ -1059,17 +1060,14 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool
evict,
/* Hardware assisted copy. */
if (drm->ttm.move) {
if (new_reg->mem_type == TTM_PL_SYSTEM)
- ret = nouveau_bo_move_flipd(bo, evict,
- ctx->interruptible,
- ctx->no_wait_gpu, new_reg);
+ ret = nouveau_bo_move_flipd(bo, evict, ctx,
+ new_reg);
else if (old_reg->mem_type == TTM_PL_SYSTEM)
- ret = nouveau_bo_move_flips(bo, evict,
- ctx->interruptible,
- ctx->no_wait_gpu, new_reg);
+ ret
[PATCH 05/10] drm/ttm: add bo wait that takes a ctx wrapper.
From: Dave Airlie
I'm thinking of pushing the wait into the drivers.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/qxl/qxl_ttm.c| 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c| 4 ++--
include/drm/ttm/ttm_bo_api.h | 5 +
5 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8a90b07f17a4..8d51cfca07c8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1038,7 +1038,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
struct nouveau_drm_tile *new_tile = NULL;
int ret = 0;
- ret = ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
+ ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
return ret;
@@ -1073,7 +1073,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
}
/* Fallback to software copy. */
- ret = ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
+ ret = ttm_bo_wait_ctx(bo, ctx);
if (ret == 0)
ret = ttm_bo_move_memcpy(bo, ctx, new_reg);
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 01fe0c3a3d9a..2c35ca4270c6 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -160,7 +160,7 @@ static int qxl_bo_move(struct ttm_buffer_object *bo, bool
evict,
struct ttm_resource *old_mem = &bo->mem;
int ret;
- ret = ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
+ ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 9ff8c81d7784..ea9ffa6198da 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -302,7 +302,7 @@ static int radeon_bo_move(struct ttm_buffer_object *bo,
bool evict,
struct ttm_resource *old_mem = &bo->mem;
int r;
- r = ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
+ r = ttm_bo_wait_ctx(bo, ctx);
if (r)
return r;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1968df9743fc..bdee4df1f3f2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -59,7 +59,7 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
int ret;
if (old_mem->mem_type != TTM_PL_SYSTEM) {
- ret = ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
+ ret = ttm_bo_wait_ctx(bo, ctx);
if (unlikely(ret != 0)) {
if (ret != -ERESTARTSYS)
@@ -231,7 +231,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
unsigned long add = 0;
int dir;
- ret = ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
+ ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
return ret;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 6cbe59bc97ab..b840756dbcca 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -262,6 +262,11 @@ ttm_bo_get_unless_zero(struct ttm_buffer_object *bo)
*/
int ttm_bo_wait(struct ttm_buffer_object *bo, bool interruptible, bool
no_wait);
+static inline int ttm_bo_wait_ctx(struct ttm_buffer_object *bo, struct
ttm_operation_ctx *ctx)
+{
+ return ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
+}
+
/**
* ttm_bo_mem_compat - Check if proposed placement is compatible with a bo
*
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 471/482] drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1502:6: warning: no previous prototype for 'amdgpu_ras_error_status_query'
Hi Stanley.Yang,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 6fe4a372821db85834f5522d94d25139ff17e414
commit: 4484ea5dfcbb092d856aee77aee01b36ff76d389 [471/482] drm/amdgpu: update
athub interrupt harvesting handle
config: ia64-randconfig-r033-20200923 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4484ea5dfcbb092d856aee77aee01b36ff76d389
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:906:5: warning: no previous
prototype for 'amdgpu_ras_error_cure' [-Wmissing-prototypes]
906 | int amdgpu_ras_error_cure(struct amdgpu_device *adev,
| ^
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1502:6: warning: no previous
>> prototype for 'amdgpu_ras_error_status_query' [-Wmissing-prototypes]
1502 | void amdgpu_ras_error_status_query(struct amdgpu_device *adev,
| ^
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:31:
drivers/gpu/drm/amd/amdgpu/amdgpu.h:197:19: warning: 'no_system_mem_limit'
defined but not used [-Wunused-const-variable=]
197 | static const bool no_system_mem_limit;
| ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:196:19: warning: 'debug_evictions'
defined but not used [-Wunused-const-variable=]
196 | static const bool debug_evictions; /* = false */
| ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:195:18: warning: 'sched_policy' defined
but not used [-Wunused-const-variable=]
195 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
| ^~~~
In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:67,
from drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:31:
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:76:32: warning:
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:75:32: warning:
'dc_fixpt_ln2' defined but not used [-Wunused-const-variable=]
75 | static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
|^~~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:74:32: warning:
'dc_fixpt_e' defined but not used [-Wunused-const-variable=]
74 | static const struct fixed31_32 dc_fixpt_e = { 11674931555LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:73:32: warning:
'dc_fixpt_two_pi' defined but not used [-Wunused-const-variable=]
73 | static const struct fixed31_32 dc_fixpt_two_pi = { 26986075409LL };
|^~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:72:32: warning:
'dc_fixpt_pi' defined but not used [-Wunused-const-variable=]
72 | static const struct fixed31_32 dc_fixpt_pi = { 13493037705LL };
|^~~
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next
git checkout 4484ea5dfcbb092d856aee77aee01b36ff76d389
vim +/amdgpu_ras_error_status_query +1502
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
1500
1501 /* Parse RdRspStatus and WrRspStatus */
> 1502 void amdgpu_ras_error_status_query(struct amdgpu_device *adev,
1503 struct ras_query_if *info)
1504 {
1505 /*
1506 * Only two block need to query read/write
1507 * RspStatus at current state
1508 */
1509 switch (info->head.block) {
1510 case AMDGPU_RAS_BLOCK__GFX:
1511 if (adev->gfx.funcs->query_ras_error_status)
1512 adev->gfx.funcs->query_ras_error_status(adev);
1513 break;
1514 case AMDGPU_RAS_BLOCK__MMHUB:
1515 if (adev->mmhub.funcs->query_ras_error_status)
1516 adev->mmhub.funcs->query_ras_error_status(adev);
1517
[PATCH 02/10] drm/qxl: kill unused bo wait wrapper
From: Dave Airlie
This wasn't used anywheere
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_object.h | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_object.h b/drivers/gpu/drm/qxl/qxl_object.h
index c7d79b20622e..09a5c818324d 100644
--- a/drivers/gpu/drm/qxl/qxl_object.h
+++ b/drivers/gpu/drm/qxl/qxl_object.h
@@ -58,29 +58,6 @@ static inline u64 qxl_bo_mmap_offset(struct qxl_bo *bo)
return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
}
-static inline int qxl_bo_wait(struct qxl_bo *bo, u32 *mem_type,
- bool no_wait)
-{
- int r;
-
- r = ttm_bo_reserve(&bo->tbo, true, no_wait, NULL);
- if (unlikely(r != 0)) {
- if (r != -ERESTARTSYS) {
- struct drm_device *ddev = bo->tbo.base.dev;
-
- dev_err(ddev->dev, "%p reserve failed for wait\n",
- bo);
- }
- return r;
- }
- if (mem_type)
- *mem_type = bo->tbo.mem.mem_type;
-
- r = ttm_bo_wait(&bo->tbo, true, no_wait);
- ttm_bo_unreserve(&bo->tbo);
- return r;
-}
-
extern int qxl_bo_create(struct qxl_device *qdev,
unsigned long size,
bool kernel, bool pinned, u32 domain,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/10] drm/radeon: cleanup ttm operation ctx usage.
From: Dave Airlie
Just pass it around move, and remove unused pieces
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_ttm.c | 34 +
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 085f58e833d8..9ff8c81d7784 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -151,7 +151,7 @@ static int radeon_verify_access(struct ttm_buffer_object
*bo, struct file *filp)
}
static int radeon_move_blit(struct ttm_buffer_object *bo,
- bool evict, bool no_wait_gpu,
+ bool evict,
struct ttm_resource *new_mem,
struct ttm_resource *old_mem)
{
@@ -206,11 +206,10 @@ static int radeon_move_blit(struct ttm_buffer_object *bo,
}
static int radeon_move_vram_ram(struct ttm_buffer_object *bo,
- bool evict, bool interruptible,
- bool no_wait_gpu,
+ bool evict,
+ struct ttm_operation_ctx *ctx,
struct ttm_resource *new_mem)
{
- struct ttm_operation_ctx ctx = { interruptible, no_wait_gpu };
struct ttm_resource *old_mem = &bo->mem;
struct ttm_resource tmp_mem;
struct ttm_place placements;
@@ -227,7 +226,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object
*bo,
placements.lpfn = 0;
placements.mem_type = TTM_PL_TT;
placements.flags = TTM_PL_MASK_CACHING;
- r = ttm_bo_mem_space(bo, &placement, &tmp_mem, &ctx);
+ r = ttm_bo_mem_space(bo, &placement, &tmp_mem, ctx);
if (unlikely(r)) {
return r;
}
@@ -237,7 +236,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object
*bo,
goto out_cleanup;
}
- r = ttm_tt_populate(bo->bdev, bo->ttm, &ctx);
+ r = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
if (unlikely(r)) {
goto out_cleanup;
}
@@ -246,22 +245,21 @@ static int radeon_move_vram_ram(struct ttm_buffer_object
*bo,
if (unlikely(r)) {
goto out_cleanup;
}
- r = radeon_move_blit(bo, true, no_wait_gpu, &tmp_mem, old_mem);
+ r = radeon_move_blit(bo, true, &tmp_mem, old_mem);
if (unlikely(r)) {
goto out_cleanup;
}
- r = ttm_bo_move_ttm(bo, &ctx, new_mem);
+ r = ttm_bo_move_ttm(bo, ctx, new_mem);
out_cleanup:
ttm_resource_free(bo, &tmp_mem);
return r;
}
static int radeon_move_ram_vram(struct ttm_buffer_object *bo,
- bool evict, bool interruptible,
- bool no_wait_gpu,
+ bool evict,
+ struct ttm_operation_ctx *ctx,
struct ttm_resource *new_mem)
{
- struct ttm_operation_ctx ctx = { interruptible, no_wait_gpu };
struct ttm_resource *old_mem = &bo->mem;
struct ttm_resource tmp_mem;
struct ttm_placement placement;
@@ -278,15 +276,15 @@ static int radeon_move_ram_vram(struct ttm_buffer_object
*bo,
placements.lpfn = 0;
placements.mem_type = TTM_PL_TT;
placements.flags = TTM_PL_MASK_CACHING;
- r = ttm_bo_mem_space(bo, &placement, &tmp_mem, &ctx);
+ r = ttm_bo_mem_space(bo, &placement, &tmp_mem, ctx);
if (unlikely(r)) {
return r;
}
- r = ttm_bo_move_ttm(bo, &ctx, &tmp_mem);
+ r = ttm_bo_move_ttm(bo, ctx, &tmp_mem);
if (unlikely(r)) {
goto out_cleanup;
}
- r = radeon_move_blit(bo, true, no_wait_gpu, new_mem, old_mem);
+ r = radeon_move_blit(bo, true, new_mem, old_mem);
if (unlikely(r)) {
goto out_cleanup;
}
@@ -334,14 +332,12 @@ static int radeon_bo_move(struct ttm_buffer_object *bo,
bool evict,
if (old_mem->mem_type == TTM_PL_VRAM &&
new_mem->mem_type == TTM_PL_SYSTEM) {
- r = radeon_move_vram_ram(bo, evict, ctx->interruptible,
- ctx->no_wait_gpu, new_mem);
+ r = radeon_move_vram_ram(bo, evict, ctx, new_mem);
} else if (old_mem->mem_type == TTM_PL_SYSTEM &&
new_mem->mem_type == TTM_PL_VRAM) {
- r = radeon_move_ram_vram(bo, evict, ctx->interruptible,
- ctx->no_wait_gpu, new_mem);
+ r = radeon_move_ram_vram(bo, evict, ctx, new_mem);
} else {
- r = radeon_move_blit(bo, evict, ctx->no_wait_gpu,
+ r = radeon_move_blit(bo, evict,
new_mem, old_mem);
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
h
[PATCH 01/10] drm/radeon: kill radeon_bo_wait
From: Dave Airlie
this is unused
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_object.c | 15 ---
drivers/gpu/drm/radeon/radeon_object.h | 3 ---
2 files changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 0de267ab3913..689426dd8480 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -825,21 +825,6 @@ int radeon_bo_fault_reserve_notify(struct
ttm_buffer_object *bo)
return 0;
}
-int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type, bool no_wait)
-{
- int r;
-
- r = ttm_bo_reserve(&bo->tbo, true, no_wait, NULL);
- if (unlikely(r != 0))
- return r;
- if (mem_type)
- *mem_type = bo->tbo.mem.mem_type;
-
- r = ttm_bo_wait(&bo->tbo, true, no_wait);
- ttm_bo_unreserve(&bo->tbo);
- return r;
-}
-
/**
* radeon_bo_fence - add fence to buffer object
*
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index e097a915277d..27cfb64057fe 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -133,9 +133,6 @@ static inline u64 radeon_bo_mmap_offset(struct radeon_bo
*bo)
return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
}
-extern int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type,
- bool no_wait);
-
extern int radeon_bo_create(struct radeon_device *rdev,
unsigned long size, int byte_align,
bool kernel, u32 domain, u32 flags,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm/ttm: add ttm_bo_pin()/ttm_bo_unpin() v2
On Tue, 22 Sep 2020 at 23:32, Christian König wrote: > > As an alternative to the placement flag add a > pin count to the ttm buffer object. These all look good to me, nice cleanup. For the series: Reviewed-by: Dave Airlie ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 443/482] drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:39:6: sparse: sparse: symbol 'kfd_initialized' was not declared. Should it be
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 6fe4a372821db85834f5522d94d25139ff17e414 commit: 0b54e1e30e9f201a63922344917e11ab60da0d1b [443/482] drm/amdgpu: Fix handling of KFD initialization failures config: x86_64-randconfig-s021-20200920 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-201-g24bdaac6-dirty git checkout 0b54e1e30e9f201a63922344917e11ab60da0d1b # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:39:6: sparse: sparse: symbol >> 'kfd_initialized' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH radeon-alex] drm/amdgpu: kfd_initialized can be static
Fixes: 0b54e1e30e9f ("drm/amdgpu: Fix handling of KFD initialization failures")
Signed-off-by: kernel test robot
---
amdgpu_amdkfd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 7f14461f7f402..01780bb8727f6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -36,7 +36,7 @@
*/
uint64_t amdgpu_amdkfd_total_mem_size;
-bool kfd_initialized;
+static bool kfd_initialized;
int amdgpu_amdkfd_init(void)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] dp/dp_mst: Add support for sink event notify messages
Sink event notify messages are used for MST CEC IRQs. Add parsing
support for sink event notify messages in preparation for handling MST
CEC IRQs.
Signed-off-by: Sam McNally
---
(no changes since v1)
drivers/gpu/drm/drm_dp_mst_topology.c | 37 ++-
include/drm/drm_dp_mst_helper.h | 14 ++
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 17dbed0a9800..15b6cc39a754 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1027,6 +1027,30 @@ static bool
drm_dp_sideband_parse_resource_status_notify(struct drm_dp_sideband_
return false;
}
+static bool drm_dp_sideband_parse_sink_event_notify(
+ struct drm_dp_sideband_msg_rx *raw,
+ struct drm_dp_sideband_msg_req_body *msg)
+{
+ int idx = 1;
+
+ msg->u.sink_event.port_number = (raw->msg[idx] & 0xf0) >> 4;
+ idx++;
+ if (idx > raw->curlen)
+ goto fail_len;
+
+ memcpy(msg->u.sink_event.guid, &raw->msg[idx], 16);
+ idx += 16;
+ if (idx > raw->curlen)
+ goto fail_len;
+
+ msg->u.sink_event.event_id = (raw->msg[idx] << 8) | (raw->msg[idx + 1]);
+ idx++;
+ return true;
+fail_len:
+ DRM_DEBUG_KMS("sink event notify parse length fail %d %d\n", idx,
raw->curlen);
+ return false;
+}
+
static bool drm_dp_sideband_parse_req(struct drm_dp_sideband_msg_rx *raw,
struct drm_dp_sideband_msg_req_body *msg)
{
@@ -1038,6 +1062,8 @@ static bool drm_dp_sideband_parse_req(struct
drm_dp_sideband_msg_rx *raw,
return drm_dp_sideband_parse_connection_status_notify(raw, msg);
case DP_RESOURCE_STATUS_NOTIFY:
return drm_dp_sideband_parse_resource_status_notify(raw, msg);
+ case DP_SINK_EVENT_NOTIFY:
+ return drm_dp_sideband_parse_sink_event_notify(raw, msg);
default:
DRM_ERROR("Got unknown request 0x%02x (%s)\n", msg->req_type,
drm_dp_mst_req_type_str(msg->req_type));
@@ -3875,6 +3901,8 @@ drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr
*mgr,
guid = msg->u.conn_stat.guid;
else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
guid = msg->u.resource_stat.guid;
+ else if (msg->req_type == DP_SINK_EVENT_NOTIFY)
+ guid = msg->u.sink_event.guid;
if (guid)
mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
@@ -3948,7 +3976,8 @@ static int drm_dp_mst_handle_up_req(struct
drm_dp_mst_topology_mgr *mgr)
drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg);
if (up_req->msg.req_type != DP_CONNECTION_STATUS_NOTIFY &&
- up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY) {
+ up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY &&
+ up_req->msg.req_type != DP_SINK_EVENT_NOTIFY) {
DRM_DEBUG_KMS("Received unknown up req type, ignoring: %x\n",
up_req->msg.req_type);
kfree(up_req);
@@ -3976,6 +4005,12 @@ static int drm_dp_mst_handle_up_req(struct
drm_dp_mst_topology_mgr *mgr)
DRM_DEBUG_KMS("Got RSN: pn: %d avail_pbn %d\n",
res_stat->port_number,
res_stat->available_pbn);
+ } else if (up_req->msg.req_type == DP_SINK_EVENT_NOTIFY) {
+ const struct drm_dp_sink_event_notify *sink_event =
+ &up_req->msg.u.sink_event;
+
+ DRM_DEBUG_KMS("Got SEN: pn: %d event_id %d\n",
+ sink_event->port_number, sink_event->event_id);
}
up_req->hdr = mgr->up_req_recv.initial_hdr;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 6ae5860d8644..c7c79e0ced18 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -402,6 +402,19 @@ struct drm_dp_resource_status_notify {
u16 available_pbn;
};
+#define DP_SINK_EVENT_PANEL_REPLAY_ACTIVE_FRAME_CRC_ERROR BIT(0)
+#define DP_SINK_EVENT_PANEL_REPLAY_RFB_STORAGE_ERROR BIT(1)
+#define DP_SINK_EVENT_DSC_RC_BUFFER_UNDER_RUN BIT(2)
+#define DP_SINK_EVENT_DSC_RC_BUFFER_OVERFLOW BIT(3)
+#define DP_SINK_EVENT_DSC_CHUNK_LENGTH_ERROR BIT(4)
+#define DP_SINK_EVENT_CEC_IRQ_EVENTBIT(5)
+
+struct drm_dp_sink_event_notify {
+ u8 port_number;
+ u8 guid[16];
+ u16 event_id;
+};
+
struct drm_dp_query_payload_ack_reply {
u8 port_number;
u16 allocated_pbn;
@@ -413,6 +426,7 @@ struct drm_dp_sideband_msg_req_body {
struct drm_dp_connection_status_notify conn_stat;
struct drm_dp_port_number_req po
[PATCH v3 4/4] drm_dp_cec: add MST support
With DP v2.0 errata E5, CEC tunneling can be supported through an MST
topology.
There are some minor differences for CEC tunneling through an MST
topology compared to CEC tunneling to an SST port:
- CEC IRQs are delivered via a sink event notify message
- CEC-related DPCD registers are accessed via remote DPCD reads and
writes.
This results in the MST implementation diverging from the existing SST
implementation:
- sink event notify messages with CEC_IRQ ID set indicate CEC IRQ rather
than ESI1
- setting edid and handling CEC IRQs, which can be triggered from
contexts where locks held preclude HPD handling, are deferred to avoid
remote DPCD access which would block until HPD handling is performed
or a timeout
Register and unregister for all MST connectors, ensuring their
drm_dp_aux_cec struct won't be accessed uninitialized.
Reviewed-by: Hans Verkuil
Signed-off-by: Sam McNally
---
Changes in v3:
- Fixed whitespace in drm_dp_cec_mst_irq_work()
- Moved drm_dp_cec_mst_set_edid_work() with the other set_edid functions
Changes in v2:
- Used aux->is_remote instead of aux->cec.is_mst, removing the need for
the previous patch in the series
- Added a defensive check for null edid in the deferred set_edid work,
in case the edid is no longer valid at that point
drivers/gpu/drm/drm_dp_cec.c | 68 +--
drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++
include/drm/drm_dp_helper.h | 4 ++
3 files changed, 91 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index 3ab2609f9ec7..1020b2cffdf0 100644
--- a/drivers/gpu/drm/drm_dp_cec.c
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/*
* Unfortunately it turns out that we have a chicken-and-egg situation
@@ -248,6 +249,10 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux)
if (!aux->transfer)
return;
+ if (aux->is_remote) {
+ schedule_work(&aux->cec.mst_irq_work);
+ return;
+ }
mutex_lock(&aux->cec.lock);
if (!aux->cec.adap)
goto unlock;
@@ -276,6 +281,23 @@ static bool drm_dp_cec_cap(struct drm_dp_aux *aux, u8
*cec_cap)
return true;
}
+static void drm_dp_cec_mst_irq_work(struct work_struct *work)
+{
+ struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
+ cec.mst_irq_work);
+ struct drm_dp_mst_port *port =
+ container_of(aux, struct drm_dp_mst_port, aux);
+
+ port = drm_dp_mst_topology_get_port_validated(port->mgr, port);
+ if (!port)
+ return;
+ mutex_lock(&aux->cec.lock);
+ if (aux->cec.adap)
+ drm_dp_cec_handle_irq(aux);
+ mutex_unlock(&aux->cec.lock);
+ drm_dp_mst_topology_put_port(port);
+}
+
/*
* Called if the HPD was low for more than drm_dp_cec_unregister_delay
* seconds. This unregisters the CEC adapter.
@@ -297,7 +319,8 @@ static void drm_dp_cec_unregister_work(struct work_struct
*work)
* were unchanged and just update the CEC physical address. Otherwise
* unregister the old CEC adapter and create a new one.
*/
-void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
+static void drm_dp_cec_handle_set_edid(struct drm_dp_aux *aux,
+ const struct edid *edid)
{
struct drm_connector *connector = aux->cec.connector;
u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
@@ -306,10 +329,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
unsigned int num_las = 1;
u8 cap;
- /* No transfer function was set, so not a DP connector */
- if (!aux->transfer)
- return;
-
#ifndef CONFIG_MEDIA_CEC_RC
/*
* CEC_CAP_RC is part of CEC_CAP_DEFAULTS, but it is stripped by
@@ -320,6 +339,7 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
*/
cec_caps &= ~CEC_CAP_RC;
#endif
+ cancel_work_sync(&aux->cec.mst_irq_work);
cancel_delayed_work_sync(&aux->cec.unregister_work);
mutex_lock(&aux->cec.lock);
@@ -375,8 +395,40 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
struct edid *edid)
unlock:
mutex_unlock(&aux->cec.lock);
}
+
+void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
+{
+ /* No transfer function was set, so not a DP connector */
+ if (!aux->transfer)
+ return;
+
+ if (aux->is_remote)
+ schedule_work(&aux->cec.mst_set_edid_work);
+ else
+ drm_dp_cec_handle_set_edid(aux, edid);
+}
EXPORT_SYMBOL(drm_dp_cec_set_edid);
+static void drm_dp_cec_mst_set_edid_work(struct work_struct *work)
+{
+ struct drm_dp_aux *aux =
+ container_of(work, struct drm_dp_aux, cec.mst_set_edid_work);
+ struct drm_dp
[PATCH v3 2/4] drm_dp_mst_topology: use correct AUX channel
From: Hans Verkuil
For adapters behind an MST hub use the correct AUX channel.
Signed-off-by: Hans Verkuil
[sa...@chromium.org: rebased, removing redundant changes]
Signed-off-by: Sam McNally
---
(no changes since v1)
drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 15b6cc39a754..0d753201adbd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2255,6 +2255,9 @@ drm_dp_mst_topology_unlink_port(struct
drm_dp_mst_topology_mgr *mgr,
drm_dp_mst_topology_put_port(port);
}
+static ssize_t
+drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg);
+
static struct drm_dp_mst_port *
drm_dp_mst_add_port(struct drm_device *dev,
struct drm_dp_mst_topology_mgr *mgr,
@@ -2271,9 +2274,13 @@ drm_dp_mst_add_port(struct drm_device *dev,
port->port_num = port_number;
port->mgr = mgr;
port->aux.name = "DPMST";
+ mutex_init(&port->aux.hw_mutex);
+ mutex_init(&port->aux.cec.lock);
port->aux.dev = dev->dev;
port->aux.is_remote = true;
+ port->aux.transfer = drm_dp_mst_aux_transfer;
+
/* initialize the MST downstream port's AUX crc work queue */
drm_dp_remote_aux_init(&port->aux);
@@ -3503,6 +3510,35 @@ static int drm_dp_send_up_ack_reply(struct
drm_dp_mst_topology_mgr *mgr,
return 0;
}
+static ssize_t
+drm_dp_mst_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
+{
+ struct drm_dp_mst_port *port =
+ container_of(aux, struct drm_dp_mst_port, aux);
+ int ret;
+
+ switch (msg->request & ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ case DP_AUX_I2C_WRITE_STATUS_UPDATE:
+ ret = drm_dp_send_dpcd_write(port->mgr, port, msg->address,
+msg->size, msg->buffer);
+ break;
+
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ ret = drm_dp_send_dpcd_read(port->mgr, port, msg->address,
+ msg->size, msg->buffer);
+ break;
+
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
{
if (dp_link_bw == 0 || dp_link_count == 0)
--
2.28.0.681.g6f77f65b4e-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] drm_dp_mst_topology: export two functions
From: Hans Verkuil
These are required for the CEC MST support.
Signed-off-by: Hans Verkuil
Signed-off-by: Sam McNally
---
(no changes since v1)
drivers/gpu/drm/drm_dp_mst_topology.c | 6 ++
include/drm/drm_dp_mst_helper.h | 4
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 0d753201adbd..c783a2a1c114 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -62,8 +62,6 @@ struct drm_dp_pending_up_req {
static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
char *buf);
-static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
-
static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
int id,
struct drm_dp_payload *payload);
@@ -1864,7 +1862,7 @@ static void drm_dp_mst_topology_get_port(struct
drm_dp_mst_port *port)
* drm_dp_mst_topology_try_get_port()
* drm_dp_mst_topology_get_port()
*/
-static void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
+void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port)
{
topology_ref_history_lock(port->mgr);
@@ -1935,7 +1933,7 @@ drm_dp_mst_topology_get_port_validated_locked(struct
drm_dp_mst_branch *mstb,
return NULL;
}
-static struct drm_dp_mst_port *
+struct drm_dp_mst_port *
drm_dp_mst_topology_get_port_validated(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port)
{
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index c7c79e0ced18..d036222e0d64 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -754,6 +754,10 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port);
+struct drm_dp_mst_port *drm_dp_mst_topology_get_port_validated
+(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
+void drm_dp_mst_topology_put_port(struct drm_dp_mst_port *port);
+
struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
--
2.28.0.681.g6f77f65b4e-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/4] dt-bindings: display: panel-simple-dsi: add optional reset gpio
On Tue, 15 Sep 2020 14:19:10 +0200, Neil Armstrong wrote: > Simple DSI panels can also have a reset GPIO signal in addition/instead of an > enable GPIO signal. > > This adds an optional reset-gpios property. > > Signed-off-by: Neil Armstrong > --- > .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] dt-bindings: display: panel-simple-dsi: add TDO TL070WSH30 DSI panel bindings
On Tue, 15 Sep 2020 14:19:11 +0200, Neil Armstrong wrote: > This add the bindings for the 1024x600 TFT LCD TL070WSH30 DSI panel to > panel-simple-dsi. > > Signed-off-by: Neil Armstrong > --- > .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/4] dt-bindings: vendor-prefixes: Add Shanghai Top Display Optolelectronics vendor prefix
On Tue, 15 Sep 2020 14:19:09 +0200, Neil Armstrong wrote: > Shanghai Top Display Optolelectronics Co., Ltd is a display manufacturer > from Shanghai. > Web site of the company: http://www.shtdo.com/ > > Signed-off-by: Neil Armstrong > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/23] device-dax: Support sub-dividing soft-reserved ranges
On Tue, Sep 8, 2020 at 3:46 AM David Hildenbrand wrote: > > On 22.08.20 01:21, Andrew Morton wrote: > > On Wed, 19 Aug 2020 18:53:57 -0700 Dan Williams > > wrote: > > > >>> I think I am missing some important pieces. Bear with me. > >> > >> No worries, also bear with me, I'm going to be offline intermittently > >> until at least mid-September. Hopefully Joao and/or Vishal can jump in > >> on this discussion. > > > > Ordinarily I'd prefer a refresh&resend for 2+ week-old series such as > > this. > > > > But given that v4 all applies OK and that Dan has pending outages, I'll > > scoop up this version, even though at least one change has been suggested. > > > > Should I try to fix patch #11 while Dan is away? Because I think at > least two things in there are wrong (and it would have been better to > split that patch into reviewable pieces). Hey David, Back now, I'll take a look. I didn't immediately see a way to meaningfully break up that patch without some dead-code steps in the conversion, but I'll take another run at it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch RFC 06/15] csky/mm/highmem: Switch to generic kmap atomic
Acked-by: Guo Ren
On Sat, Sep 19, 2020 at 5:50 PM Thomas Gleixner wrote:
>
> Signed-off-by: Thomas Gleixner
> Cc: Guo Ren
> Cc: linux-c...@vger.kernel.org
> ---
> Note: Completely untested
> ---
> arch/csky/Kconfig |1
> arch/csky/include/asm/highmem.h |4 +-
> arch/csky/mm/highmem.c | 75
>
> 3 files changed, 5 insertions(+), 75 deletions(-)
>
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -285,6 +285,7 @@ config NR_CPUS
> config HIGHMEM
> bool "High Memory Support"
> depends on !CPU_CK610
> + select KMAP_ATOMIC_GENERIC
> default y
>
> config FORCE_MAX_ZONEORDER
> --- a/arch/csky/include/asm/highmem.h
> +++ b/arch/csky/include/asm/highmem.h
> @@ -32,10 +32,12 @@ extern pte_t *pkmap_page_table;
>
> #define ARCH_HAS_KMAP_FLUSH_TLB
> extern void kmap_flush_tlb(unsigned long addr);
> -extern void *kmap_atomic_pfn(unsigned long pfn);
>
> #define flush_cache_kmaps() do {} while (0)
>
> +#define arch_kmap_temp_post_map(vaddr, pteval) kmap_flush_tlb(vaddr)
> +#define arch_kmap_temp_post_unmap(vaddr) kmap_flush_tlb(vaddr)
> +
> extern void kmap_init(void);
>
> #endif /* __KERNEL__ */
> --- a/arch/csky/mm/highmem.c
> +++ b/arch/csky/mm/highmem.c
> @@ -9,8 +9,6 @@
> #include
> #include
>
> -static pte_t *kmap_pte;
> -
> unsigned long highstart_pfn, highend_pfn;
>
> void kmap_flush_tlb(unsigned long addr)
> @@ -19,67 +17,7 @@ void kmap_flush_tlb(unsigned long addr)
> }
> EXPORT_SYMBOL(kmap_flush_tlb);
>
> -void *kmap_atomic_high_prot(struct page *page, pgprot_t prot)
> -{
> - unsigned long vaddr;
> - int idx, type;
> -
> - type = kmap_atomic_idx_push();
> - idx = type + KM_TYPE_NR*smp_processor_id();
> - vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> -#ifdef CONFIG_DEBUG_HIGHMEM
> - BUG_ON(!pte_none(*(kmap_pte - idx)));
> -#endif
> - set_pte(kmap_pte-idx, mk_pte(page, prot));
> - flush_tlb_one((unsigned long)vaddr);
> -
> - return (void *)vaddr;
> -}
> -EXPORT_SYMBOL(kmap_atomic_high_prot);
> -
> -void kunmap_atomic_high(void *kvaddr)
> -{
> - unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
> - int idx;
> -
> - if (vaddr < FIXADDR_START)
> - return;
> -
> -#ifdef CONFIG_DEBUG_HIGHMEM
> - idx = KM_TYPE_NR*smp_processor_id() + kmap_atomic_idx();
> -
> - BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
> -
> - pte_clear(&init_mm, vaddr, kmap_pte - idx);
> - flush_tlb_one(vaddr);
> -#else
> - (void) idx; /* to kill a warning */
> -#endif
> - kmap_atomic_idx_pop();
> -}
> -EXPORT_SYMBOL(kunmap_atomic_high);
> -
> -/*
> - * This is the same as kmap_atomic() but can map memory that doesn't
> - * have a struct page associated with it.
> - */
> -void *kmap_atomic_pfn(unsigned long pfn)
> -{
> - unsigned long vaddr;
> - int idx, type;
> -
> - pagefault_disable();
> -
> - type = kmap_atomic_idx_push();
> - idx = type + KM_TYPE_NR*smp_processor_id();
> - vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> - set_pte(kmap_pte-idx, pfn_pte(pfn, PAGE_KERNEL));
> - flush_tlb_one(vaddr);
> -
> - return (void *) vaddr;
> -}
> -
> -static void __init kmap_pages_init(void)
> +void __init kmap_init(void)
> {
> unsigned long vaddr;
> pgd_t *pgd;
> @@ -96,14 +34,3 @@ static void __init kmap_pages_init(void)
> pte = pte_offset_kernel(pmd, vaddr);
> pkmap_page_table = pte;
> }
> -
> -void __init kmap_init(void)
> -{
> - unsigned long vaddr;
> -
> - kmap_pages_init();
> -
> - vaddr = __fix_to_virt(FIX_KMAP_BEGIN);
> -
> - kmap_pte = pte_offset_kernel((pmd_t *)pgd_offset_k(vaddr), vaddr);
> -}
>
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 471/482] drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1502:6: warning: no previous prototype for function 'amdgpu_ras_error_status_query'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 6fe4a372821db85834f5522d94d25139ff17e414
commit: 4484ea5dfcbb092d856aee77aee01b36ff76d389 [471/482] drm/amdgpu: update
athub interrupt harvesting handle
config: x86_64-randconfig-a014-20200922 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
6a6b06f5262bb96523eceef4a42fe8e60ae2a630)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 4484ea5dfcbb092d856aee77aee01b36ff76d389
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:906:5: warning: no previous
prototype for function 'amdgpu_ras_error_cure' [-Wmissing-prototypes]
int amdgpu_ras_error_cure(struct amdgpu_device *adev,
^
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:906:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
int amdgpu_ras_error_cure(struct amdgpu_device *adev,
^
static
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1502:6: warning: no previous
>> prototype for function 'amdgpu_ras_error_status_query' [-Wmissing-prototypes]
void amdgpu_ras_error_status_query(struct amdgpu_device *adev,
^
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1502:1: note: declare 'static' if
the function is not intended to be used outside of this translation unit
void amdgpu_ras_error_status_query(struct amdgpu_device *adev,
^
static
2 warnings generated.
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next
git checkout 4484ea5dfcbb092d856aee77aee01b36ff76d389
vim +/amdgpu_ras_error_status_query +1502
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
1500
1501 /* Parse RdRspStatus and WrRspStatus */
> 1502 void amdgpu_ras_error_status_query(struct amdgpu_device *adev,
1503 struct ras_query_if *info)
1504 {
1505 /*
1506 * Only two block need to query read/write
1507 * RspStatus at current state
1508 */
1509 switch (info->head.block) {
1510 case AMDGPU_RAS_BLOCK__GFX:
1511 if (adev->gfx.funcs->query_ras_error_status)
1512 adev->gfx.funcs->query_ras_error_status(adev);
1513 break;
1514 case AMDGPU_RAS_BLOCK__MMHUB:
1515 if (adev->mmhub.funcs->query_ras_error_status)
1516 adev->mmhub.funcs->query_ras_error_status(adev);
1517 break;
1518 default:
1519 break;
1520 }
1521 }
1522
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
Hi! Since I got dropped from the thread, many responses inline
On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> +Lyude
> I notice that Lyude email was somehow dropped from the thread.
> Lyude was the person who submitted the patch for Thinkpad and should
> know the OUI of the panel.
no need - currently because of some confusion that got caused by the Intel HDR
backlight interface being the only backlight interface that works properly on
a lot of panels (many panels will advertise both interfaces, but might only
work with the Intel one), we actually rely on a small allowlist of "approved"
panels for enabling DPCD backlight control.
…however, many of these panels are annoying and don't actually provide a
reliable enough OUID to use for quirk detection, which is why we had to add
EDID quirk detection as a temporary workaround for this. The current list of
panels lives in drm_dp_helper.c:
/*
* Some devices have unreliable OUIDs where they don't set the device ID
* correctly, and as a result we need to use the EDID for finding additional
* DP quirks in such cases.
*/
static const struct edid_quirk edid_quirk_list[] = {
/* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
* only supports DPCD backlight controls
*/
{ MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
/*
* Some Dell CML 2020 systems have panels support both AUX and PWM
* backlight control, and some only support AUX backlight control. All
* said panels start up in AUX mode by default, and we don't have any
* support for disabling HDR mode on these panels which would be
* required to switch to PWM backlight control mode (plus, I'm not
* even sure we want PWM backlight controls over DPCD backlight
* controls anyway...). Until we have a better way of detecting these,
* force DPCD backlight mode on all of them.
*/
{ MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
{ MFG(0x4c, 0x83), PROD_ID(0x47, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
};
Also note that I think just about every panel on that list supports the Intel
HDR backlight interface, so it's -possible- that the VESA interface could be
broken on these panels. But, that would be a lot of different panels from
different vendors to all be broken in the same way.
>
> On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski wrote:
> > Alrighty, I'll take everyone else's silence as tacit approval of
> > Ville's opinions. (I didn't receive any email bounces this time, so I
> > think my issue was transient.) I will start on inverting the quirk and
> > making the most-significant-alignment matter for these registers by
> > default.
> >
> > Who can help me gather a list of OUIs that we need to add to the
> > quirk? I can follow up with Puthikorn about the relevant Chromebooks,
> > but I don't know what other types of laptops are using this driver.
> >
> > Thanks for your time,
> > Kevin Chowski
> >
> >
> > On Fri, Sep 18, 2020 at 12:16 PM Puthikorn Voravootivat
> > wrote:
> > > I'll defer to Ville & Lyude.
> > >
> > > I dug up more on the bug report and found that both Thinkpad and
> > > Galaxy Chromebook use the same Samsung OLED.
> > > So my 2 vs 1 argument is actually not valid.
> > >
> > > On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski
> > > wrote:
> > > > Apologies once again, some of my emails were bouncing for some
> > > > addresses yesterday. Hopefully it was a temporary condition; I'll
> > > > continue trying to dig into it on my end if it happens again for this
> > > > email.
> > > >
> > > > Since there's evidence that some models want lsb and some (well, at
> > > > least one) want msb, my understanding is that we'll need a quirk one
> > > > way or the other (please correct if I'm mistaken). I unfortunately
> > > > don't have the ability to test anything other than the Pixelbook, so
> > > > if we decide the msb is the "right" way, then I will have to rely on
> > > > others to test (and find the OUI of) other models which require lsb.
> > > >
> > > > I am happy to make any changes requested, but I do not at all have
> > > > enough background here to make the decision on whether the msb
> > > > functionality deserves the quirk or if the lsb one does. How can I
> > > > help you all come to an agreement here?
> > > >
> > > > * It seems like Ville feels strongly about the msb being the correct
> > > > interpretation of the spec.
> > > > * It's unclear to me on which side of the fence Lyude falls, I
> > > > couldn't pick up a strong opinion in her clarifying question.
> > > > * Puthikorn seems to be on th
Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()
On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote: > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote: > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for > > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8? > > I don't think that display_info.bpc actually implies a minimum bpc, only a > maximum bpc iirc (Ville would know the answer to this one). The other thing to > note here is that we want to assume the lowest possible bpc here since we're > only concerned if the mode passed to ->mode_valid can be set under -any- > conditions (including those that require lowering the bpc beyond it's maximum > value), so we definitely do want to always use 6bpc here even once we get > support for optimizing the bpc based on the available display bandwidth. Yeah, display_info is the max bpc. But would an average monitor support 6bpc? And if it does, does the current link training code even try that when display_info.bpc != 6? -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()
On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> Can we use 6bpc on arbitrary DP monitors, or is there a capability for
> it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
I don't think that display_info.bpc actually implies a minimum bpc, only a
maximum bpc iirc (Ville would know the answer to this one). The other thing to
note here is that we want to assume the lowest possible bpc here since we're
only concerned if the mode passed to ->mode_valid can be set under -any-
conditions (including those that require lowering the bpc beyond it's maximum
value), so we definitely do want to always use 6bpc here even once we get
support for optimizing the bpc based on the available display bandwidth.
>
> On Tue, Sep 22, 2020 at 5:06 PM Lyude Paul wrote:
> > While I thought I had this correct (since it actually did reject modes
> > like I expected during testing), Ville Syrjala from Intel pointed out
> > that the logic here isn't correct. max_clock refers to the max symbol
> > rate supported by the encoder, so limiting clock to ds_clock using max()
> > doesn't make sense. Additionally, we want to check against 6bpc for the
> > time being since that's the minimum possible bpc here, not the reported
> > bpc from the connector. See:
> >
> > https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html
> >
> > For more info.
> >
> > So, let's rewrite this using Ville's advice.
> >
> > Signed-off-by: Lyude Paul
> > Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock
> > limits for mode validation")
> > Cc: Ville Syrjälä
> > Cc: Lyude Paul
> > Cc: Ben Skeggs
> > ---
> > drivers/gpu/drm/nouveau/nouveau_dp.c | 23 +--
> > 1 file changed, 13 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> > b/drivers/gpu/drm/nouveau/nouveau_dp.c
> > index 7b640e05bd4cd..24c81e423d349 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> > @@ -231,23 +231,26 @@ nv50_dp_mode_valid(struct drm_connector *connector,
> >const struct drm_display_mode *mode,
> >unsigned *out_clock)
> > {
> > - const unsigned min_clock = 25000;
> > - unsigned max_clock, ds_clock, clock;
> > + const unsigned int min_clock = 25000;
> > + unsigned int max_clock, ds_clock, clock;
> > + const u8 bpp = 18; /* 6 bpc */
> > enum drm_mode_status ret;
> >
> > if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp-
> > >caps.dp_interlace)
> > return MODE_NO_INTERLACE;
> >
> > max_clock = outp->dp.link_nr * outp->dp.link_bw;
> > - ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd,
> > - outp-
> > >dp.downstream_ports);
> > - if (ds_clock)
> > - max_clock = min(max_clock, ds_clock);
> > -
> > - clock = mode->clock * (connector->display_info.bpc * 3) / 10;
> > - ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
> > - &clock);
> > + clock = mode->clock * bpp / 8;
> > + if (clock > max_clock)
> > + return MODE_CLOCK_HIGH;
> > +
> > + ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd, outp-
> > >dp.downstream_ports);
> > + if (ds_clock && mode->clock > ds_clock)
> > + return MODE_CLOCK_HIGH;
> > +
> > + ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
> > &clock);
> > if (out_clock)
> > *out_clock = clock;
> > +
> > return ret;
> > }
> > --
> > 2.26.2
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL FOR v5.10 - v3] R-Car display drivers miscellaneous changes
On Tue, Sep 22, 2020 at 02:15:26PM +0300, Laurent Pinchart wrote: > Hi Dave and Daniel, > > Still because the original pull request hasn't been pulled yet, here's > an updated version that fixes one small issue. I had initially fixed it > in a separate patch to be merged in the fixes branch for v5.10, but > realized the offending commit wasn't in -next yet. > > Is there still time to get this merged in v5.10 ? The originally pull > request was sent two weeks ago and seems to have fallen through the > cracks. > > The following changes since commit 818280d5adf1d80e78f95821815148abe9407e14: > > Merge v5.9-rc5 into drm-next (2020-09-14 17:19:11 +0200) > > are available in the Git repository at: > > git://linuxtv.org/pinchartl/media.git Modelled after the "my dog ate my homework", something ate the tag name :-) It should read du-next-20200922 (which corresponds to the commit ID just below). > for you to fetch changes up to 2a32dbdc2c7db5463483fa01fb220fd1b770c6bc: > > drm: rcar-du: Put reference to VSP device (2020-09-22 14:10:05 +0300) > > > Biju Das (2): > dt-bindings: display: bridge: lvds-codec: Document power-supply property > drm/bridge: lvds-codec: Add support for regulator > > Kuninori Morimoto (4): > dt-bindings: display: renesas: du: Document the r8a77961 bindings > dt-bindings: display: renesas: dw-hdmi: Tidyup example compatible > dt-bindings: display: renesas: dw-hdmi: Add R8A77961 support > drm: rcar-du: Add r8a77961 support > > Lad Prabhakar (5): > dt-bindings: display: renesas,du: Document the r8a7742 bindings > drm: rcar-du: Add r8a7742 support > dt-bindings: display: renesas,lvds: Document r8a7742 bindings > drm: rcar-du: lvds: Add r8a7742 support > drm: rcar-du: Update description for DRM_RCAR_DW_HDMI Kconfig entry > > Laurent Pinchart (3): > drm: rcar-du: Fix pitch handling for fully planar YUV formats > drm: rcar-du: Fix crash when enabling a non-visible plane > drm: rcar-du: Put reference to VSP device > > Marian-Cristian Rotariu (5): > dt-bindings: display: renesas,du: Document r8a774e1 bindings > drm: rcar-du: Add support for R8A774E1 SoC > dt-bindings: display: renesas,lvds: Document r8a774e1 bindings > dt-bindings: display: renesas,dw-hdmi: Add r8a774e1 support > drm: rcar-du: lvds: Add support for R8A774E1 SoC > > Qian Cai (1): > drm: rcar-du: Make DRM_RCAR_WRITEBACK depends on DRM_RCAR_DU > > .../bindings/display/bridge/lvds-codec.yaml| 3 ++ > .../bindings/display/bridge/renesas,dw-hdmi.txt| 4 +- > .../bindings/display/bridge/renesas,lvds.yaml | 2 + > .../devicetree/bindings/display/renesas,du.txt | 6 +++ > drivers/gpu/drm/bridge/lvds-codec.c| 29 > drivers/gpu/drm/rcar-du/Kconfig| 5 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 37 ++- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 54 > +- > drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 + > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 14 +- > drivers/gpu/drm/rcar-du/rcar_lvds.c| 2 + > 11 files changed, 149 insertions(+), 8 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 05/38] drm: prime: use sgtable iterators in drm_prime_sg_to_page_addr_arrays()
Hi Marek,
On Tue, 22 Sep 2020, Marek Szyprowski wrote:
> External email: Use caution opening links or attachments
>
>
> Hi Alex,
>
> On 22.09.2020 01:15, Alex Goins wrote:
> > Tested-by: Alex Goins
> >
> > This change fixes a regression with drm_prime_sg_to_page_addr_arrays() and
> > AMDGPU in v5.9.
>
> Thanks for testing!
>
> > Commit 39913934 similarly revamped AMDGPU to use sgtable helper functions.
> > When
> > it changed from dma_map_sg_attrs() to dma_map_sgtable(), as a side effect it
> > started correctly updating sgt->nents to the return value of
> > dma_map_sg_attrs().
> > However, drm_prime_sg_to_page_addr_arrays() incorrectly uses sgt->nents to
> > iterate over pages, rather than sgt->orig_nents, resulting in it now
> > returning
> > the incorrect number of pages on AMDGPU.
> >
> > I had written a patch that changes drm_prime_sg_to_page_addr_arrays() to use
> > for_each_sgtable_sg() instead of for_each_sg(), iterating using
> > sgt->orig_nents:
> >
> > - for_each_sg(sgt->sgl, sg, sgt->nents, count) {
> > + for_each_sgtable_sg(sgt, sg, count) {
> >
> > This patch takes it further, but still has the effect of fixing the number
> > of
> > pages that drm_prime_sg_to_page_addr_arrays() returns. Something like this
> > should be included in v5.9 to prevent a regression with AMDGPU.
>
> Probably the easiest way to handle a fix for v5.9 would be to simply
> merge the latest version of this patch also to v5.9-rcX:
> https://lore.kernel.org/dri-devel/20200904131711.12950-3-m.szyprow...@samsung.com/
Tested-by: Alex Goins that version too.
>
> This way we would get it fixed and avoid possible conflict in the -next.
> Do you have any AMDGPU fixes for v5.9 in the queue? Maybe you can add that
> patch to the queue?
I don't have any more AMDGPU fixes, just want to ensure that this makes it in.
Thanks,
Alex
> Dave: would it be okay that way?
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()
Can we use 6bpc on arbitrary DP monitors, or is there a capability for
it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
On Tue, Sep 22, 2020 at 5:06 PM Lyude Paul wrote:
>
> While I thought I had this correct (since it actually did reject modes
> like I expected during testing), Ville Syrjala from Intel pointed out
> that the logic here isn't correct. max_clock refers to the max symbol
> rate supported by the encoder, so limiting clock to ds_clock using max()
> doesn't make sense. Additionally, we want to check against 6bpc for the
> time being since that's the minimum possible bpc here, not the reported
> bpc from the connector. See:
>
> https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html
>
> For more info.
>
> So, let's rewrite this using Ville's advice.
>
> Signed-off-by: Lyude Paul
> Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits
> for mode validation")
> Cc: Ville Syrjälä
> Cc: Lyude Paul
> Cc: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 7b640e05bd4cd..24c81e423d349 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -231,23 +231,26 @@ nv50_dp_mode_valid(struct drm_connector *connector,
>const struct drm_display_mode *mode,
>unsigned *out_clock)
> {
> - const unsigned min_clock = 25000;
> - unsigned max_clock, ds_clock, clock;
> + const unsigned int min_clock = 25000;
> + unsigned int max_clock, ds_clock, clock;
> + const u8 bpp = 18; /* 6 bpc */
> enum drm_mode_status ret;
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
> return MODE_NO_INTERLACE;
>
> max_clock = outp->dp.link_nr * outp->dp.link_bw;
> - ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd,
> - outp->dp.downstream_ports);
> - if (ds_clock)
> - max_clock = min(max_clock, ds_clock);
> -
> - clock = mode->clock * (connector->display_info.bpc * 3) / 10;
> - ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
> - &clock);
> + clock = mode->clock * bpp / 8;
> + if (clock > max_clock)
> + return MODE_CLOCK_HIGH;
> +
> + ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd,
> outp->dp.downstream_ports);
> + if (ds_clock && mode->clock > ds_clock)
> + return MODE_CLOCK_HIGH;
> +
> + ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
> &clock);
> if (out_clock)
> *out_clock = clock;
> +
> return ret;
> }
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()
While I thought I had this correct (since it actually did reject modes
like I expected during testing), Ville Syrjala from Intel pointed out
that the logic here isn't correct. max_clock refers to the max symbol
rate supported by the encoder, so limiting clock to ds_clock using max()
doesn't make sense. Additionally, we want to check against 6bpc for the
time being since that's the minimum possible bpc here, not the reported
bpc from the connector. See:
https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html
For more info.
So, let's rewrite this using Ville's advice.
Signed-off-by: Lyude Paul
Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits for
mode validation")
Cc: Ville Syrjälä
Cc: Lyude Paul
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 7b640e05bd4cd..24c81e423d349 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -231,23 +231,26 @@ nv50_dp_mode_valid(struct drm_connector *connector,
const struct drm_display_mode *mode,
unsigned *out_clock)
{
- const unsigned min_clock = 25000;
- unsigned max_clock, ds_clock, clock;
+ const unsigned int min_clock = 25000;
+ unsigned int max_clock, ds_clock, clock;
+ const u8 bpp = 18; /* 6 bpc */
enum drm_mode_status ret;
if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
return MODE_NO_INTERLACE;
max_clock = outp->dp.link_nr * outp->dp.link_bw;
- ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd,
- outp->dp.downstream_ports);
- if (ds_clock)
- max_clock = min(max_clock, ds_clock);
-
- clock = mode->clock * (connector->display_info.bpc * 3) / 10;
- ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
- &clock);
+ clock = mode->clock * bpp / 8;
+ if (clock > max_clock)
+ return MODE_CLOCK_HIGH;
+
+ ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd,
outp->dp.downstream_ports);
+ if (ds_clock && mode->clock > ds_clock)
+ return MODE_CLOCK_HIGH;
+
+ ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock, &clock);
if (out_clock)
*out_clock = clock;
+
return ret;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 471/482] drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1502:6: warning: no previous prototype for 'amdgpu_ras_error_status_query'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 6fe4a372821db85834f5522d94d25139ff17e414
commit: 4484ea5dfcbb092d856aee77aee01b36ff76d389 [471/482] drm/amdgpu: update
athub interrupt harvesting handle
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4484ea5dfcbb092d856aee77aee01b36ff76d389
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:906:5: warning: no previous
prototype for 'amdgpu_ras_error_cure' [-Wmissing-prototypes]
906 | int amdgpu_ras_error_cure(struct amdgpu_device *adev,
| ^
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1502:6: warning: no previous
>> prototype for 'amdgpu_ras_error_status_query' [-Wmissing-prototypes]
1502 | void amdgpu_ras_error_status_query(struct amdgpu_device *adev,
| ^
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:31:
drivers/gpu/drm/amd/amdgpu/amdgpu.h:197:19: warning: 'no_system_mem_limit'
defined but not used [-Wunused-const-variable=]
197 | static const bool no_system_mem_limit;
| ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:196:19: warning: 'debug_evictions'
defined but not used [-Wunused-const-variable=]
196 | static const bool debug_evictions; /* = false */
| ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:195:18: warning: 'sched_policy' defined
but not used [-Wunused-const-variable=]
195 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
| ^~~~
In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:67,
from drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:31:
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:76:32: warning:
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:75:32: warning:
'dc_fixpt_ln2' defined but not used [-Wunused-const-variable=]
75 | static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
|^~~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:74:32: warning:
'dc_fixpt_e' defined but not used [-Wunused-const-variable=]
74 | static const struct fixed31_32 dc_fixpt_e = { 11674931555LL };
|^~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:73:32: warning:
'dc_fixpt_two_pi' defined but not used [-Wunused-const-variable=]
73 | static const struct fixed31_32 dc_fixpt_two_pi = { 26986075409LL };
|^~~
drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:72:32: warning:
'dc_fixpt_pi' defined but not used [-Wunused-const-variable=]
72 | static const struct fixed31_32 dc_fixpt_pi = { 13493037705LL };
|^~~
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next
git checkout 4484ea5dfcbb092d856aee77aee01b36ff76d389
vim +/amdgpu_ras_error_status_query +1502
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
1500
1501 /* Parse RdRspStatus and WrRspStatus */
> 1502 void amdgpu_ras_error_status_query(struct amdgpu_device *adev,
1503 struct ras_query_if *info)
1504 {
1505 /*
1506 * Only two block need to query read/write
1507 * RspStatus at current state
1508 */
1509 switch (info->head.block) {
1510 case AMDGPU_RAS_BLOCK__GFX:
1511 if (adev->gfx.funcs->query_ras_error_status)
1512 adev->gfx.funcs->query_ras_error_status(adev);
1513 break;
1514 case AMDGPU_RAS_BLOCK__MMHUB:
1515 if (adev->mmhub.funcs->query_ras_error_status)
1516 adev->mmhub.funcs->query_ras_error_status(adev);
1517 break;
1518 default:
1519
Re: [PATCH 1/3] drm: rockchip: hdmi: remove vop_crtc_mode_fixup to fix clock handling
Hi, On Tue, Sep 22, 2020 at 12:10 PM Vicente Bergas wrote: > > On Tuesday, September 22, 2020 5:26:17 PM CEST, Doug Anderson wrote: > > Hi, > > > > On Tue, Sep 22, 2020 at 7:52 AM Vicente Bergas wrote: > >> On Tue, Sep 22, 2020 at 4:28 PM Doug Anderson > >> wrote: ... > > > > Here's the code: > > > > rate = clk_round_rate(vop->dclk, adjusted_mode->clock * 1000 + 999); > > adjusted_mode->clock = DIV_ROUND_UP(rate, 1000); > > > > Input clock is in kHz and DRM always rounds down (last I checked--I > > guess you could confirm if this is still true). > > > > Imagine that you want an input clock of 99 kHz and the PLL can > > actually make this. > > > > DRM will request a clock of 999 kHz because it always rounds down. > > > > First: > > rate = 999 * 1000 + 999 = 99 Hz > > > > Now we'll ask the clock framework if it can make this. It can, so > > clk_round_rate() will return 99 kHz. Note that, at least on all > > Rockchip platforms I looked at in the past, clk_round_rate() and > > clk_set_rate() always round down. Thus, if we _hadn't_ added the 999 > > here we would not have gotten back 99 Hz. > > > > We have to return a rate in terms of kHz. While we could round down > > like DRM does, it seemed better at the time to do the rounding here. > > Thus, I now rounded up. We should end up storing > > > > (99 + 999) / 1000 = 1000 kHz > > > > Then, when we use it in vop_crtc_atomic_enable() we don't have to do > > any more rounding. > > > > I guess it's possible that the problem is that the function is > > starting with an input where it knows that "adjusted_mode->clock" was > > rounded down and it ends with it rounded up. That shouldn't cause > > problems unless somehow the function is being called twice or someone > > else is making assumptions about the rounding. You could, > > potentially, change this to: > > > > adjusted_mode->clock = rate / 1000; > > > > ...and then in vop_crtc_atomic_enable() you add the "999" back in, like: > > > > clk_set_rate(vop->dclk, adjusted_mode->clock * 1000 + 999); > > > > That would make it more consistent / stable. Does it work for you? > > Hi Douglas, > > i've tested this as suggested: > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > @@ -1181,7 +1181,7 @@ > *this in the actual clk_set_rate(). > */ > rate = clk_round_rate(vop->dclk, adjusted_mode->clock * 1000 + 999); > - adjusted_mode->clock = DIV_ROUND_UP(rate, 1000); > + adjusted_mode->clock = rate / 1000; You'll also want to change the comment above. Specifically it says that we're storing the rounded up state. > return true; > } > @@ -1380,7 +1380,7 @@ > > VOP_REG_SET(vop, intr, line_flag_num[0], vact_end); > > - clk_set_rate(vop->dclk, adjusted_mode->clock * 1000); > + clk_set_rate(vop->dclk, adjusted_mode->clock * 1000 + 999); > > VOP_REG_SET(vop, common, standby, 0); > mutex_unlock(&vop->vop_lock); > and it also works fine. > Should i sent a V2 of this patch series including your approach? That would be good w/ me. -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] clk: bcm: rpi: Add register to control pixel bvb clk
Quoting Hoegeun Kwon (2020-08-31 21:07:56) > To use QHD or higher, we need to modify the pixel_bvb_clk value. So > add register to control this clock. > > Signed-off-by: Hoegeun Kwon > --- Applied to clk-next ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
Hi,
On Tue, 22 Sep 2020 at 19:18, Daniel Vetter wrote:
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + affected_crtc |= drm_crtc_mask(crtc);
> +
> + /*
> +* For commits that allow modesets drivers can add other CRTCs to the
> +* atomic commit, e.g. when they need to reallocate global resources.
> +* This can cause spurious EBUSY, which robs compositors of a very
> +* effective sanity check for their drawing loop. Therefor only allow
> +* this for modeset commits.
> +*
> +* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an
> output
> +* so compositors know what's going on.
> +*/
> + if (affected_crtc != requested_crtc) {
> + /* adding other CRTC is only allowed for modeset commits */
> + WARN_ON(!state->allow_modeset);
> + }
> +
Can we please add a DRM_DEBUG() here, regardless of the WARN_ON(), to
let people know what's happening?
With that, R-b me.
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
Hi, On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > I think we need a guarantee that this never happens if ALLOW_MODESET > > is always used in blocking mode, plus in future a cap we can use to > > detect that we won't be getting spurious EBUSY events. > > > > I really don't want to ever paper over this, because it's one of the > > clearest indications that userspace has its timing/signalling wrong. > > Ok so the hang-up last time around iirc was that I broke igt by making > a few things more synchronous. Let's hope I'm not also breaking stuff > with the WARN_ON ... > > New plan: > - make this patch here only document existing behaviour and enforce it > with the WARN_ON > - new uapi would be behind a flag or something, with userspace and > everything hanging off it. > > Thoughts? What do you mean by 'new uapi'? The proposal that the kernel communicates back which object IDs have been added to the state behind your back? That it's been made automatically blocking? Something else? Cheers, Daniel (the other one) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix Kernel-doc warnings introduced on next-20200921
On Tue, 22 Sep 2020 20:52:06 +0300 Ville Syrjälä wrote: > Mea culpa. My doc test build was foiled by the sphinx 2 vs. 3 > regression and I was too lazy to start downgrading things. > Any ETA for getting that fixed btw? There's a fix of sorts in docs-next (and thus linux-next) now, has been there for a few weeks. Really fixing that problem properly requires more time than anybody seems to have at the moment. jon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v7 2/4] drm/kmb: Add support for KeemBay Display
Hi Daniel,
Thank you for your review. Keem Bay is developed on kernel 5.45 (Yocto) and I
am working with the program to get a working 5.9 kernel for Keem Bay and will
test this driver when that becomes available.
Thanks,
Anitha
> -Original Message-
> From: Daniel Vetter
> Sent: Thursday, September 10, 2020 1:31 AM
> To: Chrisanthus, Anitha
> Cc: dri-devel@lists.freedesktop.org; Paauwe, Bob J
> ; Dea, Edmund J ;
> Vetter, Daniel
> Subject: Re: [PATCH v7 2/4] drm/kmb: Add support for KeemBay Display
>
> On Mon, Aug 31, 2020 at 01:02:50PM -0700, Anitha Chrisanthus wrote:
> > This is a basic KMS atomic modesetting display driver for KeemBay family
> of
> > SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge
> > driver at the connector level.
> >
> > Single CRTC with LCD controller->mipi DSI-> ADV bridge
> >
> > Only 1080p resolution and single plane is supported at this time.
> >
> > v2: moved extern to .h, removed license text
> > use drm_dev_init, upclassed dev_private, removed HAVE_IRQ.(Sam)
> >
> > v3: Squashed all 59 commits to one
> >
> > v4: review changes from Sam Ravnborg
> > renamed dev_p to kmb
> > moved clocks under kmb_clock, consolidated clk initializations
> > use drmm functions
> > use DRM_GEM_CMA_DRIVER_OPS_VMAP
> >
> > v5: corrected spellings
> > v6: corrected checkpatch warnings
> > v7: review changes Sam Ravnborg and Thomas Zimmerman
> > removed kmb_crtc.h kmb_crtc_cleanup (Thomas)
> > renamed mode_set, kmb_load, inlined unload (Thomas)
> > moved remaining logging to drm_*(Thomas)
> > re-orged driver initialization (Thomas)
> > moved plane_status to drm_private (Sam)
> > removed unnecessary logs and defines and ifdef codes (Sam)
> > call helper_check in plane_atomic_check (Sam)
> > renamed set to get for bpp and format functions(Sam)
> > use drm helper functions for reset, duplicate/destroy state instead
> > of kmb functions (Sam)
> > removed kmb_priv from kmb_plane and removed kmb_plane_state
> (Sam)
> >
> > Cc: Sam Ravnborg
> > Signed-off-by: Anitha Chrisanthus
> > Reviewed-by: Bob Paauwe
>
> Sam asked me to take a look at this too, looks reasonable overall. I've
> spotted a few small things plus a potential functional issue around
> vblank/event handling. I strongly recommend running the igt test suite
> over the driver to see whether it all works reasonably ok. See below for
> details.
>
> > ---
> > drivers/gpu/drm/kmb/kmb_crtc.c | 224 +
> > drivers/gpu/drm/kmb/kmb_drv.c | 676
>
> > drivers/gpu/drm/kmb/kmb_drv.h | 170 ++
> > drivers/gpu/drm/kmb/kmb_plane.c | 480
>
> > drivers/gpu/drm/kmb/kmb_plane.h | 110 +++
> > 5 files changed, 1660 insertions(+)
> > create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c
> > create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c
> > create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h
> > create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c
> > create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h
> >
> > diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c
> b/drivers/gpu/drm/kmb/kmb_crtc.c
> > new file mode 100644
> > index 000..a684331
> > --- /dev/null
> > +++ b/drivers/gpu/drm/kmb/kmb_crtc.c
> > @@ -0,0 +1,224 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (c) 2018-2020 Intel Corporation
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "kmb_drv.h"
> > +#include "kmb_dsi.h"
> > +#include "kmb_plane.h"
> > +#include "kmb_regs.h"
> > +
> > +struct kmb_crtc_timing {
> > + u32 vfront_porch;
> > + u32 vback_porch;
> > + u32 vsync_len;
> > + u32 hfront_porch;
> > + u32 hback_porch;
> > + u32 hsync_len;
> > +};
> > +
> > +static int kmb_crtc_enable_vblank(struct drm_crtc *crtc)
> > +{
> > + struct drm_device *dev = crtc->dev;
> > + struct kmb_drm_private *kmb = to_kmb(dev);
> > +
> > + /* Clear interrupt */
> > + kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
> > + /* Set which interval to generate vertical interrupt */
> > + kmb_write_lcd(kmb, LCD_VSTATUS_COMPARE,
> > + LCD_VSTATUS_COMPARE_VSYNC);
> > + /* Enable vertical interrupt */
> > + kmb_set_bitmask_lcd(kmb, LCD_INT_ENABLE,
> > + LCD_INT_VERT_COMP);
> > + return 0;
> > +}
> > +
> > +static void kmb_crtc_disable_vblank(struct drm_crtc *crtc)
> > +{
> > + struct drm_device *dev = crtc->dev;
> > + struct kmb_drm_private *kmb = to_kmb(dev);
> > +
> > + /* Clear interrupt */
> > + kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
> > + /* Disable vertical interrupt */
> > + kmb_clr_bitmask_lcd(kmb, LCD_INT_ENABLE,
> > + LCD_INT_VERT
[PATCH] drm: document and enforce rules around "spurious" EBUSY from atomic_commit
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the
ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because
of the additional commit inserted by the kernel without userspace's
knowledge
For blocking commits this isn't a problem, because everyone else will
just block until all the CRTC are reconfigured. Only thing userspace
can notice is the dropped frames without any reason for why frames got
dropped.
Consensus is that we need new uapi to handle this properly, but no one
has any idea what exactly the new uapi should look like. Since this
has been shipping for years already compositors need to deal no matter
what, so as a first step just try to enforce this across drivers
better with some checks.
v2: Add comments and a WARN_ON to enforce this only when allowed - we
don't want to silently convert page flips into blocking plane updates
just because the driver is buggy.
v3: Fix inverted WARN_ON (Pekka).
v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
rules for drivers.
References:
https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..ef106e7153a6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -281,6 +281,10 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
* needed. It will also grab the relevant CRTC lock to make sure that the state
* is consistent.
*
+ * WARNING: Drivers may only add new CRTC states to a @state if
+ * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
+ * not created by userspace through an IOCTL call.
+ *
* Returns:
*
* Either the allocated state or the error code encoded into the pointer. When
@@ -1262,10 +1266,15 @@ int drm_atomic_check_only(struct drm_atomic_state
*state)
struct drm_crtc_state *new_crtc_state;
struct drm_connector *conn;
struct drm_connector_state *conn_state;
+ unsigned requested_crtc = 0;
+ unsigned affected_crtc = 0;
int i, ret = 0;
DRM_DEBUG_ATOMIC("checking %p\n", state);
+ for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
+ requested_crtc |= drm_crtc_mask(crtc);
+
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
if (ret) {
@@ -1313,6 +1322,24 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
+ for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
+ affected_crtc |= drm_crtc_mask(crtc);
+
+ /*
+* For commits that allow modesets drivers can add other CRTCs to the
+* atomic commit, e.g. when they need to reallocate global resources.
+* This can cause spurious EBUSY, which robs compositors of a very
+* effective sanity check for their drawing loop. Therefor only allow
+* this for modeset commits.
+*
+* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
+* so compositors know what's going on.
+*/
+ if (affected_crtc != requested_crtc) {
+ /* adding other CRTC is only allowed for modeset commits */
+ WARN_ON(!state->allow_modeset);
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_atomic_check_only);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau/kms: Remove set but not used 'ret'
On Tue, 2020-09-22 at 17:25 +0800, Tian Tao wrote:
> This addresses the following gcc warning with "make W=1":
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_prepare’:
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1378:6: warning:
> variable ‘ret’ set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index b111fe2..d05c57c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1379,6 +1379,9 @@ nv50_mstm_prepare(struct nv50_mstm *mstm)
>
> NV_ATOMIC(drm, "%s: mstm prepare\n", mstm->outp->base.base.name);
> ret = drm_dp_update_payload_part1(&mstm->mgr);
> + if (ret) {
> +NV_ATOMIC(drm, "failed to update payload %d\n", ret);
> +}
Remove the braces around ret and this is:
Reviewed-by: Lyude Paul
>
> drm_for_each_encoder(encoder, mstm->outp->base.base.dev) {
> if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST) {
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4] drm/dp_mst: Retrieve extended DPCD caps for topology manager
One last change I realized we should do is print the name of the AUX adapter
in question. I don't mind just adding that myself before I push it though so
you don't need to send a respin.
Going to go push this to drm-misc-next, thanks!
On Tue, 2020-09-22 at 14:53 +0800, Koba Ko wrote:
> As per DP-1.3, First check DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT.
> If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 1,read the DP_DP13_DPCD_REV to
> get the faster capability.
> If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 0,read DP_DPCD_REV.
>
> Signed-off-by: Koba Ko
> Reviewed-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index e87542533640..63f8809b9aa4 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3686,9 +3686,9 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr *mgr, bool ms
> WARN_ON(mgr->mst_primary);
>
> /* get dpcd info */
> - ret = drm_dp_dpcd_read(mgr->aux, DP_DPCD_REV, mgr->dpcd,
> DP_RECEIVER_CAP_SIZE);
> - if (ret != DP_RECEIVER_CAP_SIZE) {
> - DRM_DEBUG_KMS("failed to read DPCD\n");
> + ret = drm_dp_read_dpcd_caps(mgr->aux, mgr->dpcd);
> + if (ret < 0) {
> + drm_dbg_kms(mgr->dev, "failed to read DPCD, ret %d\n",
> ret);
> goto out_unlock;
> }
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH 2/2] drm/dp: fix a kernel-doc issue at drm_edid.c
From: Mauro Carvalho Chehab
The name of the argument is different, causing those warnings:
./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or
member 'video_code' not described in 'drm_display_mode_from_cea_vic'
./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter
'vic' description in 'drm_display_mode_from_cea_vic'
Fixes: 7af655bce275 ("drm/dp: Add drm_dp_downstream_mode()")
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a82f37d44258..631125b46e04 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3741,7 +3741,7 @@ drm_add_cmdb_modes(struct drm_connector *connector, u8
svd)
/**
* drm_display_mode_from_cea_vic() - return a mode for CEA VIC
* @dev: DRM device
- * @vic: CEA VIC of the mode
+ * @video_code: CEA VIC of the mode
*
* Creates a new mode matching the specified CEA VIC.
*
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH 1/2] drm/dp: fix kernel-doc warnings at drm_dp_helper.c
From: Mauro Carvalho Chehab
As warned by kernel-doc:
./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or
member 'type' not described in 'drm_dp_downstream_is_type'
./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or
member 'dev' not described in 'drm_dp_downstream_mode'
Some function parameters weren't documented.
Fixes: 38784f6f8805 ("drm/dp: Add helpers to identify downstream facing port
types")
Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 90807a6b415c..478dd51f738d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -374,6 +374,10 @@ static bool is_edid_digital_input_dp(const struct edid
*edid)
* drm_dp_downstream_is_type() - is the downstream facing port of certain type?
* @dpcd: DisplayPort configuration data
* @port_cap: port capabilities
+ * @type: port type to be checked. Can be:
+ * %DP_DS_PORT_TYPE_DP, %DP_DS_PORT_TYPE_VGA, %DP_DS_PORT_TYPE_DVI,
+ * %DP_DS_PORT_TYPE_HDMI, %DP_DS_PORT_TYPE_NON_EDID,
+ * %DP_DS_PORT_TYPE_DP_DUALMODE or %DP_DS_PORT_TYPE_WIRELESS.
*
* Caveat: Only works with DPCD 1.1+ port caps.
*
@@ -870,6 +874,7 @@ EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
/**
* drm_dp_downstream_mode() - return a mode for downstream facing port
+ * @dev: DRM device
* @dpcd: DisplayPort configuration data
* @port_cap: port capabilities
*
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix Kernel-doc warnings introduced on next-20200921
On Tue, Sep 22, 2020 at 01:39:41PM -0400, Lyude Paul wrote: > For patches 2 and 3: > > Reviewed-by: Lyude Paul > > I'll go ahead and push these to drm-intel-next-queued (since drm-misc-next > doesn't have these patches in yet, and the commits these fix were originally > merged through drm-intel-next-queued anyway). thanks! Mea culpa. My doc test build was foiled by the sphinx 2 vs. 3 regression and I was too lazy to start downgrading things. Any ETA for getting that fixed btw? > > On Tue, 2020-09-22 at 13:22 +0200, Mauro Carvalho Chehab wrote: > > A few new warnings were added at linux-next. Address them, in order for us > > to keep zero warnings at the docs. > > > > The entire patchset fixing all kernel-doc warnings is at: > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=doc-fixes > > > > Mauro Carvalho Chehab (3): > > net: fix a new kernel-doc warning at dev.c > > drm/dp: fix kernel-doc warnings at drm_dp_helper.c > > drm/dp: fix a kernel-doc issue at drm_edid.c > > > > drivers/gpu/drm/drm_dp_helper.c | 5 + > > drivers/gpu/drm/drm_edid.c | 2 +- > > net/core/dev.c | 4 ++-- > > 3 files changed, 8 insertions(+), 3 deletions(-) > > > -- > Cheers, > Lyude Paul (she/her) > Software Engineer at Red Hat -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Fix Kernel-doc warnings introduced on next-20200921
For patches 2 and 3: Reviewed-by: Lyude Paul I'll go ahead and push these to drm-intel-next-queued (since drm-misc-next doesn't have these patches in yet, and the commits these fix were originally merged through drm-intel-next-queued anyway). thanks! On Tue, 2020-09-22 at 13:22 +0200, Mauro Carvalho Chehab wrote: > A few new warnings were added at linux-next. Address them, in order for us > to keep zero warnings at the docs. > > The entire patchset fixing all kernel-doc warnings is at: > https://git.linuxtv.org/mchehab/experimental.git/log/?h=doc-fixes > > Mauro Carvalho Chehab (3): > net: fix a new kernel-doc warning at dev.c > drm/dp: fix kernel-doc warnings at drm_dp_helper.c > drm/dp: fix a kernel-doc issue at drm_edid.c > > drivers/gpu/drm/drm_dp_helper.c | 5 + > drivers/gpu/drm/drm_edid.c | 2 +- > net/core/dev.c | 4 ++-- > 3 files changed, 8 insertions(+), 3 deletions(-) > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On 22/09/2020 17:33, Christoph Hellwig wrote:
On Tue, Sep 22, 2020 at 05:13:45PM +0100, Tvrtko Ursulin wrote:
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
Chris can comment how much he'd miss the 32 page stack shortcut.
I'd like to see a profile that claim that kmalloc matters in a
path that does a vmap and reads pages through the page cache.
Especially when the kmalloc saves doing another page cache lookup
on the free side.
Only reason I can come up with now is if mapping side is on a latency
sensitive path, while un-mapping is lazy/delayed so can be more costly.
Then fast map and extra cost on unmap may make sense.
It more applies to the other i915 patch, which implements a much more
used API, but whether or not we can demonstrate any difference in the
perf profiles I couldn't tell you without trying to collect some.
Is there something in vmap() preventing us from freeing the pages array
here? I can't spot anything that is holding on to the pointer. Or it was
just a sketch before you realized we could walk the vm_area?
Also, I may be totally misunderstanding something, but I think you need to
assign area->pages manually so shmem_unpin_map can access it below.
We need area->pages to hold the pages for the free side. That being
said the patch I posted is broken because it never assigned to that.
As said it was a sketch. This is the patch I just rebooted into on
my Laptop:
http://git.infradead.org/users/hch/misc.git/commitdiff/048522dfa26b6667adfb0371ff530dc263abe829
it needs extra prep patches from the series:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/alloc_vm_area
mapping_clear_unevictable(file->f_mapping);
- __shmem_unpin_map(file, ptr, shmem_npte(file));
+ for (i = 0; i < shmem_npages(file); i++)
+ put_page(area->pages[i]);
+ kvfree(area->pages);
+ vunmap(ptr);
Is the verdict from mm experts that we can't use vfree due __free_pages vs
put_page differences?
Switched to vfree now.
Could we get from ptes to pages, so that we don't have to keep the
area->pages array allocated for the duration of the pin?
We could do vmalloc_to_page, but that is fairly expensive (not as bad
as reading from the page cache..). Are you really worried about the
allocation?
Not so much given how we don't even use shmem_pin_map outside selftests.
If we start using it I expect it will be for tiny objects anyway. Only
if they end up being pinned for the lifetime of the driver, it may be a
pointless waste of memory compared to the downsides of vmalloc_to_page.
But we can revisit this particular edge case optimization if the need
arises.
I'll look at your other i915 patch tomorrow.
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On 22/09/2020 15:31, Christoph Hellwig wrote:
On Tue, Sep 22, 2020 at 09:23:59AM +0100, Tvrtko Ursulin wrote:
If I understood this sub-thread correctly, iterating and freeing the pages
via the vmapped ptes, so no need for a
shmem_read_mapping_page_gfp loop in shmem_unpin_map looks plausible to me.
I did not get the reference to kernel/dma/remap.c though,
What I mean is the code in dma_common_find_pages, which returns the
page array for freeing.
Got it.
and also not sure
how to do the error unwind path in shmem_pin_map at which point the
allocated vm area hasn't been fully populated yet. Hand-roll the loop
walking vm area struct in there?
Yes. What I originally did (re-created as I didn't save it) would be
something like this:
---
From 5605e77cda246df6dd7ded99ec22cb3f341ef5d5 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Wed, 16 Sep 2020 13:54:04 +0200
Subject: drm/i915: use vmap in shmem_pin_map
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap using a flag
if actually required).
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 81 +--
1 file changed, 27 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 43c7acbdc79dea..7ec6ba4c1065b2 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -49,80 +49,53 @@ struct file *shmem_create_from_object(struct
drm_i915_gem_object *obj)
return file;
}
-static size_t shmem_npte(struct file *file)
+static size_t shmem_npages(struct file *file)
{
return file->f_mapping->host->i_size >> PAGE_SHIFT;
}
-static void __shmem_unpin_map(struct file *file, void *ptr, size_t n_pte)
-{
- unsigned long pfn;
-
- vunmap(ptr);
-
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
-
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (!WARN_ON(IS_ERR(page))) {
- put_page(page);
- put_page(page);
- }
- }
-}
-
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
Chris can comment how much he'd miss the 32 page stack shortcut.
- struct vm_struct *area;
- unsigned long pfn;
-
- mem = stack;
- if (n_pte > ARRAY_SIZE(stack)) {
- mem = kvmalloc_array(n_pte, sizeof(*mem), GFP_KERNEL);
- if (!mem)
- return NULL;
- }
+ size_t n_pages = shmem_npages(file), i;
+ struct page **pages;
+ void *vaddr;
- area = alloc_vm_area(n_pte << PAGE_SHIFT, mem);
- if (!area) {
- if (mem != stack)
- kvfree(mem);
+ pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
+ if (!pages)
return NULL;
- }
-
- ptes = mem;
- for (pfn = 0; pfn < n_pte; pfn++) {
- struct page *page;
- page = shmem_read_mapping_page_gfp(file->f_mapping, pfn,
- GFP_KERNEL);
- if (IS_ERR(page))
+ for (i = 0; i < n_pages; i++) {
+ pages[i] = shmem_read_mapping_page_gfp(file->f_mapping, i,
+ GFP_KERNEL);
+ if (IS_ERR(pages[i]))
goto err_page;
-
- **ptes++ = mk_pte(page, PAGE_KERNEL);
}
- if (mem != stack)
- kvfree(mem);
-
+ vaddr = vmap(pages, n_pages, 0, PAGE_KERNEL);
+ if (!vaddr)
+ goto err_page;
mapping_set_unevictable(file->f_mapping);
- return area->addr;
-
+ return vaddr;
Is there something in vmap() preventing us from freeing the pages array
here? I can't spot anything that is holding on to the pointer. Or it was
just a sketch before you realized we could walk the vm_area?
Also, I may be totally misunderstanding something, but I think you need
to assign area->pages manually so shmem_unpin_map can access it below.
err_page:
- if (mem != stack)
- kvfree(mem);
-
- __shmem_unpin_map(file, area->addr, pfn);
+ while (--i >= 0)
+ put_page(pages[i]);
+ kvfree(pages);
return NULL;
}
void shmem_unpin_map(struct file *file, void *ptr)
{
+ struct vm_struct *area = find_vm_area(ptr);
+ size_t i = shmem_npages(file);
+
+ if (WARN_ON_ONCE(!area || !area->pages))
+ return;
+
mapping_clear_unevictable(file->f_mapping);
- __shmem_unpin_map(file, ptr,
Re: [PATCH 4/4] dt-bindings: phy: convert HDMI PHY binding to YAML schema
On Tue, 22 Sep 2020 15:55:08 +0800, Chunfeng Yun wrote: > Convert HDMI PHY binding to YAML schema mediatek,ufs-phy.yaml > > Signed-off-by: Chunfeng Yun > --- > .../display/mediatek/mediatek,hdmi.txt| 17 +--- > .../bindings/phy/mediatek,hdmi-phy.yaml | 90 +++ > 2 files changed, 91 insertions(+), 16 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.example.dt.yaml: example-0: hdmi-phy@10209100:reg:0: [0, 270569728, 0, 36] is too long From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml See https://patchwork.ozlabs.org/patch/1368816 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dt-bindings: phy: convert phy-mtk-ufs.txt to YAML schema
On Tue, 22 Sep 2020 15:55:07 +0800, Chunfeng Yun wrote: > Convert phy-mtk-ufs.txt to YAML schema mediatek,ufs-phy.yaml > > Signed-off-by: Chunfeng Yun > --- > .../bindings/phy/mediatek,ufs-phy.yaml| 64 +++ > .../devicetree/bindings/phy/phy-mtk-ufs.txt | 38 --- > 2 files changed, 64 insertions(+), 38 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml > delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,ufs-phy.example.dt.yaml: example-0: ufs-phy@11fa:reg:0: [0, 301596672, 0, 49152] is too long From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml See https://patchwork.ozlabs.org/patch/1368813 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: phy: convert phy-mtk-tphy.txt to YAML schema
On Tue, 22 Sep 2020 15:55:06 +0800, Chunfeng Yun wrote: > Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml > > Signed-off-by: Chunfeng Yun > --- > .../bindings/phy/mediatek,tphy.yaml | 260 ++ > .../devicetree/bindings/phy/phy-mtk-tphy.txt | 162 --- > 2 files changed, 260 insertions(+), 162 deletions(-) > create mode 100644 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml > delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.example.dt.yaml: t-phy@1129: usb-phy@11290800:clocks: [[4294967295, 15]] is too short From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.example.dt.yaml: t-phy@1129: usb-phy@11290800:clock-names: ['ref'] is too short From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.example.dt.yaml: t-phy@1129: usb-phy@11290900:clocks: [[4294967295]] is too short From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.example.dt.yaml: t-phy@1129: usb-phy@11290900:clock-names: ['ref'] is too short From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.example.dt.yaml: t-phy@1129: usb-phy@11291000:clocks: [[4294967295, 15]] is too short From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.example.dt.yaml: t-phy@1129: usb-phy@11291000:clock-names: ['ref'] is too short From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml See https://patchwork.ozlabs.org/patch/1368817 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote: > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad > > wrote: > > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > > I've noticed this isn't integrated/added. > > > > Defacto the uapi we have now is that userspace needs to ignore "spurious" > > EBUSY. > > This really, really, really, bites. > > I think we need a guarantee that this never happens if ALLOW_MODESET > is always used in blocking mode, plus in future a cap we can use to > detect that we won't be getting spurious EBUSY events. > > I really don't want to ever paper over this, because it's one of the > clearest indications that userspace has its timing/signalling wrong. Ok so the hang-up last time around iirc was that I broke igt by making a few things more synchronous. Let's hope I'm not also breaking stuff with the WARN_ON ... New plan: - make this patch here only document existing behaviour and enforce it with the WARN_ON - new uapi would be behind a flag or something, with userspace and everything hanging off it. Thoughts? Cheers, 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] gpu/drm/radeon: fix spellint typo in comments
Applied with subject typo fixed. Thanks! Alex On Tue, Sep 22, 2020 at 10:07 AM Ernst Sjöstrand wrote: > > There is a typo in your patch subject. ;-) > > Regards > //Ernst > > Den tis 22 sep. 2020 kl 15:11 skrev Wang Qing : >> >> Modify the comment typo: "definately" -> "definitely". >> >> Signed-off-by: Wang Qing >> --- >> drivers/gpu/drm/radeon/radeon_vm.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c >> b/drivers/gpu/drm/radeon/radeon_vm.c >> index f60fae0..3d6e2cd >> --- a/drivers/gpu/drm/radeon/radeon_vm.c >> +++ b/drivers/gpu/drm/radeon/radeon_vm.c >> @@ -188,7 +188,7 @@ struct radeon_fence *radeon_vm_grab_id(struct >> radeon_device *rdev, >> vm_id->last_id_use == rdev->vm_manager.active[vm_id->id]) >> return NULL; >> >> - /* we definately need to flush */ >> + /* we definitely need to flush */ >> vm_id->pd_gpu_addr = ~0ll; >> >> /* skip over VMID 0, since it is the system VM */ >> -- >> 2.7.4 >> >> ___ >> amd-gfx mailing list >> amd-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amd/display: optimize code runtime a bit
Applied. Thanks!
Alex
On Tue, Sep 22, 2020 at 3:52 AM Bernard Zhao wrote:
>
> In the function dal_ddc_service_query_ddc_data,
> get rid of dal_ddc_i2c_payloads_destroy, call
> dal_vector_destruct() directly.
> This change is to make the code run a bit fast.
>
> Signed-off-by: Bernard Zhao
> Changes since V1:
> *get rid of dal_ddc_i2c_payloads_destroy, call
> dal_vector_destruct() directly.
>
> Link for V1:
> *https://lore.kernel.org/patchwork/patch/1309014/
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
> index b984eecca58b..dec12de37642 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
> @@ -148,14 +148,6 @@ static uint32_t dal_ddc_i2c_payloads_get_count(struct
> i2c_payloads *p)
> return p->payloads.count;
> }
>
> -static void dal_ddc_i2c_payloads_destroy(struct i2c_payloads *p)
> -{
> - if (!p)
> - return;
> -
> - dal_vector_destruct(&p->payloads);
> -}
> -
> #define DDC_MIN(a, b) (((a) < (b)) ? (a) : (b))
>
> void dal_ddc_i2c_payloads_add(
> @@ -582,7 +574,7 @@ bool dal_ddc_service_query_ddc_data(
> ddc->link,
> &command);
>
> - dal_ddc_i2c_payloads_destroy(&payloads);
> + dal_vector_destruct(&payloads.payloads);
> }
>
> return success;
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd:fix typoes in comments
Applied. Thanks! Alex On Tue, Sep 22, 2020 at 9:11 AM Bernard Zhao wrote: > > Change the comment typo: "programm" -> "program". > > Signed-off-by: Bernard Zhao > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +- > drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 2 +- > drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 4 ++-- > 8 files changed, 14 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h > index 770025a5e500..7c46937c1c0e 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h > @@ -98,7 +98,7 @@ struct amdgpu_bo_list_entry; > #define AMDGPU_PTE_MTYPE_NV10(a) ((uint64_t)(a) << 48) > #define AMDGPU_PTE_MTYPE_NV10_MASK AMDGPU_PTE_MTYPE_NV10(7ULL) > > -/* How to programm VM fault handling */ > +/* How to program VM fault handling */ > #define AMDGPU_VM_FAULT_STOP_NEVER 0 > #define AMDGPU_VM_FAULT_STOP_FIRST 1 > #define AMDGPU_VM_FAULT_STOP_ALWAYS2 > diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c > b/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c > index 3cafba726587..b0c0c438fc93 100644 > --- a/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c > +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c > @@ -348,7 +348,7 @@ static int uvd_v4_2_start(struct amdgpu_device *adev) > /* Set the write pointer delay */ > WREG32(mmUVD_RBC_RB_WPTR_CNTL, 0); > > - /* programm the 4GB memory segment for rptr and ring buffer */ > + /* program the 4GB memory segment for rptr and ring buffer */ > WREG32(mmUVD_LMI_EXT40_ADDR, upper_32_bits(ring->gpu_addr) | >(0x7 << 16) | (0x1 << 31)); > > @@ -541,7 +541,7 @@ static void uvd_v4_2_mc_resume(struct amdgpu_device *adev) > uint64_t addr; > uint32_t size; > > - /* programm the VCPU memory controller bits 0-27 */ > + /* program the VCPU memory controller bits 0-27 */ > addr = (adev->uvd.inst->gpu_addr + AMDGPU_UVD_FIRMWARE_OFFSET) >> 3; > size = AMDGPU_UVD_FIRMWARE_SIZE(adev) >> 3; > WREG32(mmUVD_VCPU_CACHE_OFFSET0, addr); > diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c > b/drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c > index a566ff926e90..6e57001f6d0a 100644 > --- a/drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c > @@ -253,7 +253,7 @@ static void uvd_v5_0_mc_resume(struct amdgpu_device *adev) > uint64_t offset; > uint32_t size; > > - /* programm memory controller bits 0-27 */ > + /* program memory controller bits 0-27 */ > WREG32(mmUVD_LMI_VCPU_CACHE_64BIT_BAR_LOW, > lower_32_bits(adev->uvd.inst->gpu_addr)); > WREG32(mmUVD_LMI_VCPU_CACHE_64BIT_BAR_HIGH, > @@ -404,7 +404,7 @@ static int uvd_v5_0_start(struct amdgpu_device *adev) > /* set the wb address */ > WREG32(mmUVD_RBC_RB_RPTR_ADDR, (upper_32_bits(ring->gpu_addr) >> 2)); > > - /* programm the RB_BASE for ring buffer */ > + /* program the RB_BASE for ring buffer */ > WREG32(mmUVD_LMI_RBC_RB_64BIT_BAR_LOW, > lower_32_bits(ring->gpu_addr)); > WREG32(mmUVD_LMI_RBC_RB_64BIT_BAR_HIGH, > diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c > b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c > index 0a880bc101b8..d2d90fe5c6f8 100644 > --- a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c > @@ -583,7 +583,7 @@ static void uvd_v6_0_mc_resume(struct amdgpu_device *adev) > uint64_t offset; > uint32_t size; > > - /* programm memory controller bits 0-27 */ > + /* program memory controller bits 0-27 */ > WREG32(mmUVD_LMI_VCPU_CACHE_64BIT_BAR_LOW, > lower_32_bits(adev->uvd.inst->gpu_addr)); > WREG32(mmUVD_LMI_VCPU_CACHE_64BIT_BAR_HIGH, > @@ -825,7 +825,7 @@ static int uvd_v6_0_start(struct amdgpu_device *adev) > /* set the wb address */ > WREG32(mmUVD_RBC_RB_RPTR_ADDR, (upper_32_bits(ring->gpu_addr) >> 2)); > > - /* programm the RB_BASE for ring buffer */ > + /* program the RB_BASE for ring buffer */ > WREG32(mmUVD_LMI_RBC_RB_64BIT_BAR_LOW, > lower_32_bits(ring->gpu_addr)); > WREG32(mmUVD_LMI_RBC_RB_64BIT_BAR_HIGH, > diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c > b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c > index e07e3fae99b5..b44c8677ce8d 100644 > --- a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c > @@ -1073,7 +1073,7 @@ static int uvd_v7_0_start(struct amdgpu_device *adev) > WREG32_SOC15(UVD, k, mmUVD_RBC_RB_RPTR_ADDR, > (upper_3
Re: [PATCH] drm/radeon:fix typoes in comments
Applied. Thanks! Alex On Tue, Sep 22, 2020 at 9:11 AM Bernard Zhao wrote: > > Change the comment typo: "programm" -> "program". > > Signed-off-by: Bernard Zhao > --- > drivers/gpu/drm/radeon/uvd_v1_0.c | 4 ++-- > drivers/gpu/drm/radeon/uvd_v2_2.c | 2 +- > drivers/gpu/drm/radeon/uvd_v4_2.c | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/uvd_v1_0.c > b/drivers/gpu/drm/radeon/uvd_v1_0.c > index 800721153d51..58557c2263a7 100644 > --- a/drivers/gpu/drm/radeon/uvd_v1_0.c > +++ b/drivers/gpu/drm/radeon/uvd_v1_0.c > @@ -117,7 +117,7 @@ int uvd_v1_0_resume(struct radeon_device *rdev) > if (r) > return r; > > - /* programm the VCPU memory controller bits 0-27 */ > + /* program the VCPU memory controller bits 0-27 */ > addr = (rdev->uvd.gpu_addr >> 3) + 16; > size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size) >> 3; > WREG32(UVD_VCPU_CACHE_OFFSET0, addr); > @@ -360,7 +360,7 @@ int uvd_v1_0_start(struct radeon_device *rdev) > /* Set the write pointer delay */ > WREG32(UVD_RBC_RB_WPTR_CNTL, 0); > > - /* programm the 4GB memory segment for rptr and ring buffer */ > + /* program the 4GB memory segment for rptr and ring buffer */ > WREG32(UVD_LMI_EXT40_ADDR, upper_32_bits(ring->gpu_addr) | >(0x7 << 16) | (0x1 << 31)); > > diff --git a/drivers/gpu/drm/radeon/uvd_v2_2.c > b/drivers/gpu/drm/radeon/uvd_v2_2.c > index 23b18edda20e..6266167886d9 100644 > --- a/drivers/gpu/drm/radeon/uvd_v2_2.c > +++ b/drivers/gpu/drm/radeon/uvd_v2_2.c > @@ -109,7 +109,7 @@ int uvd_v2_2_resume(struct radeon_device *rdev) > if (r) > return r; > > - /* programm the VCPU memory controller bits 0-27 */ > + /* program the VCPU memory controller bits 0-27 */ > addr = rdev->uvd.gpu_addr >> 3; > size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 4) >> 3; > WREG32(UVD_VCPU_CACHE_OFFSET0, addr); > diff --git a/drivers/gpu/drm/radeon/uvd_v4_2.c > b/drivers/gpu/drm/radeon/uvd_v4_2.c > index dc54fa4aaea8..f9e97fa63674 100644 > --- a/drivers/gpu/drm/radeon/uvd_v4_2.c > +++ b/drivers/gpu/drm/radeon/uvd_v4_2.c > @@ -40,7 +40,7 @@ int uvd_v4_2_resume(struct radeon_device *rdev) > uint64_t addr; > uint32_t size; > > - /* programm the VCPU memory controller bits 0-27 */ > + /* program the VCPU memory controller bits 0-27 */ > > /* skip over the header of the new firmware format */ > if (rdev->uvd.fw_header_present) > -- > 2.28.0 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> > So if I understand this correctly, it sounds like that some Pixelbooks
> > boot up
> > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
> > panel actually having DPCD backlight controls enabled?
>
> It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
> backlight.enabled = false. By changing backlight.level = max,
> backlight.enabled is now set to true. This results in losing backlight
> control on boot (since the enable routine is no longer invoked).
>
Ahhh ok, I'm fine with that - review still stands :)
> Sean
>
> > If I'm understanding that correctly, then this patch looks good to me:
> >
> > Reviewed-by: Lyude Paul
> >
> > On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > DPCD control mode"), we fixed the brightness level when DPCD control was
> > > not active to max brightness. This is as good as we can guess since most
> > > backlights go on full when uncontrolled.
> > >
> > > However in doing so we changed the semantics of the initial
> > > 'backlight.enabled' value. At least on Pixelbooks, they were relying
> > > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> > > boot such that enabled would be false. This causes the device to be
> > > enabled when the brightness is set. Without this, brightness control
> > > doesn't work. So by changing brightness to max, we also flipped enabled
> > > to be true on boot.
> > >
> > > To fix this, make enabled a function of brightness and backlight control
> > > mechanism.
> > >
> > > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD
> > > control mode")
> > > Cc: Lyude Paul
> > > Cc: Jani Nikula
> > > Cc: Juha-Pekka Heikkila
> > > Cc: "Ville Syrjälä"
> > > Cc: Rodrigo Vivi
> > > Cc: Kevin Chowski >
> > > Signed-off-by: Sean Paul
> > > ---
> > > .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
> > > 1 file changed, 20 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index acbd7eb66cbe..036f504ac7db 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct intel_dp
> > > *intel_dp, bool enable)
> > > }
> > > }
> > >
> > > -/*
> > > - * Read the current backlight value from DPCD register(s) based
> > > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > - */
> > > -static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > *connector)
> > > +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> > > *connector)
> > > {
> > > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > - u8 read_val[2] = { 0x0 };
> > > u8 mode_reg;
> > > - u16 level = 0;
> > >
> > > if (drm_dp_dpcd_readb(&intel_dp->aux,
> > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> > > @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
> > > intel_connector *connector)
> > > drm_dbg_kms(&i915->drm,
> > > "Failed to read the DPCD register 0x%x\n",
> > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> > > - return 0;
> > > + return false;
> > > }
> > >
> > > + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> > > +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > > +}
> > > +
> > > +/*
> > > + * Read the current backlight value from DPCD register(s) based
> > > + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > + */
> > > +static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > *connector)
> > > +{
> > > + struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > + u8 read_val[2] = { 0x0 };
> > > + u16 level = 0;
> > > +
> > > /*
> > >* If we're not in DPCD control mode yet, the programmed
> > > brightness
> > >* value is meaningless and we should assume max brightness
> > >*/
> > > - if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
> > > - DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
> > > + if (!intel_dp_aux_backlight_dpcd_mode(connector))
> > > return connector->panel.backlight.max;
> > >
> > > if (drm_dp_dpcd_read(&intel_dp->aux,
> > > DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
> > > @@ -319,7 +327,8 @@ static int intel_dp_aux_setup_backlight(struct
> > > intel_connector *connector,
> > >
> > > panel->backlight.min = 0;
Re: [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
On 9/22/20 11:27 AM, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 11:24:20AM -0400, boris.ostrov...@oracle.com wrote:
>> On 9/22/20 10:58 AM, Christoph Hellwig wrote:
>>> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
This will end up incrementing area->ptes pointer. So perhaps something like
pte_t **ptes = area->ptes;
if (apply_to_page_range(&init_mm, (unsigned long)area->area->addr,
PAGE_SIZE * nr_frames, gnttab_apply, &ptes)) {
...
>>> Yeah. What do you think of this version?
>>
>> Oh yes, this is way better. This now can actually be read without trying to
>> mentally unwind triple pointers. (You probably want to initialize idx to
>> zero before calling apply_to_page_range(), I am not sure it's guaranteed to
>> be zero).
> Both instances are static variables, thus in .bss and initialized.
> So unless you insist I don't think we need a manual one.
Yes, you are right. (I thought perhaps this code could be called more than once
but no, it can't).
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] MAINTAINERS: add Dan Murphy as TP LP8xxx drivers maintainer
Milo Kim's email in TI bounces with permanent error (550: Invalid recipient). Last email from him on LKML was in 2017. Move Milo Kim to credits and add Dan Murphy from TI to look after: - TI LP855x backlight driver, - TI LP8727 charger driver, - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers. Cc: Dan Murphy Signed-off-by: Krzysztof Kozlowski --- Changes since v1: 1. Add Dan Murphy, do not remove the entries. --- CREDITS | 3 +++ MAINTAINERS | 6 +++--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/CREDITS b/CREDITS index 1df63cdf71df..46384b11f258 100644 --- a/CREDITS +++ b/CREDITS @@ -1910,6 +1910,9 @@ S: 660 Harvard Ave. #7 S: Santa Clara, CA 95051 S: USA +N: Milo Kim +D: TI LP855x, LP8727 and LP8788 drivers + N: Russell King E: r...@arm.linux.org.uk D: Linux/arm integrator, maintainer & hacker diff --git a/MAINTAINERS b/MAINTAINERS index 5b9621ca2b31..bcd2fdf0dbf2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17472,20 +17472,20 @@ F:sound/soc/codecs/isabelle* F: sound/soc/codecs/lm49453* TI LP855x BACKLIGHT DRIVER -M: Milo Kim +M: Dan Murphy S: Maintained F: Documentation/driver-api/backlight/lp855x-driver.rst F: drivers/video/backlight/lp855x_bl.c F: include/linux/platform_data/lp855x.h TI LP8727 CHARGER DRIVER -M: Milo Kim +M: Dan Murphy S: Maintained F: drivers/power/supply/lp8727_charger.c F: include/linux/platform_data/lp8727.h TI LP8788 MFD DRIVER -M: Milo Kim +M: Dan Murphy S: Maintained F: drivers/iio/adc/lp8788_adc.c F: drivers/leds/leds-lp8788.c -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: rockchip: hdmi: remove vop_crtc_mode_fixup to fix clock handling【请注意，邮件由linux-rockchip-bounces+andy.yan=rock-chips....@lists.infradead.org代发】
Hi,
On Tue, Sep 22, 2020 at 7:52 AM Vicente Bergas wrote:
>
> On Tue, Sep 22, 2020 at 4:28 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Sep 22, 2020 at 3:13 AM crj wrote:
> > >
> > > Hi, Douglas
> > >
> > > 在 2020/9/22 17:31, Vicente Bergas 写道:
> > > > On Tue, Sep 22, 2020 at 11:24 AM crj wrote:
> > > >> Hello Vicente,
> > > >>
> > > >> 在 2020/9/22 15:40, Andy Yan 写道:
> > > >>> Add our HDMI driver owner Algea to list.
> > > >>>
> > > >>> On 9/22/20 2:18 AM, Vicente Bergas wrote:
> > > Under certain conditions vop_crtc_mode_fixup rounds the clock
> > > >>
> > > >> May I ask under what conditions that the clock of HDMI will
> > > >>
> > > >> be changed to 148501000? In general, the description of clock
> > > >>
> > > >> in EDID will not be detailed below the thousands place.
> > > > There is no clock in the EDID with 1KHz resolution, the clock is
> > > > 14850 which has 500KHz resolution.
> > > > It is the function vop_crtc_mode_fixup that gets xxx and returns
> > > > xxx1000
> > >
> > > I checked the commit msg of commit 287422a95fe2 ("drm/rockchip: Round up
> > > _before_ giving to the clock framework").
> > >
> > > Round up hdmi clock is for some panels with special clocks. Are these
> > > panels clock can't be divided correctly common?
> >
> > I'm sorry, but I don't understand the question. Can you restate? I
> > think the commit message that you refer to is pretty thorough.
> > Specifically the problem is all around the fact that, internally, DRM
> > often refers to clocks in kHz. We end up with issues when converting
> > back and forth between numbers in kHz and in MHz. Since DRM always
> > rounds down when going to kHz we end up with problems.
> >
> > I'm curious how you're ending up with an error, though. How could
> > adding 999 to 14850 and then rounding down cause you to get
> > 148501000?
>
> The name of the macro is DIV_ROUND_UP, or is clk_round_rate who should
> round down?
Here's the code:
rate = clk_round_rate(vop->dclk, adjusted_mode->clock * 1000 + 999);
adjusted_mode->clock = DIV_ROUND_UP(rate, 1000);
Input clock is in kHz and DRM always rounds down (last I checked--I
guess you could confirm if this is still true).
Imagine that you want an input clock of 99 kHz and the PLL can
actually make this.
DRM will request a clock of 999 kHz because it always rounds down.
First:
rate = 999 * 1000 + 999 = 99 Hz
Now we'll ask the clock framework if it can make this. It can, so
clk_round_rate() will return 99 kHz. Note that, at least on all
Rockchip platforms I looked at in the past, clk_round_rate() and
clk_set_rate() always round down. Thus, if we _hadn't_ added the 999
here we would not have gotten back 99 Hz.
We have to return a rate in terms of kHz. While we could round down
like DRM does, it seemed better at the time to do the rounding here.
Thus, I now rounded up. We should end up storing
(99 + 999) / 1000 = 1000 kHz
Then, when we use it in vop_crtc_atomic_enable() we don't have to do
any more rounding.
I guess it's possible that the problem is that the function is
starting with an input where it knows that "adjusted_mode->clock" was
rounded down and it ends with it rounded up. That shouldn't cause
problems unless somehow the function is being called twice or someone
else is making assumptions about the rounding. You could,
potentially, change this to:
adjusted_mode->clock = rate / 1000;
...and then in vop_crtc_atomic_enable() you add the "999" back in, like:
clk_set_rate(vop->dclk, adjusted_mode->clock * 1000 + 999);
That would make it more consistent / stable. Does it work for you?
> > > 14850 to 148501000 which leads to the following error:
> > > dwhdmi-rockchip ff94.hdmi: PHY configuration failed (clock
> > > 148501000)
> > >
> > > The issue was found on RK3399 booting with u-boot. U-boot configures
> > > the
> > > display at 2560x1440 and then linux comes up with a black screen.
> > > A workaround was to un-plug and re-plug the HDMI display.
> > >
> > > Signed-off-by: Vicente Bergas
> > > Tested-by: Vicente Bergas
> > > ---
> > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 45
> > > -
> > > 1 file changed, 45 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > index c80f7d9fd13f..fe80da652994 100644
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > @@ -1142,50 +1142,6 @@ static void vop_crtc_disable_vblank(struct
> > > drm_crtc *crtc)
> > > spin_unlock_irqrestore(&vop->irq_lock, flags);
> > > }
> > > -static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
> > > -const struct drm_display_mode *mode,
> > > -struct drm_display_m
Re: [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc
On 9/22/20 10:58 AM, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
>> This will end up incrementing area->ptes pointer. So perhaps something like
>>
>>
>> pte_t **ptes = area->ptes;
>>
>> if (apply_to_page_range(&init_mm, (unsigned long)area->area->addr,
>> PAGE_SIZE * nr_frames, gnttab_apply, &ptes)) {
>>
>> ...
> Yeah. What do you think of this version?
Oh yes, this is way better. This now can actually be read without trying to
mentally unwind triple pointers. (You probably want to initialize idx to zero
before calling apply_to_page_range(), I am not sure it's guaranteed to be zero).
> I think it is a little
> cleaner and matches what xenbus does. At this point it probably should
> be split into a Xen and a alloc_vm_area removal patch, though.
Right.
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Simplify condition in try_disable_dsc
On Tue, Sep 22, 2020 at 3:47 AM Nathan Chancellor
wrote:
>
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:637:8:
> warning: logical not is only applied to the left hand side of this
> comparison [-Wlogical-not-parentheses]
> && !params[i].clock_force_enable ==
> DSC_CLK_FORCE_DEFAULT) {
>^ ~~
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:637:8:
> note: add parentheses after the '!' to evaluate the comparison first
> && !params[i].clock_force_enable ==
> DSC_CLK_FORCE_DEFAULT) {
>^
> (
> )
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:637:8:
> note: add parentheses around left hand side expression to silence this
> warning
> && !params[i].clock_force_enable ==
> DSC_CLK_FORCE_DEFAULT) {
>^
>()
> 1 warning generated.
>
> The expression "!a == 0" can be more simply written as "a", which makes
> it easier to reason about the logic and prevents the warning.
>
> Fixes: 0749ddeb7d6c ("drm/amd/display: Add DSC force disable to dsc_clock_en
> debugfs entry")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1158
> Signed-off-by: Nathan Chancellor
@Wentland, Harry or @Leo (Sunpeng) Li can you provide some guidance
on what the logic is supposed to be here?
Thanks,
Alex
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 9d7333a36fac..0852a24ee392 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -634,7 +634,7 @@ static void try_disable_dsc(struct drm_atomic_state
> *state,
> for (i = 0; i < count; i++) {
> if (vars[i].dsc_enabled
> && vars[i].bpp_x16 ==
> params[i].bw_range.max_target_bpp_x16
> - && !params[i].clock_force_enable ==
> DSC_CLK_FORCE_DEFAULT) {
> + && params[i].clock_force_enable) {
> kbps_increase[i] = params[i].bw_range.stream_kbps -
> params[i].bw_range.max_kbps;
> tried[i] = false;
> remaining_to_try += 1;
>
> base-commit: 6651cdf3bfeeaeb499db11668313666bf756579a
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ttm: stop dangerous caching attribute change
On Fri, Sep 18, 2020 at 11:01 AM Christian König
wrote:
>
> When we swapout/in a BO we try to change the caching
> attributes of the pages before/after doing the copy.
>
> On x86 this is done by calling set_pages_uc(),
> set_memory_wc() or set_pages_wb() for not highmem pages
> to update the linear mapping of the page.
>
> On all other platforms we do exactly nothing.
>
> Now on x86 this is unnecessary because copy_highpage() will
> either create a temporary mapping of the page which is wb
> anyway and destroyed immediately again or use the linear
> mapping with the correct caching attributes.
>
> So stop this nonsense and just keep the caching as it is and
> return an error when a driver tries to change the caching of
> an already populated TT object.
>
> This is much more defensive since changing caching
> attributes is platform and driver specific and usually
> doesn't work after the page was initially allocated.
>
> Signed-off-by: Christian König
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 5 +--
> drivers/gpu/drm/ttm/ttm_tt.c | 71 ++--
> include/drm/ttm/ttm_set_memory.h | 22 --
> 3 files changed, 5 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 1441bc86ac1c..1fa8d87c13ce 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1555,14 +1555,13 @@ int ttm_bo_swapout(struct ttm_bo_global *glob, struct
> ttm_operation_ctx *ctx)
> * Move to system cached
> */
>
> - if (bo->mem.mem_type != TTM_PL_SYSTEM ||
> - bo->ttm->caching_state != tt_cached) {
> + if (bo->mem.mem_type != TTM_PL_SYSTEM) {
> struct ttm_operation_ctx ctx = { false, false };
> struct ttm_resource evict_mem;
>
> evict_mem = bo->mem;
> evict_mem.mm_node = NULL;
> - evict_mem.placement = TTM_PL_FLAG_CACHED;
> + evict_mem.placement = TTM_PL_MASK_CACHING;
> evict_mem.mem_type = TTM_PL_SYSTEM;
>
> ret = ttm_bo_handle_move_mem(bo, &evict_mem, true, &ctx);
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 014fb3656407..7c278216a188 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -38,7 +38,6 @@
> #include
> #include
> #include
> -#include
>
> /**
> * Allocates a ttm structure for the given BO.
> @@ -115,81 +114,19 @@ static int ttm_sg_tt_alloc_page_directory(struct
> ttm_dma_tt *ttm)
> return 0;
> }
>
> -static int ttm_tt_set_page_caching(struct page *p,
> - enum ttm_caching_state c_old,
> - enum ttm_caching_state c_new)
> -{
> - int ret = 0;
> -
> - if (PageHighMem(p))
> - return 0;
> -
> - if (c_old != tt_cached) {
> - /* p isn't in the default caching state, set it to
> -* writeback first to free its current memtype. */
> -
> - ret = ttm_set_pages_wb(p, 1);
> - if (ret)
> - return ret;
> - }
> -
> - if (c_new == tt_wc)
> - ret = ttm_set_pages_wc(p, 1);
> - else if (c_new == tt_uncached)
> - ret = ttm_set_pages_uc(p, 1);
> -
> - return ret;
> -}
> -
> -/*
> - * Change caching policy for the linear kernel map
> - * for range of pages in a ttm.
> - */
> -
> static int ttm_tt_set_caching(struct ttm_tt *ttm,
> enum ttm_caching_state c_state)
> {
> - int i, j;
> - struct page *cur_page;
> - int ret;
> -
> if (ttm->caching_state == c_state)
> return 0;
>
> - if (!ttm_tt_is_populated(ttm)) {
> - /* Change caching but don't populate */
> - ttm->caching_state = c_state;
> - return 0;
> - }
> -
> - if (ttm->caching_state == tt_cached)
> - drm_clflush_pages(ttm->pages, ttm->num_pages);
> -
> - for (i = 0; i < ttm->num_pages; ++i) {
> - cur_page = ttm->pages[i];
> - if (likely(cur_page != NULL)) {
> - ret = ttm_tt_set_page_caching(cur_page,
> - ttm->caching_state,
> - c_state);
> - if (unlikely(ret != 0))
> - goto out_err;
> - }
> - }
> + /* Can't change the caching state after TT is populated */
> + if (WARN_ON_ONCE(ttm_tt_is_populated(ttm)))
> + return -EINVAL;
>
> ttm->caching_state = c_state;
>
> return 0;
> -
> -out_err:
> - for (j = 0; j < i; ++j) {
> - cur_page = ttm->pages[j];
> - if (likely(cur_page != NULL)) {
> - (void)t
[PATCH 1/3] drm/vram-helper: Integrate drm_gem_vram_init() into drm_gem_vram_create()
The drm_gem_vram_create() function is the only caller of the internal
helper drm_gem_vram_init(). Streamline the code by putting all code into
the create function.
v2:
* rebased onto latest drm-tip
* fixed typo in commit message (Sam)
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_vram_helper.c | 77 ++-
1 file changed, 29 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 375c79e23ca5..9fa7f0ec9308 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -167,52 +167,6 @@ static void drm_gem_vram_placement(struct
drm_gem_vram_object *gbo,
}
}
-/*
- * Note that on error, drm_gem_vram_init will free the buffer object.
- */
-
-static int drm_gem_vram_init(struct drm_device *dev,
-struct drm_gem_vram_object *gbo,
-size_t size, unsigned long pg_align)
-{
- struct drm_vram_mm *vmm = dev->vram_mm;
- struct ttm_bo_device *bdev;
- int ret;
- size_t acc_size;
-
- if (WARN_ONCE(!vmm, "VRAM MM not initialized")) {
- kfree(gbo);
- return -EINVAL;
- }
- bdev = &vmm->bdev;
-
- gbo->bo.base.funcs = &drm_gem_vram_object_funcs;
-
- ret = drm_gem_object_init(dev, &gbo->bo.base, size);
- if (ret) {
- kfree(gbo);
- return ret;
- }
-
- acc_size = ttm_bo_dma_acc_size(bdev, size, sizeof(*gbo));
-
- gbo->bo.bdev = bdev;
- drm_gem_vram_placement(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
- DRM_GEM_VRAM_PL_FLAG_SYSTEM);
-
- ret = ttm_bo_init(bdev, &gbo->bo, size, ttm_bo_type_device,
- &gbo->placement, pg_align, false, acc_size,
- NULL, NULL, ttm_buffer_object_destroy);
- if (ret)
- /*
-* A failing ttm_bo_init will call ttm_buffer_object_destroy
-* to release gbo->bo.base and kfree gbo.
-*/
- return ret;
-
- return 0;
-}
-
/**
* drm_gem_vram_create() - Creates a VRAM-backed GEM object
* @dev: the DRM device
@@ -228,7 +182,13 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
drm_device *dev,
unsigned long pg_align)
{
struct drm_gem_vram_object *gbo;
+ struct drm_vram_mm *vmm = dev->vram_mm;
+ struct ttm_bo_device *bdev;
int ret;
+ size_t acc_size;
+
+ if (WARN_ONCE(!vmm, "VRAM MM not initialized"))
+ return ERR_PTR(-EINVAL);
if (dev->driver->gem_create_object) {
struct drm_gem_object *gem =
@@ -242,8 +202,29 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
drm_device *dev,
return ERR_PTR(-ENOMEM);
}
- ret = drm_gem_vram_init(dev, gbo, size, pg_align);
- if (ret < 0)
+ gbo->bo.base.funcs = &drm_gem_vram_object_funcs;
+
+ ret = drm_gem_object_init(dev, &gbo->bo.base, size);
+ if (ret) {
+ kfree(gbo);
+ return ERR_PTR(ret);
+ }
+
+ bdev = &vmm->bdev;
+ acc_size = ttm_bo_dma_acc_size(bdev, size, sizeof(*gbo));
+
+ gbo->bo.bdev = bdev;
+ drm_gem_vram_placement(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
+ DRM_GEM_VRAM_PL_FLAG_SYSTEM);
+
+ /*
+* A failing ttm_bo_init will call ttm_buffer_object_destroy
+* to release gbo->bo.base and kfree gbo.
+*/
+ ret = ttm_bo_init(bdev, &gbo->bo, size, ttm_bo_type_device,
+ &gbo->placement, pg_align, false, acc_size,
+ NULL, NULL, ttm_buffer_object_destroy);
+ if (ret)
return ERR_PTR(ret);
return gbo;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/vram-helper: Set object function iff they are not provided by driver
Don't override the GEM object functions unconditionally. If the driver
sets the GEM functions, VRAM helpers will not set them. The idea has been
taken from SHMEM helpers.
v2:
* updated the commit message (Sam)
* document the new feature for drm_gem_vram_create()
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 9fa7f0ec9308..11315b9e8c03 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -173,6 +173,12 @@ static void drm_gem_vram_placement(struct
drm_gem_vram_object *gbo,
* @size: the buffer size in bytes
* @pg_align: the buffer's alignment in multiples of the page size
*
+ * GEM objects are allocated by calling struct drm_driver.gem_create_object,
+ * if set. Otherwise kzalloc() will be used. Drivers can set their own GEM
+ * object functions in struct drm_driver.gem_create_object. If no functions
+ * are set, the new GEM object will use the default functions from GEM VRAM
+ * helpers.
+ *
* Returns:
* A new instance of &struct drm_gem_vram_object on success, or
* an ERR_PTR()-encoded error code otherwise.
@@ -182,6 +188,7 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
drm_device *dev,
unsigned long pg_align)
{
struct drm_gem_vram_object *gbo;
+ struct drm_gem_object *gem;
struct drm_vram_mm *vmm = dev->vram_mm;
struct ttm_bo_device *bdev;
int ret;
@@ -191,8 +198,7 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
drm_device *dev,
return ERR_PTR(-EINVAL);
if (dev->driver->gem_create_object) {
- struct drm_gem_object *gem =
- dev->driver->gem_create_object(dev, size);
+ gem = dev->driver->gem_create_object(dev, size);
if (!gem)
return ERR_PTR(-ENOMEM);
gbo = drm_gem_vram_of_gem(gem);
@@ -200,11 +206,13 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct
drm_device *dev,
gbo = kzalloc(sizeof(*gbo), GFP_KERNEL);
if (!gbo)
return ERR_PTR(-ENOMEM);
+ gem = &gbo->bo.base;
}
- gbo->bo.base.funcs = &drm_gem_vram_object_funcs;
+ if (!gem->funcs)
+ gem->funcs = &drm_gem_vram_object_funcs;
- ret = drm_gem_object_init(dev, &gbo->bo.base, size);
+ ret = drm_gem_object_init(dev, gem, size);
if (ret) {
kfree(gbo);
return ERR_PTR(ret);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/vram-helper: Don't put new BOs into VRAM
Most drivers that use VRAM helpers have only a few MiB of framebuffer memory available. To reduce fragmentation, new BOs are now put into system memory by default. Only pin operations are allowed to move BOs into VRAM. v2: * rebased onto latest drm-tip Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_gem_vram_helper.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c index 11315b9e8c03..9d85790e0c07 100644 --- a/drivers/gpu/drm/drm_gem_vram_helper.c +++ b/drivers/gpu/drm/drm_gem_vram_helper.c @@ -222,8 +222,7 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct drm_device *dev, acc_size = ttm_bo_dma_acc_size(bdev, size, sizeof(*gbo)); gbo->bo.bdev = bdev; - drm_gem_vram_placement(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM | - DRM_GEM_VRAM_PL_FLAG_SYSTEM); + drm_gem_vram_placement(gbo, DRM_GEM_VRAM_PL_FLAG_SYSTEM); /* * A failing ttm_bo_init will call ttm_buffer_object_destroy -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/vram-helper: Various improvements
This is a collection of improvements for GEM VRAM helpers. The patches were part of other patchsets that didn't make it into upstream, but the changes are nevertheless useful. Thomas Zimmermann (3): drm/vram-helper: Integrate drm_gem_vram_init() into drm_gem_vram_create() drm/vram-helper: Set object function iff they are not provided by driver drm/vram-helper: Don't put new BOs into VRAM drivers/gpu/drm/drm_gem_vram_helper.c | 88 --- 1 file changed, 38 insertions(+), 50 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/msm: Leave inuse count intact on map failure
Leave the inuse count intact on map failure to keep the accounting
accurate.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/msm_gem_vma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
b/drivers/gpu/drm/msm/msm_gem_vma.c
index 80a8a26..f914ddb 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -88,8 +88,10 @@ msm_gem_map_vma(struct msm_gem_address_space *aspace,
ret = aspace->mmu->funcs->map(aspace->mmu, vma->iova, sgt,
size, prot);
- if (ret)
+ if (ret) {
vma->mapped = false;
+ vma->inuse--;
+ }
return ret;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/msm: Fix premature purging of BO
In the case where we have a back-to-back submission that shares the same
BO, this BO will be prematurely moved to inactive_list while retiring the
first submit. But it will be still part of the second submit which is
being processed by the GPU. Now, if the shrinker happens to be triggered at
this point, it will result in a premature purging of this BO.
To fix this, we need to refcount BO while doing submit and retire. Then,
it should be moved to inactive list when this refcount becomes 0.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
1. Keep Active List around
2. Put back the deleted WARN_ON
drivers/gpu/drm/msm/msm_drv.h | 5 ++---
drivers/gpu/drm/msm/msm_gem.c | 32
drivers/gpu/drm/msm/msm_gem.h | 4 +++-
drivers/gpu/drm/msm/msm_gpu.c | 11 +++
4 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 3193274..28e3c8d 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -309,9 +309,8 @@ void msm_gem_put_vaddr(struct drm_gem_object *obj);
int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv);
int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive);
-void msm_gem_move_to_active(struct drm_gem_object *obj,
- struct msm_gpu *gpu, bool exclusive, struct dma_fence *fence);
-void msm_gem_move_to_inactive(struct drm_gem_object *obj);
+void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu);
+void msm_gem_active_put(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t
*timeout);
int msm_gem_cpu_fini(struct drm_gem_object *obj);
void msm_gem_free_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 76a6c52..14e14ca 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -743,31 +743,31 @@ int msm_gem_sync_object(struct drm_gem_object *obj,
return 0;
}
-void msm_gem_move_to_active(struct drm_gem_object *obj,
- struct msm_gpu *gpu, bool exclusive, struct dma_fence *fence)
+void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED);
- msm_obj->gpu = gpu;
- if (exclusive)
- dma_resv_add_excl_fence(obj->resv, fence);
- else
- dma_resv_add_shared_fence(obj->resv, fence);
- list_del_init(&msm_obj->mm_list);
- list_add_tail(&msm_obj->mm_list, &gpu->active_list);
+
+ if (!atomic_fetch_inc(&msm_obj->active_count)) {
+ msm_obj->gpu = gpu;
+ list_del_init(&msm_obj->mm_list);
+ list_add_tail(&msm_obj->mm_list, &gpu->active_list);
+ }
}
-void msm_gem_move_to_inactive(struct drm_gem_object *obj)
+void msm_gem_active_put(struct drm_gem_object *obj)
{
- struct drm_device *dev = obj->dev;
- struct msm_drm_private *priv = dev->dev_private;
struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ struct msm_drm_private *priv = obj->dev->dev_private;
- WARN_ON(!mutex_is_locked(&dev->struct_mutex));
+ WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
- msm_obj->gpu = NULL;
- list_del_init(&msm_obj->mm_list);
- list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
+ if (!atomic_dec_return(&msm_obj->active_count)) {
+ msm_obj->gpu = NULL;
+ list_del_init(&msm_obj->mm_list);
+ list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
+ }
}
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t *timeout)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 7b1c7a5..a1bf741 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -88,12 +88,14 @@ struct msm_gem_object {
struct mutex lock; /* Protects resources associated with bo */
char name[32]; /* Identifier to print for the debugfs files */
+
+ atomic_t active_count;
};
#define to_msm_bo(x) container_of(x, struct msm_gem_object, base)
static inline bool is_active(struct msm_gem_object *msm_obj)
{
- return msm_obj->gpu != NULL;
+ return atomic_read(&msm_obj->active_count);
}
static inline bool is_purgeable(struct msm_gem_object *msm_obj)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 29c8d73c..55d1648 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -698,8 +698,8 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
for (i = 0; i < submit->nr_bos; i++) {
struct msm_gem_object *msm_obj = submit->bos[i].obj;
- /
Re: [PATCH -next] dma-buf: heaps: Remove unused variable ret
Hello Zou,
On Tue, 22 Sep 2020 at 18:12, Christian König wrote:
>
> Am 22.09.20 um 09:53 schrieb Zou Wei:
> > This patch fixes below warnings reported by coccicheck
> >
> > ./drivers/dma-buf/heaps/heap-helpers.c:202:5-8: Unneeded variable: "ret".
> > Return "0" on line 215
> >
> > Signed-off-by: Zou Wei
>
> Acked-by: Christian König
>
> Going to pick this up for drm-misc-next.
Thanks Christian!
Fwiw, feel free to add my
Acked-by: Sumit Semwal
>
> > ---
> > drivers/dma-buf/heaps/heap-helpers.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma-buf/heaps/heap-helpers.c
> > b/drivers/dma-buf/heaps/heap-helpers.c
> > index d0696cf..7969510 100644
> > --- a/drivers/dma-buf/heaps/heap-helpers.c
> > +++ b/drivers/dma-buf/heaps/heap-helpers.c
> > @@ -199,7 +199,6 @@ static int dma_heap_dma_buf_begin_cpu_access(struct
> > dma_buf *dmabuf,
> > {
> > struct heap_helper_buffer *buffer = dmabuf->priv;
> > struct dma_heaps_attachment *a;
> > - int ret = 0;
> >
> > mutex_lock(&buffer->lock);
> >
> > @@ -212,7 +211,7 @@ static int dma_heap_dma_buf_begin_cpu_access(struct
> > dma_buf *dmabuf,
> > }
> > mutex_unlock(&buffer->lock);
> >
> > - return ret;
> > + return 0;
> > }
> >
> > static int dma_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: commit_work scheduling
On Mon, Sep 21, 2020 at 11:59 PM Daniel Vetter wrote:
>
> On Mon, Sep 21, 2020 at 5:16 PM Rob Clark wrote:
> >
> > On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote:
> > >
> > > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > The android userspace treats the display pipeline as a realtime problem.
> > > > And arguably, if your goal is to not miss frame deadlines (ie. vblank),
> > > > it is. (See https://lwn.net/Articles/809545/ for the best explaination
> > > > that I found.)
> > > >
> > > > But this presents a problem with using workqueues for non-blocking
> > > > atomic commit_work(), because the SCHED_FIFO userspace thread(s) can
> > > > preempt the worker. Which is not really the outcome you want.. once
> > > > the required fences are scheduled, you want to push the atomic commit
> > > > down to hw ASAP.
> > > >
> > > > But the decision of whether commit_work should be RT or not really
> > > > depends on what userspace is doing. For a pure CFS userspace display
> > > > pipeline, commit_work() should remain SCHED_NORMAL.
> > > >
> > > > To handle this, convert non-blocking commit_work() to use per-CRTC
> > > > kthread workers, instead of system_unbound_wq. Per-CRTC workers are
> > > > used to avoid serializing commits when userspace is using a per-CRTC
> > > > update loop.
> > > >
> > > > A client-cap is introduced so that userspace can opt-in to SCHED_FIFO
> > > > priority commit work.
> > > >
> > > > A potential issue is that since 616d91b68cd ("sched: Remove
> > > > sched_setscheduler*() EXPORTs") we have limited RT priority levels,
> > > > meaning that commit_work() ends up running at the same priority level
> > > > as vblank-work. This shouldn't be a big problem *yet*, due to limited
> > > > use of vblank-work at this point. And if it could be arranged that
> > > > vblank-work is scheduled before signaling out-fences and/or sending
> > > > pageflip events, it could probably work ok to use a single priority
> > > > level for both commit-work and vblank-work.
> > >
> > > The part I don't like about this is that it all feels rather hacked
> > > together, and if we add more stuff (or there's some different thing in the
> > > system that also needs rt scheduling) then it doesn't compose.
> >
> > The ideal thing would be that userspace is in control of the
> > priorities.. the setclientcap approach seemed like a reasonable way to
> > give the drm-master a way to opt in.
> >
> > I suppose instead userspace could use sched_setscheduler().. but that
> > would require userspace to be root, and would require some way to find
> > the tid.
>
> Userspace already needs that for the SCHED_FIFO for surface-flinger.
> Or is the problem that CAP_SYS_NICE is only good for your own
> processes?
tbh, I'm not completely sure offhand what gives surfaceflinger
permission to set itself SCHED_FIFO
(But on CrOS there are a few more pieces to the puzzle)
> Other question I have for this is whether there's any recommendations
> for naming the kthreads (since I guess that name is what becomes the
> uapi for userspace to control this)?
>
> Otherwise I think "userspace calls sched_setscheduler on the right
> kthreads" sounds like a good interface, since it lets userspace decide
> how it all needs to fit together and compose. Anything we hard-code in
> an ioctl is kinda lost cause. And we can choose the default values to
> work reasonably well when the compositor runs at normal priority
> (lowest niceness or something like that for the commit work).
I don't really like the naming convention approach.. what is to stop
some unrelated process to name it's thread the same thing to get a
SCHED_FIFO boost..
But we can stick with my idea to expose the thread id as a read-only
CRTC property, for userspace to find the things to call
sched_setscheduler() on. If for whatever reason the drm master is not
privileged (or is running in a sandbox, etc), a small helper that has
the necessary permissions could open the drm device to find the CRTC
thread-ids and call sched_setscheduler()..
BR,
-R
> -Daniel
>
> > Is there some way we could arrange for the per-crtc kthread's to be
> > owned by the drm master? That would solve the "must be root" issue.
> > And since the target audience is an atomic userspace, I suppose we
> > could expose the tid as a read-only property on the crtc?
> >
> > BR,
> > -R
> >
> > > So question to rt/worker folks: What's the best way to let userspace set
> > > the scheduling mode and priorities of things the kernel does on its
> > > behalf? Surely we're not the first ones where if userspace runs with some
> > > rt priority it'll starve out the kernel workers that it needs. Hardcoding
> > > something behind a subsystem ioctl (which just means every time userspace
> > > changes what it does, we need a new such flag or mode) can't be the right
> > > thing.
> > >
> > > Peter, Tejun?
> > >
> > > Thanks, Daniel
> > >
> > > >
> > > > Rob Clark (3):
> > > > dr
[PATCH] drm/ast: Reload gamma LUT after changing primary plane's color format
The gamma LUT has to be reloaded after changing the primary plane's
color format. This used to be done implicitly by the CRTC atomic_enable()
helper after updating the primary plane. With the recent reordering of
the steps, the primary plane's setup was moved last and invalidated
the gamma LUT. Fix this by setting the LUT from within atomic_flush().
Signed-off-by: Thomas Zimmermann
Fixes: 2f0ddd89fe32 ("drm/ast: Enable CRTC before planes")
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/ast/ast_mode.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 834a156e3a75..ba3bf76e104d 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -742,7 +742,6 @@ static void ast_crtc_dpms(struct drm_crtc *crtc, int mode)
case DRM_MODE_DPMS_SUSPEND:
if (ast->tx_chip_type == AST_TX_DP501)
ast_set_dp501_video_output(crtc->dev, 1);
- ast_crtc_load_lut(ast, crtc);
break;
case DRM_MODE_DPMS_OFF:
if (ast->tx_chip_type == AST_TX_DP501)
@@ -777,6 +776,17 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc
*crtc,
return 0;
}
+static void
+ast_crtc_helper_atomic_flush(struct drm_crtc *crtc, struct drm_crtc_state
*old_crtc_state)
+{
+ struct ast_private *ast = to_ast_private(crtc->dev);
+ struct ast_crtc_state *ast_crtc_state = to_ast_crtc_state(crtc->state);
+ struct ast_crtc_state *old_ast_crtc_state =
to_ast_crtc_state(old_crtc_state);
+
+ if (old_ast_crtc_state->format != ast_crtc_state->format)
+ ast_crtc_load_lut(ast, crtc);
+}
+
static void
ast_crtc_helper_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
@@ -830,6 +840,7 @@ ast_crtc_helper_atomic_disable(struct drm_crtc *crtc,
static const struct drm_crtc_helper_funcs ast_crtc_helper_funcs = {
.atomic_check = ast_crtc_helper_atomic_check,
+ .atomic_flush = ast_crtc_helper_atomic_flush,
.atomic_enable = ast_crtc_helper_atomic_enable,
.atomic_disable = ast_crtc_helper_atomic_disable,
};
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.4 13/15] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is
On Mon, Sep 21, 2020 at 04:48:05PM +0200, Michel Dänzer wrote: On 2020-09-21 4:40 p.m., Sasha Levin wrote: From: Michel Dänzer [ Upstream commit 2f228aab21bbc74e90e267a721215ec8be51daf7 ] Don't check drm_crtc_state::active for this either, per its documentation in include/drm/drm_crtc.h: * Hence drivers must not consult @active in their various * &drm_mode_config_funcs.atomic_check callback to reject an atomic * commit. atomic_remove_fb disables the CRTC as needed for disabling the primary plane. This prevents at least the following problems if the primary plane gets disabled (e.g. due to destroying the FB assigned to the primary plane, as happens e.g. with mutter in Wayland mode): * The legacy cursor ioctl returned EINVAL for a non-0 cursor FB ID (which enables the cursor plane). * If the cursor plane was enabled, changing the legacy DPMS property value from off to on returned EINVAL. v2: * Minor changes to code comment and commit log, per review feedback. GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1108 GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1165 GitLab: https://gitlab.gnome.org/GNOME/mutter/-/issues/1344 Suggested-by: Daniel Vetter Acked-by: Daniel Vetter Reviewed-by: Nicholas Kazlauskas Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin I'm a bit nervous about this getting backported so far back so quickly. I'd prefer waiting for 5.9 final first at least. Will drop it for now, thanks. -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: rockchip: hdmi: remove vop_crtc_mode_fixup to fix clock handling【请注意，邮件由linux-rockchip-bounces+andy.yan=rock-chips....@lists.infradead.org代发】
Hi,
On Tue, Sep 22, 2020 at 3:13 AM crj wrote:
>
> Hi, Douglas
>
> 在 2020/9/22 17:31, Vicente Bergas 写道:
> > On Tue, Sep 22, 2020 at 11:24 AM crj wrote:
> >> Hello Vicente,
> >>
> >> 在 2020/9/22 15:40, Andy Yan 写道:
> >>> Add our HDMI driver owner Algea to list.
> >>>
> >>> On 9/22/20 2:18 AM, Vicente Bergas wrote:
> Under certain conditions vop_crtc_mode_fixup rounds the clock
> >>
> >> May I ask under what conditions that the clock of HDMI will
> >>
> >> be changed to 148501000? In general, the description of clock
> >>
> >> in EDID will not be detailed below the thousands place.
> > There is no clock in the EDID with 1KHz resolution, the clock is
> > 14850 which has 500KHz resolution.
> > It is the function vop_crtc_mode_fixup that gets xxx and returns xxx1000
>
> I checked the commit msg of commit 287422a95fe2 ("drm/rockchip: Round up
> _before_ giving to the clock framework").
>
> Round up hdmi clock is for some panels with special clocks. Are these
> panels clock can't be divided correctly common?
I'm sorry, but I don't understand the question. Can you restate? I
think the commit message that you refer to is pretty thorough.
Specifically the problem is all around the fact that, internally, DRM
often refers to clocks in kHz. We end up with issues when converting
back and forth between numbers in kHz and in MHz. Since DRM always
rounds down when going to kHz we end up with problems.
I'm curious how you're ending up with an error, though. How could
adding 999 to 14850 and then rounding down cause you to get
148501000?
> 14850 to 148501000 which leads to the following error:
> dwhdmi-rockchip ff94.hdmi: PHY configuration failed (clock
> 148501000)
>
> The issue was found on RK3399 booting with u-boot. U-boot configures the
> display at 2560x1440 and then linux comes up with a black screen.
> A workaround was to un-plug and re-plug the HDMI display.
>
> Signed-off-by: Vicente Bergas
> Tested-by: Vicente Bergas
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 45 -
> 1 file changed, 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index c80f7d9fd13f..fe80da652994 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1142,50 +1142,6 @@ static void vop_crtc_disable_vblank(struct
> drm_crtc *crtc)
> spin_unlock_irqrestore(&vop->irq_lock, flags);
> }
> -static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
> -const struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted_mode)
> -{
> -struct vop *vop = to_vop(crtc);
> -unsigned long rate;
> -
> -/*
> - * Clock craziness.
> - *
> - * Key points:
> - *
> - * - DRM works in in kHz.
> - * - Clock framework works in Hz.
> - * - Rockchip's clock driver picks the clock rate that is the
> - * same _OR LOWER_ than the one requested.
> - *
> - * Action plan:
> - *
> - * 1. When DRM gives us a mode, we should add 999 Hz to it.
> That way
> - *if the clock we need is 6001 Hz (~60 MHz) and DRM
> tells us to
> - *make 6 kHz then the clock framework will actually give us
> - *the right clock.
> - *
> - *NOTE: if the PLL (maybe through a divider) could actually
> make
> - *a clock rate 999 Hz higher instead of the one we want then
> this
> - *could be a problem. Unfortunately there's not much we can do
> - *since it's baked into DRM to use kHz. It shouldn't matter in
> - *practice since Rockchip PLLs are controlled by tables and
> - *even if there is a divider in the middle I wouldn't expect
> PLL
> - *rates in the table that are just a few kHz different.
> - *
> - * 2. Get the clock framework to round the rate for us to tell us
> - *what it will actually make.
> - *
> - * 3. Store the rounded up rate so that we don't need to worry
> about
> - *this in the actual clk_set_rate().
> - */
> -rate = clk_round_rate(vop->dclk, adjusted_mode->clock * 1000 +
> 999);
> -adjusted_mode->clock = DIV_ROUND_UP(rate, 1000);
> -
> -return true;
> -}
> -
> static bool vop_dsp_lut_is_enabled(struct vop *vop)
> {
> return vop_read_reg(vop, 0, &vop->data->common->dsp_lut_en);
> @@ -1512,7 +1468,6 @@ static void vop_crtc_atomic_flush(struct
> drm_crtc *crtc,
> }
> static const struct drm_crtc_helper_funcs vop_crtc_h
[Bug 209345] [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80)
https://bugzilla.kernel.org/show_bug.cgi?id=209345 --- Comment #11 from Alexander von Gluck (kallis...@unixzen.com) --- weird... let me move things over to my Ryzen desktop and see what changes. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209345] [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80)
https://bugzilla.kernel.org/show_bug.cgi?id=209345 --- Comment #10 from Ilia Mirkin (imir...@alum.mit.edu) --- [ 176.562278] nouveau :08:00.0: bar: one-time init failed, -12 08:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1) Subsystem: NVIDIA Corporation Device 106c Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- (64-bit, prefetchable) Region 3: Memory at a000 (64-bit, prefetchable) [size=32M] That's not good. BAR1 is unassigned. We want BAR1. This is fallout from the TB enclosure. I know nothing about this stuff... there are various memory windows, etc. And apparently we don't fit in the window. I'm guessing there are errors further up about how there's not enough space to assign those BAR's. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/panfrost: Support cache-coherent integrations
When the GPU's ACE-Lite interface is fully wired up and capable of
snooping CPU caches, it may be described as "dma-coherent" in
devicetree, which will already inform the DMA layer not to perform
unnecessary cache maintenance. However, we still need to ensure that
the GPU uses the appropriate cacheable outer-shareable attributes in
order to generate the requisite snoop signals, and that CPU mappings
don't create a mismatch by using a non-cacheable type either.
Reviewed-by: Steven Price
Tested-by: Neil Armstrong
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost/panfrost_drv.c| 2 ++
drivers/gpu/drm/panfrost/panfrost_gem.c| 2 ++
drivers/gpu/drm/panfrost/panfrost_mmu.c| 1 +
4 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index c30c719a8059..b31f45315e96 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -84,6 +84,7 @@ struct panfrost_device {
/* pm_domains for devices with more than one. */
struct device *pm_domain_devs[MAX_PM_DOMAINS];
struct device_link *pm_domain_links[MAX_PM_DOMAINS];
+ bool coherent;
struct panfrost_features features;
const struct panfrost_compatible *comp;
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index ada51df9a7a3..2a6f2f716b2f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -588,6 +588,8 @@ static int panfrost_probe(struct platform_device *pdev)
if (!pfdev->comp)
return -ENODEV;
+ pfdev->coherent = device_get_dma_attr(&pdev->dev) == DEV_DMA_COHERENT;
+
/* Allocate and initialze the DRM device. */
ddev = drm_dev_alloc(&panfrost_drm_driver, &pdev->dev);
if (IS_ERR(ddev))
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 33355dd302f1..cdf1a8754eba 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -220,6 +220,7 @@ static const struct drm_gem_object_funcs panfrost_gem_funcs
= {
*/
struct drm_gem_object *panfrost_gem_create_object(struct drm_device *dev,
size_t size)
{
+ struct panfrost_device *pfdev = dev->dev_private;
struct panfrost_gem_object *obj;
obj = kzalloc(sizeof(*obj), GFP_KERNEL);
@@ -229,6 +230,7 @@ struct drm_gem_object *panfrost_gem_create_object(struct
drm_device *dev, size_t
INIT_LIST_HEAD(&obj->mappings.list);
mutex_init(&obj->mappings.lock);
obj->base.base.funcs = &panfrost_gem_funcs;
+ obj->base.map_cached = pfdev->coherent;
return &obj->base.base;
}
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index e8f7b11352d2..8852fd378f7a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -371,6 +371,7 @@ int panfrost_mmu_pgtable_alloc(struct panfrost_file_priv
*priv)
.pgsize_bitmap = SZ_4K | SZ_2M,
.ias= FIELD_GET(0xff, pfdev->features.mmu_features),
.oas= FIELD_GET(0xff00,
pfdev->features.mmu_features),
+ .coherent_walk = pfdev->coherent,
.tlb= &mmu_tlb_ops,
.iommu_dev = pfdev->dev,
};
--
2.28.0.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] arm64: dts: meson: Describe G12b GPU as coherent
According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
how to handle this properly) we should describe it as such. Otherwise
the mismatch leads to all manner of fun with mismatched attributes and
inadvertently snooping stale data from caches, which would account for
at least some of the brokenness observed on this platform.
Reviewed-by: Neil Armstrong
Tested-by: Neil Armstrong
Signed-off-by: Robin Murphy
---
arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
index 9b8548e5f6e5..ee8fcae9f9f0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
@@ -135,3 +135,7 @@ map1 {
};
};
};
+
+&mali {
+ dma-coherent;
+};
--
2.28.0.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm: panfrost: Coherency support
Hi all, Here's a quick v2 with the tags so far picked up and some inline commentary about the shareability domains for the pagetable code. Robin. Robin Murphy (3): iommu/io-pgtable-arm: Support coherency for Mali LPAE drm/panfrost: Support cache-coherent integrations arm64: dts: meson: Describe G12b GPU as coherent arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4 drivers/gpu/drm/panfrost/panfrost_device.h | 1 + drivers/gpu/drm/panfrost/panfrost_drv.c | 2 ++ drivers/gpu/drm/panfrost/panfrost_gem.c | 2 ++ drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 + drivers/iommu/io-pgtable-arm.c | 11 ++- 6 files changed, 20 insertions(+), 1 deletion(-) -- 2.28.0.dirty ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] iommu/io-pgtable-arm: Support coherency for Mali LPAE
Midgard GPUs have ACE-Lite master interfaces which allows systems to integrate them in an I/O-coherent manner. It seems that from the GPU's viewpoint, the rest of the system is its outer shareable domain, and so even when snoop signals are wired up, they are only emitted for outer shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does indeed get coherent pagetable walks working nicely for the coherent T620 in the Arm Juno SoC. Reviewed-by: Steven Price Tested-by: Neil Armstrong Signed-off-by: Robin Murphy --- drivers/iommu/io-pgtable-arm.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c index dc7bcf858b6d..b4072a18e45d 100644 --- a/drivers/iommu/io-pgtable-arm.c +++ b/drivers/iommu/io-pgtable-arm.c @@ -440,7 +440,13 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data, << ARM_LPAE_PTE_ATTRINDX_SHIFT); } - if (prot & IOMMU_CACHE) + /* +* Also Mali has its own notions of shareability wherein its Inner +* domain covers the cores within the GPU, and its Outer domain is +* "outside the GPU" (i.e. either the Inner or System domain in CPU +* terms, depending on coherency). +*/ + if (prot & IOMMU_CACHE && data->iop.fmt != ARM_MALI_LPAE) pte |= ARM_LPAE_PTE_SH_IS; else pte |= ARM_LPAE_PTE_SH_OS; @@ -1049,6 +1055,9 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie) cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) | ARM_MALI_LPAE_TTBR_READ_INNER | ARM_MALI_LPAE_TTBR_ADRMODE_TABLE; + if (cfg->coherent_walk) + cfg->arm_mali_lpae_cfg.transtab |= ARM_MALI_LPAE_TTBR_SHARE_OUTER; + return &data->iop; out_free_data: -- 2.28.0.dirty ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > I've noticed this isn't integrated/added. > > Defacto the uapi we have now is that userspace needs to ignore "spurious" > EBUSY. This really, really, really, bites. I think we need a guarantee that this never happens if ALLOW_MODESET is always used in blocking mode, plus in future a cap we can use to detect that we won't be getting spurious EBUSY events. I really don't want to ever paper over this, because it's one of the clearest indications that userspace has its timing/signalling wrong. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209345] [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80)
https://bugzilla.kernel.org/show_bug.cgi?id=209345 --- Comment #8 from Alexander von Gluck (kallis...@unixzen.com) --- rebooted without TB3 enclosure attached. Msnuslly loaded nouveau vis insmod after the TB3 attachment calmed down, and got something a bit cleaner: [ 176.083524] nouveau: loading out-of-tree module taints kernel. [ 176.084343] nouveau: module verification failed: signature and/or required key missing - tainting kernel [ 176.124991] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20200528/nsarguments-59) [ 176.125405] nouveau :08:00.0: NVIDIA GK120 (0f22d0a1) [ 176.406057] nouveau :08:00.0: bios: version 80.21.1f.00.01 [ 176.537701] nouveau :08:00.0: fb: 11520 MiB GDDR5 [ 176.562278] nouveau :08:00.0: bar: one-time init failed, -12 [ 176.562522] nouveau :08:00.0: init failed with -12 [ 176.562523] nouveau: DRM-master::0080: init failed with -12 [ 176.562525] nouveau :08:00.0: DRM-master: Device allocation failed: -12 [ 176.563099] nouveau: probe of :08:00.0 failed with error -12 [ 176.563387] nouveau :09:00.0: NVIDIA GK120 (0f22d0a1) [ 176.842900] nouveau :09:00.0: bios: version 80.21.1f.00.02 [ 176.977507] nouveau :09:00.0: fb: 11520 MiB GDDR5 [ 177.002138] nouveau :09:00.0: bar: one-time init failed, -12 [ 177.002380] nouveau :09:00.0: init failed with -12 [ 177.002382] nouveau: DRM-master::0080: init failed with -12 [ 177.002384] nouveau :09:00.0: DRM-master: Device allocation failed: -12 [ 177.003019] nouveau: probe of :09:00.0 failed with error -12 So, each GK120 gets 11.5 GiB to make up that 24GiB of ram. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209345] [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80)
https://bugzilla.kernel.org/show_bug.cgi?id=209345 --- Comment #9 from Alexander von Gluck (kallis...@unixzen.com) --- better lspci: 08:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1) Subsystem: NVIDIA Corporation Device 106c Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- (64-bit, prefetchable) Region 3: Memory at a000 (64-bit, prefetchable) [size=32M] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Capabilities: [78] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 25.000W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #8, Speed 8GT/s, Width x16, ASPM not supported ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (downgraded), Width x16 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range AB, TimeoutDis+, NROPrPrP-, LTR- 10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt-, EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS-, TPHComp-, ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled AtomicOpsCtl: ReqEn- LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+ EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- Capabilities: [128 v1] Power Budgeting Capabilities: [420 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 Capabilities: [900 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn-, PerformEqu- LaneErrStat: 0 Kernel modules: nouveau 09:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1) Subsystem: NVIDIA Corporation Device 106c Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- (64-bit, prefetchable) Region 3: Memory at a400 (64-bit, prefetchable) [size=32M] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftR
Re: [PATCH] gpu/drm/radeon: fix spellint typo in comments
There is a typo in your patch subject. ;-) Regards //Ernst Den tis 22 sep. 2020 kl 15:11 skrev Wang Qing : > Modify the comment typo: "definately" -> "definitely". > > Signed-off-by: Wang Qing > --- > drivers/gpu/drm/radeon/radeon_vm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_vm.c > b/drivers/gpu/drm/radeon/radeon_vm.c > index f60fae0..3d6e2cd > --- a/drivers/gpu/drm/radeon/radeon_vm.c > +++ b/drivers/gpu/drm/radeon/radeon_vm.c > @@ -188,7 +188,7 @@ struct radeon_fence *radeon_vm_grab_id(struct > radeon_device *rdev, > vm_id->last_id_use == rdev->vm_manager.active[vm_id->id]) > return NULL; > > - /* we definately need to flush */ > + /* we definitely need to flush */ > vm_id->pd_gpu_addr = ~0ll; > > /* skip over VMID 0, since it is the system VM */ > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote: > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > > pull in arbitrary other resources, including CRTCs (e.g. when > > > reconfiguring global resources). > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > which can lead to spurious EBUSY calls, both: > > > - when that other CRTC is currently busy doing a page_flip the > > > ALLOW_MODESET commit can fail with an EBUSY > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > of the additional commit inserted by the kernel without userspace's > > > knowledge > > > > > > For blocking commits this isn't a problem, because everyone else will > > > just block until all the CRTC are reconfigured. Only thing userspace > > > can notice is the dropped frames without any reason for why frames got > > > dropped. > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > plug this problem by demoting nonblocking commits which might cause > > > issues by including CRTCs not in the original request to blocking > > > commits. > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > I've noticed this isn't integrated/added. Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY. > Noticed this is fixing (also) DPMS when multiple outputs are in use. > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm > seeing > the warning quite often. This would be a driver bug I think. That really shouldn't happen for normal page flips. -Daniel > > > > Thanks for writing this up Daniel, and for reminding me about it some > > time later as well ... > > > > Reviewed-by: Daniel Stone > > > > Cheers, > > Daniel > > ___ > > 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
[Bug 209345] [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80)
https://bugzilla.kernel.org/show_bug.cgi?id=209345 --- Comment #7 from Ilia Mirkin (imir...@alum.mit.edu) --- [ 2460.923220] nouveau :08:00.0: can't change power state from D3hot to D0 (config space inaccessible) That's just really bad. My guess is that the "big-endian" notice is just due to a register returning all 0x (we try to flip the GPU into little-endian mode if we can). Seems like there are issues with the TB enclosure, or something along those lines. It does seem like you got further earlier to have gotten the "unknown chipset" error, but by the time you were running lspci above, they were gone already (returning all 1's, and PCI is active-low, so that just means it's all off). Don't know what the difference is, I know nothing about those enclosures. I'd try to disable any sort of power management that might be turning the enclosure off. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
>
> So if I understand this correctly, it sounds like that some Pixelbooks boot up
> with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
> panel actually having DPCD backlight controls enabled?
It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
backlight.enabled = false. By changing backlight.level = max,
backlight.enabled is now set to true. This results in losing backlight
control on boot (since the enable routine is no longer invoked).
Sean
>
> If I'm understanding that correctly, then this patch looks good to me:
>
> Reviewed-by: Lyude Paul
>
> On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> > DPCD control mode"), we fixed the brightness level when DPCD control was
> > not active to max brightness. This is as good as we can guess since most
> > backlights go on full when uncontrolled.
> >
> > However in doing so we changed the semantics of the initial
> > 'backlight.enabled' value. At least on Pixelbooks, they were relying
> > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> > boot such that enabled would be false. This causes the device to be
> > enabled when the brightness is set. Without this, brightness control
> > doesn't work. So by changing brightness to max, we also flipped enabled
> > to be true on boot.
> >
> > To fix this, make enabled a function of brightness and backlight control
> > mechanism.
> >
> > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD
> > control mode")
> > Cc: Lyude Paul
> > Cc: Jani Nikula
> > Cc: Juha-Pekka Heikkila
> > Cc: "Ville Syrjälä"
> > Cc: Rodrigo Vivi
> > Cc: Kevin Chowski >
> > Signed-off-by: Sean Paul
> > ---
> > .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
> > 1 file changed, 20 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index acbd7eb66cbe..036f504ac7db 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct intel_dp
> > *intel_dp, bool enable)
> > }
> > }
> >
> > -/*
> > - * Read the current backlight value from DPCD register(s) based
> > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > - */
> > -static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> > +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> > *connector)
> > {
> > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > - u8 read_val[2] = { 0x0 };
> > u8 mode_reg;
> > - u16 level = 0;
> >
> > if (drm_dp_dpcd_readb(&intel_dp->aux,
> > DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> > @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> > drm_dbg_kms(&i915->drm,
> > "Failed to read the DPCD register 0x%x\n",
> > DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> > - return 0;
> > + return false;
> > }
> >
> > + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> > +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > +}
> > +
> > +/*
> > + * Read the current backlight value from DPCD register(s) based
> > + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > + */
> > +static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> > +{
> > + struct intel_dp *intel_dp = intel_attached_dp(connector);
> > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > + u8 read_val[2] = { 0x0 };
> > + u16 level = 0;
> > +
> > /*
> >* If we're not in DPCD control mode yet, the programmed brightness
> >* value is meaningless and we should assume max brightness
> >*/
> > - if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
> > - DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
> > + if (!intel_dp_aux_backlight_dpcd_mode(connector))
> > return connector->panel.backlight.max;
> >
> > if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
> > @@ -319,7 +327,8 @@ static int intel_dp_aux_setup_backlight(struct
> > intel_connector *connector,
> >
> > panel->backlight.min = 0;
> > panel->backlight.level = intel_dp_aux_get_backlight(connector);
> > - panel->backlight.enabled = panel->backlight.level != 0;
> > + panel->backlight.enabled = intel_dp_aux_backlight_dpcd_mode(connector)
> > &&
> > +panel->backlight.level != 0;
> >
> > return 0;
> > }
> --
> Cheers,
> Lyude Paul (she/
Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote: > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > pull in arbitrary other resources, including CRTCs (e.g. when > > reconfiguring global resources). > > > > But in nonblocking mode userspace has then no idea this happened, > > which can lead to spurious EBUSY calls, both: > > - when that other CRTC is currently busy doing a page_flip the > > ALLOW_MODESET commit can fail with an EBUSY > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > of the additional commit inserted by the kernel without userspace's > > knowledge > > > > For blocking commits this isn't a problem, because everyone else will > > just block until all the CRTC are reconfigured. Only thing userspace > > can notice is the dropped frames without any reason for why frames got > > dropped. > > > > Consensus is that we need new uapi to handle this properly, but no one > > has any idea what exactly the new uapi should look like. As a stop-gap > > plug this problem by demoting nonblocking commits which might cause > > issues by including CRTCs not in the original request to blocking > > commits. Gentle ping. I've tried out Linus's master tree and, and like Pekka, I've noticed this isn't integrated/added. Noticed this is fixing (also) DPMS when multiple outputs are in use. Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm seeing the warning quite often. > > Thanks for writing this up Daniel, and for reminding me about it some > time later as well ... > > Reviewed-by: Daniel Stone > > Cheers, > Daniel > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/vmwgfx: stop using ttm_bo_create
Implement in the driver instead since it is the only user of that function.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 42 ++
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 6 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 4 +++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 8 ++---
4 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 813f1b148094..30d19b45b602 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -487,6 +487,48 @@ static void vmw_user_bo_destroy(struct ttm_buffer_object
*bo)
ttm_prime_object_kfree(vmw_user_bo, prime);
}
+/**
+ * vmw_bo_create_kernel - Create a pinned BO for internal kernel use.
+ *
+ * @dev_priv: Pointer to the device private struct
+ * @size: size of the BO we need
+ * @placement: where to put it
+ * @p_bo: resulting BO
+ *
+ * Creates and pin a simple BO for in kernel use.
+ */
+int vmw_bo_create_kernel(struct vmw_private *dev_priv, unsigned long size,
+struct ttm_placement *placement,
+struct ttm_buffer_object **p_bo)
+{
+ unsigned npages = PAGE_ALIGN(size) >> PAGE_SHIFT;
+ struct ttm_buffer_object *bo;
+ size_t acc_size;
+ int ret;
+
+ bo = kzalloc(sizeof(*bo), GFP_KERNEL);
+ if (unlikely(!bo))
+ return -ENOMEM;
+
+ acc_size = ttm_round_pot(sizeof(*bo));
+ acc_size += ttm_round_pot(npages * sizeof(void *));
+ acc_size += ttm_round_pot(sizeof(struct ttm_tt));
+ ret = ttm_bo_init_reserved(&dev_priv->bdev, bo, size,
+ ttm_bo_type_device, placement, 0,
+ false, acc_size, NULL, NULL, NULL);
+ if (unlikely(ret))
+ goto error_free;
+
+ ttm_bo_pin(bo);
+ ttm_bo_unreserve(bo);
+ *p_bo = bo;
+
+ return 0;
+
+error_free:
+ kfree(bo);
+ return ret;
+}
/**
* vmw_bo_init - Initialize a vmw buffer object
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 3b41cf63110a..9a9fe10d829b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -1245,9 +1245,9 @@ int vmw_cmdbuf_set_pool_size(struct vmw_cmdbuf_man *man,
!dev_priv->has_mob)
return -ENOMEM;
- ret = ttm_bo_create(&dev_priv->bdev, size, ttm_bo_type_device,
- &vmw_mob_ne_placement, 0, false,
- &man->cmd_space);
+ ret = vmw_bo_create_kernel(dev_priv, size,
+ &vmw_mob_placement,
+ &man->cmd_space);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 9ceee4eb0b13..5d07de5183e1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -845,6 +845,10 @@ extern void vmw_bo_get_guest_ptr(const struct
ttm_buffer_object *buf,
SVGAGuestPtr *ptr);
extern void vmw_bo_pin_reserved(struct vmw_buffer_object *bo, bool pin);
extern void vmw_bo_bo_free(struct ttm_buffer_object *bo);
+extern int vmw_bo_create_kernel(struct vmw_private *dev_priv,
+ unsigned long size,
+ struct ttm_placement *placement,
+ struct ttm_buffer_object **p_bo);
extern int vmw_bo_init(struct vmw_private *dev_priv,
struct vmw_buffer_object *vmw_bo,
size_t size, struct ttm_placement *placement,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index d7ea658e9910..39a2f720f4ed 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -793,11 +793,9 @@ int vmw_bo_create_and_populate(struct vmw_private
*dev_priv,
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);
-
+ ret = vmw_bo_create_kernel(dev_priv, bo_size,
+ &vmw_sys_placement,
+ &bo);
if (unlikely(ret != 0))
return ret;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/11] drm/nouveau: switch over to the new pin interface
Stop using TTM_PL_FLAG_NO_EVICT.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +++---
drivers/gpu/drm/nouveau/nouveau_bo.h | 3 --
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
3 files changed, 13 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 2ee75646ad6f..bcae4514952f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -139,7 +139,7 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
struct drm_device *dev = drm->dev;
struct nouveau_bo *nvbo = nouveau_bo(bo);
- WARN_ON(nvbo->pin_refcnt > 0);
+ WARN_ON(nvbo->bo.pin_count > 0);
nouveau_bo_del_io_reserve_lru(bo);
nv10_bo_put_tile_region(dev, nvbo->tile, NULL);
@@ -417,9 +417,8 @@ nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t
domain,
{
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct ttm_placement *pl = &nvbo->placement;
- uint32_t flags = (nvbo->force_coherent ? TTM_PL_FLAG_UNCACHED :
-TTM_PL_MASK_CACHING) |
-(nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
+ uint32_t flags = nvbo->force_coherent ? TTM_PL_FLAG_UNCACHED :
+ TTM_PL_MASK_CACHING;
pl->placement = nvbo->placements;
set_placement_list(drm, nvbo->placements, &pl->num_placement,
@@ -453,7 +452,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t domain,
bool contig)
}
}
- if (nvbo->pin_refcnt) {
+ if (nvbo->bo.pin_count) {
bool error = evict;
switch (bo->mem.mem_type) {
@@ -472,7 +471,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t domain,
bool contig)
bo->mem.mem_type, domain);
ret = -EBUSY;
}
- nvbo->pin_refcnt++;
+ ttm_bo_pin(&nvbo->bo);
goto out;
}
@@ -483,18 +482,12 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t domain,
bool contig)
goto out;
}
- nvbo->pin_refcnt++;
nouveau_bo_placement_set(nvbo, domain, 0);
-
- /* drop pin_refcnt temporarily, so we don't trip the assertion
-* in nouveau_bo_move() that makes sure we're not trying to
-* move a pinned buffer
-*/
- nvbo->pin_refcnt--;
ret = nouveau_bo_validate(nvbo, false, false);
if (ret)
goto out;
- nvbo->pin_refcnt++;
+
+ ttm_bo_pin(&nvbo->bo);
switch (bo->mem.mem_type) {
case TTM_PL_VRAM:
@@ -519,30 +512,14 @@ nouveau_bo_unpin(struct nouveau_bo *nvbo)
{
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct ttm_buffer_object *bo = &nvbo->bo;
- int ret, ref;
+ int ret;
ret = ttm_bo_reserve(bo, false, false, NULL);
if (ret)
return ret;
- ref = --nvbo->pin_refcnt;
- WARN_ON_ONCE(ref < 0);
- if (ref)
- goto out;
-
- switch (bo->mem.mem_type) {
- case TTM_PL_VRAM:
- nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_VRAM, 0);
- break;
- case TTM_PL_TT:
- nouveau_bo_placement_set(nvbo, NOUVEAU_GEM_DOMAIN_GART, 0);
- break;
- default:
- break;
- }
-
- ret = nouveau_bo_validate(nvbo, false, false);
- if (ret == 0) {
+ ttm_bo_unpin(&nvbo->bo);
+ if (!nvbo->bo.pin_count) {
switch (bo->mem.mem_type) {
case TTM_PL_VRAM:
drm->gem.vram_available += bo->mem.size;
@@ -555,9 +532,8 @@ nouveau_bo_unpin(struct nouveau_bo *nvbo)
}
}
-out:
ttm_bo_unreserve(bo);
- return ret;
+ return 0;
}
int
@@ -1065,7 +1041,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
if (ret)
return ret;
- if (nvbo->pin_refcnt)
+ if (nvbo->bo.pin_count)
NV_WARN(drm, "Moving pinned object %p!\n", nvbo);
if (drm->client.device.info.family < NV_DEVICE_INFO_V0_TESLA) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 2a23c8207436..ff68ded8d590 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -40,9 +40,6 @@ struct nouveau_bo {
struct nouveau_drm_tile *tile;
- /* protect by the ttm reservation lock */
- int pin_refcnt;
-
struct ttm_bo_kmap_obj dma_buf_vmap;
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 8f099601d2f2..5d191e58edf1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -107,7 +107,7
[PATCH 10/11] drm/ttm: remove ttm_bo_create
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 40
include/drm/ttm/ttm_bo_api.h | 24 --
2 files changed, 64 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b82b49d43942..1a4b25083326 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1254,19 +1254,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
}
EXPORT_SYMBOL(ttm_bo_init);
-static size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
- unsigned long bo_size,
- unsigned struct_size)
-{
- unsigned npages = (PAGE_ALIGN(bo_size)) >> PAGE_SHIFT;
- size_t size = 0;
-
- size += ttm_round_pot(struct_size);
- size += ttm_round_pot(npages * sizeof(void *));
- size += ttm_round_pot(sizeof(struct ttm_tt));
- return size;
-}
-
size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
unsigned long bo_size,
unsigned struct_size)
@@ -1281,33 +1268,6 @@ size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
}
EXPORT_SYMBOL(ttm_bo_dma_acc_size);
-int ttm_bo_create(struct ttm_bo_device *bdev,
- unsigned long size,
- enum ttm_bo_type type,
- struct ttm_placement *placement,
- uint32_t page_alignment,
- bool interruptible,
- struct ttm_buffer_object **p_bo)
-{
- struct ttm_buffer_object *bo;
- size_t acc_size;
- int ret;
-
- bo = kzalloc(sizeof(*bo), GFP_KERNEL);
- if (unlikely(bo == NULL))
- return -ENOMEM;
-
- acc_size = ttm_bo_acc_size(bdev, size, sizeof(struct
ttm_buffer_object));
- ret = ttm_bo_init(bdev, bo, size, type, placement, page_alignment,
- interruptible, acc_size,
- NULL, NULL, NULL);
- if (likely(ret == 0))
- *p_bo = bo;
-
- return ret;
-}
-EXPORT_SYMBOL(ttm_bo_create);
-
int ttm_bo_evict_mm(struct ttm_bo_device *bdev, unsigned mem_type)
{
struct ttm_resource_manager *man = ttm_manager_type(bdev, mem_type);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 33aca60870e2..6cbe59bc97ab 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -447,30 +447,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev, struct
ttm_buffer_object *bo,
struct sg_table *sg, struct dma_resv *resv,
void (*destroy) (struct ttm_buffer_object *));
-/**
- * ttm_bo_create
- *
- * @bdev: Pointer to a ttm_bo_device struct.
- * @size: Requested size of buffer object.
- * @type: Requested type of buffer object.
- * @placement: Initial placement.
- * @page_alignment: Data alignment in pages.
- * @interruptible: If needing to sleep while waiting for GPU resources,
- * sleep interruptible.
- * @p_bo: On successful completion *p_bo points to the created object.
- *
- * This function allocates a ttm_buffer_object, and then calls ttm_bo_init
- * on that object. The destroy function is set to kfree().
- * Returns
- * -ENOMEM: Out of memory.
- * -EINVAL: Invalid placement flags.
- * -ERESTARTSYS: Interrupted by signal while waiting for resources.
- */
-int ttm_bo_create(struct ttm_bo_device *bdev, unsigned long size,
- enum ttm_bo_type type, struct ttm_placement *placement,
- uint32_t page_alignment, bool interruptible,
- struct ttm_buffer_object **p_bo);
-
/**
* ttm_bo_evict_mm
*
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/11] drm/qxl: switch over to the new pin interface
Stop using TTM_PL_FLAG_NO_EVICT.
Signed-off-by: Christian König
Reviewed-by: Gerd Hoffmann
Tested-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +--
drivers/gpu/drm/qxl/qxl_object.c | 44 +--
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_release.c | 4 +--
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
7 files changed, 20 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c
b/drivers/gpu/drm/qxl/qxl_debugfs.c
index 524d35b648d8..183d15e2cf58 100644
--- a/drivers/gpu/drm/qxl/qxl_debugfs.c
+++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
@@ -67,7 +67,7 @@ qxl_debugfs_buffers_info(struct seq_file *m, void *data)
seq_printf(m, "size %ld, pc %d, num releases %d\n",
(unsigned long)bo->tbo.base.size,
- bo->pin_count, rel);
+ bo->tbo.pin_count, rel);
}
return 0;
}
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index aae90a9ee1db..3602e8b34189 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -80,7 +80,6 @@ struct qxl_bo {
struct ttm_placeplacements[3];
struct ttm_placementplacement;
struct ttm_bo_kmap_obj kmap;
- unsigned int pin_count;
void*kptr;
unsigned intmap_count;
int type;
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 5cea6eea72ab..0bab9ec6adc1 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -326,8 +326,8 @@ static int qxl_update_area_ioctl(struct drm_device *dev,
void *data,
if (ret)
goto out;
- if (!qobj->pin_count) {
- qxl_ttm_placement_from_domain(qobj, qobj->type, false);
+ if (!qobj->tbo.pin_count) {
+ qxl_ttm_placement_from_domain(qobj, qobj->type);
ret = ttm_bo_validate(&qobj->tbo, &qobj->placement, &ctx);
if (unlikely(ret))
goto out;
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index 2bc364412e8b..d3635e3e3267 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -51,14 +51,12 @@ bool qxl_ttm_bo_is_qxl_bo(struct ttm_buffer_object *bo)
return false;
}
-void qxl_ttm_placement_from_domain(struct qxl_bo *qbo, u32 domain, bool pinned)
+void qxl_ttm_placement_from_domain(struct qxl_bo *qbo, u32 domain)
{
u32 c = 0;
u32 pflag = 0;
unsigned int i;
- if (pinned)
- pflag |= TTM_PL_FLAG_NO_EVICT;
if (qbo->tbo.base.size <= PAGE_SIZE)
pflag |= TTM_PL_FLAG_TOPDOWN;
@@ -128,14 +126,13 @@ int qxl_bo_create(struct qxl_device *qdev,
}
bo->tbo.base.funcs = &qxl_object_funcs;
bo->type = domain;
- bo->pin_count = pinned ? 1 : 0;
bo->surface_id = 0;
INIT_LIST_HEAD(&bo->list);
if (surf)
bo->surf = *surf;
- qxl_ttm_placement_from_domain(bo, domain, pinned);
+ qxl_ttm_placement_from_domain(bo, domain);
r = ttm_bo_init(&qdev->mman.bdev, &bo->tbo, size, type,
&bo->placement, 0, !kernel, size,
@@ -147,6 +144,8 @@ int qxl_bo_create(struct qxl_device *qdev,
size, domain);
return r;
}
+ if (pinned)
+ ttm_bo_pin(&bo->tbo);
*bo_ptr = bo;
return 0;
}
@@ -248,39 +247,22 @@ static int __qxl_bo_pin(struct qxl_bo *bo)
struct drm_device *ddev = bo->tbo.base.dev;
int r;
- if (bo->pin_count) {
- bo->pin_count++;
+ if (bo->tbo.pin_count) {
+ ttm_bo_pin(&bo->tbo);
return 0;
}
- qxl_ttm_placement_from_domain(bo, bo->type, true);
+ qxl_ttm_placement_from_domain(bo, bo->type);
r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
- if (likely(r == 0)) {
- bo->pin_count = 1;
- }
+ if (likely(r == 0))
+ ttm_bo_pin(&bo->tbo);
if (unlikely(r != 0))
dev_err(ddev->dev, "%p pin failed\n", bo);
return r;
}
-static int __qxl_bo_unpin(struct qxl_bo *bo)
+static void __qxl_bo_unpin(struct qxl_bo *bo)
{
- struct ttm_operation_ctx ctx = { false, false };
- struct drm_device *ddev = bo->tbo.base.dev;
- int r, i;
-
- if (!bo->pin_count) {
- dev_warn(ddev->dev, "%p unpin not necessary\n", bo);
- return 0;
- }
- bo->pin_count--;
- if (bo->pin_count)
- return 0;
- for (i = 0; i < bo->placement.num_placement; i++)
- bo->place
[PATCH 09/11] drm/amdgpu: switch over to the new pin interface
Stop using TTM_PL_FLAG_NO_EVICT.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 5 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 41 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +-
9 files changed, 24 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index b6b821500d30..64d4b5ff95d6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1479,7 +1479,7 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
}
}
- if (!amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) && !bo->pin_count)
+ if (!amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) && !bo->tbo.pin_count)
amdgpu_bo_fence(bo,
&avm->process_info->eviction_fence->base,
true);
@@ -1558,7 +1558,8 @@ int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
* required.
*/
if (mem->mapped_to_gpu_memory == 0 &&
- !amdgpu_ttm_tt_get_usermm(mem->bo->tbo.ttm) && !mem->bo->pin_count)
+ !amdgpu_ttm_tt_get_usermm(mem->bo->tbo.ttm) &&
+ !mem->bo->tbo.pin_count)
amdgpu_amdkfd_remove_eviction_fence(mem->bo,
process_info->eviction_fence);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 12598a4b5c78..d50b63a93d37 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -410,7 +410,7 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
uint32_t domain;
int r;
- if (bo->pin_count)
+ if (bo->tbo.pin_count)
return 0;
/* Don't move this buffer if we have depleted our allowance
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index c81206e6096f..4cba095b6c44 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -132,10 +132,7 @@ static void amdgpu_display_unpin_work_func(struct
work_struct *__work)
/* unpin of the old buffer */
r = amdgpu_bo_reserve(work->old_abo, true);
if (likely(r == 0)) {
- r = amdgpu_bo_unpin(work->old_abo);
- if (unlikely(r != 0)) {
- DRM_ERROR("failed to unpin buffer after flip\n");
- }
+ amdgpu_bo_unpin(work->old_abo);
amdgpu_bo_unreserve(work->old_abo);
} else
DRM_ERROR("failed to reserve buffer after flip\n");
@@ -249,8 +246,7 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc
*crtc,
}
unpin:
if (!adev->enable_virtual_display)
- if (unlikely(amdgpu_bo_unpin(new_abo) != 0))
- DRM_ERROR("failed to unpin new abo in error path\n");
+ amdgpu_bo_unpin(new_abo);
unreserve:
amdgpu_bo_unreserve(new_abo);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 957934926b24..5b465ab774d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -281,7 +281,7 @@ static struct sg_table *amdgpu_dma_buf_map(struct
dma_buf_attachment *attach,
struct sg_table *sgt;
long r;
- if (!bo->pin_count) {
+ if (!bo->tbo.pin_count) {
/* move buffer into GTT or VRAM */
struct ttm_operation_ctx ctx = { false, false };
unsigned domains = AMDGPU_GEM_DOMAIN_GTT;
@@ -390,7 +390,8 @@ static int amdgpu_dma_buf_begin_cpu_access(struct dma_buf
*dma_buf,
if (unlikely(ret != 0))
return ret;
- if (!bo->pin_count && (bo->allowed_domains & AMDGPU_GEM_DOMAIN_GTT)) {
+ if (!bo->tbo.pin_count &&
+ (bo->allowed_domains & AMDGPU_GEM_DOMAIN_GTT)) {
amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
ret = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index aa7f230c71bf..59b52804622d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -860,7 +860,7 @@ static int amdgpu_debugfs_gem_bo_info(int id, void *ptr,
void *data)
seq_printf(m, "\t0x%08x: %12ld byte %s",
id, amdgpu_bo_size(bo), placement);
-
[PATCH 08/11] drm/radeon: switch over to the new pin interface
Stop using TTM_PL_FLAG_NO_EVICT.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 1 -
drivers/gpu/drm/radeon/radeon_display.c | 9 ++
drivers/gpu/drm/radeon/radeon_object.c | 37 ++---
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
5 files changed, 13 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index a6d8de01194a..5d54bccebd4d 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -497,7 +497,6 @@ struct radeon_bo {
struct ttm_buffer_objecttbo;
struct ttm_bo_kmap_obj kmap;
u32 flags;
- unsignedpin_count;
void*kptr;
u32 tiling_flags;
u32 pitch;
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 7b69d6dfe44a..3eacf33bbe48 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -273,10 +273,7 @@ static void radeon_unpin_work_func(struct work_struct
*__work)
/* unpin of the old buffer */
r = radeon_bo_reserve(work->old_rbo, false);
if (likely(r == 0)) {
- r = radeon_bo_unpin(work->old_rbo);
- if (unlikely(r != 0)) {
- DRM_ERROR("failed to unpin buffer after flip\n");
- }
+ radeon_bo_unpin(work->old_rbo);
radeon_bo_unreserve(work->old_rbo);
} else
DRM_ERROR("failed to reserve buffer after flip\n");
@@ -607,9 +604,7 @@ static int radeon_crtc_page_flip_target(struct drm_crtc
*crtc,
DRM_ERROR("failed to reserve new rbo in error path\n");
goto cleanup;
}
- if (unlikely(radeon_bo_unpin(new_rbo) != 0)) {
- DRM_ERROR("failed to unpin new rbo in error path\n");
- }
+ radeon_bo_unpin(new_rbo);
radeon_bo_unreserve(new_rbo);
cleanup:
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 316e35d3f8a9..0de267ab3913 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -334,8 +334,8 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
domain, u64 max_offset,
if (radeon_ttm_tt_has_userptr(bo->rdev, bo->tbo.ttm))
return -EPERM;
- if (bo->pin_count) {
- bo->pin_count++;
+ if (bo->tbo.pin_count) {
+ ttm_bo_pin(&bo->tbo);
if (gpu_addr)
*gpu_addr = radeon_bo_gpu_offset(bo);
@@ -367,13 +367,11 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
domain, u64 max_offset,
bo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
else
bo->placements[i].lpfn = max_offset >> PAGE_SHIFT;
-
- bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
}
r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
if (likely(r == 0)) {
- bo->pin_count = 1;
+ ttm_bo_pin(&bo->tbo);
if (gpu_addr != NULL)
*gpu_addr = radeon_bo_gpu_offset(bo);
if (domain == RADEON_GEM_DOMAIN_VRAM)
@@ -391,32 +389,15 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64
*gpu_addr)
return radeon_bo_pin_restricted(bo, domain, 0, gpu_addr);
}
-int radeon_bo_unpin(struct radeon_bo *bo)
+void radeon_bo_unpin(struct radeon_bo *bo)
{
- struct ttm_operation_ctx ctx = { false, false };
- int r, i;
-
- if (!bo->pin_count) {
- dev_warn(bo->rdev->dev, "%p unpin not necessary\n", bo);
- return 0;
- }
- bo->pin_count--;
- if (bo->pin_count)
- return 0;
- for (i = 0; i < bo->placement.num_placement; i++) {
- bo->placements[i].lpfn = 0;
- bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
- }
- r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
- if (likely(r == 0)) {
+ ttm_bo_unpin(&bo->tbo);
+ if (!bo->tbo.pin_count) {
if (bo->tbo.mem.mem_type == TTM_PL_VRAM)
bo->rdev->vram_pin_size -= radeon_bo_size(bo);
else
bo->rdev->gart_pin_size -= radeon_bo_size(bo);
- } else {
- dev_err(bo->rdev->dev, "%p validate failed for unpin\n", bo);
}
- return r;
}
int radeon_bo_evict_vram(struct radeon_device *rdev)
@@ -549,7 +530,7 @@ int radeon_bo_list_validate(struct radeon_device *rdev,
list_for_each_entry(lobj, head, tv.head) {
struct radeon_bo *bo = lobj->robj;
- if (!bo->pin_count)
[PATCH 02/11] drm/vmwgfx: remove unused placement combination
Just some dead code cleanup.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 30 --
2 files changed, 31 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 1523b51a7284..9ceee4eb0b13 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1008,7 +1008,6 @@ extern struct ttm_placement vmw_vram_placement;
extern struct ttm_placement vmw_vram_ne_placement;
extern struct ttm_placement vmw_vram_sys_placement;
extern struct ttm_placement vmw_vram_gmr_placement;
-extern struct ttm_placement vmw_vram_gmr_ne_placement;
extern struct ttm_placement vmw_sys_placement;
extern struct ttm_placement vmw_sys_ne_placement;
extern struct ttm_placement vmw_evictable_placement;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 7454f797d37b..d7ea658e9910 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -65,13 +65,6 @@ static const struct ttm_place gmr_placement_flags = {
.flags = TTM_PL_FLAG_CACHED
};
-static const struct ttm_place gmr_ne_placement_flags = {
- .fpfn = 0,
- .lpfn = 0,
- .mem_type = VMW_PL_GMR,
- .flags = TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT
-};
-
static const struct ttm_place mob_placement_flags = {
.fpfn = 0,
.lpfn = 0,
@@ -128,29 +121,6 @@ struct ttm_placement vmw_vram_gmr_placement = {
.busy_placement = &gmr_placement_flags
};
-static const struct ttm_place vram_gmr_ne_placement_flags[] = {
- {
- .fpfn = 0,
- .lpfn = 0,
- .mem_type = TTM_PL_VRAM,
- .flags = TTM_PL_FLAG_CACHED |
-TTM_PL_FLAG_NO_EVICT
- }, {
- .fpfn = 0,
- .lpfn = 0,
- .mem_type = VMW_PL_GMR,
- .flags = TTM_PL_FLAG_CACHED |
-TTM_PL_FLAG_NO_EVICT
- }
-};
-
-struct ttm_placement vmw_vram_gmr_ne_placement = {
- .num_placement = 2,
- .placement = vram_gmr_ne_placement_flags,
- .num_busy_placement = 1,
- .busy_placement = &gmr_ne_placement_flags
-};
-
struct ttm_placement vmw_vram_sys_placement = {
.num_placement = 1,
.placement = &vram_placement_flags,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/11] drm/vmwgfx: switch over to the new pin interface v2
Stop using TTM_PL_FLAG_NO_EVICT.
v2: fix unconditional pinning
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 49 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 7 +---
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 42 ---
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 2 +-
11 files changed, 39 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
index e8d66182cd7b..ea2f2f937eb3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -459,9 +459,9 @@ int vmw_bo_cpu_blit(struct ttm_buffer_object *dst,
int ret = 0;
/* Buffer objects need to be either pinned or reserved: */
- if (!(dst->mem.placement & TTM_PL_FLAG_NO_EVICT))
+ if (!(dst->pin_count))
dma_resv_assert_held(dst->base.resv);
- if (!(src->mem.placement & TTM_PL_FLAG_NO_EVICT))
+ if (!(src->pin_count))
dma_resv_assert_held(src->base.resv);
if (!ttm_tt_is_populated(dst->ttm)) {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 30d19b45b602..a1f675c5f471 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -106,7 +106,7 @@ int vmw_bo_pin_in_placement(struct vmw_private *dev_priv,
if (unlikely(ret != 0))
goto err;
- if (buf->pin_count > 0)
+ if (buf->base.pin_count > 0)
ret = ttm_bo_mem_compat(placement, &bo->mem,
&new_flags) == true ? 0 : -EINVAL;
else
@@ -155,7 +155,7 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private *dev_priv,
if (unlikely(ret != 0))
goto err;
- if (buf->pin_count > 0) {
+ if (buf->base.pin_count > 0) {
ret = ttm_bo_mem_compat(&vmw_vram_gmr_placement, &bo->mem,
&new_flags) == true ? 0 : -EINVAL;
goto out_unreserve;
@@ -246,12 +246,12 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
if (bo->mem.mem_type == TTM_PL_VRAM &&
bo->mem.start < bo->num_pages &&
bo->mem.start > 0 &&
- buf->pin_count == 0) {
+ buf->base.pin_count == 0) {
ctx.interruptible = false;
(void) ttm_bo_validate(bo, &vmw_sys_placement, &ctx);
}
- if (buf->pin_count > 0)
+ if (buf->base.pin_count > 0)
ret = ttm_bo_mem_compat(&placement, &bo->mem,
&new_flags) == true ? 0 : -EINVAL;
else
@@ -343,23 +343,13 @@ void vmw_bo_pin_reserved(struct vmw_buffer_object *vbo,
bool pin)
dma_resv_assert_held(bo->base.resv);
- if (pin) {
- if (vbo->pin_count++ > 0)
- return;
- } else {
- WARN_ON(vbo->pin_count <= 0);
- if (--vbo->pin_count > 0)
- return;
- }
+ if (pin == !!bo->pin_count)
+ return;
pl.fpfn = 0;
pl.lpfn = 0;
pl.mem_type = bo->mem.mem_type;
pl.flags = bo->mem.placement;
- if (pin)
- pl.flags |= TTM_PL_FLAG_NO_EVICT;
- else
- pl.flags &= ~TTM_PL_FLAG_NO_EVICT;
memset(&placement, 0, sizeof(placement));
placement.num_placement = 1;
@@ -368,8 +358,12 @@ void vmw_bo_pin_reserved(struct vmw_buffer_object *vbo,
bool pin)
ret = ttm_bo_validate(bo, &placement, &ctx);
BUG_ON(ret != 0 || bo->mem.mem_type != old_mem_type);
-}
+ if (pin)
+ ttm_bo_pin(bo);
+ else
+ ttm_bo_unpin(bo);
+}
/**
* vmw_bo_map_and_cache - Map a buffer object and cache the map
@@ -538,6 +532,7 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv,
unsigned long size,
* @size: Buffer object size in bytes.
* @placement: Initial placement.
* @interruptible: Whether waits should be performed interruptible.
+ * @pin: If the BO should be created pinned at a fixed location.
* @bo_free: The buffer object destructor.
* Returns: Zero on success, negative error code on error.
*
@@ -546,9 +541,10 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv,
unsigned long size,
int vmw_bo_init(struct vmw_private *dev_priv,
struct vmw_buffer_object *vmw_bo,
size_t size, struct ttm_placement *placement,
- bool interruptible,
+ bool interruptible, bool pin,
v
