Re: [PATCH 2/7] drm/ttm: use an operation ctx for ttm_mem_global_alloc
Unfortunately the patches are already comitted (with a better commit
message IIRC).
But the variable name sounds just like a style nit pick to me we can fix
in a separate patch as well.
Thanks,
Christian.
Am 25.01.2018 um 00:24 schrieb Sinclair Yeh:
Hi,
Sorry, I've been on a leave. Catching up on emails.
In case this is still not yet merged, my comment is
be consist with the new variable name. In some cases
it's "ttm_opt_ctx", in others it's "ctx".
I prefer ttm_opt_ctx because it's more descriptive.
And yes, some description on why this change is necessary in the
commit message is nice, too.
Sinclair
On Wed, Dec 20, 2017 at 02:33:37PM +0100, Christian König wrote:
Commit message needed! Something like:
Forward the operation context to ttm_mem_global_alloc as well.
Am 20.12.2017 um 11:34 schrieb Roger He:
Change-Id: I5279b5cd3560c4082b00f822219575a5f9c3808a
Signed-off-by: Roger He
With the commit message fixed, patch is Reviewed-by: Christian König
.
I would like to get an rb or ab from Thomas and/or Sinclair as well, since
this is touching a lot of vmwgfx code.
Regards,
Christian.
---
drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
drivers/gpu/drm/ttm/ttm_memory.c| 15 +--
drivers/gpu/drm/ttm/ttm_object.c| 13 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_binding.c | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 13 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 18 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 12 ++--
include/drm/ttm/ttm_memory.h| 3 ++-
13 files changed, 87 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index fa57aa8..c59f572 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1133,7 +1133,7 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
struct ttm_mem_global *mem_glob = bdev->glob->mem_glob;
bool locked;
- ret = ttm_mem_global_alloc(mem_glob, acc_size, false, false);
+ ret = ttm_mem_global_alloc(mem_glob, acc_size, ctx);
if (ret) {
pr_err("Out of kernel memory\n");
if (destroy)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 9130bdf..525d3b6 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -508,7 +508,7 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
static int ttm_mem_global_alloc_zone(struct ttm_mem_global *glob,
struct ttm_mem_zone *single_zone,
uint64_t memory,
-bool no_wait, bool interruptible)
+struct ttm_operation_ctx *ctx)
{
int count = TTM_MEMORY_ALLOC_RETRIES;
@@ -516,7 +516,7 @@ static int ttm_mem_global_alloc_zone(struct ttm_mem_global
*glob,
single_zone,
memory, true)
!= 0)) {
- if (no_wait)
+ if (ctx->no_wait_gpu)
return -ENOMEM;
if (unlikely(count-- == 0))
return -ENOMEM;
@@ -527,15 +527,14 @@ static int ttm_mem_global_alloc_zone(struct
ttm_mem_global *glob,
}
int ttm_mem_global_alloc(struct ttm_mem_global *glob, uint64_t memory,
-bool no_wait, bool interruptible)
+struct ttm_operation_ctx *ctx)
{
/**
* Normal allocations of kernel memory are registered in
* all zones.
*/
- return ttm_mem_global_alloc_zone(glob, NULL, memory, no_wait,
-interruptible);
+ return ttm_mem_global_alloc_zone(glob, NULL, memory, ctx);
}
EXPORT_SYMBOL(ttm_mem_global_alloc);
@@ -544,6 +543,10 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
{
struct ttm_mem_zone *zone = NULL;
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
/**
* Page allocations may be registed in a single zone
@@ -557,7 +560,7 @@ int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
if (glob->zone_dma32 && page_to_pfn(page) > 0x0010UL)
zone = glob->zone_kernel;
#endif
- return ttm_mem_global_alloc_zone(glob, zone, size, false, false);
+ return ttm_mem_global_alloc_zone(glob, zone, size, &ctx);
}
[Bug 104762] Various segfaults/problems in qt/plasma
https://bugs.freedesktop.org/show_bug.cgi?id=104762 --- Comment #7 from Christoph Haag --- (In reply to Timothy Arceri from comment #5) > Created attachment 136950 [details] [review] > possible fix > > I wasn't able to reproduce the issue, but can you give this patch a try? Preliminary result: It does not help, after booting today with the patch plasmashell was segfaulting again until rm -rf ~/.cache/mesa_shader_cache/ ~/.cache/qtshadercache -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks
Op 24-01-18 om 22:47 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> Naturally we can only do that if the index of those objects stays
> below 32. Issue a warning whenever we exceed that limit, hopefully
> prompting someone to fix the problem.
>
> For connectors the issue is a bit more complicated as they can
> be created/destroyed at runtime due to MST. So the problem is no
> longer a purely theoretical programmer error. As the connector
> indexes are allocated via ida, we can simply limit the maximum
> value the ida is allowed to hand out. The error handling is already
> in place.
>
> v2: Return an error to the caller (Harry)
>
> Cc: Harry Wentland
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_connector.c | 3 ++-
> drivers/gpu/drm/drm_crtc.c | 4
> drivers/gpu/drm/drm_encoder.c | 4
> drivers/gpu/drm/drm_plane.c | 4
> 4 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b85a7749709d..f4a689ab990a 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -205,7 +205,8 @@ int drm_connector_init(struct drm_device *dev,
> connector->dev = dev;
> connector->funcs = funcs;
>
> - ret = ida_simple_get(&config->connector_ida, 0, 0, GFP_KERNEL);
> + /* connector index is used with 32bit bitmasks */
> + ret = ida_simple_get(&config->connector_ida, 0, 32, GFP_KERNEL);
> if (ret < 0)
> goto out_put;
> connector->index = ret;
Could we also put a DRM_DEBUG_KMS in here if allocation fails? Since it's more
likely to happen now..
Otherwise looks good so with that change:
Reviewed-by: Maarten Lankhorst
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f0556e654116..5b4be382a1d7 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -282,6 +282,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> struct drm_crtc *crtc,
> WARN_ON(primary && primary->type != DRM_PLANE_TYPE_PRIMARY);
> WARN_ON(cursor && cursor->type != DRM_PLANE_TYPE_CURSOR);
>
> + /* crtc index is used with 32bit bitmasks */
> + if (WARN_ON(config->num_crtc >= 32))
> + return -EINVAL;
> +
> crtc->dev = dev;
> crtc->funcs = funcs;
>
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index 59e0ebe733f8..273e1c59c54a 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -110,6 +110,10 @@ int drm_encoder_init(struct drm_device *dev,
> {
> int ret;
>
> + /* encoder index is used with 32bit bitmasks */
> + if (WARN_ON(dev->mode_config.num_encoder >= 32))
> + return -EINVAL;
> +
> ret = drm_mode_object_add(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 2c90519576a3..22b54663b6e7 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -173,6 +173,10 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> unsigned int format_modifier_count = 0;
> int ret;
>
> + /* plane index is used with 32bit bitmasks */
> + if (WARN_ON(config->num_total_plane >= 32))
> + return -EINVAL;
> +
> ret = drm_mode_object_add(dev, &plane->base, DRM_MODE_OBJECT_PLANE);
> if (ret)
> return ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/etnaviv: remove the need for a gpu-subsystem DT node
Am Mittwoch, den 24.01.2018, 14:49 -0600 schrieb Rob Herring: > On Wed, Jan 24, 2018 at 9:37 AM, Lucas Stach > wrote: > > The module autoloading can be triggered through the GPU core nodes > > and the necessary platform device for the DRM toplevel device will > > be instantiated on module init. > > > > Suggested-by: Rob Herring > > Signed-off-by: Lucas Stach > > --- > > .../bindings/display/etnaviv/etnaviv-drm.txt | 20 -- > > -- > > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 36 > > -- > > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 1 + > > 3 files changed, 20 insertions(+), 37 deletions(-) > > Reviewed-by: Rob Herring > > Are you going to update dts files to remove the node? Sure. I'll send DT update patches for this once this patch has landed in my etnaviv/next tree. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104723] [CI] igt@[kms_3d|igt@kms_panel_fitting] - fail - Could not open data file "1080p-left.png": No such file or directoryReceived signal SIGSEGV.
https://bugs.freedesktop.org/show_bug.cgi?id=104723 Petri Latvala changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Petri Latvala --- commit 9c448ea79ebb0899dc18746fa7f31e19803c4d88 Author: Petri Latvala Date: Mon Jan 22 15:04:07 2018 +0200 meson: Use absolute path for IGT_DATADIR Setting resolved/fixed, will be tested in CI probably this weekend. Depending on the results will reopen or close. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [RFC]drm/ttm: fix scheduling balance
there is a scheduling balance issue about get node like:
a. process A allocates full memory and use it for submission.
b. process B tries to allocates memory, will wait for process A BO idle in
eviction.
c. process A completes the job, process B eviction will put process A BO node,
but in the meantime, process C is comming to allocate BO, whill directly get
node successfully, and do submission,
process B will again wait for process C BO idle.
d. repeat the above setps, process B could be delayed much more.
add a mutex to gerantee the allocation sequence for same domain. But there is a
possibility that
visible vram could be evicted to invisilbe, the tricky is they are same domain
manager, so which needs a special handling.
Change-Id: I260e8eb704f7b4788b071d3f641f21b242912256
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c| 16 +++-
include/drm/ttm/ttm_bo_api.h| 2 ++
include/drm/ttm/ttm_bo_driver.h | 1 +
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index d33a6bb742a1..f465f1d38711 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -969,7 +969,11 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (mem_type == TTM_PL_SYSTEM)
break;
+ if (ctx->man != man)
+ mutex_lock(&man->node_mutex);
ret = (*man->func->get_node)(man, bo, place, mem);
+ if (ctx->man != man)
+ mutex_unlock(&man->node_mutex);
if (unlikely(ret))
return ret;
@@ -991,6 +995,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
for (i = 0; i < placement->num_busy_placement; ++i) {
const struct ttm_place *place = &placement->busy_placement[i];
+ struct ttm_operation_ctx busy_ctx;
ret = ttm_mem_type_from_place(place, &mem_type);
if (ret)
@@ -1018,7 +1023,15 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
return 0;
}
- ret = ttm_bo_mem_force_space(bo, mem_type, place, mem, ctx);
+ memcpy(&busy_ctx, ctx, sizeof(busy_ctx));
+ if (ctx->man != man) {
+ mutex_lock(&man->node_mutex);
+ busy_ctx.man = man;
+ }
+ ret = ttm_bo_mem_force_space(bo, mem_type, place, mem,
+&busy_ctx);
+ if (ctx->man != man)
+ mutex_unlock(&man->node_mutex);
if (ret == 0 && mem->mm_node) {
mem->placement = cur_flags;
return 0;
@@ -1449,6 +1462,7 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned
type,
man->io_reserve_fastpath = true;
man->use_io_reserve_lru = false;
mutex_init(&man->io_reserve_mutex);
+ mutex_init(&man->node_mutex);
spin_lock_init(&man->move_lock);
INIT_LIST_HEAD(&man->io_reserve_lru);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 2cd025c2abe7..b08629050215 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -265,6 +265,7 @@ struct ttm_bo_kmap_obj {
* @no_wait_gpu: Return immediately if the GPU is busy.
* @allow_reserved_eviction: Allow eviction of reserved BOs.
* @resv: Reservation object to allow reserved evictions with.
+ * @man: record ctx is under man->node_mutex.
*
* Context for TTM operations like changing buffer placement or general memory
* allocation.
@@ -275,6 +276,7 @@ struct ttm_operation_ctx {
bool allow_reserved_eviction;
struct reservation_object *resv;
uint64_t bytes_moved;
+ struct ttm_mem_type_manager *man;
};
/**
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 9b417eb2df20..d85d6ee4f54d 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -288,6 +288,7 @@ struct ttm_mem_type_manager {
uint32_t default_caching;
const struct ttm_mem_type_manager_func *func;
void *priv;
+ struct mutex node_mutex;
struct mutex io_reserve_mutex;
bool use_io_reserve_lru;
bool io_reserve_fastpath;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87172] UHD 4K (DisplayPort 1.2) monitor autodetects at 60Hz on Radeon 5870, which fails as this card doesn't support DP1.2
https://bugs.freedesktop.org/show_bug.cgi?id=87172 --- Comment #2 from Paolo Devoti --- Same issue on Ubuntu 17.10 AMD RX480 and an UHD tv see also https://bugs.launchpad.net/ubuntu/+bug/1725395 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC]drm/ttm: fix scheduling balance
Am 25.01.2018 um 10:59 schrieb Chunming Zhou:
there is a scheduling balance issue about get node like:
a. process A allocates full memory and use it for submission.
b. process B tries to allocates memory, will wait for process A BO idle in
eviction.
c. process A completes the job, process B eviction will put process A BO node,
but in the meantime, process C is comming to allocate BO, whill directly get
node successfully, and do submission,
process B will again wait for process C BO idle.
d. repeat the above setps, process B could be delayed much more.
NAK, this is intended behavior please don't change it. If you start to
use a per domain mutex like this no concurrent allocation is possible
any more.
In other words when process B needs a lot of memory and blocks for that
memory to be evicted it is intended that process C which doesn't needs
so much memory can jump in and execute before B.
add a mutex to gerantee the allocation sequence for same domain. But there is a
possibility that
visible vram could be evicted to invisilbe, the tricky is they are same domain
manager, so which needs a special handling.
To avoid lock inversion you would need a global mutex here, otherwise
you can run into the following issue:
Eviction: VRAM domain mutex locked first then GTT mutex.
Swapping in: GTT mutex locked first, then VRAM mutex.
Regards,
Christian.
Change-Id: I260e8eb704f7b4788b071d3f641f21b242912256
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c| 16 +++-
include/drm/ttm/ttm_bo_api.h| 2 ++
include/drm/ttm/ttm_bo_driver.h | 1 +
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index d33a6bb742a1..f465f1d38711 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -969,7 +969,11 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (mem_type == TTM_PL_SYSTEM)
break;
+ if (ctx->man != man)
+ mutex_lock(&man->node_mutex);
ret = (*man->func->get_node)(man, bo, place, mem);
+ if (ctx->man != man)
+ mutex_unlock(&man->node_mutex);
if (unlikely(ret))
return ret;
@@ -991,6 +995,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
for (i = 0; i < placement->num_busy_placement; ++i) {
const struct ttm_place *place = &placement->busy_placement[i];
+ struct ttm_operation_ctx busy_ctx;
ret = ttm_mem_type_from_place(place, &mem_type);
if (ret)
@@ -1018,7 +1023,15 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
return 0;
}
- ret = ttm_bo_mem_force_space(bo, mem_type, place, mem, ctx);
+ memcpy(&busy_ctx, ctx, sizeof(busy_ctx));
+ if (ctx->man != man) {
+ mutex_lock(&man->node_mutex);
+ busy_ctx.man = man;
+ }
+ ret = ttm_bo_mem_force_space(bo, mem_type, place, mem,
+&busy_ctx);
+ if (ctx->man != man)
+ mutex_unlock(&man->node_mutex);
if (ret == 0 && mem->mm_node) {
mem->placement = cur_flags;
return 0;
@@ -1449,6 +1462,7 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned
type,
man->io_reserve_fastpath = true;
man->use_io_reserve_lru = false;
mutex_init(&man->io_reserve_mutex);
+ mutex_init(&man->node_mutex);
spin_lock_init(&man->move_lock);
INIT_LIST_HEAD(&man->io_reserve_lru);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 2cd025c2abe7..b08629050215 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -265,6 +265,7 @@ struct ttm_bo_kmap_obj {
* @no_wait_gpu: Return immediately if the GPU is busy.
* @allow_reserved_eviction: Allow eviction of reserved BOs.
* @resv: Reservation object to allow reserved evictions with.
+ * @man: record ctx is under man->node_mutex.
*
* Context for TTM operations like changing buffer placement or general memory
* allocation.
@@ -275,6 +276,7 @@ struct ttm_operation_ctx {
bool allow_reserved_eviction;
struct reservation_object *resv;
uint64_t bytes_moved;
+ struct ttm_mem_type_manager *man;
};
/**
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 9b417eb2df20..d85d6ee4f54d 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -288,6 +288,7 @@ struct ttm_mem_type_manager {
uint32_t default_caching;
const struct ttm_mem_type_manager_func *func;
void *priv;
+ struct mutex node_mutex;
struct mutex io_reserve_mutex;
bool use_io_reserve_lru;
Re: [Mesa-dev] [PATCH 0/2] Small fixes for the meson build
On Wednesday, 2018-01-24 14:31:08 -0800, Dylan Baker wrote: > ping Both patches are correct: Reviewed-by: Eric Engestrom > > Quoting Dylan Baker (2018-01-12 11:57:34) > > Here's a few things I've caught as I've started trying to add the meson > > build to our CI system. > > > > Dylan Baker (2): > > meson: set proper pkg-config version for libdrm_freedreno > > meson: set the minimum version correctly > > > > freedreno/meson.build | 2 +- > > meson.build | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > base-commit: fd9bcb73e9c5a01085069b37c2f5e04300a9b4d4 > > -- > > git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] meson: set proper pkg-config version for libdrm_freedreno
Hi Dylan, To make it easier to spot these, do set the git subject prefix to PATCH libdrm. See autogen.sh for an example. On 12 January 2018 at 19:57, Dylan Baker wrote: > Copy and paste error from exynos. > > Signed-off-by: Dylan Baker > --- > freedreno/meson.build | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/freedreno/meson.build b/freedreno/meson.build > index b4035e1..de6a413 100644 > --- a/freedreno/meson.build > +++ b/freedreno/meson.build > @@ -64,7 +64,7 @@ pkg.generate( >name : 'libdrm_freedreno', >libraries : libdrm_freedreno, >subdirs : ['.', 'libdrm', 'freedreno'], > - version : '0.7', > + version : meson.project_version(), Ideally we'll have version file(s) to share across builds - both the shared libraries' --version-info and the pkg-config ones. Otherwise things will be out of sync far too often. But that can happen as a follow-up. The series is Reviewed-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104762] Various segfaults/problems in qt/plasma
https://bugs.freedesktop.org/show_bug.cgi?id=104762 --- Comment #8 from Dieter Nützel --- Sometimes I wiped this, too. .cache/plasmashell/qmlcache/ .cache/ksycoca5_de_*** .cache/plasma-svgelements-*** .cache/plasma_theme_*** .cache/icon-cache.kcache All above files would be regenerated automatically. After this KDE5/Plasma5 started all the time with a nice/clean desktop, again. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] drm/bridge/synopsys: dsi: Add fix & warning in dsi_host_transfer()
Add a fix & a warning in the dsi_host_transfer(). Version 2: - Simplify the 2 patches following comments from Brian Norris. - Swap the 2 patches as the return value is only on tx and in case of rx requests the warning is there. Version 1: - Initial commit Philippe Cornu (2): drm/bridge/synopsys: dsi: Add a warning msg on dsi read requests drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value
The dw_mipi_dsi_host_transfer() must return the number of
bytes transmitted/received on success instead of 0.
Note: As the read feature is not implemented, only the
transmitted number of bytes is returned for the moment.
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 72ecaeb40822..090bf62d1ea8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -419,7 +419,16 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
mipi_dsi_host *host,
dw_mipi_message_config(dsi, msg);
- return dw_mipi_dsi_write(dsi, &packet);
+ ret = dw_mipi_dsi_write(dsi, &packet);
+ if (ret)
+ return ret;
+
+ /*
+* TODO Only transmitted size is returned as actual driver does
+* not support dcs/generic reads. Please update return value when
+* delivering the read feature.
+*/
+ return packet.size;
}
static const struct mipi_dsi_host_ops dw_mipi_dsi_host_ops = {
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/bridge/synopsys: dsi: Add a warning msg on dsi read requests
The dcs/generic dsi read feature is not yet implemented so it
is important to warn the host_transfer() caller in case of
read operation requests.
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index daec7881be6d..72ecaeb40822 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -405,6 +405,12 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
mipi_dsi_host *host,
struct mipi_dsi_packet packet;
int ret;
+ if (msg->rx_buf || msg->rx_len) {
+ /* TODO dw drv improvements: implement read feature */
+ dev_warn(dsi->dev, "read operations not yet implemented\n");
+ return -EINVAL;
+ }
+
ret = mipi_dsi_create_packet(&packet, msg);
if (ret) {
dev_err(dsi->dev, "failed to create packet: %d\n", ret);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104762] Various segfaults/problems in qt/plasma
https://bugs.freedesktop.org/show_bug.cgi?id=104762 --- Comment #9 from Mike Lothian --- It might be worth keeping these somewhere rather than deleting. Once everything is working, copy them back see if they issue can be reproduced that way -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 1/4] drm: Add colorkey properties
On Sun, Dec 17, 2017 at 02:17:21AM +0200, Laurent Pinchart wrote: > Color keying is the action of replacing pixels matching a given color > (or range of colors) with transparent pixels in an overlay when > performing blitting. Depending on the hardware capabilities, the > matching pixel can either become fully transparent, or gain a > programmable alpha value. > > Color keying is found in a large number of devices whose capabilities > often differ, but they still have enough common features in range to > standardize color key properties. This commit adds four properties > related to color keying named colorkey.min, colorkey.max, colorkey.alpha > and colorkey.mode. Additional properties can be defined by drivers to > expose device-specific features. > > Signed-off-by: Laurent Pinchart Sorry for the delay, Reviewed-by: Maxime Ripard Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 4/4] drm: rcar-du: Add support for color keying on Gen3
Hi,
On Sun, Dec 17, 2017 at 02:17:24AM +0200, Laurent Pinchart wrote:
> +static const struct drm_prop_enum_list colorkey_modes[] = {
> + { 0, "disabled" },
> + { 1, "source" },
> +};
> +
> int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np,
>unsigned int crtcs)
> {
> @@ -441,6 +453,10 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct
> device_node *np,
> rcdu->props.alpha, 255);
> drm_plane_create_zpos_property(&plane->plane, 1, 1,
> vsp->num_planes - 1);
> + drm_plane_create_colorkey_properties(&plane->plane,
> + colorkey_modes,
> + ARRAY_SIZE(colorkey_modes),
> + true);
You seem to define the same list in your enumeration between your
patch 2 and this one. Can this be something made generic too?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()
On 24.01.2018 10:51, Philippe CORNU wrote: > Hi Brian, > > On 01/23/2018 10:15 PM, Brian Norris wrote: >> Hi Philippe, >> >> On Thu, Jan 18, 2018 at 11:40:48AM +, Philippe CORNU wrote: >>> On 01/11/2018 12:16 PM, Philippe CORNU wrote: To be honest, I do not really like the memcpy here too and I agree with you regarding the BE issue. My first "stm" driver (ie. before using this "freescale/rockchip" dw-mipi-dsi driver with the memcpy) used the "exact" same code as the Tegra dsi tegra_dsi_writesl() function with the 2 loops. https://elixir.free-electrons.com/linux/v4.14/source/drivers/gpu/drm/tegra/dsi.c#L1248 IMHO, it is better than memcpy... I added these 3 "documentation" lines, maybe we may reuse them or something similar... /* * Write 8-bit payload data into the 32-bit payload data register. * ex: payload data "0x01, 0x02, 0x03, 0x04, 0x05, 0x06" will become * "0x04030201 0x0605" 32-bit writes */ Not sure it helps to fix the BE issue but we may add a TODO stating that "this loop has not been tested on BE"... What is your opinion? >> I'm sorry, I don't think I noticed your reply here. I'm trying to unbury >> some email, but that's sometimes a losing battle... >> >> That code actually does look correct, and it's perhaps marginally >> better-looking in my opinion. It's up to you if you want to propose >> another patch :) At this point, it's only a matter of nice code, not >> correctness I believe. >> >>> As your patch has been merged, I have few short questions and for each >>> related new patch, I would like to know if you prefer that I implement >>> it or if you prefer to do it by yourself, it's really like you want, on >>> my side, no problem to make them all, some or none, I don't want us to >>> implement these in parallel :-) >>> >>> * Do you have any opinion regarding Tegra-like loops vs the memcpy? (see >>> my comment above) If you think the Tegra-like loops is a better approach >>> than memcpy, there is a small patch to write. >> My opinion is above. >> > I do not know yet if I will send a patch but several reasons may push me > to do it: > * Andrzej proposed a nicer code in his last review so it means the > actual code with memcpy's is "not so nice" (even if it works fine) I was not against memcpy, I have just suggested to abstract the code out to some helper function. Regarding memcpy vs loop I would prefer memcpy - simpler code, but it is looks less important that abstracting out. Regards Andrzej > * Several dsi drivers use the Tegra-like loops (Tegra, intel,... ) and > in vc4/exynos/mtk drivers memcpy is not used, msm uses memcpy... well, > not sure it is then a good argument, different solutions for different hw... > * Coming cadence dsi bridge driver uses Tegra-like loops. > * I think my read function will also have Tegra-like loops, if it is the > case, it could be nice to have something homogeneous... > > Anyway, it is not an important point : ) > >>> * Returned value with number of bytes received/transferred: there is a >>> small patch to write >> I don't think I followed that one very well. I'm not sure my opinion >> really matters, as long as you get someone else to agree. I do not plan >> to write any such patch in the near term. >> >>> * Regarding read operations: I propose to add a TODO + DRM_WARN in case >>> someone want to use the API for read operations. Note that I plan to >>> implement the read feature but I do not know yet when and maybe Rockchip >>> people already have something ~ready? >> The warning would be nice to do now, regardless. >> >> Rockchip folks wrote up something for read support here [1], but it's >> based on a semi-forked version of the driver (we're trying to clean up >> the divergence, but it's not there yet). Perhaps it would provide useful >> fodder for your work. I don't think Rockchip is immediately working on >> upstreaming this particular patch, so it's totally fair to handle it >> yourself. It's got the GPL sign-off ;) >> >> Brian >> >> [1] >> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/863347 >> > Very good information, I will have a look, > many thanks > Philippe :-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v19 10/10] drm/omapdrm: Use of_find_backlight helper
On Wed, Jan 24, 2018 at 02:26:48PM -0500, Sean Paul wrote: > So, > > Reviewed-by: Sean Paul > > I think every other patch has R-b, so if no one objects in the next day or so, > I'll apply this to drm-misc-next No problems on my side... but please make sure Lee J. gets a PR. Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC v2 0/6] DRM logging tidy
On Wed, 24 Jan 2018, Tvrtko Ursulin wrote: > On 24/01/2018 16:23, Chris Wilson wrote: >> Quoting Tvrtko Ursulin (2018-01-24 16:18:15) >>> From: Tvrtko Ursulin >>> >>> This series tries to solve a few issues in the current DRM logging code to >>> primarily make it clearer which messages belong to which driver. >>> >>> Main problem is that currently some logging functions allow individual >>> drivers >>> to override the log prefix (since they are defined as macros, or static >>> inlines), while other hardcode the "drm" prefix into them due being >>> situated in >>> the DRM core modules. >>> >>> Another thing is that I noticed the DRM_NAME macro which is used for this is >>> defined in the uAPI header and had a comment which looked outdated. >>> >>> Therefore I introduce a new define, called, DRM_LOG_NAME, this time defined >>> internally in the kernel headers and not exported in the uAPI. >>> >>> I also refactored some logging functions to take this string as a parameter >>> instead of hardcoding it. >>> >>> Individual drivers can then override this define to make DRM logging >>> functions >>> prefix their message with the respective driver prefix. >>> >>> End result in the case of the i915 driver looks like this: >>> >>> Old log: >>> >>> [drm] Found 128MB of eDRAM >>> [drm:skl_enable_dc6 [i915]] Enabling DC6 >>> >>> New log: >>> >>> [i915] Found 128MB of eDRAM >>> [i915:skl_enable_dc6 [i915]] Enabling DC6 >> >> And still not conforming to the standard logging string. DRM_LOG should > > What is the standard logging string? the dev_ one? > >> be killed off as an anachronistic OS compat layer. > > You mean only dev variants should be kept? I think the DRM_LOG_NAME override mechanism is too fragile, as it depends on #include ordering. For our driver, I think it basically means always including one of our headers (i915_drv.h) first everywhere (to have a single point of truth for DRM_LOG_NAME), and including drm_print.h first from there. That's not currently true, and I don't want to see a massive #include reordering patchset to make it so. This is like pr_fmt() which I think has been a mistake and should not be repeated. I think the direction to go is using dev_printk, dev_dbg, dev_err, dev_warn, and friends, which use dev_driver_string internally. We already have some drm wrappers for those. The problem with them is passing dev, and I think that's the problem we should think about. We also seem to have opted to use drm_dev_printk (which calls dev_printk or printk) for DRM_DEV_DEBUG and friends. This is arguably a bad choice, because using dev_dbg would let us make use of dynamic debug. BR, Jani. > > Regards, > > Tvrtko > > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks
On Thu, Jan 25, 2018 at 10:17:21AM +0100, Maarten Lankhorst wrote:
> Op 24-01-18 om 22:47 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> > Naturally we can only do that if the index of those objects stays
> > below 32. Issue a warning whenever we exceed that limit, hopefully
> > prompting someone to fix the problem.
> >
> > For connectors the issue is a bit more complicated as they can
> > be created/destroyed at runtime due to MST. So the problem is no
> > longer a purely theoretical programmer error. As the connector
> > indexes are allocated via ida, we can simply limit the maximum
> > value the ida is allowed to hand out. The error handling is already
> > in place.
> >
> > v2: Return an error to the caller (Harry)
> >
> > Cc: Harry Wentland
> > Cc: Maarten Lankhorst
> > Cc: Daniel Vetter
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_connector.c | 3 ++-
> > drivers/gpu/drm/drm_crtc.c | 4
> > drivers/gpu/drm/drm_encoder.c | 4
> > drivers/gpu/drm/drm_plane.c | 4
> > 4 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index b85a7749709d..f4a689ab990a 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -205,7 +205,8 @@ int drm_connector_init(struct drm_device *dev,
> > connector->dev = dev;
> > connector->funcs = funcs;
> >
> > - ret = ida_simple_get(&config->connector_ida, 0, 0, GFP_KERNEL);
> > + /* connector index is used with 32bit bitmasks */
> > + ret = ida_simple_get(&config->connector_ida, 0, 32, GFP_KERNEL);
> > if (ret < 0)
> > goto out_put;
> > connector->index = ret;
> Could we also put a DRM_DEBUG_KMS in here if allocation fails? Since it's
> more likely to happen now..
I was actually pondering using DRM_ERROR(), or maybe even WARN(). It
shouldn't be directly user triggerable so I think we want to get the
bugreport if we do run out of bits.
>
> Otherwise looks good so with that change:
> Reviewed-by: Maarten Lankhorst
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index f0556e654116..5b4be382a1d7 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -282,6 +282,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> > struct drm_crtc *crtc,
> > WARN_ON(primary && primary->type != DRM_PLANE_TYPE_PRIMARY);
> > WARN_ON(cursor && cursor->type != DRM_PLANE_TYPE_CURSOR);
> >
> > + /* crtc index is used with 32bit bitmasks */
> > + if (WARN_ON(config->num_crtc >= 32))
> > + return -EINVAL;
> > +
> > crtc->dev = dev;
> > crtc->funcs = funcs;
> >
> > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > index 59e0ebe733f8..273e1c59c54a 100644
> > --- a/drivers/gpu/drm/drm_encoder.c
> > +++ b/drivers/gpu/drm/drm_encoder.c
> > @@ -110,6 +110,10 @@ int drm_encoder_init(struct drm_device *dev,
> > {
> > int ret;
> >
> > + /* encoder index is used with 32bit bitmasks */
> > + if (WARN_ON(dev->mode_config.num_encoder >= 32))
> > + return -EINVAL;
> > +
> > ret = drm_mode_object_add(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
> > if (ret)
> > return ret;
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 2c90519576a3..22b54663b6e7 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -173,6 +173,10 @@ int drm_universal_plane_init(struct drm_device *dev,
> > struct drm_plane *plane,
> > unsigned int format_modifier_count = 0;
> > int ret;
> >
> > + /* plane index is used with 32bit bitmasks */
> > + if (WARN_ON(config->num_total_plane >= 32))
> > + return -EINVAL;
> > +
> > ret = drm_mode_object_add(dev, &plane->base, DRM_MODE_OBJECT_PLANE);
> > if (ret)
> > return ret;
>
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/bridge/synopsys: dsi: add optional pixel clock
Hi Brian, On 01/24/2018 07:09 PM, Brian Norris wrote: > On Wed, Jan 24, 2018 at 09:24:06AM +, Philippe CORNU wrote: >> On 01/23/2018 09:49 PM, Brian Norris wrote: >>> On Tue, Jan 23, 2018 at 06:08:06PM +0100, Philippe Cornu wrote: --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > @@ -828,6 +833,14 @@ __dw_mipi_dsi_probe(struct platform_device *pdev, return ERR_PTR(ret); } + dsi->px_clk = devm_clk_get(dev, "px_clk"); >>> >>> Did you write a device tree binding document update for this anywhere? >> >> Many thanks for your review, >> >> yes, "px_clk" is already documented, please have a look to >> Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt > > Ah, I see. Normally I expect that the binding document is sent around > when the first user of it shows up, but I guess that's not a > requirement. Sorry I missed that! > > Just a note: I don't think that Rockchip systems have an equivalent > clock from which to directly derive the pixel clock rate. I believe it's > controlled through additional dividers that are not part of the common > clock framework. So this isn't particularly useful for them. > > I don't think it's worth very much in this case, but: > > Reviewed-by: Brian Norris > Many thanks for the review and your comments. Looking more deeply into the rockchip vop driver (in order to understand how the px clock is used), I can see that adjusted_mode/mode_fixup is (now) used. I have already tried to use adjusted_mode/mode_fixup on stm32 but without success. Nevertheless, I will do more tests with adjusted_mode/mode_fixup as it could help to have a simpler patch than adding the px_clk. Many thanks, Philippe :-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()
Hi Andrzej, On 01/25/2018 12:07 PM, Andrzej Hajda wrote: > On 24.01.2018 10:51, Philippe CORNU wrote: >> Hi Brian, >> >> On 01/23/2018 10:15 PM, Brian Norris wrote: >>> Hi Philippe, >>> >>> On Thu, Jan 18, 2018 at 11:40:48AM +, Philippe CORNU wrote: On 01/11/2018 12:16 PM, Philippe CORNU wrote: > To be honest, I do not really like the memcpy here too and I agree with > you regarding the BE issue. > > My first "stm" driver (ie. before using this "freescale/rockchip" > dw-mipi-dsi driver with the memcpy) used the "exact" same code as the > Tegra dsi tegra_dsi_writesl() function with the 2 loops. > > https://elixir.free-electrons.com/linux/v4.14/source/drivers/gpu/drm/tegra/dsi.c#L1248 > > > IMHO, it is better than memcpy... > I added these 3 "documentation" lines, maybe we may reuse them or > something similar... > > /* > * Write 8-bit payload data into the 32-bit payload data register. > * ex: payload data "0x01, 0x02, 0x03, 0x04, 0x05, 0x06" will become > * "0x04030201 0x0605" 32-bit writes > */ > > Not sure it helps to fix the BE issue but we may add a TODO stating that > "this loop has not been tested on BE"... > > What is your opinion? >>> I'm sorry, I don't think I noticed your reply here. I'm trying to unbury >>> some email, but that's sometimes a losing battle... >>> >>> That code actually does look correct, and it's perhaps marginally >>> better-looking in my opinion. It's up to you if you want to propose >>> another patch :) At this point, it's only a matter of nice code, not >>> correctness I believe. >>> As your patch has been merged, I have few short questions and for each related new patch, I would like to know if you prefer that I implement it or if you prefer to do it by yourself, it's really like you want, on my side, no problem to make them all, some or none, I don't want us to implement these in parallel :-) * Do you have any opinion regarding Tegra-like loops vs the memcpy? (see my comment above) If you think the Tegra-like loops is a better approach than memcpy, there is a small patch to write. >>> My opinion is above. >>> >> I do not know yet if I will send a patch but several reasons may push me >> to do it: >> * Andrzej proposed a nicer code in his last review so it means the >> actual code with memcpy's is "not so nice" (even if it works fine) > > I was not against memcpy, I have just suggested to abstract the code out > to some helper function. > Regarding memcpy vs loop I would prefer memcpy - simpler code, but it is > looks less important that abstracting out. > > Regards > Andrzej > > Many thanks for the clarification. Good to know your preference here for memcpy. So then if someone decides to rework this piece of code, all these arguments in this email thread will help. Many thanks Philippe :-) >> * Several dsi drivers use the Tegra-like loops (Tegra, intel,... ) and >> in vc4/exynos/mtk drivers memcpy is not used, msm uses memcpy... well, >> not sure it is then a good argument, different solutions for different hw... >> * Coming cadence dsi bridge driver uses Tegra-like loops. >> * I think my read function will also have Tegra-like loops, if it is the >> case, it could be nice to have something homogeneous... >> >> Anyway, it is not an important point : ) >> * Returned value with number of bytes received/transferred: there is a small patch to write >>> I don't think I followed that one very well. I'm not sure my opinion >>> really matters, as long as you get someone else to agree. I do not plan >>> to write any such patch in the near term. >>> * Regarding read operations: I propose to add a TODO + DRM_WARN in case someone want to use the API for read operations. Note that I plan to implement the read feature but I do not know yet when and maybe Rockchip people already have something ~ready? >>> The warning would be nice to do now, regardless. >>> >>> Rockchip folks wrote up something for read support here [1], but it's >>> based on a semi-forked version of the driver (we're trying to clean up >>> the divergence, but it's not there yet). Perhaps it would provide useful >>> fodder for your work. I don't think Rockchip is immediately working on >>> upstreaming this particular patch, so it's totally fair to handle it >>> yourself. It's got the GPL sign-off ;) >>> >>> Brian >>> >>> [1] >>> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/863347 >>> >> Very good information, I will have a look, >> many thanks >> Philippe :-) > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value
On 24.01.2018 19:37, Brian Norris wrote: > Hi Philippe, > > On Wed, Jan 24, 2018 at 01:33:54PM +, Philippe CORNU wrote: >> On 01/23/2018 10:38 PM, Brian Norris wrote: >>> Hi Philippe, >>> >>> On Tue, Jan 23, 2018 at 6:26 AM, Philippe Cornu >>> wrote: The dw_mipi_dsi_host_transfer() must return the number of bytes transmitted/received on success instead of 0. >>> I'm a little confused. As of the latest drm-misc-next I'm looking at, >>> this still has conflicting documentation. >>> >>> For ->transfer(): >>> >>> On success it shall return the number of bytes >>> * transmitted for write packets or the number of bytes received for read >>> * packets. >>> >>> While mipi_dsi_generic_read() says: >>> >>> * Return: The number of bytes successfully read or a negative error code >>> on >>> * failure. >>> >>> But it just returns the value that ->transfer() returns. >>> >> Not sure to follow you here: mipi_dsi_generic_read() will trig a dsi >> generic read so it has to return "the number of bytes received for read >> packets" as explained for the ->transfer() function... so it looks >> "coherent"... >> >> But maybe you want to point out something different? > Actually, reading back what I wrote, I'm not sure it made sense. I think > *I* was confusing "supporting TX only" with "supporting TX and RX". I > believe the documentation isn't conflicting, but your current patch is a > little misleading. > > With your current patch, you're returning the 'mipi_dsi_packet::size', > which is the sum of both TX and RX. I did not found docs saying mipi_dsi_packet::size is a sum of tx and rx. tx and rx packets are two different packets, so they do not sum up. But thanks for bringing it up, it shows docs are incomplete/misleading. > Since we only support TX right now, > I suppose that actually is fine (because 'rx_len == 0'). But if we start > supporting RX too, then this field is not the right one to return. > > Anyway, maybe this patch was fine as it was. But when you get RX > support, this will have to be something like: > > if (msg->rx_len) > return msg->rx_len; > else > return packet.size; > > BTW, does anyone actually care about seeing the number of TX bytes > returned? That seems weird, because I wouldn't expect you'd get a good > result from a partial TX (dunno about partial RX). And I also see that > there are other drivers that get this all wrong too. See > mtk_dsi_host_transfer(), which only returns 0 for TX and 'recv_cnt' for > RX. As far as I remember MIPI DSI standard does not allow partial TX, it is all-or-nothing operation. > > So all-in-all, maybe my problem isn't that the documentation is > conflicting, exactly, but that the requirements are somewhat odd, such > that either implementations get it wrong (2 of 3 that I've looked at!), > or they have to write somewhat odd special-casing. mipi_dsi_host_ops::transfer in case of write sends only tx packet, in case of read it sends tx packets and receives rx packet, so it can be confusing what it should return in case of read. IMO changing mipi_dsi_host_ops::transfer to always return number of bytes RECEIVED or error should make it clearer and simpler. +CC Thierry Regards Andrzej > >>> So I'm not sure whether the documentation is still wrong, or if the >>> implementation is. >>> >>> Anyway, I guess maybe that isn't super-critical to *this* patch, since >>> we don't have RX support yet... >>> >> The main reason why I want to "fix" this is because I do not want to >> explain to our customers (writing dsi panel drivers) why we have a >> different returned value compare to other platforms : ) > Brian > ___ > 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: [Intel-gfx] [PATCH v2] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks
On Thu, Jan 25, 2018 at 01:27:27PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 25, 2018 at 10:17:21AM +0100, Maarten Lankhorst wrote:
> > Op 24-01-18 om 22:47 schreef Ville Syrjala:
> > > From: Ville Syrjälä
> > >
> > > We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> > > Naturally we can only do that if the index of those objects stays
> > > below 32. Issue a warning whenever we exceed that limit, hopefully
> > > prompting someone to fix the problem.
> > >
> > > For connectors the issue is a bit more complicated as they can
> > > be created/destroyed at runtime due to MST. So the problem is no
> > > longer a purely theoretical programmer error. As the connector
> > > indexes are allocated via ida, we can simply limit the maximum
> > > value the ida is allowed to hand out. The error handling is already
> > > in place.
> > >
> > > v2: Return an error to the caller (Harry)
> > >
> > > Cc: Harry Wentland
> > > Cc: Maarten Lankhorst
> > > Cc: Daniel Vetter
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/drm_connector.c | 3 ++-
> > > drivers/gpu/drm/drm_crtc.c | 4
> > > drivers/gpu/drm/drm_encoder.c | 4
> > > drivers/gpu/drm/drm_plane.c | 4
> > > 4 files changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_connector.c
> > > b/drivers/gpu/drm/drm_connector.c
> > > index b85a7749709d..f4a689ab990a 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -205,7 +205,8 @@ int drm_connector_init(struct drm_device *dev,
> > > connector->dev = dev;
> > > connector->funcs = funcs;
> > >
> > > - ret = ida_simple_get(&config->connector_ida, 0, 0, GFP_KERNEL);
> > > + /* connector index is used with 32bit bitmasks */
> > > + ret = ida_simple_get(&config->connector_ida, 0, 32, GFP_KERNEL);
> > > if (ret < 0)
> > > goto out_put;
> > > connector->index = ret;
> > Could we also put a DRM_DEBUG_KMS in here if allocation fails? Since it's
> > more likely to happen now..
>
> I was actually pondering using DRM_ERROR(), or maybe even WARN(). It
> shouldn't be directly user triggerable so I think we want to get the
> bugreport if we do run out of bits.
OTOH we are likely to get the "my screen don't work" bugreport anyway,
so maybe a debug print is enough.
>
> >
> > Otherwise looks good so with that change:
> > Reviewed-by: Maarten Lankhorst
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index f0556e654116..5b4be382a1d7 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -282,6 +282,10 @@ int drm_crtc_init_with_planes(struct drm_device
> > > *dev, struct drm_crtc *crtc,
> > > WARN_ON(primary && primary->type != DRM_PLANE_TYPE_PRIMARY);
> > > WARN_ON(cursor && cursor->type != DRM_PLANE_TYPE_CURSOR);
> > >
> > > + /* crtc index is used with 32bit bitmasks */
> > > + if (WARN_ON(config->num_crtc >= 32))
> > > + return -EINVAL;
> > > +
> > > crtc->dev = dev;
> > > crtc->funcs = funcs;
> > >
> > > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > > index 59e0ebe733f8..273e1c59c54a 100644
> > > --- a/drivers/gpu/drm/drm_encoder.c
> > > +++ b/drivers/gpu/drm/drm_encoder.c
> > > @@ -110,6 +110,10 @@ int drm_encoder_init(struct drm_device *dev,
> > > {
> > > int ret;
> > >
> > > + /* encoder index is used with 32bit bitmasks */
> > > + if (WARN_ON(dev->mode_config.num_encoder >= 32))
> > > + return -EINVAL;
> > > +
> > > ret = drm_mode_object_add(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
> > > if (ret)
> > > return ret;
> > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > index 2c90519576a3..22b54663b6e7 100644
> > > --- a/drivers/gpu/drm/drm_plane.c
> > > +++ b/drivers/gpu/drm/drm_plane.c
> > > @@ -173,6 +173,10 @@ int drm_universal_plane_init(struct drm_device *dev,
> > > struct drm_plane *plane,
> > > unsigned int format_modifier_count = 0;
> > > int ret;
> > >
> > > + /* plane index is used with 32bit bitmasks */
> > > + if (WARN_ON(config->num_total_plane >= 32))
> > > + return -EINVAL;
> > > +
> > > ret = drm_mode_object_add(dev, &plane->base, DRM_MODE_OBJECT_PLANE);
> > > if (ret)
> > > return ret;
> >
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks
From: Ville Syrjälä
We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
Naturally we can only do that if the index of those objects stays
below 32. Issue a warning whenever we exceed that limit, hopefully
prompting someone to fix the problem.
For connectors the issue is a bit more complicated as they can
be created/destroyed at runtime due to MST. So the problem is no
longer a purely theoretical programmer error. As the connector
indexes are allocated via ida, we can simply limit the maximum
value the ida is allowed to hand out. The error handling is already
in place.
v2: Return an error to the caller (Harry)
v3: Print a debug message so that we know what happened (Maarten)
Cc: Harry Wentland
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Reviewed-by: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 9 +++--
drivers/gpu/drm/drm_crtc.c | 4
drivers/gpu/drm/drm_encoder.c | 4
drivers/gpu/drm/drm_plane.c | 4
4 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b85a7749709d..16b9c3810af2 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -205,9 +205,14 @@ int drm_connector_init(struct drm_device *dev,
connector->dev = dev;
connector->funcs = funcs;
- ret = ida_simple_get(&config->connector_ida, 0, 0, GFP_KERNEL);
- if (ret < 0)
+ /* connector index is used with 32bit bitmasks */
+ ret = ida_simple_get(&config->connector_ida, 0, 32, GFP_KERNEL);
+ if (ret < 0) {
+ DRM_DEBUG_KMS("Failed to allocate %s connector index: %d\n",
+ drm_connector_enum_list[connector_type].name,
+ ret);
goto out_put;
+ }
connector->index = ret;
ret = 0;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f0556e654116..5b4be382a1d7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -282,6 +282,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
WARN_ON(primary && primary->type != DRM_PLANE_TYPE_PRIMARY);
WARN_ON(cursor && cursor->type != DRM_PLANE_TYPE_CURSOR);
+ /* crtc index is used with 32bit bitmasks */
+ if (WARN_ON(config->num_crtc >= 32))
+ return -EINVAL;
+
crtc->dev = dev;
crtc->funcs = funcs;
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 59e0ebe733f8..273e1c59c54a 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -110,6 +110,10 @@ int drm_encoder_init(struct drm_device *dev,
{
int ret;
+ /* encoder index is used with 32bit bitmasks */
+ if (WARN_ON(dev->mode_config.num_encoder >= 32))
+ return -EINVAL;
+
ret = drm_mode_object_add(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 2c90519576a3..22b54663b6e7 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -173,6 +173,10 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
unsigned int format_modifier_count = 0;
int ret;
+ /* plane index is used with 32bit bitmasks */
+ if (WARN_ON(config->num_total_plane >= 32))
+ return -EINVAL;
+
ret = drm_mode_object_add(dev, &plane->base, DRM_MODE_OBJECT_PLANE);
if (ret)
return ret;
--
2.13.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC v2 0/6] DRM logging tidy
On 25/01/2018 11:32, Jani Nikula wrote: On Wed, 24 Jan 2018, Tvrtko Ursulin wrote: On 24/01/2018 16:23, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-01-24 16:18:15) From: Tvrtko Ursulin This series tries to solve a few issues in the current DRM logging code to primarily make it clearer which messages belong to which driver. Main problem is that currently some logging functions allow individual drivers to override the log prefix (since they are defined as macros, or static inlines), while other hardcode the "drm" prefix into them due being situated in the DRM core modules. Another thing is that I noticed the DRM_NAME macro which is used for this is defined in the uAPI header and had a comment which looked outdated. Therefore I introduce a new define, called, DRM_LOG_NAME, this time defined internally in the kernel headers and not exported in the uAPI. I also refactored some logging functions to take this string as a parameter instead of hardcoding it. Individual drivers can then override this define to make DRM logging functions prefix their message with the respective driver prefix. End result in the case of the i915 driver looks like this: Old log: [drm] Found 128MB of eDRAM [drm:skl_enable_dc6 [i915]] Enabling DC6 New log: [i915] Found 128MB of eDRAM [i915:skl_enable_dc6 [i915]] Enabling DC6 And still not conforming to the standard logging string. DRM_LOG should What is the standard logging string? the dev_ one? be killed off as an anachronistic OS compat layer. You mean only dev variants should be kept? I think the DRM_LOG_NAME override mechanism is too fragile, as it depends on #include ordering. For our driver, I think it basically means always including one of our headers (i915_drv.h) first everywhere (to have a single point of truth for DRM_LOG_NAME), and including drm_print.h first from there. That's not currently true, and I don't want to see a massive #include reordering patchset to make it so. This is like pr_fmt() which I think has been a mistake and should not be repeated. I think the direction to go is using dev_printk, dev_dbg, dev_err, dev_warn, and friends, which use dev_driver_string internally. We already have some drm wrappers for those. The problem with them is passing dev, and I think that's the problem we should think about. We also seem to have opted to use drm_dev_printk (which calls dev_printk or printk) for DRM_DEV_DEBUG and friends. This is arguably a bad choice, because using dev_dbg would let us make use of dynamic debug. I agree the current state is messy and that a better improvement could be made. And that the macro string approach is ugly. To my defence, it sounded like a smaller amount of work to make it at least a little bit better. The way I implemented it, as long as the define is before any include directives it will work as expected. And on my T460p which has both nouveau and i915 it makes the kernel log a bit less confusing. But yeah, it is a marginal user base. Scratch this then, previous posting was only two years ago so it can wait some more for a more thorough etc rework. Regards, Tvrtko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87172] UHD 4K (DisplayPort 1.2) monitor autodetects at 60Hz on Radeon 5870, which fails as this card doesn't support DP1.2
https://bugs.freedesktop.org/show_bug.cgi?id=87172 --- Comment #3 from Alex Deucher --- (In reply to Paolo Devoti from comment #2) > Same issue on Ubuntu 17.10 AMD RX480 and an UHD tv > see also > https://bugs.launchpad.net/ubuntu/+bug/1725395 Your chip is supported by a different driver (radeon vs amdgpu) please open your own bug. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87172] UHD 4K (DisplayPort 1.2) monitor autodetects at 60Hz on Radeon 5870, which fails as this card doesn't support DP1.2
https://bugs.freedesktop.org/show_bug.cgi?id=87172 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Alex Deucher --- Closing due to no feedback. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm: add ARM flush implementation
On Wed, Jan 24, 2018 at 07:26:11PM +, Russell King - ARM Linux wrote:
> On Wed, Jan 24, 2018 at 10:45:28AM -0800, Gurchetan Singh wrote:
> > On Wed, Jan 24, 2018 at 4:45 AM, Russell King - ARM Linux <
> > li...@armlinux.org.uk> wrote:
> > > So no, this is not an acceptable approach.
> > >
> > > Secondly, in light of spectre and meltdown, do we _really_ want to
> > > export cache flushing to userspace in any case - these attacks rely
> > > on being able to flush specific cache lines from the caches in order
> > > to do the timing attacks (while leaving others in place.)
> >
> > > Currently, 32-bit ARM does not export such flushing capabilities to
> > > userspace, which makes it very difficult (I'm not going to say
> > > impossible) to get any working proof-of-code program that even
> > > illustrates the timing attack. Exposing this functionality changes
> > > that game, and means that we're much more open to these exploits.
> > > (Some may say that you can flush cache lines by reading a large
> > > enough buffer - I'm aware, I've tried that, the results are too
> > > unreliable even for a simple attempt which doesn't involve crossing
> > > privilege boundaries.)
> > >
> >
> > Will using the DMA API (dma_sync_single_for_device /
> > dma_sync_sg_for_device) mitigate your Meltdown / Spectre concerns in any
> > way?
>
> I see no point in answering that question based on what you've written
> below (see below for why).
>
> > > Do you really need cacheable GPU buffers, or will write combining
> > > buffers (as we use elsewhere such as etnaviv) suffice? Please provide
> > > some _real_ _world_ performance measurements that demonstrate that
> > > there is a real need for this functionality.
> >
> >
> > My desire is for the vgem driver to work correctly on ARM, which requires
> > cache flushing. The mappings vgem itself creates are write combine.
>
> If the pages are mapped write-combine, they are by definition *not*
> cacheable, so there should be no cache flushing required.
>
> > The
> > issue is the pages retrieved on ARM architecture usually have to be flushed
> > before they can be used (see rockchip_gem_get_pages / tegra_bo_get_pages).
> > This patch set attempts to do the flushing in an architecture independent
> > manner (since vgem is intended to work on ARM / x86).
>
> I see rockchip_gem_get_pages() using shmem_read_mapping_page() to get
> the pages. That's more or less fine, we do that on Etnaviv too.
>
> (Side note: provided the pages are not coming from lowmem, as mapping
> lowmem pages are mapped cacheable, and if you also map them elsewhere
> as write-combine, you're stepping into some potential cache attribute
> issues.)
>
> How we deal with this in Etnaviv is to use dma_map_sg() after we get
> the pages - see
>
> etnaviv_gem_get_pages(), which calls the memory specific .get_pages
> method, and goes on to call etnaviv_gem_scatter_map().
I think I'm to blame for this. Back at the time the patch was based on
my incomplete understanding of the DMA API. It's also possible that it
wasn't working at the time because the DMA/IOMMU glue wasn't quite the
same as it is today. I have a vague recollection that I tried using
dma_map_sg() and it was creating a second IOVA mapping (in addition to
the one we explicitly create in the driver with the IOMMU API).
However, that's no longer happening today, so I ended up doing something
very similar to etnaviv. I've got the below patch queued for v4.17 and I
think the same should work for both Rockchip and VGEM.
Thierry
--- >8 ---
From 0f83d1aefcd0ca49c88d483a4161e3a02b5d1f32 Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Wed, 13 Dec 2017 12:22:48 +0100
Subject: [PATCH] drm/tegra: gem: Map pages via the DMA API
When allocating pages, map them with the DMA API in order to invalidate
caches. This is the correct usage of the API and works just as well as
faking up the SG table and using the dma_sync_sg_for_device() function.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gem.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 1bc5c6d1e5b5..8ab6057808e6 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -203,6 +203,8 @@ static struct tegra_bo *tegra_bo_alloc_object(struct
drm_device *drm,
static void tegra_bo_free(struct drm_device *drm, struct tegra_bo *bo)
{
if (bo->pages) {
+ dma_unmap_sg(drm->dev, bo->sgt->sgl, bo->sgt->nents,
+DMA_BIDIRECTIONAL);
drm_gem_put_pages(&bo->gem, bo->pages, true, true);
sg_free_table(bo->sgt);
kfree(bo->sgt);
@@ -213,8 +215,7 @@ static void tegra_bo_free(struct drm_device *drm, struct
tegra_bo *bo)
static int tegra_bo_get_pages(struct drm_device *drm, struct tegra_bo *bo)
{
- struct scatterlist *s;
- unsigned int i;
+ int err;
Re: [PATCH v19 07/10] drm/panel: Use backlight_enable/disable helpers
On Wed, Jan 24, 2018 at 04:39:27PM +, Meghana Madhyastha wrote: > Use backlight_enable/disable helpers instead of changing > the property and calling backlight_update_status for cleaner > and simpler code and also to avoid repetitions. > > Reviewed-by: Noralf Trønnes > Reviewed-by: Sean Paul > Signed-off-by: Meghana Madhyastha > --- > drivers/gpu/drm/panel/panel-innolux-p079zca.c | 6 ++ > drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 6 ++ > drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 10 ++ > drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 10 ++ > 4 files changed, 8 insertions(+), 24 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v19 09/10] drm/panel: Use of_find_backlight helper
On Wed, Jan 24, 2018 at 04:40:51PM +, Meghana Madhyastha wrote: > Replace of_find_backlight_by_node and of the code around it > with of_find_backlight helper to avoid repetition of code. > > Reviewed-by: Noralf Trønnes > Reviewed-by: Sean Paul > Signed-off-by: Meghana Madhyastha > --- > drivers/gpu/drm/panel/panel-innolux-p079zca.c | 24 - > drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 28 > + > drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 27 > 3 files changed, 13 insertions(+), 66 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence
On Thu, Jan 25, 2018 at 02:37:26PM +0100, Hans de Goede wrote:
> So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
> index = 3, one of which has been kindly provided to me by Jan Brummer,
> where not working with the i915 driver, giving a black screen on the
> first modeset.
>
> The problem with at least these Dells is that their VBT defines a MIPI
> ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
> reset in their INIT_OTP sequence, but the deassert must be done before
> calling intel_dsi_device_ready(), so that is too late.
>
> Simply doing the INIT_OTP sequence earlier is not enough to fix this,
> because the INIT_OTP sequence also sends various MIPI packets to the
> panel, which can only happen after calling intel_dsi_device_ready().
>
> This commit fixes this by making mipi_exec_send_packet() call
> intel_dsi_device_ready() if not done already, so that we can call the
> INIT_OTP sequence earlier on affected devices.
>
> Note that this only changes the init-sequence on devices for which
> intel_dsi_use_init_otp_as_deassert() returns true, on other devices
> intel_dsi->device_ready will be set to true before calling any
> MIPI sequences which may send packets, so the check added to
> mipi_exec_send_packet() is a nop there.
I don't like how wide this kludge spreads in the code.
Could we instead just extract the deassert sequence from the
OTP sequence? Looks like your code already assumes that everything
up to the first DSI packet is part of the deassert sequence. So
I imagine it should be pretty easy to split the sequence up at
that same point?
>
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=82880
> Related: https://bugs.freedesktop.org/show_bug.cgi?id=101205
> Reported-by: Jan-Michael Brummer
> Tested-by: Hans de Goede
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 53
> ++--
> drivers/gpu/drm/i915/intel_dsi.h | 4 +++
> drivers/gpu/drm/i915/intel_dsi_vbt.c | 6
> 3 files changed, 60 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index f67d321376e4..3d82811a38f3 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -539,9 +539,14 @@ static void vlv_dsi_device_ready(struct intel_encoder
> *encoder)
> }
> }
>
> -static void intel_dsi_device_ready(struct intel_encoder *encoder)
> +void intel_dsi_device_ready(struct intel_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> +
> + /* Already done? */
> + if (intel_dsi->device_ready)
> + return;
>
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> vlv_dsi_device_ready(encoder);
> @@ -549,6 +554,8 @@ static void intel_dsi_device_ready(struct intel_encoder
> *encoder)
> bxt_dsi_device_ready(encoder);
> else if (IS_GEMINILAKE(dev_priv))
> glk_dsi_device_ready(encoder);
> +
> + intel_dsi->device_ready = true;
> }
>
> static void glk_dsi_enter_low_power_mode(struct intel_encoder *encoder)
> @@ -786,6 +793,36 @@ static void intel_dsi_msleep(struct intel_dsi
> *intel_dsi, int msec)
> * - wait t4 - wait t4
> */
>
> +/*
> + * Some v1 VBT MIPI sequences do the deassert in the init OTP sequence.
> + * The deassert must be done before calling intel_dsi_device_ready, while
> + * intel_dsi_device_ready() must be called before any send packet ops inside
> + * the init OTP sequence. mipi_exec_send_packet() deals with calling
> + * intel_dsi_device_ready() if necessary. This function checks if we need
> + * to call init OTP at deassert time.
> + */
> +static bool intel_dsi_use_init_otp_as_deassert(struct intel_dsi *intel_dsi)
> +{
> + struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
> +
> + /* Limit this to VLV for now. */
> + if (!IS_VALLEYVIEW(dev_priv))
> + return false;
> +
> + /* Limit this to v1 vid-mode sequences */
> + if (!is_vid_mode(intel_dsi) || dev_priv->vbt.dsi.seq_version != 1)
> + return false;
> +
> + /* If there is an assert-reset seq and no deassert one, use init OTP */
> + if (dev_priv->vbt.dsi.sequence[MIPI_SEQ_ASSERT_RESET] != 0 &&
> + dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET] == 0) {
> + DRM_DEBUG_KMS("Using init OTP to deassert reset\n");
> + return true;
> + }
> +
> + return false;
> +}
> +
> static void intel_dsi_pre_enable(struct intel_encoder *encoder,
>const struct intel_crtc_state *pipe_config,
>const struct drm_connector_state *conn_state)
> @@ -840,7 +877,10 @@ static void intel_dsi_pre_enable(struct intel_encoder
> *encoder,
> intel_dsi_msl
Re: [PATCH v19 03/10] video: backlight: Add of_find_backlight helper in backlight.c
On Wed, Jan 24, 2018 at 04:35:30PM +, Meghana Madhyastha wrote: > Add of_find_backlight, a helper function which is a generic version > of tinydrm_of_find_backlight that can be used by other drivers to avoid > repetition of code and simplify things. > > Acked-by: Daniel Thompson > Reviewed-by: Noralf Trønnes > Reviewed-by: Sean Paul > Signed-off-by: Meghana Madhyastha > --- > drivers/video/backlight/backlight.c | 43 > + > include/linux/backlight.h | 19 > 2 files changed, 62 insertions(+) > > diff --git a/drivers/video/backlight/backlight.c > b/drivers/video/backlight/backlight.c > index 8049e7656..553bf5c48 100644 > --- a/drivers/video/backlight/backlight.c > +++ b/drivers/video/backlight/backlight.c > @@ -580,6 +580,49 @@ struct backlight_device > *of_find_backlight_by_node(struct device_node *node) > EXPORT_SYMBOL(of_find_backlight_by_node); > #endif > > +/** > + * of_find_backlight - Get backlight device > + * @dev: Device > + * > + * This function looks for a property named 'backlight' on the DT node > + * connected to @dev and looks up the backlight device. > + * > + * Call backlight_put() to drop the reference on the backlight device. > + * > + * Returns: > + * A pointer to the backlight device if found. > + * Error pointer -EPROBE_DEFER if the DT property is set, but no backlight > + * device is found. > + * NULL if there's no backlight property. > + */ > +struct backlight_device *of_find_backlight(struct device *dev) Just a nit: there isn't really anything OF specific about this. It would be if this took a struct device_node * as parameter. So technically you could implement this for ACPI or whatever other firmware interface as well. So I think a more idiomatic name for this would be: struct backlight_device *backlight_get(struct device *dev); which would match the: void backlight_put(struct backlight_device *bd); and be consistent with how other resources are obtained. Not a big deal, though. It can always be changed later on. Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v19 00/10] Add backlight helper functions
On Wed, Jan 24, 2018 at 04:32:26PM +, Meghana Madhyastha wrote: > Move drm helper functions from tinydrm-helpers to linux/backlight for > ease of use by callers in other drivers. > > Changes in v19: > -Changed to devm version of of_find_backlight in omapdrm (patch 10) > -removed assigning pdev->dev to variable dev in omapdrm (patch 10) > > Meghana Madhyastha (10): > video: backlight: Add helpers to enable and disable backlight > drm/tinydrm: Convert tinydrm_enable/disable_backlight to > backlight_enable/disable > video: backlight: Add of_find_backlight helper in backlight.c > drm/tinydrm: Replace tinydrm_of_find_backlight with of_find_backlight > video: backlight: Add devres versions of of_find_backlight > drm/tinydrm: Call devres version of of_find_backlight > drm/panel: Use backlight_enable/disable helpers > drm/omapdrm: Use backlight_enable/disable helpers > drm/panel: Use of_find_backlight helper > drm/omapdrm: Use of_find_backlight helper > > drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 36 ++ > drivers/gpu/drm/panel/panel-innolux-p079zca.c | 30 ++-- > drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 6 +- > drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 38 ++ > drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 37 ++ > drivers/gpu/drm/tinydrm/Kconfig | 2 - > drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 95 > - > drivers/gpu/drm/tinydrm/mi0283qt.c | 3 +- > drivers/gpu/drm/tinydrm/mipi-dbi.c | 4 +- > drivers/gpu/drm/tinydrm/st7735r.c | 3 +- > drivers/video/backlight/backlight.c | 73 +++ > include/drm/tinydrm/tinydrm-helpers.h | 4 -- > include/linux/backlight.h | 58 +++ > 13 files changed, 165 insertions(+), 224 deletions(-) Thanks for doing this, this has been a long-standing issue! Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/6] drm/exynos: Let core take care of normalizing the zpos
Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.
Signed-off-by: Peter Ujfalusi
CC: Inki Dae
CC: Joonyoung Shim
CC: Seung-Woo Kim
CC: Kyungmin Park
Acked-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 20
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 +++-
3 files changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index a518e9c6d6cc..39284bb7c2c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -37,26 +37,6 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-int exynos_atomic_check(struct drm_device *dev,
- struct drm_atomic_state *state)
-{
- int ret;
-
- ret = drm_atomic_helper_check_modeset(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_normalize_zpos(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_helper_check_planes(dev, state);
- if (ret)
- return ret;
-
- return ret;
-}
-
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index df2262f70d91..075957cb6ba1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -275,7 +275,6 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state
*state,
bool nonblock);
-int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state
*state);
extern struct platform_driver fimd_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 0faaf829f5bf..2379d732da67 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -206,7 +206,7 @@ static struct drm_mode_config_helper_funcs
exynos_drm_mode_config_helpers = {
static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
- .atomic_check = exynos_atomic_check,
+ .atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -227,4 +227,6 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
dev->mode_config.helper_private = &exynos_drm_mode_config_helpers;
dev->mode_config.allow_fb_modifiers = true;
+
+ dev->mode_config.normalize_zpos = true;
}
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/6] drm: zpos normalization cleanup and omapdrm to use it
Hi, Changes since v2: - Fixed commit messages (s/drm_device/drm_mode_config) - Added ack from Benjamin Gaignard to drm/sti patch Changes since v1: - normalize_zpos flag moved to drm_mode_config - Added comment to note the side effect of normalization and updated the comment for normalized_zpos in the header file as well. - Added Acked-by from Daniel to patch 2-6 but not for patch 1 as I'm not sure if the comments I have added matches with what is expected to be. The first patch is adding a flag to drm_device that drivers can set if they want the zpos to be normalized. Then convert exynos, tegra, sti and rcar-du to use this flag instead of re-implementing the drm_atomic_helper_check() locally just to add the call to drm_atomic_normalize_zpos(). The last patch is moving omapdrm to use the zpos normalization as well to comply with the UAPI documentation regarding to zpos. Laurent's note in an earlier thread: https://marc.info/?l=dri-devel&m=151567355225029&w=2 "The problem is that zpos normalization requires accessing the state of all enabled planes for a CRTC in order to compute (and store) the normalized zpos values. This thus forces all planes to be added to the commit state, even when the commit doesn't touch the zpos property. I assume this caused issues (possibly performance issues) in drivers that then performed hardware setup of all planes as a result." can be addressed later in the core for all users of drm_atomic_normalize_zpos() Regards, Peter --- Peter Ujfalusi (6): drm: Add drm_mode_config->normalize_zpos boolean drm/exynos: Let core take care of normalizing the zpos drm/tegra: Let core take care of normalizing the zpos drm/sti: Let core take care of normalizing the zpos drm: rcar-du: Let core take care of normalizing the zpos drm/omap: Use normalized zpos for plane placement drivers/gpu/drm/drm_atomic_helper.c | 11 +++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 - drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 +++- drivers/gpu/drm/omapdrm/omap_drv.c | 3 +++ drivers/gpu/drm/omapdrm/omap_plane.c| 2 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 11 ++- drivers/gpu/drm/sti/sti_drv.c | 24 +++- drivers/gpu/drm/tegra/drm.c | 27 +++ include/drm/drm_mode_config.h | 8 include/drm/drm_plane.h | 4 ++-- 11 files changed, 36 insertions(+), 79 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/6] drm/tegra: Let core take care of normalizing the zpos
Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.
Signed-off-by: Peter Ujfalusi
CC: Thierry Reding
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tegra/drm.c | 27 +++
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d50bddb2e447..037c79d9c6fd 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -33,29 +33,6 @@ struct tegra_drm_file {
struct mutex lock;
};
-static int tegra_atomic_check(struct drm_device *drm,
- struct drm_atomic_state *state)
-{
- int err;
-
- err = drm_atomic_helper_check_modeset(drm, state);
- if (err < 0)
- return err;
-
- err = drm_atomic_normalize_zpos(drm, state);
- if (err < 0)
- return err;
-
- err = drm_atomic_helper_check_planes(drm, state);
- if (err < 0)
- return err;
-
- if (state->legacy_cursor_update)
- state->async_update = !drm_atomic_helper_async_check(drm,
state);
-
- return 0;
-}
-
static struct drm_atomic_state *
tegra_atomic_state_alloc(struct drm_device *drm)
{
@@ -90,7 +67,7 @@ static const struct drm_mode_config_funcs
tegra_drm_mode_config_funcs = {
#ifdef CONFIG_DRM_FBDEV_EMULATION
.output_poll_changed = drm_fb_helper_output_poll_changed,
#endif
- .atomic_check = tegra_atomic_check,
+ .atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
.atomic_state_alloc = tegra_atomic_state_alloc,
.atomic_state_clear = tegra_atomic_state_clear,
@@ -179,6 +156,8 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
drm->mode_config.allow_fb_modifiers = true;
+ drm->mode_config.normalize_zpos = true;
+
drm->mode_config.funcs = &tegra_drm_mode_config_funcs;
drm->mode_config.helper_private = &tegra_drm_mode_config_helpers;
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/6] drm/omap: Use normalized zpos for plane placement
Planes with identical zpos value will result undefined behavior: disappearing planes, screen flickering and it is not supported by the hardware. Use normalized zpos to make sure that we don't encounter invalid configuration. Signed-off-by: Peter Ujfalusi CC: Tomi Valkeinen Acked-by: Daniel Vetter --- drivers/gpu/drm/omapdrm/omap_drv.c | 3 +++ drivers/gpu/drm/omapdrm/omap_plane.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index dd68b2556f5b..37ee20c773c7 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.c +++ b/drivers/gpu/drm/omapdrm/omap_drv.c @@ -316,6 +316,9 @@ static int omap_modeset_init(struct drm_device *dev) dev->mode_config.max_width = 2048; dev->mode_config.max_height = 2048; + /* We want the zpos to be normalized */ + dev->mode_config.normalize_zpos = true; + dev->mode_config.funcs = &omap_mode_config_funcs; dev->mode_config.helper_private = &omap_mode_config_helper_funcs; diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c index 7d789d1551a1..2c19d2239bc5 100644 --- a/drivers/gpu/drm/omapdrm/omap_plane.c +++ b/drivers/gpu/drm/omapdrm/omap_plane.c @@ -65,7 +65,7 @@ static void omap_plane_atomic_update(struct drm_plane *plane, info.rotation_type = OMAP_DSS_ROT_NONE; info.rotation = DRM_MODE_ROTATE_0; info.global_alpha = 0xff; - info.zorder = state->zpos; + info.zorder = state->normalized_zpos; /* update scanout: */ omap_framebuffer_update_scanout(state->fb, state, &info); -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/6] drm: Add drm_mode_config->normalize_zpos boolean
Instead of drivers duplicating the drm_atomic_helper_check() code to be
able to normalize the zpos they can use the normalize_zpos flag to let the
drm core to do it.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/drm_atomic_helper.c | 11 +++
include/drm/drm_mode_config.h | 8
include/drm/drm_plane.h | 4 ++--
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ab4032167094..0f6a4949e6dc 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -873,6 +873,11 @@ EXPORT_SYMBOL(drm_atomic_helper_check_planes);
* functions depend upon an updated adjusted_mode.clock to e.g. properly
compute
* watermarks.
*
+ * Note that zpos normalization will add all enable planes to the state which
+ * might not desired for some drivers.
+ * For example enable/disable of a cursor plane which have fixed zpos value
+ * would trigger all other enabled planes to be forced to the state change.
+ *
* RETURNS:
* Zero for success or -errno
*/
@@ -885,6 +890,12 @@ int drm_atomic_helper_check(struct drm_device *dev,
if (ret)
return ret;
+ if (dev->mode_config.normalize_zpos) {
+ ret = drm_atomic_normalize_zpos(dev, state);
+ if (ret)
+ return ret;
+ }
+
ret = drm_atomic_helper_check_planes(dev, state);
if (ret)
return ret;
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 2cb6f02df64a..987ab63ae037 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -792,6 +792,14 @@ struct drm_mode_config {
/* cursor size */
uint32_t cursor_width, cursor_height;
+ /**
+* @normalize_zpos:
+*
+* If true the drm core will call drm_atomic_normalize_zpos() as part of
+* atomic mode checking from drm_atomic_helper_check()
+*/
+ bool normalize_zpos;
+
/**
* @suspend_state:
*
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 8185e3468a23..2c0adb124e0f 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -50,8 +50,8 @@ struct drm_modeset_acquire_ctx;
* plane with a lower ID.
* @normalized_zpos: normalized value of zpos: unique, range from 0 to N-1
* where N is the number of active planes for given crtc. Note that
- * the driver must call drm_atomic_normalize_zpos() to update this before
- * it can be trusted.
+ * the driver must set drm_mode_config.normalize_zpos or call
+ * drm_atomic_normalize_zpos() to update this before it can be trusted.
* @src: clipped source coordinates of the plane (in 16.16)
* @dst: clipped destination coordinates of the plane
* @state: backpointer to global drm_atomic_state
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/6] drm/sti: Let core take care of normalizing the zpos
Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.
Signed-off-by: Peter Ujfalusi
CC: Benjamin Gaignard
CC: Vincent Abriou
Acked-by: Daniel Vetter
Acked-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 55b6967d27e1..90c46b49c931 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -119,30 +119,10 @@ static int sti_drm_dbg_init(struct drm_minor *minor)
return ret;
}
-static int sti_atomic_check(struct drm_device *dev,
- struct drm_atomic_state *state)
-{
- int ret;
-
- ret = drm_atomic_helper_check_modeset(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_normalize_zpos(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_helper_check_planes(dev, state);
- if (ret)
- return ret;
-
- return ret;
-}
-
static const struct drm_mode_config_funcs sti_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
- .atomic_check = sti_atomic_check,
+ .atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -160,6 +140,8 @@ static void sti_mode_config_init(struct drm_device *dev)
dev->mode_config.max_height = STI_MAX_FB_HEIGHT;
dev->mode_config.funcs = &sti_mode_config_funcs;
+
+ dev->mode_config.normalize_zpos = true;
}
DEFINE_DRM_GEM_CMA_FOPS(sti_driver_fops);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/6] drm: rcar-du: Let core take care of normalizing the zpos
Set the drm_mode_config->normalize_zpos and call drm_atomic_helper_check() from rcar_du_atomic_check() instead of re implementing the function locally. Signed-off-by: Peter Ujfalusi CC: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 566d1a948c8f..384f98aa4ca3 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -234,15 +234,7 @@ static int rcar_du_atomic_check(struct drm_device *dev, struct rcar_du_device *rcdu = dev->dev_private; int ret; - ret = drm_atomic_helper_check_modeset(dev, state); - if (ret) - return ret; - - ret = drm_atomic_normalize_zpos(dev, state); - if (ret) - return ret; - - ret = drm_atomic_helper_check_planes(dev, state); + ret = drm_atomic_helper_check(dev, state); if (ret) return ret; @@ -531,6 +523,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu) dev->mode_config.min_height = 0; dev->mode_config.max_width = 4095; dev->mode_config.max_height = 2047; + dev->mode_config.normalize_zpos = true; dev->mode_config.funcs = &rcar_du_mode_config_funcs; dev->mode_config.helper_private = &rcar_du_mode_config_helper; -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/6] drm: Add drm_mode_config->normalize_zpos boolean
On Thu, Jan 25, 2018 at 04:26:25PM +0200, Peter Ujfalusi wrote:
> Instead of drivers duplicating the drm_atomic_helper_check() code to be
> able to normalize the zpos they can use the normalize_zpos flag to let the
> drm core to do it.
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 11 +++
> include/drm/drm_mode_config.h | 8
> include/drm/drm_plane.h | 4 ++--
> 3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ab4032167094..0f6a4949e6dc 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -873,6 +873,11 @@ EXPORT_SYMBOL(drm_atomic_helper_check_planes);
> * functions depend upon an updated adjusted_mode.clock to e.g. properly
> compute
> * watermarks.
> *
> + * Note that zpos normalization will add all enable planes to the state which
> + * might not desired for some drivers.
> + * For example enable/disable of a cursor plane which have fixed zpos value
> + * would trigger all other enabled planes to be forced to the state change.
> + *
> * RETURNS:
> * Zero for success or -errno
> */
> @@ -885,6 +890,12 @@ int drm_atomic_helper_check(struct drm_device *dev,
> if (ret)
> return ret;
>
> + if (dev->mode_config.normalize_zpos) {
> + ret = drm_atomic_normalize_zpos(dev, state);
> + if (ret)
> + return ret;
> + }
I think we originally had this in drm_atomic_helper_check_planes().
Looking through some of the drivers it looks like we could maybe
kill a few more LOC by putting it there.
> +
> ret = drm_atomic_helper_check_planes(dev, state);
> if (ret)
> return ret;
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 2cb6f02df64a..987ab63ae037 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -792,6 +792,14 @@ struct drm_mode_config {
> /* cursor size */
> uint32_t cursor_width, cursor_height;
>
> + /**
> + * @normalize_zpos:
> + *
> + * If true the drm core will call drm_atomic_normalize_zpos() as part of
> + * atomic mode checking from drm_atomic_helper_check()
> + */
> + bool normalize_zpos;
> +
Can we pack it next to some other bools to try and keep the struct
size down?
> /**
>* @suspend_state:
>*
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 8185e3468a23..2c0adb124e0f 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -50,8 +50,8 @@ struct drm_modeset_acquire_ctx;
> * plane with a lower ID.
> * @normalized_zpos: normalized value of zpos: unique, range from 0 to N-1
> * where N is the number of active planes for given crtc. Note that
> - * the driver must call drm_atomic_normalize_zpos() to update this before
> - * it can be trusted.
> + * the driver must set drm_mode_config.normalize_zpos or call
> + * drm_atomic_normalize_zpos() to update this before it can be trusted.
> * @src: clipped source coordinates of the plane (in 16.16)
> * @dst: clipped destination coordinates of the plane
> * @state: backpointer to global drm_atomic_state
> --
> Peter
>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104736] Kernel panic with agd5's drm-next-4.17-wip & GFX8/Polaris10/Ellesmere/Rx-480-8GiB
https://bugs.freedesktop.org/show_bug.cgi?id=104736 Christian König changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/6] drm: Add drm_mode_config->normalize_zpos boolean
On Thu, Jan 25, 2018 at 04:40:48PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 25, 2018 at 04:26:25PM +0200, Peter Ujfalusi wrote:
> > Instead of drivers duplicating the drm_atomic_helper_check() code to be
> > able to normalize the zpos they can use the normalize_zpos flag to let the
> > drm core to do it.
> >
> > Signed-off-by: Peter Ujfalusi
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 11 +++
> > include/drm/drm_mode_config.h | 8
> > include/drm/drm_plane.h | 4 ++--
> > 3 files changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index ab4032167094..0f6a4949e6dc 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -873,6 +873,11 @@ EXPORT_SYMBOL(drm_atomic_helper_check_planes);
> > * functions depend upon an updated adjusted_mode.clock to e.g. properly
> > compute
> > * watermarks.
> > *
> > + * Note that zpos normalization will add all enable planes to the state
> > which
> > + * might not desired for some drivers.
> > + * For example enable/disable of a cursor plane which have fixed zpos value
> > + * would trigger all other enabled planes to be forced to the state change.
> > + *
> > * RETURNS:
> > * Zero for success or -errno
> > */
> > @@ -885,6 +890,12 @@ int drm_atomic_helper_check(struct drm_device *dev,
> > if (ret)
> > return ret;
> >
> > + if (dev->mode_config.normalize_zpos) {
> > + ret = drm_atomic_normalize_zpos(dev, state);
> > + if (ret)
> > + return ret;
> > + }
>
> I think we originally had this in drm_atomic_helper_check_planes().
> Looking through some of the drivers it looks like we could maybe
> kill a few more LOC by putting it there.
Actually, I guess it's fine as is. I though the "async" flip thing I
saw in some of the drivers wasn't in the atomic helper. But it is
there.
That actually makes me slightly worried whether it's safe to just
blindly replace the hand rolled stuff w/o "async" with
drm_atomic_helper_check(). The commit messages should perhaps
justify that somehow.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC]drm/ttm: fix scheduling balance
On 01/25/2018 10:59 AM, Chunming Zhou wrote:
there is a scheduling balance issue about get node like:
a. process A allocates full memory and use it for submission.
b. process B tries to allocates memory, will wait for process A BO idle in
eviction.
c. process A completes the job, process B eviction will put process A BO node,
but in the meantime, process C is comming to allocate BO, whill directly get
node successfully, and do submission,
process B will again wait for process C BO idle.
d. repeat the above setps, process B could be delayed much more.
add a mutex to gerantee the allocation sequence for same domain. But there is a
possibility that
visible vram could be evicted to invisilbe, the tricky is they are same domain
manager, so which needs a special handling.
Change-Id: I260e8eb704f7b4788b071d3f641f21b242912256
Signed-off-by: Chunming Zhou
I think this is a good approach, however there are two things that IMO
needs fixing.
1) You must lock mutex interruptible if requested. It's important for
fast delivery of Xserver mouse signals, and also to avoid unkillable
processes on GPU hang.
2) How do we resolve contradictary eviction order between buffers? You'd
probably get lockdep warnings if that should happen. Now I'm not sure
there are
drivers that do this, and that would probably be a bug if they did. In
principle you'd have to either establish a manager priority and document
that drivers have to do that,
or use ww_mutexes.
/Thomas
---
drivers/gpu/drm/ttm/ttm_bo.c| 16 +++-
include/drm/ttm/ttm_bo_api.h| 2 ++
include/drm/ttm/ttm_bo_driver.h | 1 +
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index d33a6bb742a1..f465f1d38711 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -969,7 +969,11 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (mem_type == TTM_PL_SYSTEM)
break;
+ if (ctx->man != man)
+ mutex_lock(&man->node_mutex);
ret = (*man->func->get_node)(man, bo, place, mem);
+ if (ctx->man != man)
+ mutex_unlock(&man->node_mutex);
if (unlikely(ret))
return ret;
@@ -991,6 +995,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
for (i = 0; i < placement->num_busy_placement; ++i) {
const struct ttm_place *place = &placement->busy_placement[i];
+ struct ttm_operation_ctx busy_ctx;
ret = ttm_mem_type_from_place(place, &mem_type);
if (ret)
@@ -1018,7 +1023,15 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
return 0;
}
- ret = ttm_bo_mem_force_space(bo, mem_type, place, mem, ctx);
+ memcpy(&busy_ctx, ctx, sizeof(busy_ctx));
+ if (ctx->man != man) {
+ mutex_lock(&man->node_mutex);
+ busy_ctx.man = man;
+ }
+ ret = ttm_bo_mem_force_space(bo, mem_type, place, mem,
+&busy_ctx);
+ if (ctx->man != man)
+ mutex_unlock(&man->node_mutex);
if (ret == 0 && mem->mm_node) {
mem->placement = cur_flags;
return 0;
@@ -1449,6 +1462,7 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned
type,
man->io_reserve_fastpath = true;
man->use_io_reserve_lru = false;
mutex_init(&man->io_reserve_mutex);
+ mutex_init(&man->node_mutex);
spin_lock_init(&man->move_lock);
INIT_LIST_HEAD(&man->io_reserve_lru);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 2cd025c2abe7..b08629050215 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -265,6 +265,7 @@ struct ttm_bo_kmap_obj {
* @no_wait_gpu: Return immediately if the GPU is busy.
* @allow_reserved_eviction: Allow eviction of reserved BOs.
* @resv: Reservation object to allow reserved evictions with.
+ * @man: record ctx is under man->node_mutex.
*
* Context for TTM operations like changing buffer placement or general memory
* allocation.
@@ -275,6 +276,7 @@ struct ttm_operation_ctx {
bool allow_reserved_eviction;
struct reservation_object *resv;
uint64_t bytes_moved;
+ struct ttm_mem_type_manager *man;
};
/**
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 9b417eb2df20..d85d6ee4f54d 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -288,6 +288,7 @@ struct ttm_mem_type_manager {
uint32_t default_caching;
const struct ttm_mem_type_manager_func *func;
void *priv;
+ struct mutex node_mutex;
struct mutex io_reserve_mutex;
bool use_io_res
Re: [PATCH v3] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks
On 2018-01-25 08:30 AM, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> Naturally we can only do that if the index of those objects stays
> below 32. Issue a warning whenever we exceed that limit, hopefully
> prompting someone to fix the problem.
>
> For connectors the issue is a bit more complicated as they can
> be created/destroyed at runtime due to MST. So the problem is no
> longer a purely theoretical programmer error. As the connector
> indexes are allocated via ida, we can simply limit the maximum
> value the ida is allowed to hand out. The error handling is already
> in place.
>
> v2: Return an error to the caller (Harry)
> v3: Print a debug message so that we know what happened (Maarten)
>
> Cc: Harry Wentland
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Reviewed-by: Maarten Lankhorst
Reviewed-by: Harry Wentland
Harry
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_connector.c | 9 +++--
> drivers/gpu/drm/drm_crtc.c | 4
> drivers/gpu/drm/drm_encoder.c | 4
> drivers/gpu/drm/drm_plane.c | 4
> 4 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b85a7749709d..16b9c3810af2 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -205,9 +205,14 @@ int drm_connector_init(struct drm_device *dev,
> connector->dev = dev;
> connector->funcs = funcs;
>
> - ret = ida_simple_get(&config->connector_ida, 0, 0, GFP_KERNEL);
> - if (ret < 0)
> + /* connector index is used with 32bit bitmasks */
> + ret = ida_simple_get(&config->connector_ida, 0, 32, GFP_KERNEL);
> + if (ret < 0) {
> + DRM_DEBUG_KMS("Failed to allocate %s connector index: %d\n",
> + drm_connector_enum_list[connector_type].name,
> + ret);
> goto out_put;
> + }
> connector->index = ret;
> ret = 0;
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f0556e654116..5b4be382a1d7 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -282,6 +282,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> struct drm_crtc *crtc,
> WARN_ON(primary && primary->type != DRM_PLANE_TYPE_PRIMARY);
> WARN_ON(cursor && cursor->type != DRM_PLANE_TYPE_CURSOR);
>
> + /* crtc index is used with 32bit bitmasks */
> + if (WARN_ON(config->num_crtc >= 32))
> + return -EINVAL;
> +
> crtc->dev = dev;
> crtc->funcs = funcs;
>
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index 59e0ebe733f8..273e1c59c54a 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -110,6 +110,10 @@ int drm_encoder_init(struct drm_device *dev,
> {
> int ret;
>
> + /* encoder index is used with 32bit bitmasks */
> + if (WARN_ON(dev->mode_config.num_encoder >= 32))
> + return -EINVAL;
> +
> ret = drm_mode_object_add(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 2c90519576a3..22b54663b6e7 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -173,6 +173,10 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> unsigned int format_modifier_count = 0;
> int ret;
>
> + /* plane index is used with 32bit bitmasks */
> + if (WARN_ON(config->num_total_plane >= 32))
> + return -EINVAL;
> +
> ret = drm_mode_object_add(dev, &plane->base, DRM_MODE_OBJECT_PLANE);
> if (ret)
> return ret;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly
Hi, On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote: > Hi, > > Il 24/01/2018 18:38, Giulio Benetti ha scritto: > > Hi, > > > > Il 22/01/2018 21:27, Giulio Benetti ha scritto: > > > Hi, > > > > > > Il 22/01/2018 09:51, Maxime Ripard ha scritto: > > > > On Sat, Jan 20, 2018 at 07:50:21PM +0100, Giulio Benetti wrote: > > > > > On previous handling, if specified DRM_MODE_FLAG_N*SYNC, > > > > > it was ignored, > > > > > because only PHSYNC and PVSYNC were taken into account. > > > > > DRM_MODE_FLAG_P*SYNC and DRM_MODE_FLAG_N*SYNC are not exclusive. > > > > > > > > > > If flags contains PVSYNC, it doesn't mean it is NVSYNC. > > > > > And it's true also the contrary. > > > > > Also, as I've checked with scope on A20, > > > > > if (flags & PVSYNC) then SUN4I_TCON0_IO_POL_VSYNC_POSITIVE > > > > > must be set, as name suggests. > > > > > It seems all display io polarities starts inverted if 0. > > > > > > > > > > Signed-off-by: Giulio Benetti > > > > > > > > > > PVSYNC and PHSYNC only > > > > > > > > > > Signed-off-by: Giulio Benetti > > > > > > > > Checkpatch: > > > > WARNING: Duplicate signature > > > > > > Sorry I didn't use ./scripts/checkpatch.pl > > > > > > > > > > > > --- > > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++-- > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > index 6121210..e873a37 100644 > > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c > > > > > @@ -224,10 +224,10 @@ static void > > > > > sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, > > > > > SUN4I_TCON0_BASIC3_H_SYNC(hsync)); > > > > > /* Setup the polarity of the various signals */ > > > > > - if (!(mode->flags & DRM_MODE_FLAG_PHSYNC)) > > > > > + if (mode->flags & DRM_MODE_FLAG_PHSYNC) > > > > > val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE; > > > > > - if (!(mode->flags & DRM_MODE_FLAG_PVSYNC)) > > > > > + if (mode->flags & DRM_MODE_FLAG_PVSYNC) > > > > > val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE; > > > > > > > > I'm not sure why you were talking of the differences between NVSYNC > > > > and PVSYNC if you're not making use of any of it here? > > > > > > Thinking about it more now, the point is that all Lcd IOs seem to be > > > inverted by default(at least on A20). > > > With inverted, I mean that if for example PVSYNC, > > > I should see vsync line low and when asserted to give VSync, > > > it goes high. > > > This is what I've checked with oscilloscope on A20. > > > Can someone give a try on A33? Otherwise I will, > > > but I will take some time. > > > On uboot, everything is treated equal to kernel, > > > but to have my falling edge dclk and low h/vsync I had to specify: > > > CONFIG_VIDEO_LCD_DCLK_PHASE=0 (giving me falling edge on dclk) > > > and > > > CONFIG_VIDEO_LCD_MODE=",sync:3,..." > > > but digging into code, I see "sync:3" means H/VSYNC HIGH, > > > but I experience both LOW during their pulse. > > > > > > > > > > > Also, how was it tested? This seems quite weird that we haven't caught > > > > that one sooner, and I'm a bit worried about the possible regressions > > > > here. > > > > > > It sounds really strange to me too, > > > because everybody under uboot use "sync:3"(HIGH). > > > I will retry to measure, > > > unfortunately at home I don't have a scope, > > > but I think I'm going to have one soon, because of this. :) > > > > Here I am with scope captures and tcon0 registers dump: > > tcon0_regs => https://pasteboard.co/H4r8Zcs.png > > dclk_d0 => https://pasteboard.co/H4r8QRe.png > > dclk_de => https://pasteboard.co/H4r8zh4R.png > > dclk_vsnc => https://pasteboard.co/H4r8Hye.png > > > > As you can see circled in reg on registers, > > TCON0_IO_POL_REG = 0x. > > But on all the waveforms you can see: > > - dclk_d0: clock phase is 0, but it starts with falling edge, otherwise > > the rising front overlaps dclk rising edge(not good), so to me this is > > falling, then I mean it Negative. > > - dclk_de: de pulse is clearly negative, even if register is 0 and its' > > polarity bit is 0. > > - dclk_vsnc: same as dclk_de > > - dclk_hsync: I didn't take scope screenshot but I can assure you it's > > negative. > > > > You can also check all the other registers about TCON0. > > > > Now I proceed testing it on A33, maybe the peripheral is slightly > > different between Axx SoCs, if I find it that way, > > it should be only a check about SoC or peripheral ID, > > and treat polarity as it should be done. > > Here I am with A33 waveforms: > tcon0_regs => https://pasteboard.co/H4rXfN0M.png > dclk_d0 => https://pasteboard.co/H4rVXwy.png > dclk_de => https://pasteboard.co/H4rWDt8.png > dclk_vsnc => https://pasteboard.co/H4rWRACu.png > dclk_hsync => https://pasteboard.co/H4rWK6I.png Thanks, that's really helpful. > It behaves the same way as A20, so as I
[Bug 104790] When using OpenGL 4.x some applications crash
https://bugs.freedesktop.org/show_bug.cgi?id=104790 Bug ID: 104790 Summary: When using OpenGL 4.x some applications crash Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: lei.p...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 136962 --> https://bugs.freedesktop.org/attachment.cgi?id=136962&action=edit screenshot of artifact with compatibility profile While enabling GL 4.x core profiles on Radeon HD 6770 (Juniper), applications such as genymotion and most wine games crash without any error. WHen using 4.xCOMPAT profile instead of core, they do not crash, however, some games in wine have serious graphical corruption (such as in atachment). This is with mesa-git (with all commits to this date) and earlier versions, just to report it so it can be solved before enabling core profiles by default. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode_set
The "adjusted_mode" clock value (ie the real pixel clock) is more
accurate than "mode" clock value (ie the panel/bridge requested
clock value). It offers a better preciseness for timing
computations and allows to reduce the extra dsi bandwidth in
burst mode (from ~20% to ~10-12%, hw platform dependant).
Signed-off-by: Philippe Cornu
---
Note: This patch replaces "drm/bridge/synopsys: dsi: add optional pixel clock"
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index ed8af32f8e52..b926b62e9e33 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -707,20 +707,20 @@ static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
*bridge,
clk_prepare_enable(dsi->pclk);
- ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
+ ret = phy_ops->get_lane_mbps(priv_data, adjusted_mode, dsi->mode_flags,
dsi->lanes, dsi->format, &dsi->lane_mbps);
if (ret)
DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
pm_runtime_get_sync(dsi->dev);
dw_mipi_dsi_init(dsi);
- dw_mipi_dsi_dpi_config(dsi, mode);
+ dw_mipi_dsi_dpi_config(dsi, adjusted_mode);
dw_mipi_dsi_packet_handler_config(dsi);
dw_mipi_dsi_video_mode_config(dsi);
- dw_mipi_dsi_video_packet_config(dsi, mode);
+ dw_mipi_dsi_video_packet_config(dsi, adjusted_mode);
dw_mipi_dsi_command_mode_config(dsi);
- dw_mipi_dsi_line_timer_config(dsi, mode);
- dw_mipi_dsi_vertical_timing_config(dsi, mode);
+ dw_mipi_dsi_line_timer_config(dsi, adjusted_mode);
+ dw_mipi_dsi_vertical_timing_config(dsi, adjusted_mode);
dw_mipi_dsi_dphy_init(dsi);
dw_mipi_dsi_dphy_timing_config(dsi);
@@ -734,7 +734,7 @@ static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
*bridge,
dw_mipi_dsi_dphy_enable(dsi);
- dw_mipi_dsi_wait_for_two_frames(mode);
+ dw_mipi_dsi_wait_for_two_frames(adjusted_mode);
/* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
dw_mipi_dsi_set_mode(dsi, 0);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/stm: ltdc: use crtc_mode_fixup to update adjusted_mode clock
There is a difference between the panel/bridge requested pixel clock
value and the real one due to the hw platform clock preciseness (pll,
dividers...). This patch updates the adjusted_mode clock value with
the real hw clock value so then attached encoder & connector can use
it for precise timing computations.
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/stm/ltdc.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index b48589343ae1..90b3de516c91 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -428,12 +428,35 @@ static void ltdc_crtc_atomic_disable(struct drm_crtc
*crtc,
reg_set(ldev->regs, LTDC_SRCR, SRCR_IMR);
}
+static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
+const struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+ struct ltdc_device *ldev = crtc_to_ltdc(crtc);
+ int rate = mode->clock * 1000;
+
+ /*
+* TODO clk_round_rate() does not work yet. When ready, it can
+* be used instead of clk_set_rate() then clk_get_rate().
+*/
+
+ clk_disable(ldev->pixel_clk);
+ if (clk_set_rate(ldev->pixel_clk, rate) < 0) {
+ DRM_ERROR("Cannot set rate (%dHz) for pixel clk\n", rate);
+ return false;
+ }
+ clk_enable(ldev->pixel_clk);
+
+ adjusted_mode->clock = clk_get_rate(ldev->pixel_clk) / 1000;
+
+ return true;
+}
+
static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct ltdc_device *ldev = crtc_to_ltdc(crtc);
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
struct videomode vm;
- int rate = mode->clock * 1000;
u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
u32 total_width, total_height;
u32 val;
@@ -456,15 +479,6 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
total_width = accum_act_w + vm.hfront_porch;
total_height = accum_act_h + vm.vfront_porch;
- clk_disable(ldev->pixel_clk);
-
- if (clk_set_rate(ldev->pixel_clk, rate) < 0) {
- DRM_ERROR("Cannot set rate (%dHz) for pixel clk\n", rate);
- return;
- }
-
- clk_enable(ldev->pixel_clk);
-
/* Configures the HS, VS, DE and PC polarities. Default Active Low */
val = 0;
@@ -528,6 +542,7 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc *crtc,
}
static const struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
+ .mode_fixup = ltdc_crtc_mode_fixup,
.mode_set_nofb = ltdc_crtc_mode_set_nofb,
.atomic_flush = ltdc_crtc_atomic_flush,
.atomic_enable = ltdc_crtc_atomic_enable,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/bridge/synopsys: dsi: add optional pixel clock
Hi,
in short: this patch is "CANCELLED" : )
Thanks to comments from some of you, I managed to use adjusted_mode.
Please have a look to the patch "drm/bridge/synopsys: dsi: use
adjusted_mode in mode_set".
Hope it is better, comments are welcome
Many thanks,
Philippe :-)
On 01/23/2018 06:08 PM, Philippe Cornu wrote:
> The pixel clock is optional. When available, it offers a better
> preciseness for timing computations and allows to reduce the extra dsi
> bandwidth in burst mode (from ~20% to ~10-12%, hw platform dependant).
>
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Philippe Cornu
> ---
> Changes in v3: Simplify px_clk probing thanks to Andrzej Hajda comments
>
> Changes in v2: Improve px_clk probing in case of ENOENT dt returned value
> (thanks to Philipp Zabel & Andrzej Hajda comments)
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index ed8af32f8e52..9fb35385c348 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -217,6 +217,7 @@ struct dw_mipi_dsi {
> void __iomem *base;
>
> struct clk *pclk;
> + struct clk *px_clk;
>
> unsigned int lane_mbps; /* per lane */
> u32 channel;
> @@ -703,24 +704,28 @@ static void dw_mipi_dsi_bridge_mode_set(struct
> drm_bridge *bridge,
> struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
> const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
> void *priv_data = dsi->plat_data->priv_data;
> + struct drm_display_mode px_clk_mode = *mode;
> int ret;
>
> clk_prepare_enable(dsi->pclk);
>
> - ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
> + if (dsi->px_clk)
> + px_clk_mode.clock = clk_get_rate(dsi->px_clk) / 1000;
> +
> + ret = phy_ops->get_lane_mbps(priv_data, &px_clk_mode, dsi->mode_flags,
>dsi->lanes, dsi->format, &dsi->lane_mbps);
> if (ret)
> DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
>
> pm_runtime_get_sync(dsi->dev);
> dw_mipi_dsi_init(dsi);
> - dw_mipi_dsi_dpi_config(dsi, mode);
> + dw_mipi_dsi_dpi_config(dsi, &px_clk_mode);
> dw_mipi_dsi_packet_handler_config(dsi);
> dw_mipi_dsi_video_mode_config(dsi);
> - dw_mipi_dsi_video_packet_config(dsi, mode);
> + dw_mipi_dsi_video_packet_config(dsi, &px_clk_mode);
> dw_mipi_dsi_command_mode_config(dsi);
> - dw_mipi_dsi_line_timer_config(dsi, mode);
> - dw_mipi_dsi_vertical_timing_config(dsi, mode);
> + dw_mipi_dsi_line_timer_config(dsi, &px_clk_mode);
> + dw_mipi_dsi_vertical_timing_config(dsi, &px_clk_mode);
>
> dw_mipi_dsi_dphy_init(dsi);
> dw_mipi_dsi_dphy_timing_config(dsi);
> @@ -734,7 +739,7 @@ static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
> *bridge,
>
> dw_mipi_dsi_dphy_enable(dsi);
>
> - dw_mipi_dsi_wait_for_two_frames(mode);
> + dw_mipi_dsi_wait_for_two_frames(&px_clk_mode);
>
> /* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
> dw_mipi_dsi_set_mode(dsi, 0);
> @@ -828,6 +833,14 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> return ERR_PTR(ret);
> }
>
> + dsi->px_clk = devm_clk_get(dev, "px_clk");
> + if (IS_ERR(dsi->px_clk)) {
> + ret = PTR_ERR(dsi->px_clk);
> + if (ret != ENOENT)
> + dev_err(dev, "Unable to get opt. px_clk: %d\n", ret);
> + dsi->px_clk = NULL;
> + }
> +
> /*
>* Note that the reset was not defined in the initial device tree, so
>* we have to be prepared for it not being found.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: stm32: add pixel clock mandatory property
Hi, in short: this patch is "CANCELLED" : ) There is no need to add the pixel clock as a mandatory property because now the clock value is ajusted in adjusted_mode. Please have a look to patches: - drm/stm: ltdc: use crtc_mode_fixup to update adjusted_mode clock - drm/bridge/synopsys: dsi: use adjusted_mode in mode_set Hope it is better, comments are welcome Many thanks, Philippe :-) On 01/22/2018 04:38 PM, Philippe Cornu wrote: > Add the DPI/RGB input pixel clock in mandatory properties > because it really offers a better preciseness for timing > computations. > > Signed-off-by: Philippe Cornu > --- > Please apply "dt-bindings: display: stm32: correct clock-names > in dsi panel example" before this patch. > > Changes in v3: remove the note regarding swapped clock names >(now in a separate patch). > Changes in v2: put new clock in last position (Rob Herring) > > Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > index 3eb1b48b47dd..942b7237ae87 100644 > --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt > @@ -29,6 +29,7 @@ Mandatory properties specific to STM32 DSI: > - compatible: "st,stm32-dsi". > - clock-names: > - phy pll reference clock string name, must be "ref". > + - DPI/RGB input pixel clock string name, must be "px_clk". > - resets: see [5]. > - reset-names: see [5]. > > @@ -97,8 +98,9 @@ Example 2: DSI panel > #size-cells = <0>; > compatible = "st,stm32-dsi"; > reg = <0x40016c00 0x800>; > - clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>; > - clock-names = "pclk", "ref"; > + clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>, > + <&rcc 1 CLK_LCD>; > + clock-names = "pclk", "ref", "px_clk"; > resets = <&rcc STM32F4_APB2_RESET(DSI)>; > reset-names = "apb"; > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC]drm/ttm: fix scheduling balance
On 01/25/2018 03:57 PM, Thomas Hellstrom wrote: On 01/25/2018 10:59 AM, Chunming Zhou wrote: there is a scheduling balance issue about get node like: a. process A allocates full memory and use it for submission. b. process B tries to allocates memory, will wait for process A BO idle in eviction. c. process A completes the job, process B eviction will put process A BO node, but in the meantime, process C is comming to allocate BO, whill directly get node successfully, and do submission, process B will again wait for process C BO idle. d. repeat the above setps, process B could be delayed much more. add a mutex to gerantee the allocation sequence for same domain. But there is a possibility that visible vram could be evicted to invisilbe, the tricky is they are same domain manager, so which needs a special handling. Change-Id: I260e8eb704f7b4788b071d3f641f21b242912256 Signed-off-by: Chunming Zhou I think this is a good approach, however there are two things that IMO needs fixing. [...] Thinking a bit more about this, the end result would be that typical "C" processes would get an unfair amount of GPU scheduling. Isn't it actually a scheduler's task outside of TTM to mitigate this? Further, TTM has had a design principle of avoiding locks held while waiting for GPU, with the exception of buffer object reservations, I think this would be the first violator, but a fairly harmless one. I can see the use for it though. It would also allow scanning the LRU lists for a suitable set of buffer objects to evict, rather than evicting in strict LRU order... /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC]drm/ttm: fix scheduling balance
Am 25.01.2018 um 17:47 schrieb Thomas Hellstrom: On 01/25/2018 03:57 PM, Thomas Hellstrom wrote: On 01/25/2018 10:59 AM, Chunming Zhou wrote: there is a scheduling balance issue about get node like: a. process A allocates full memory and use it for submission. b. process B tries to allocates memory, will wait for process A BO idle in eviction. c. process A completes the job, process B eviction will put process A BO node, but in the meantime, process C is comming to allocate BO, whill directly get node successfully, and do submission, process B will again wait for process C BO idle. d. repeat the above setps, process B could be delayed much more. add a mutex to gerantee the allocation sequence for same domain. But there is a possibility that visible vram could be evicted to invisilbe, the tricky is they are same domain manager, so which needs a special handling. Change-Id: I260e8eb704f7b4788b071d3f641f21b242912256 Signed-off-by: Chunming Zhou I think this is a good approach, however there are two things that IMO needs fixing. [...] Thinking a bit more about this, the end result would be that typical "C" processes would get an unfair amount of GPU scheduling. Isn't it actually a scheduler's task outside of TTM to mitigate this? Yes, exactly the reason why I rejected this. I actually considered moving the whole evicting to a background workitem. Further, TTM has had a design principle of avoiding locks held while waiting for GPU, with the exception of buffer object reservations, I think this would be the first violator, but a fairly harmless one. At least amdgpu normally doesn't block for any GPU operation to finish (with a few exception), but yes I see the problem as well. I can see the use for it though. It would also allow scanning the LRU lists for a suitable set of buffer objects to evict, rather than evicting in strict LRU order... At least for amdgpu that won't be possible even then, cause we don't tell TTM everything about buffer placement. E.g. BOs are not necessary composed from contiguous allocations. Christian. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC]drm/ttm: fix scheduling balance
Hi, On 01/25/2018 06:30 PM, Christian König wrote: Am 25.01.2018 um 17:47 schrieb Thomas Hellstrom: On 01/25/2018 03:57 PM, Thomas Hellstrom wrote: On 01/25/2018 10:59 AM, Chunming Zhou wrote: there is a scheduling balance issue about get node like: a. process A allocates full memory and use it for submission. b. process B tries to allocates memory, will wait for process A BO idle in eviction. c. process A completes the job, process B eviction will put process A BO node, but in the meantime, process C is comming to allocate BO, whill directly get node successfully, and do submission, process B will again wait for process C BO idle. d. repeat the above setps, process B could be delayed much more. add a mutex to gerantee the allocation sequence for same domain. But there is a possibility that visible vram could be evicted to invisilbe, the tricky is they are same domain manager, so which needs a special handling. Change-Id: I260e8eb704f7b4788b071d3f641f21b242912256 Signed-off-by: Chunming Zhou I think this is a good approach, however there are two things that IMO needs fixing. [...] Thinking a bit more about this, the end result would be that typical "C" processes would get an unfair amount of GPU scheduling. Isn't it actually a scheduler's task outside of TTM to mitigate this? Yes, exactly the reason why I rejected this. I actually considered moving the whole evicting to a background workitem. Ah,I should've read up on the following emails, Sorry about that. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/2] amdgpu: Update deadlock test to not assert on -ECANCELED
Kernel will abort jobs for guilty (causing GPU hang) context
with -ECANCELED don't assert if that the case.
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/deadlock_tests.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
index cd34cdf..9a42885 100644
--- a/tests/amdgpu/deadlock_tests.c
+++ b/tests/amdgpu/deadlock_tests.c
@@ -230,7 +230,7 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
for (i = 0; i < 200; i++) {
r = amdgpu_cs_submit(context_handle, 0,&ibs_request, 1);
- CU_ASSERT_EQUAL(r, 0);
+ CU_ASSERT_EQUAL((r == 0 || r == -ECANCELED), 1);
}
@@ -243,7 +243,7 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
r = amdgpu_cs_query_fence_status(&fence_status,
AMDGPU_TIMEOUT_INFINITE,0, &expired);
- CU_ASSERT_EQUAL(r, 0);
+ CU_ASSERT_EQUAL((r == 0 || r == -ECANCELED), 1);
r = amdgpu_bo_list_destroy(bo_list);
CU_ASSERT_EQUAL(r, 0);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/2] amdgpu: Fix segfault in deadlock test.
If amdgpu_cs_query_fence_status terminates prematurely the BO sometimes is unmapped before helper thread writes a vlaue into it causing a segfault. Signed-off-by: Andrey Grodzovsky --- tests/amdgpu/deadlock_tests.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c index 9a42885..fc49c48 100644 --- a/tests/amdgpu/deadlock_tests.c +++ b/tests/amdgpu/deadlock_tests.c @@ -245,6 +245,8 @@ static void amdgpu_deadlock_helper(unsigned ip_type) AMDGPU_TIMEOUT_INFINITE,0, &expired); CU_ASSERT_EQUAL((r == 0 || r == -ECANCELED), 1); + pthread_join(stress_thread, NULL); + r = amdgpu_bo_list_destroy(bo_list); CU_ASSERT_EQUAL(r, 0); @@ -254,6 +256,4 @@ static void amdgpu_deadlock_helper(unsigned ip_type) r = amdgpu_cs_ctx_free(context_handle); CU_ASSERT_EQUAL(r, 0); - - pthread_join(stress_thread, NULL); } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/2] amdgpu: Update deadlock test to not assert on -ECANCELED
Am 25.01.2018 um 19:10 schrieb Andrey Grodzovsky:
Kernel will abort jobs for guilty (causing GPU hang) context
with -ECANCELED don't assert if that the case.
Signed-off-by: Andrey Grodzovsky
Acked-by: Christian König
---
tests/amdgpu/deadlock_tests.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
index cd34cdf..9a42885 100644
--- a/tests/amdgpu/deadlock_tests.c
+++ b/tests/amdgpu/deadlock_tests.c
@@ -230,7 +230,7 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
for (i = 0; i < 200; i++) {
r = amdgpu_cs_submit(context_handle, 0,&ibs_request, 1);
- CU_ASSERT_EQUAL(r, 0);
+ CU_ASSERT_EQUAL((r == 0 || r == -ECANCELED), 1);
}
@@ -243,7 +243,7 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
r = amdgpu_cs_query_fence_status(&fence_status,
AMDGPU_TIMEOUT_INFINITE,0, &expired);
- CU_ASSERT_EQUAL(r, 0);
+ CU_ASSERT_EQUAL((r == 0 || r == -ECANCELED), 1);
r = amdgpu_bo_list_destroy(bo_list);
CU_ASSERT_EQUAL(r, 0);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103900] [SUMO][TURKS] Launching War Thunder make GPU stuck, and then system is hard lockup
https://bugs.freedesktop.org/show_bug.cgi?id=103900 --- Comment #3 from r...@tehno.ee --- After turning off shader optimization with R600_DEBUG=nosb War Thunder works and doesn't crash. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mgag200: fix a test in mga_vga_mode_valid()
The parentheses are in the wrong place here so we pass the bits per
pixel as zero.
Fixes: abbee6238775 ("drm/mgag200: Added resolution and bandwidth limits for
various G200e products.")
Signed-off-by: Dan Carpenter
---
Static analysis. Not tested.
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 68e5d9c94475..fb50a9ddaae8 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1620,8 +1620,8 @@ static int mga_vga_mode_valid(struct drm_connector
*connector,
return MODE_VIRTUAL_X;
if (mode->vdisplay > 1024)
return MODE_VIRTUAL_Y;
- if (mga_vga_calculate_mode_bandwidth(mode,
- bpp > (31877 * 1024)))
+ if (mga_vga_calculate_mode_bandwidth(mode, bpp) >
+ (31877 * 1024))
return MODE_BANDWIDTH;
} else if (mdev->type == G200_EV &&
(mga_vga_calculate_mode_bandwidth(mode, bpp)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM: double free in rcar_du_vsp.c
Hi Volodymyr, My apologies for the silence on this thread, but it has not been ignored. I believe Laurent has investigated this issue, and prepared a patch locally on his tree. However, he is currently out-of-office with travel and may not find time to reply to this thread this week or next. I suspect after a bit of testing and polish he will send it out for review/integration, or inclusion in a mainline pull-request. -- Regards Kieran On 24/01/18 12:04, Volodymyr Babchuk wrote: > > Looping in DRM maintainer. > >> Hello, >> >> I have found issue with double free() in RCAR DU VSP driver. it is >> caused by rcar_du_vsp_plane_atomic_duplicate_state(), which duplicates >> struct rcar_du_vsp_plane_state. This struct holds sg_tables which are >> then freed in rcar_du_vsp_plane_cleanup_fb(). This function is called >> for every rcar_du_vsp_plane_state, so it calls sg_free_table() twice for >> the same sg_table. >> >> I'm not familiar with DRM, so I can't say why this does not occur every >> time, but this bug caused problems on our setup from time to time. Looks >> like it occurs only under heavy system load. >> >> As I said, I'm not good in DRM, so I don't know the proper fix. But you >> can find workaround at [1]. I don't know how good it is, but at least >> it resolved issue on our setup. If drm guys think that this fix is fine >> enough, I can push it to the ML for a proper review. >> >> [1] >> https://github.com/lorc/linux/commit/80155506d3499273155366a1d263a81baface718 >> >> Cheers, >> -- >> Volodymyr Babchuk >> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Move irq setup/teardown to pci ctor/dtor
For a while we've been having issues with seemingly random interrupts
coming from nvidia cards when resuming them. Originally the fix for this
was thought to be just re-arming the MSI interrupt registers right after
re-allocating our IRQs, however it seems a lot of what we do is both
wrong and not even nessecary.
This was made apparent by what appeared to be a regression in the
mainline kernel that started introducing suspend/resume issues for
nouveau:
a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation)
After this commit was introduced, we started getting interrupts from the
GPU before we actually re-allocated our own IRQ (see references below)
and assigned the IRQ handler. Investigating this turned out that the
problem was not with the commit, but the fact that nouveau even
free/allocates it's irqs before and after suspend/resume.
For starters: drivers in the linux kernel haven't had to handle
freeing/re-allocating their IRQs during suspend/resume cycles for quite
a while now. Nouveau seems to be one of the few drivers left that still
does this, despite the fact there's no reason we actually need to since
disabling interrupts from the device side should be enough, as the
kernel is already smart enough to know to disable host-side interrupts
for us before going into suspend. Since we were tearing down our IRQs by
hand however, that means there was a short period during resume where
interrupts could be received before we re-allocated our IRQ which would
lead to us getting an unhandled IRQ. Since we never handle said IRQ and
re-arm the interrupt registers, this would cause us to miss all of the
interrupts from the GPU and cause our init process to start timing out
on anything requiring interrupts.
So, since this whole setup/teardown every suspend/resume cycle is
useless anyway, move irq setup/teardown into the pci subdev's ctor/dtor
functions instead so they're only called at driver load and driver
unload. This should fix most of the issues with pending interrupts on
resume, along with getting suspend/resume for nouveau to work again.
As well, this probably means we can also just remove the msi rearm call
inside nvkm_pci_init(). But since our main focus here is to fix
suspend/resume before 4.16, we'll save that for a later patch.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
Cc: Thomas Gleixner
Cc: Mike Galbraith
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c| 43 +++
2 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h
index 23803cc859fd..378bfc8d5fa8 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h
@@ -31,6 +31,7 @@ struct nvkm_pci {
} pcie;
bool msi;
+ bool teardown;
};
u32 nvkm_pci_rd32(struct nvkm_pci *, u16 addr);
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
index deb96de54b00..4e020f05c99f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
@@ -71,6 +71,10 @@ nvkm_pci_intr(int irq, void *arg)
struct nvkm_pci *pci = arg;
struct nvkm_device *device = pci->subdev.device;
bool handled = false;
+
+ if (pci->teardown)
+ return IRQ_HANDLED;
+
nvkm_mc_intr_unarm(device);
if (pci->msi)
pci->func->msi_rearm(pci);
@@ -84,11 +88,6 @@ nvkm_pci_fini(struct nvkm_subdev *subdev, bool suspend)
{
struct nvkm_pci *pci = nvkm_pci(subdev);
- if (pci->irq >= 0) {
- free_irq(pci->irq, pci);
- pci->irq = -1;
- }
-
if (pci->agp.bridge)
nvkm_agp_fini(pci);
@@ -108,8 +107,20 @@ static int
nvkm_pci_oneinit(struct nvkm_subdev *subdev)
{
struct nvkm_pci *pci = nvkm_pci(subdev);
- if (pci_is_pcie(pci->pdev))
- return nvkm_pcie_oneinit(pci);
+ struct pci_dev *pdev = pci->pdev;
+ int ret;
+
+ if (pci_is_pcie(pci->pdev)) {
+ ret = nvkm_pcie_oneinit(pci);
+ if (ret)
+ return ret;
+ }
+
+ ret = request_irq(pdev->irq, nvkm_pci_intr, IRQF_SHARED, "nvkm", pci);
+ if (ret)
+ return ret;
+ pci->irq = pdev->irq;
+
return 0;
}
@@ -117,7 +128,6 @@ static int
nvkm_pci_init(struct nvkm_subdev *subdev)
{
struct nvkm_pci *pci = nvkm_pci(subdev);
- struct pci_dev *pdev = pci->pdev;
int ret;
if (pci->agp.bridge) {
@@ -131,28 +141,30 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
if (pci->func->init)
pci->func->init(pci);
- ret = request_irq(pdev->irq, nvkm_pci_intr, IRQF_SHARED, "nvkm", pci);
- if (ret)
- r
[PATCH v2] drm/nouveau: Move irq setup/teardown to pci ctor/dtor
For a while we've been having issues with seemingly random interrupts
coming from nvidia cards when resuming them. Originally the fix for this
was thought to be just re-arming the MSI interrupt registers right after
re-allocating our IRQs, however it seems a lot of what we do is both
wrong and not even nessecary.
This was made apparent by what appeared to be a regression in the
mainline kernel that started introducing suspend/resume issues for
nouveau:
a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation)
After this commit was introduced, we started getting interrupts from the
GPU before we actually re-allocated our own IRQ (see references below)
and assigned the IRQ handler. Investigating this turned out that the
problem was not with the commit, but the fact that nouveau even
free/allocates it's irqs before and after suspend/resume.
For starters: drivers in the linux kernel haven't had to handle
freeing/re-allocating their IRQs during suspend/resume cycles for quite
a while now. Nouveau seems to be one of the few drivers left that still
does this, despite the fact there's no reason we actually need to since
disabling interrupts from the device side should be enough, as the
kernel is already smart enough to know to disable host-side interrupts
for us before going into suspend. Since we were tearing down our IRQs by
hand however, that means there was a short period during resume where
interrupts could be received before we re-allocated our IRQ which would
lead to us getting an unhandled IRQ. Since we never handle said IRQ and
re-arm the interrupt registers, this would cause us to miss all of the
interrupts from the GPU and cause our init process to start timing out
on anything requiring interrupts.
So, since this whole setup/teardown every suspend/resume cycle is
useless anyway, move irq setup/teardown into the pci subdev's ctor/dtor
functions instead so they're only called at driver load and driver
unload. This should fix most of the issues with pending interrupts on
resume, along with getting suspend/resume for nouveau to work again.
As well, this probably means we can also just remove the msi rearm call
inside nvkm_pci_init(). But since our main focus here is to fix
suspend/resume before 4.15, we'll save that for a later patch.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
Cc: Thomas Gleixner
Cc: Mike Galbraith
Cc: sta...@vger.kernel.org
---
Changes since v1:
- Fix small typo in commit message
No functional changes
drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c| 43 +++
2 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h
index 23803cc859fd..378bfc8d5fa8 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/pci.h
@@ -31,6 +31,7 @@ struct nvkm_pci {
} pcie;
bool msi;
+ bool teardown;
};
u32 nvkm_pci_rd32(struct nvkm_pci *, u16 addr);
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
index deb96de54b00..4e020f05c99f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
@@ -71,6 +71,10 @@ nvkm_pci_intr(int irq, void *arg)
struct nvkm_pci *pci = arg;
struct nvkm_device *device = pci->subdev.device;
bool handled = false;
+
+ if (pci->teardown)
+ return IRQ_HANDLED;
+
nvkm_mc_intr_unarm(device);
if (pci->msi)
pci->func->msi_rearm(pci);
@@ -84,11 +88,6 @@ nvkm_pci_fini(struct nvkm_subdev *subdev, bool suspend)
{
struct nvkm_pci *pci = nvkm_pci(subdev);
- if (pci->irq >= 0) {
- free_irq(pci->irq, pci);
- pci->irq = -1;
- }
-
if (pci->agp.bridge)
nvkm_agp_fini(pci);
@@ -108,8 +107,20 @@ static int
nvkm_pci_oneinit(struct nvkm_subdev *subdev)
{
struct nvkm_pci *pci = nvkm_pci(subdev);
- if (pci_is_pcie(pci->pdev))
- return nvkm_pcie_oneinit(pci);
+ struct pci_dev *pdev = pci->pdev;
+ int ret;
+
+ if (pci_is_pcie(pci->pdev)) {
+ ret = nvkm_pcie_oneinit(pci);
+ if (ret)
+ return ret;
+ }
+
+ ret = request_irq(pdev->irq, nvkm_pci_intr, IRQF_SHARED, "nvkm", pci);
+ if (ret)
+ return ret;
+ pci->irq = pdev->irq;
+
return 0;
}
@@ -117,7 +128,6 @@ static int
nvkm_pci_init(struct nvkm_subdev *subdev)
{
struct nvkm_pci *pci = nvkm_pci(subdev);
- struct pci_dev *pdev = pci->pdev;
int ret;
if (pci->agp.bridge) {
@@ -131,28 +141,30 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
if (pci->func->init)
pci->func->init(pci);
- ret = request_irq(pdev->i
[Bug 104790] When using OpenGL 4.x some applications crash
https://bugs.freedesktop.org/show_bug.cgi?id=104790 --- Comment #1 from Dieter Nützel --- Are you running Wine-Nine? I remember such 'red'ich' colors with Nine. Then it could be the current Mesa git Nine bug. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode_set
On Thu, Jan 25, 2018 at 7:55 AM, Philippe Cornu wrote: > The "adjusted_mode" clock value (ie the real pixel clock) is more > accurate than "mode" clock value (ie the panel/bridge requested > clock value). It offers a better preciseness for timing > computations and allows to reduce the extra dsi bandwidth in > burst mode (from ~20% to ~10-12%, hw platform dependant). > > Signed-off-by: Philippe Cornu > --- > Note: This patch replaces "drm/bridge/synopsys: dsi: add optional pixel clock" These two appear to be the same for my cases, but at least nothing breaks: Tested-by: Brian Norris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value
On Thu, Jan 25, 2018 at 4:16 AM, Andrzej Hajda wrote: > On 24.01.2018 19:37, Brian Norris wrote: >> With your current patch, you're returning the 'mipi_dsi_packet::size', >> which is the sum of both TX and RX. > > I did not found docs saying mipi_dsi_packet::size is a sum of tx and rx. > tx and rx packets are two different packets, so they do not sum up. > But thanks for bringing it up, it shows docs are incomplete/misleading. Ugh, I misread that again. No, mipi_dsi_packet::size is NOT claimed to contain both TX and RX. It just says "size of the packet", and packet clearly does not hold the RX data anyway. I don't know what's happening to my reading comprehension... But the mismatch on whether drivers implement these correctly and whether any callers actually care about the documented semantics still stands. Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104790] When using OpenGL 4.x some applications crash
https://bugs.freedesktop.org/show_bug.cgi?id=104790 --- Comment #2 from lei.p...@gmail.com --- (In reply to Dieter Nützel from comment #1) > Are you running Wine-Nine? > I remember such 'red'ich' colors with Nine. > Then it could be the current Mesa git Nine bug. No, this glitch is under Wine CSMT D3D, when using nine it is actually proper picture with compatibility mode, with core profile, it is irrelevant what I use (nine or wine d3d) it would crash instantly without any trace in terminal, but standard wine output error in "Windows like" dialog. With core profile, same would happen to native GNU/Linux application genymotion, but it does work with COMPAT profile. If you are asking me is wine patched with nine, yes it is, but that should be irrelevant when "nine" is unticked and CSMT or non-CSMT wine translation is used. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [amd-staging-drm-next] regression - *ERROR* Don't have enable_spread_spectrum_on_ppll for v4
Am 03.01.2018 16:03, schrieb Harry Wentland:
On 2017-12-27 04:04 AM, Michel Dänzer wrote:
On 2017-12-27 05:43 AM, Dieter Nützel wrote:
Hello AMD team,
I got this since latest 'amd-staging-drm-next' git update
(#b956c586e58a) during boot with Polaris RX580 DC on:
[ 3.586342] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR*
Don't
have enable_spread_spectrum_on_ppll for v4
[ 3.586410] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR*
Don't
have program_clock for v7
Latest GOOD commit was #b341a19e8039 (drm/radeon: Remove
KFD_CIK_SDMA_QUEUE_OFFSET).
I'll bisect if I have some time.
Maybe someone send a hint to the right commit.
I don't think bisecting is useful, it'll most likely just identify
commit 040dda2e1f52 ("drm/amd/display: Error print when ATOM BIOS
implementation is missing") which started printing these messages for
missing ATOM BIOS implementations.
I'm not sure, but I suspect these messages are harmless, given that
things are otherwise presumably still working as well as they were
before.
These are harmless. I wrongfully assumed that printing errors here
should be fine on all ASICs as I assumed all relevant functions were
implemented. Apparently they're not, proving me wrong and proving the
usefulness of some sort of print here. I'll send a patch to demote the
prints to debug level.
Harry
Thank you Harry,
current amd-staging-drm-next (#0a7d506e54ca) calmed it, at least for me.
;-)
Greetings,
Dieter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104790] When using OpenGL 4.x some applications crash
https://bugs.freedesktop.org/show_bug.cgi?id=104790 --- Comment #3 from Dieter Nützel --- (In reply to lei.pero from comment #2) > (In reply to Dieter Nützel from comment #1) > > Are you running Wine-Nine? > > I remember such 'red'ich' colors with Nine. > > Then it could be the current Mesa git Nine bug. > > No, this glitch is under Wine CSMT D3D, when using nine it is actually > proper picture with compatibility mode, with core profile, it is irrelevant > what I use (nine or wine d3d) it would crash instantly without any trace in > terminal, but standard wine output error in "Windows like" dialog. > > With core profile, same would happen to native GNU/Linux application > genymotion, but it does work with COMPAT profile. > > If you are asking me is wine patched with nine, yes it is, but that should > be irrelevant when "nine" is unticked and CSMT or non-CSMT wine translation > is used. Yes,right. Is this a regression (worked before)? Can you bisect? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/sii8620: fix display modes validation
Hi Maciej,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20180119]
[cannot apply to v4.15-rc9]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Maciej-Purski/drm-bridge-sii8620-fix-display-modes-validation/20180125-174703
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-sb0-01260635 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/gpu/drm/bridge/sil-sii8620.c: In function 'sii8620_mode_valid':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2242:2: warning: 'ret' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
return ret;
^
vim +/ret +2242 drivers/gpu/drm/bridge/sil-sii8620.c
2220
2221 static enum drm_mode_status sii8620_mode_valid(struct drm_bridge
*bridge,
const struct drm_display_mode
*mode)
2223 {
2224 enum drm_mode_status ret;
2225 struct sii8620 *ctx = bridge_to_sii8620(bridge);
2226 int pack_required = sii8620_is_packing_required(ctx, mode);
2227 bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] &
2228 MHL_DCAP_VID_LINK_PPIXEL;
2229
2230 switch (pack_required) {
2231 case -1:
2232 ret = MODE_CLOCK_HIGH;
2233 break;
2234 case 1:
2235 ret = (can_pack) ? MODE_OK : MODE_CLOCK_HIGH;
2236 break;
2237 case 0:
2238 ret = MODE_OK;
2239 break;
2240 }
2241
> 2242 return ret;
2243 }
2244
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/nouveau: Move irq setup/teardown to pci ctor/dtor
For a while we've been having issues with seemingly random interrupts
coming from nvidia cards when resuming them. Originally the fix for this
was thought to be just re-arming the MSI interrupt registers right after
re-allocating our IRQs, however it seems a lot of what we do is both
wrong and not even nessecary.
This was made apparent by what appeared to be a regression in the
mainline kernel that started introducing suspend/resume issues for
nouveau:
a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation)
After this commit was introduced, we started getting interrupts from the
GPU before we actually re-allocated our own IRQ (see references below)
and assigned the IRQ handler. Investigating this turned out that the
problem was not with the commit, but the fact that nouveau even
free/allocates it's irqs before and after suspend/resume.
For starters: drivers in the linux kernel haven't had to handle
freeing/re-allocating their IRQs during suspend/resume cycles for quite
a while now. Nouveau seems to be one of the few drivers left that still
does this, despite the fact there's no reason we actually need to since
disabling interrupts from the device side should be enough, as the
kernel is already smart enough to know to disable host-side interrupts
for us before going into suspend. Since we were tearing down our IRQs by
hand however, that means there was a short period during resume where
interrupts could be received before we re-allocated our IRQ which would
lead to us getting an unhandled IRQ. Since we never handle said IRQ and
re-arm the interrupt registers, this would cause us to miss all of the
interrupts from the GPU and cause our init process to start timing out
on anything requiring interrupts.
So, since this whole setup/teardown every suspend/resume cycle is
useless anyway, move irq setup/teardown into the pci subdev's ctor/dtor
functions instead so they're only called at driver load and driver
unload. This should fix most of the issues with pending interrupts on
resume, along with getting suspend/resume for nouveau to work again.
As well, this probably means we can also just remove the msi rearm call
inside nvkm_pci_init(). But since our main focus here is to fix
suspend/resume before 4.15, we'll save that for a later patch.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
Cc: Thomas Gleixner
Cc: Mike Galbraith
Cc: sta...@vger.kernel.org
---
Changes since v2:
- Remove teardown, just reuse pci->irq to indicate when we're tearing
down the driver
drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 44 +-
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
index deb96de54b00..3b2cad639388 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
@@ -71,6 +71,10 @@ nvkm_pci_intr(int irq, void *arg)
struct nvkm_pci *pci = arg;
struct nvkm_device *device = pci->subdev.device;
bool handled = false;
+
+ if (pci->irq < 0)
+ return IRQ_HANDLED;
+
nvkm_mc_intr_unarm(device);
if (pci->msi)
pci->func->msi_rearm(pci);
@@ -84,11 +88,6 @@ nvkm_pci_fini(struct nvkm_subdev *subdev, bool suspend)
{
struct nvkm_pci *pci = nvkm_pci(subdev);
- if (pci->irq >= 0) {
- free_irq(pci->irq, pci);
- pci->irq = -1;
- }
-
if (pci->agp.bridge)
nvkm_agp_fini(pci);
@@ -108,8 +107,20 @@ static int
nvkm_pci_oneinit(struct nvkm_subdev *subdev)
{
struct nvkm_pci *pci = nvkm_pci(subdev);
- if (pci_is_pcie(pci->pdev))
- return nvkm_pcie_oneinit(pci);
+ struct pci_dev *pdev = pci->pdev;
+ int ret;
+
+ if (pci_is_pcie(pci->pdev)) {
+ ret = nvkm_pcie_oneinit(pci);
+ if (ret)
+ return ret;
+ }
+
+ ret = request_irq(pdev->irq, nvkm_pci_intr, IRQF_SHARED, "nvkm", pci);
+ if (ret)
+ return ret;
+ pci->irq = pdev->irq;
+
return 0;
}
@@ -117,7 +128,6 @@ static int
nvkm_pci_init(struct nvkm_subdev *subdev)
{
struct nvkm_pci *pci = nvkm_pci(subdev);
- struct pci_dev *pdev = pci->pdev;
int ret;
if (pci->agp.bridge) {
@@ -131,28 +141,32 @@ nvkm_pci_init(struct nvkm_subdev *subdev)
if (pci->func->init)
pci->func->init(pci);
- ret = request_irq(pdev->irq, nvkm_pci_intr, IRQF_SHARED, "nvkm", pci);
- if (ret)
- return ret;
-
- pci->irq = pdev->irq;
-
/* Ensure MSI interrupts are armed, for the case where there are
* already interrupts pending (for whatever reason) at load time.
*/
if (pci->msi)
pci->func->msi_rearm(pci);
- return ret;
+ return 0;
}
static void *
nvkm_pci_dtor(struct nvkm_subdev *subde
[Bug 104790] When using OpenGL 4.x some applications crash
https://bugs.freedesktop.org/show_bug.cgi?id=104790 --- Comment #4 from lei.p...@gmail.com --- (In reply to Dieter Nützel from comment #3) > (In reply to lei.pero from comment #2) > > (In reply to Dieter Nützel from comment #1) > > > Are you running Wine-Nine? > > > I remember such 'red'ich' colors with Nine. > > > Then it could be the current Mesa git Nine bug. > > > > No, this glitch is under Wine CSMT D3D, when using nine it is actually > > proper picture with compatibility mode, with core profile, it is irrelevant > > what I use (nine or wine d3d) it would crash instantly without any trace in > > terminal, but standard wine output error in "Windows like" dialog. > > > > With core profile, same would happen to native GNU/Linux application > > genymotion, but it does work with COMPAT profile. > > > > If you are asking me is wine patched with nine, yes it is, but that should > > be irrelevant when "nine" is unticked and CSMT or non-CSMT wine translation > > is used. > > Yes,right. > > Is this a regression (worked before)? > Can you bisect? As far as I know it isn't regression, the first time I've tried to enable 4.1 profile it did behave that way, I think it was on Mesa 12.0, but don't hold me for a word. I did not reported at that time because there was no full support for r600, but now, I reported it just in case decision comes to enable 4.x profile by default, not to "slip" in stable realese. With core profile 3.3 (default one) everything works as expected, none of these issues. I could try to bisect, but I don't think distribution would alow me to go that far, and if even there is a point of doing so because almost full support for r600 was added just recently. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: Add a warning msg on dsi read requests
On Thu, Jan 25, 2018 at 11:37:59AM +0100, Philippe Cornu wrote:
> The dcs/generic dsi read feature is not yet implemented so it
> is important to warn the host_transfer() caller in case of
> read operation requests.
>
> Signed-off-by: Philippe Cornu
Awesome, thanks.
Reviewed-by: Brian Norris
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index daec7881be6d..72ecaeb40822 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -405,6 +405,12 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
> mipi_dsi_host *host,
> struct mipi_dsi_packet packet;
> int ret;
>
> + if (msg->rx_buf || msg->rx_len) {
> + /* TODO dw drv improvements: implement read feature */
> + dev_warn(dsi->dev, "read operations not yet implemented\n");
> + return -EINVAL;
> + }
> +
> ret = mipi_dsi_create_packet(&packet, msg);
> if (ret) {
> dev_err(dsi->dev, "failed to create packet: %d\n", ret);
> --
> 2.15.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value
On Thu, Jan 25, 2018 at 11:38:00AM +0100, Philippe Cornu wrote:
> The dw_mipi_dsi_host_transfer() must return the number of
> bytes transmitted/received on success instead of 0.
> Note: As the read feature is not implemented, only the
> transmitted number of bytes is returned for the moment.
>
> Signed-off-by: Philippe Cornu
Assuming we're going with the current documented semantics (where we
return # of TX bytes for writes), then:
Reviewed-by: Brian Norris
I believe Archit was suggesting maybe changing that sometime, but that's
no excuse for not matching documentation now.
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 72ecaeb40822..090bf62d1ea8 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -419,7 +419,16 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
> mipi_dsi_host *host,
>
> dw_mipi_message_config(dsi, msg);
>
> - return dw_mipi_dsi_write(dsi, &packet);
> + ret = dw_mipi_dsi_write(dsi, &packet);
> + if (ret)
> + return ret;
> +
> + /*
> + * TODO Only transmitted size is returned as actual driver does
> + * not support dcs/generic reads. Please update return value when
> + * delivering the read feature.
> + */
> + return packet.size;
You're really holding my hand here, I see :) Thanks I guess.
> }
>
> static const struct mipi_dsi_host_ops dw_mipi_dsi_host_ops = {
> --
> 2.15.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104762] Various segfaults/problems in qt/plasma
https://bugs.freedesktop.org/show_bug.cgi?id=104762 --- Comment #10 from Timothy Arceri --- I was able to reproduce the problem. Fix sent to list: https://patchwork.freedesktop.org/series/37147/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98974] Can't see borders/empires in Stellaris
https://bugs.freedesktop.org/show_bug.cgi?id=98974 John changed: What|Removed |Added CC||bugs.freedesktop@johnthomso ||n.fastmail.com.au --- Comment #20 from John --- (In reply to Gert Wollny from comment #14) > If this doesn't fix the bug, could you post an apitrace? mesa 17.3.2 no galaxy map borders apitrace: DEBUGGER="apitrace trace" steam-native steam://rungameid/281990 https://www.dropbox.com/s/a8d38yoaeu7n9uy/stellaris_noborders_r600g.trace?dl=1 SHA256(stellaris_noborders_r600g.trace)= bfc9f724dff5f27a3b3670a15b0bdd72c14b049e047c9194d22fe0651f653888 EE r600_shader.c:3672 r600_shader_from_tgsi - GPR limit exceeded - shader requires 213 registers EE r600_shader.c:183 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:787 r600_shader_select - Failed to build shader variant (type=1) -12 AMD 5850 DRI3 Arch Linux Stellaris 1.9.1 Is there a preferred apitrace file host? Thanks -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] drm: xlnx: Xilinx DRM KMS module
Xilinx has various platforms for display, where users can create using multiple IPs in the programmable FPGA fabric, or where some hardened piepline is available on the chip. Furthermore, hardened pipeline can also interact with soft logics in FPGA. The Xilinx DRM KMS module is to integrate multiple subdevices and to represent the entire pipeline as a single DRM device. The module includes helper (ex, framebuffer and gem helpers) and glue logic (ex, crtc interface) functions. Signed-off-by: Hyun Kwon Acked-by: Daniel Vetter --- v4 - Fix a bug in of graph binding handling - Remove vblank callbacks from xlnx_crtc - Remove the dt binding. This module becomes more like a library. - Rephrase the commit message v3 - Add Laurent as a maintainer - Fix multiple-reference on gem objects v2 - Change the SPDX identifier format - Merge patches(crtc, gem, fb) into single one v2 of xlnx_drv - Rename kms to display in xlnx_drv - Replace some xlnx specific fb helper with common helpers in xlnx_drv - Don't set the commit tail callback in xlnx_drv - Support 'ports' graph binding in xlnx_drv v2 of xlnx_fb - Remove wrappers in xlnx_fb - Replace some functions with drm core helpers in xlnx_fb --- --- MAINTAINERS | 9 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/xlnx/Kconfig | 12 + drivers/gpu/drm/xlnx/Makefile| 2 + drivers/gpu/drm/xlnx/xlnx_crtc.c | 177 + drivers/gpu/drm/xlnx/xlnx_crtc.h | 70 + drivers/gpu/drm/xlnx/xlnx_drv.c | 546 +++ drivers/gpu/drm/xlnx/xlnx_drv.h | 33 +++ drivers/gpu/drm/xlnx/xlnx_fb.c | 298 + drivers/gpu/drm/xlnx/xlnx_fb.h | 33 +++ drivers/gpu/drm/xlnx/xlnx_gem.c | 47 drivers/gpu/drm/xlnx/xlnx_gem.h | 26 ++ 13 files changed, 1256 insertions(+) create mode 100644 drivers/gpu/drm/xlnx/Kconfig create mode 100644 drivers/gpu/drm/xlnx/Makefile create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h diff --git a/MAINTAINERS b/MAINTAINERS index 5bc088f..07c0e73 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4789,6 +4789,15 @@ F: drivers/gpu/drm/etnaviv/ F: include/uapi/drm/etnaviv_drm.h F: Documentation/devicetree/bindings/display/etnaviv/ +DRM DRIVERS FOR XILINX +M: Hyun Kwon +M: Laurent Pinchart +L: dri-devel@lists.freedesktop.org +S: Maintained +F: drivers/gpu/drm/xlnx/ +F: Documentation/devicetree/bindings/display/xlnx/ +T: git git://anongit.freedesktop.org/drm/drm-misc + DRM DRIVERS FOR ZTE ZX M: Shawn Guo L: dri-devel@lists.freedesktop.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index deeefa7..5a3ec66 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig" source "drivers/gpu/drm/tve200/Kconfig" +source "drivers/gpu/drm/xlnx/Kconfig" + # Keep legacy drivers last menuconfig DRM_LEGACY diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 50093ff..f93557e 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB) += mxsfb/ obj-$(CONFIG_DRM_TINYDRM) += tinydrm/ obj-$(CONFIG_DRM_PL111) += pl111/ obj-$(CONFIG_DRM_TVE200) += tve200/ +obj-$(CONFIG_DRM_XLNX) += xlnx/ diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig new file mode 100644 index 000..19fd7cd --- /dev/null +++ b/drivers/gpu/drm/xlnx/Kconfig @@ -0,0 +1,12 @@ +config DRM_XLNX + tristate "Xilinx DRM KMS Driver" + depends on DRM && OF + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + help + Xilinx DRM KMS driver. Choose this option if you have + a Xilinx SoCs with hardened display pipeline or soft + display pipeline using Xilinx IPs in FPGA. This module + provides the kernel mode setting functionalities + for Xilinx display drivers. diff --git a/drivers/gpu/drm/xlnx/Makefile b/drivers/gpu/drm/xlnx/Makefile new file mode 100644 index 000..c60a281 --- /dev/null +++ b/drivers/gpu/drm/xlnx/Makefile @@ -0,0 +1,2 @@ +xlnx_drm-objs += xlnx_crtc.o xlnx_drv.o xlnx_fb.o xlnx_gem.o +obj-$(CONFIG_DRM_XLNX) += xlnx_drm.o diff --git a/drivers/gpu/drm/xlnx/xlnx_crtc.c b/drivers/gpu/drm/xlnx/xlnx_crtc.c new file mode 100644 index 000..de83905 --- /dev/null +++ b/drivers/gpu/drm/xlnx/xlnx_crtc.c @@ -0,0 +1,177 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Xilinx DRM crtc driver + * + * Copyright (C) 2017 - 2018 Xilinx, Inc. + * + * Author: Hyun
[PATCH v4 3/5] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DP subsystem display
Xilinx ZynqMP has a hardened display pipeline. The pipeline can be logically partitioned into 2 parts: display controller and DisplayPort encoder / transmitter. This driver handles the display controller part of the pipeline that handles buffer management and blending. Signed-off-by: Hyun Kwon Acked-by: Daniel Vetter --- v4 - Use drm_crtc_funcs for vblank - Remove child nodes for layer v3 - Fix a small typo v2 - Use drm_fb_cma_get_gem_addr() - Use drm_crtc_arm_vblank_event() - Split drm properties into a separate patch - Remove dummy funcs - Don't add offset as it's already done by a new helper - Change the SPDX identifier format - Minor change of a commit message --- --- drivers/gpu/drm/xlnx/zynqmp_disp.c | 2676 drivers/gpu/drm/xlnx/zynqmp_disp.h | 36 + 2 files changed, 2712 insertions(+) create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.c create mode 100644 drivers/gpu/drm/xlnx/zynqmp_disp.h diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c new file mode 100644 index 000..e47d77d --- /dev/null +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c @@ -0,0 +1,2676 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * ZynqMP Display Controller Driver + * + * Copyright (C) 2017 - 2018 Xilinx, Inc. + * + * Author: Hyun Woo Kwon + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "xlnx_crtc.h" +#include "xlnx_fb.h" +#include "zynqmp_disp.h" +#include "zynqmp_dp.h" +#include "zynqmp_dpsub.h" + +/* + * Overview + * + * + * The display part of ZynqMP DP subsystem. Internally, the device + * is partitioned into 3 blocks: AV buffer manager, Blender, Audio. + * The driver creates the DRM crtc and plane objectes and maps the DRM + * interface into those 3 blocks. In high level, the driver is layered + * in the following way: + * + * zynqmp_disp_crtc & zynqmp_disp_plane + * |->zynqmp_disp + * |->zynqmp_disp_aud + * |->zynqmp_disp_blend + * |->zynqmp_disp_av_buf + * + * The driver APIs are used externally by + * - zynqmp_dpsub: Top level ZynqMP DP subsystem driver + * - zynqmp_dp: ZynqMP DP driver + * - xlnx_crtc: Xilinx DRM specific crtc functions + */ + +/* Blender registers */ +#define ZYNQMP_DISP_V_BLEND_BG_CLR_0 0x0 +#define ZYNQMP_DISP_V_BLEND_BG_CLR_1 0x4 +#define ZYNQMP_DISP_V_BLEND_BG_CLR_2 0x8 +#define ZYNQMP_DISP_V_BLEND_BG_MAX 0xfff +#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA 0xc +#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA_MASK 0x1fe +#define ZYNQMP_DISP_V_BLEND_SET_GLOBAL_ALPHA_MAX 0xff +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT 0x14 +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_RGB 0x0 +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YCBCR4440x1 +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YCBCR4220x2 +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_YONLY 0x3 +#define ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_XVYCC 0x4 +#define ZYNQMP_DISP_V_BLEND_OUTPUT_EN_DOWNSAMPLE BIT(4) +#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL 0x18 +#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_EN_USBIT(0) +#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_RGB BIT(1) +#define ZYNQMP_DISP_V_BLEND_LAYER_CONTROL_BYPASS BIT(8) +#define ZYNQMP_DISP_V_BLEND_NUM_COEFF 9 +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF0 0x20 +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF1 0x24 +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF2 0x28 +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF3 0x2c +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF4 0x30 +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF5 0x34 +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF6 0x38 +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF7 0x3c +#define ZYNQMP_DISP_V_BLEND_RGB2YCBCR_COEFF8 0x40 +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF0 0x44 +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF1 0x48 +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF2 0x4c +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF3 0x50 +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF4 0x54 +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF5 0x58 +#define ZYNQMP_DISP_V_BLEND_IN1CSC_COEFF6
[PATCH v4 5/5] drm: xlnx: ZynqMP DP subsystem DRM KMS driver
This is a wrapper around the ZynqMP Display and DisplayPort drivers.
Signed-off-by: Hyun Kwon
Acked-by: Daniel Vetter
---
v4
- Use the newly added xlnx pipeline calls to initialize drm device
v2
- Change the SPDX identifier format
---
---
drivers/gpu/drm/xlnx/Kconfig| 11 +++
drivers/gpu/drm/xlnx/Makefile | 3 +
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 155
drivers/gpu/drm/xlnx/zynqmp_dpsub.h | 28 +++
4 files changed, 197 insertions(+)
create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.c
create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dpsub.h
diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
index 19fd7cd..7c5529c 100644
--- a/drivers/gpu/drm/xlnx/Kconfig
+++ b/drivers/gpu/drm/xlnx/Kconfig
@@ -10,3 +10,14 @@ config DRM_XLNX
display pipeline using Xilinx IPs in FPGA. This module
provides the kernel mode setting functionalities
for Xilinx display drivers.
+
+config DRM_ZYNQMP_DPSUB
+ tristate "ZynqMP DP Subsystem Driver"
+ depends on ARCH_ZYNQMP && OF && DRM_XLNX && COMMON_CLK
+ select DMA_ENGINE
+ select GENERIC_PHY
+ help
+ DRM KMS driver for ZynqMP DP Subsystem controller. Choose
+ this option if you have a Xilinx ZynqMP SoC with DisplayPort
+ subsystem. The driver provides the kernel mode setting
+ functionlaities for ZynqMP DP subsystem.
diff --git a/drivers/gpu/drm/xlnx/Makefile b/drivers/gpu/drm/xlnx/Makefile
index c60a281..064a05a 100644
--- a/drivers/gpu/drm/xlnx/Makefile
+++ b/drivers/gpu/drm/xlnx/Makefile
@@ -1,2 +1,5 @@
xlnx_drm-objs += xlnx_crtc.o xlnx_drv.o xlnx_fb.o xlnx_gem.o
obj-$(CONFIG_DRM_XLNX) += xlnx_drm.o
+
+zynqmp-dpsub-objs += zynqmp_disp.o zynqmp_dpsub.o zynqmp_dp.o
+obj-$(CONFIG_DRM_ZYNQMP_DPSUB) += zynqmp-dpsub.o
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
new file mode 100644
index 000..5aaf9fb
--- /dev/null
+++ b/drivers/gpu/drm/xlnx/zynqmp_dpsub.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP DP Subsystem Driver
+ *
+ * Copyright (C) 2017 - 2018 Xilinx, Inc.
+ *
+ * Author: Hyun Woo Kwon
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "xlnx_drv.h"
+
+#include "zynqmp_disp.h"
+#include "zynqmp_dp.h"
+#include "zynqmp_dpsub.h"
+
+static int
+zynqmp_dpsub_bind(struct device *dev, struct device *master, void *data)
+{
+ int ret;
+
+ ret = zynqmp_disp_bind(dev, master, data);
+ if (ret)
+ return ret;
+
+ /* zynqmp_disp should bind first, so zynqmp_dp encoder can find crtc */
+ ret = zynqmp_dp_bind(dev, master, data);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static void
+zynqmp_dpsub_unbind(struct device *dev, struct device *master, void *data)
+{
+ zynqmp_dp_unbind(dev, master, data);
+ zynqmp_disp_unbind(dev, master, data);
+}
+
+static const struct component_ops zynqmp_dpsub_component_ops = {
+ .bind = zynqmp_dpsub_bind,
+ .unbind = zynqmp_dpsub_unbind,
+};
+
+static int zynqmp_dpsub_probe(struct platform_device *pdev)
+{
+ struct zynqmp_dpsub *dpsub;
+ int ret;
+
+ dpsub = devm_kzalloc(&pdev->dev, sizeof(*dpsub), GFP_KERNEL);
+ if (!dpsub)
+ return -ENOMEM;
+
+ /* Sub-driver will access dpsub from drvdata */
+ platform_set_drvdata(pdev, dpsub);
+ pm_runtime_enable(&pdev->dev);
+
+ /*
+* DP should be probed first so that the zynqmp_disp can set the output
+* format accordingly.
+*/
+ ret = zynqmp_dp_probe(pdev);
+ if (ret)
+ goto err_pm;
+
+ ret = zynqmp_disp_probe(pdev);
+ if (ret)
+ goto err_dp;
+
+ ret = component_add(&pdev->dev, &zynqmp_dpsub_component_ops);
+ if (ret)
+ goto err_disp;
+
+ /* Populate the sound child nodes */
+ ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to populate child nodes\n");
+ goto err_component;
+ }
+
+ dev_info(&pdev->dev, "ZynqMP DisplayPort Subsystem driver probed");
+
+ dpsub->master = xlnx_drm_pipeline_init(pdev);
+
+ return 0;
+
+err_component:
+ component_del(&pdev->dev, &zynqmp_dpsub_component_ops);
+err_disp:
+ zynqmp_disp_remove(pdev);
+err_dp:
+ zynqmp_dp_remove(pdev);
+err_pm:
+ pm_ru
[PATCH v4 2/5] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings
This add a dt binding for ZynqMP DP subsystem.
Signed-off-by: Hyun Kwon
---
v4
- Specify phy related descriptions
- Specify dma related descriptions
- Remove ports
- Remove child nodes for layers
- Update the example accordingly
v2
- Group multiple ports under 'ports'
- Replace linux specific terms with generic hardware descriptions
---
---
.../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 67 ++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
diff --git
a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
new file mode 100644
index 000..f4a2e6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt
@@ -0,0 +1,67 @@
+Xilinx ZynqMP DisplayPort subsystem
+---
+
+Required properties:
+
+- compatible: Must be "xlnx,zynqmp-dpsub-1.7".
+
+- reg: Physical base address and length of the registers set for the device.
+- reg-names: Must be "dp", "blend", "av_buf", and "aud" to map logical register
+ partitions.
+
+- interrupts: Interrupt number.
+- interrupts-parent: phandle for interrupt controller.
+
+- clocks: phandles for axi, audio, non-live video, and live video clocks.
+ axi clock is required. Audio clock is optional. If not present, audio will
+ be disabled. One of non-live or live video clock should be present.
+- clock-names: The identification strings are required. "aclk" for axi clock.
+ "dp_aud_clk" for audio clock. "dp_vtc_pixel_clk_in" for non-live video clock.
+ "dp_live_video_in_clk" for live video clock (clock from programmable logic).
+
+- phys: phandles for phy specifier. The number of lanes is configurable
+ between 1 and 2. The number of phandles should be 1 or 2.
+- phy-names: The identifier strings. "dp-phy" followed by index, 0 or 1.
+ For single lane, only "dp-phy0" is required. For dual lane, both "dp-phy0"
+ and "dp-phy1" are required where "dp-phy0" is the primary lane.
+
+- power-domains: phandle for the corresponding power domain
+
+- dmas: phandles for DMA channels as defined in
+ Documentation/devicetree/bindings/dma/dma.txt.
+- dma-names: The identifier strings are required. "gfx0" for graphics layer
+ dma channel. "vid" followed by index (0 - 2) for video layer dma channels.
+
+Optional child node
+
+- The driver populates any child device node in this node. This can be used,
+ for example, to populate the sound device from the DisplayPort subsystem
+ driver.
+
+Example:
+ zynqmp-display-subsystem@fd4a {
+ compatible = "xlnx,zynqmp-dpsub-1.7";
+ reg = <0x0 0xfd4a 0x0 0x1000>,
+ <0x0 0xfd4aa000 0x0 0x1000>,
+ <0x0 0xfd4ab000 0x0 0x1000>,
+ <0x0 0xfd4ac000 0x0 0x1000>;
+ reg-names = "dp", "blend", "av_buf", "aud";
+ interrupts = <0 119 4>;
+ interrupt-parent = <&gic>;
+
+ clock-names = "dp_apb_clk", "dp_aud_clk",
"dp_live_video_in_clk";
+ clocks = <&dp_aclk>, <&clkc 17>, <&si570_1>;
+
+ phys = <&lane1>, <&lane0>;
+ phy-names = "dp-phy0", "dp-phy1";
+
+ power-domains = <&pd_dp>;
+
+ dma-names = "vid0", "vid1", "vid2", "gfx0";
+ dmas = <&xlnx_dpdma 0>,
+ <&xlnx_dpdma 1>,
+ <&xlnx_dpdma 2>,
+ <&xlnx_dpdma 3>;
+ };
+};
+
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/5] drm: xlnx: DRM KMS driver for Xilinx ZynqMP DisplayPort
This driver creates DRM encoder and connector for ZynqMP DisplayPort. Signed-off-by: Hyun Kwon Acked-by: Daniel Vetter --- v2 - Change the SPDX identifier format - Split drm properties into a separate patch --- --- drivers/gpu/drm/xlnx/zynqmp_dp.c | 1738 ++ drivers/gpu/drm/xlnx/zynqmp_dp.h | 37 + 2 files changed, 1775 insertions(+) create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.c create mode 100644 drivers/gpu/drm/xlnx/zynqmp_dp.h diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c new file mode 100644 index 000..9c9f4df --- /dev/null +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c @@ -0,0 +1,1738 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * ZynqMP DisplayPort Driver + * + * Copyright (C) 2017 - 2018 Xilinx, Inc. + * + * Author: Hyun Woo Kwon + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "zynqmp_disp.h" +#include "zynqmp_dpsub.h" + +static uint zynqmp_dp_aux_timeout_ms = 50; +module_param_named(aux_timeout_ms, zynqmp_dp_aux_timeout_ms, uint, 0444); +MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value in msec (default: 50)"); + +/* + * Some sink requires a delay after power on request + */ +static uint zynqmp_dp_power_on_delay_ms = 4; +module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint, 0444); +MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)"); + +/* Link configuration registers */ +#define ZYNQMP_DP_TX_LINK_BW_SET 0x0 +#define ZYNQMP_DP_TX_LANE_CNT_SET 0x4 +#define ZYNQMP_DP_TX_ENHANCED_FRAME_EN 0x8 +#define ZYNQMP_DP_TX_TRAINING_PATTERN_SET 0xc +#define ZYNQMP_DP_TX_SCRAMBLING_DISABLE0x14 +#define ZYNQMP_DP_TX_DOWNSPREAD_CTL0x18 +#define ZYNQMP_DP_TX_SW_RESET 0x1c +#define ZYNQMP_DP_TX_SW_RESET_STREAM1 BIT(0) +#define ZYNQMP_DP_TX_SW_RESET_STREAM2 BIT(1) +#define ZYNQMP_DP_TX_SW_RESET_STREAM3 BIT(2) +#define ZYNQMP_DP_TX_SW_RESET_STREAM4 BIT(3) +#define ZYNQMP_DP_TX_SW_RESET_AUX BIT(7) +#define ZYNQMP_DP_TX_SW_RESET_ALL (ZYNQMP_DP_TX_SW_RESET_STREAM1 | \ + ZYNQMP_DP_TX_SW_RESET_STREAM2 | \ + ZYNQMP_DP_TX_SW_RESET_STREAM3 | \ + ZYNQMP_DP_TX_SW_RESET_STREAM4 | \ + ZYNQMP_DP_TX_SW_RESET_AUX) + +/* Core enable registers */ +#define ZYNQMP_DP_TX_ENABLE0x80 +#define ZYNQMP_DP_TX_ENABLE_MAIN_STREAM0x84 +#define ZYNQMP_DP_TX_FORCE_SCRAMBLER_RESET 0xc0 +#define ZYNQMP_DP_TX_VERSION 0xf8 +#define ZYNQMP_DP_TX_VERSION_MAJOR_MASKGENMASK(31, 24) +#define ZYNQMP_DP_TX_VERSION_MAJOR_SHIFT 24 +#define ZYNQMP_DP_TX_VERSION_MINOR_MASKGENMASK(23, 16) +#define ZYNQMP_DP_TX_VERSION_MINOR_SHIFT 16 +#define ZYNQMP_DP_TX_VERSION_REVISION_MASK GENMASK(15, 12) +#define ZYNQMP_DP_TX_VERSION_REVISION_SHIFT12 +#define ZYNQMP_DP_TX_VERSION_PATCH_MASKGENMASK(11, 8) +#define ZYNQMP_DP_TX_VERSION_PATCH_SHIFT 8 +#define ZYNQMP_DP_TX_VERSION_INTERNAL_MASK GENMASK(7, 0) +#define ZYNQMP_DP_TX_VERSION_INTERNAL_SHIFT0 + +/* Core ID registers */ +#define ZYNQMP_DP_TX_CORE_ID 0xfc +#define ZYNQMP_DP_TX_CORE_ID_MAJOR_MASKGENMASK(31, 24) +#define ZYNQMP_DP_TX_CORE_ID_MAJOR_SHIFT 24 +#define ZYNQMP_DP_TX_CORE_ID_MINOR_MASKGENMASK(23, 16) +#define ZYNQMP_DP_TX_CORE_ID_MINOR_SHIFT 16 +#define ZYNQMP_DP_TX_CORE_ID_REVISION_MASK GENMASK(15, 8) +#define ZYNQMP_DP_TX_CORE_ID_REVISION_SHIFT8 +#define ZYNQMP_DP_TX_CORE_ID_DIRECTION GENMASK(1) + +/* AUX channel interface registers */ +#define ZYNQMP_DP_TX_AUX_COMMAND 0x100 +#define ZYNQMP_DP_TX_AUX_COMMAND_CMD_SHIFT 8 +#define ZYNQMP_DP_TX_AUX_COMMAND_ADDRESS_ONLY BIT(12) +#define ZYNQMP_DP
RE: [PATCH v3 2/8] drm: xlnx: Xilinx DRM KMS driver
Hi Daniel, > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Wednesday, January 17, 2018 12:20 AM > To: Hyun Kwon > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal > Simek ; Rob Herring ; Daniel > Vetter ; Laurent Pinchart > > Subject: Re: [PATCH v3 2/8] drm: xlnx: Xilinx DRM KMS driver > > On Mon, Jan 15, 2018 at 05:57:05PM -0800, Hyun Kwon wrote: > > Xilinx has various platforms for display, where users can create > > using multiple IPs in the programmable FPGA fabric, or where > > some hardened piepline is available on the chip. Furthermore, > > hardened pipeline can also interact with soft logics in FPGA. > > > > The Xilinx DRM KMS is to integrate multiple subdevices and to represent > > the entire pipeline as a single DRM device. The driver includes helpers > > (ex, framebuffer and gem helpers) and glue logics (ex, crtc interface). > > > > Signed-off-by: Hyun Kwon > > --- > > v3 > > - Add Laurent as a maintainer > > - Fix multiple-reference on gem objects > > v2 > > - Change the SPDX identifier format > > - Merge patches(crtc, gem, fb) into single one > > v2 of xlnx_drv > > - Rename kms to display in xlnx_drv > > - Replace some xlnx specific fb helper with common helpers in xlnx_drv > > - Don't set the commit tail callback in xlnx_drv > > - Support 'ports' graph binding in xlnx_drv > > v2 of xlnx_fb > > - Remove wrappers in xlnx_fb > > - Replace some functions with drm core helpers in xlnx_fb > > --- > > --- > > MAINTAINERS | 9 + > > drivers/gpu/drm/Kconfig | 2 + > > drivers/gpu/drm/Makefile | 1 + > > drivers/gpu/drm/xlnx/Kconfig | 12 ++ > > drivers/gpu/drm/xlnx/Makefile| 2 + > > drivers/gpu/drm/xlnx/xlnx_crtc.c | 203 ++ > > drivers/gpu/drm/xlnx/xlnx_crtc.h | 78 +++ > > drivers/gpu/drm/xlnx/xlnx_drv.c | 447 > +++ > > drivers/gpu/drm/xlnx/xlnx_drv.h | 30 +++ > > drivers/gpu/drm/xlnx/xlnx_fb.c | 298 ++ > > drivers/gpu/drm/xlnx/xlnx_fb.h | 33 +++ > > drivers/gpu/drm/xlnx/xlnx_gem.c | 47 > > drivers/gpu/drm/xlnx/xlnx_gem.h | 26 +++ > > 13 files changed, 1188 insertions(+) > > create mode 100644 drivers/gpu/drm/xlnx/Kconfig > > create mode 100644 drivers/gpu/drm/xlnx/Makefile > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.c > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_crtc.h > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.c > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_drv.h > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.c > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_fb.h > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.c > > create mode 100644 drivers/gpu/drm/xlnx/xlnx_gem.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 2811a21..dc84346 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4682,6 +4682,15 @@ F: drivers/gpu/drm/etnaviv/ > > F: include/uapi/drm/etnaviv_drm.h > > F: Documentation/devicetree/bindings/display/etnaviv/ > > > > +DRM DRIVERS FOR XILINX > > +M: Hyun Kwon > > +M: Laurent Pinchart > > +L: dri-devel@lists.freedesktop.org > > +S: Maintained > > +F: drivers/gpu/drm/xlnx/ > > +F: Documentation/devicetree/bindings/display/xlnx/ > > +T: git git://anongit.freedesktop.org/drm/drm-misc > > Ok, I scrolled through the patches again and besides the one nit for the > enable/disable_vblank callback it looks all good. On patches 2 and 4-6: > > Acked-by: Daniel Vetter > > These are ready for merging. The 2 dt patches need an ack from Rob > Herring. The final 2 patches with the new properties need the usual uapi > work and userspace enabling per > > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source- > userspace-requirements > > Since Laurent is listed as co-maintainer, and Laurent is already drm-misc > committer I think it's indeed best to maintain it in there. Please request > a new account per > > https://www.freedesktop.org/wiki/AccountRequests/ > > and check out quickstart in > > https://01.org/linuxgraphics/gfx-docs/maintainer- > tools/dim.html#quickstart > > For any questions I or Laurent should be able to help out. My expectation > is that once you have the ack from DT maintainers you'll merge patches 1-6 > yourself directly. > > Thanks, Daniel > Thanks for the pointers and help. I'll follow the process once bindings are accepted. Thanks, -hyun > > + > > DRM DRIVERS FOR ZTE ZX > > M: Shawn Guo > > L: dri-devel@lists.freedesktop.org > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > > index 22ee5a1..f3c71e3 100644 > > --- a/drivers/gpu/drm/Kconfig > > +++ b/drivers/gpu/drm/Kconfig > > @@ -282,6 +282,8 @@ source "drivers/gpu/drm/tinydrm/Kconfig" > > > > source "drivers/gpu/drm/pl111/Kconfig" > > > > +source "drivers/gpu/drm/xlnx/Kconfig" > > + > > # Keep legacy driver
[RFC v2 05/10] drm: fb_cma_helper: Use drm_format_plane_width_bytes()
In order to handle non byte aligned formats, use drm_format_plane_width_bytes(). Use of 'cpp' can result in incorrect number of bytes from bit level rounding. Signed-off-by: Hyun Kwon --- v2 - This patch is added. --- --- drivers/gpu/drm/drm_fb_cma_helper.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index 186d00a..271175e 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -124,7 +124,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer *fb, return 0; paddr = obj->paddr + fb->offsets[plane]; - paddr += fb->format->cpp[plane] * (state->src_x >> 16); + paddr += drm_format_plane_width_bytes(fb->format, plane, + state->src_x >> 16); paddr += fb->pitches[plane] * (state->src_y >> 16); return paddr; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 06/10] uapi: drm: New fourcc codes needed by Xilinx Video IP
From: Jeffrey Mouroux
The Xilinx Video Mixer andn Xilinx Video Framebuffer DMA IP
support video memory formats that are not represented in the
current DRM fourcc library. This patch adds those missing
fourcc codes.
Signed-off-by: Jeffrey Mouroux
Signed-off-by: Hyun Kwon
---
v2
- Add detailed descriptions
- Remove formats with no user
---
---
include/uapi/drm/drm_fourcc.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d..6ac5282 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -142,6 +142,14 @@ extern "C" {
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane 10 bit per component YCbCr
+ * index 0 = Y plane, [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian
+ * index 1 = Cb:Cr plane, [63:0] x:Cb2:Cr2:Cb1:x:Cr1:Cb0:Cr0
2:10:10:10:2:10:10:10 little endian
+ */
+#define DRM_FORMAT_XV15fourcc_code('X', 'V', '1', '5') /* 2x2
subsampled Cb:Cr plane 2:10:10:10 */
+#define DRM_FORMAT_XV20fourcc_code('X', 'V', '2', '0') /* 2x1
subsampled Cb:Cr plane 2:10:10:10 */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 09/10] uapi: drm: drm_fourcc: Add new formats for Xilinx IPs
This adds packed YUV and grey scale format fourccs.
Signed-off-by: Hyun Kwon
---
v2
- Split from the previous patch
---
---
include/uapi/drm/drm_fourcc.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 6ac5282..7014a3d 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -112,6 +112,13 @@ extern "C" {
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_VUY888 fourcc_code('V', 'U', '2', '4') /* [23:0]
Cr:Cb:Y 8:8:8 little endian */
+#define DRM_FORMAT_XVUYfourcc_code('X', 'V', '2', '4') /* [31:0]
x:Cr:Cb:Y 8:8:8:8 little endian */
+#define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'Y', '3', '0') /* [31:0]
x:Cr:Cb:Y 2:10:10:10 little endian */
+
+/* Grey scale */
+#define DRM_FORMAT_Y8 fourcc_code('G', 'R', 'E', 'Y') /* 8 Greyscale
*/
+#define DRM_FORMAT_Y10 fourcc_code('Y', '1', '0', ' ') /* 10 Greyscale
*/
/*
* 2 plane RGB + A
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 08/10] drm: xlnx: zynqmp: Add XV15 and XV20 formats
Signed-off-by: Hyun Kwon
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index fd6ddfe..b1aaa71 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -968,6 +968,24 @@ static const struct zynqmp_disp_fmt av_buf_vid_fmts[] = {
.sf[0] = ZYNQMP_DISP_AV_BUF_8BIT_SF,
.sf[1] = ZYNQMP_DISP_AV_BUF_8BIT_SF,
.sf[2] = ZYNQMP_DISP_AV_BUF_8BIT_SF,
+ }, {
+ .drm_fmt= DRM_FORMAT_XV15,
+ .disp_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_420_10,
+ .rgb= false,
+ .swap = false,
+ .chroma_sub = true,
+ .sf[0] = ZYNQMP_DISP_AV_BUF_10BIT_SF,
+ .sf[1] = ZYNQMP_DISP_AV_BUF_10BIT_SF,
+ .sf[2] = ZYNQMP_DISP_AV_BUF_10BIT_SF,
+ }, {
+ .drm_fmt= DRM_FORMAT_XV20,
+ .disp_fmt = ZYNQMP_DISP_AV_BUF_FMT_NL_VID_YV16CI_10,
+ .rgb= false,
+ .swap = false,
+ .chroma_sub = true,
+ .sf[0] = ZYNQMP_DISP_AV_BUF_10BIT_SF,
+ .sf[1] = ZYNQMP_DISP_AV_BUF_10BIT_SF,
+ .sf[2] = ZYNQMP_DISP_AV_BUF_10BIT_SF,
}
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 10/10] drm: drm_fourcc: Add new formats to the drm format table
This adds new formats (packed YUV and grey scale) to
the drm format table.
Signed-off-by: Hyun Kwon
---
v2
- Split from previous patch
---
---
drivers/gpu/drm/drm_fourcc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 2f6c9eb..420d043 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -175,6 +175,11 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm = { 1, 0, 0 },
.bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm = { 1, 0, 0 },
.bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .bpp = { 32, 0, 0 }, .ppm = { 1, 0, 0 },
.bpm = { 32, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_VUY888, .depth = 0,
.num_planes = 1, .cpp = { 3, 0, 0 }, .bpp = { 24, 0, 0 }, .ppm = { 1, 0, 0 },
.bpm = { 24, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_XVUY,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .bpp = { 32, 0, 0 }, .ppm = { 1, 0, 0 },
.bpm = { 32, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_XVUY2101010, .depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .bpp = { 32, 0, 0 }, .ppm = { 1, 0, 0 },
.bpm = { 32, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_Y8, .depth = 0,
.num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 }, .ppm = { 1, 0, 0 },
.bpm = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_Y10, .depth = 0,
.num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 10, 0, 0 }, .ppm = { 3, 0, 0 },
.bpm = { 32, 0, 0 }, .hsub = 1, .vsub = 1 },
};
unsigned int i;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 01/10] drm: drm:fourcc: Add bpp information to struct drm_format_info
'cpp' doesn't work for any format where component size is not byte aligned.
Add 'bpp' to have a bit level information. Add a meesage to
drm_format_plane_cpp() to indicate that the returned cpp would be
rounded for non byte aligned formats.
Signed-off-by: Hyun Kwon
---
v2
- Introduce bpp
---
---
drivers/gpu/drm/drm_fourcc.c | 164 +--
include/drm/drm_fourcc.h | 3 +
2 files changed, 99 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 9c0152d..b891fe0 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -105,74 +105,74 @@ EXPORT_SYMBOL(drm_get_format_name);
const struct drm_format_info *__drm_format_info(u32 format)
{
static const struct drm_format_info formats[] = {
- { .format = DRM_FORMAT_C8, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGB332, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGR233, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XRGB,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XBGR,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGBX,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGRX,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_ARGB,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_ABGR,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGBA,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGRA,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XRGB1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XBGR1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGBX5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGRX5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_ARGB1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_ABGR1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGBA5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGRA5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGB565, .depth = 16,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGR565, .depth = 16,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGB888, .depth = 24,
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGR888, .depth = 24,
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XRGB,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XBGR,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGBX,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGRX,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGB565_A8, .depth = 24,
.num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_BGR565_A8, .depth = 24,
.num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XRGB2101010, .depth = 30,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_XBGR2101010, .depth = 30,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
- { .format = DRM_FORMAT_RGBX1010102, .depth = 30,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1
[RFC v2 04/10] drm: xlnx: zynqmp: use drm_format_width_bytes
Signed-off-by: Hyun Kwon
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index d2e1034..fd6ddfe 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -2138,6 +2138,7 @@ static int zynqmp_disp_plane_mode_set(struct drm_plane
*plane,
for (i = 0; i < info->num_planes; i++) {
unsigned int width = src_w / (i ? info->hsub : 1);
unsigned int height = src_h / (i ? info->vsub : 1);
+ int width_bytes;
paddr = drm_fb_cma_get_gem_addr(fb, plane->state, i);
if (!paddr) {
@@ -2146,7 +2147,8 @@ static int zynqmp_disp_plane_mode_set(struct drm_plane
*plane,
}
layer->dma[i].xt.numf = height;
- layer->dma[i].sgl[0].size = width * info->cpp[i];
+ width_bytes = drm_format_plane_width_bytes(info, i, width);
+ layer->dma[i].sgl[0].size = width_bytes;
layer->dma[i].sgl[0].icg = fb->pitches[i] -
layer->dma[i].sgl[0].size;
layer->dma[i].xt.src_start = paddr;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 02/10] drm: drm_fourcc: Introduce macro-pixel info to drm_format_info
Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
This is to model formats where multiple pixels are stored together
in a specific way, likely byte-algined. For example, if 3 - 10 bit
pixels are stored in 32 bit, the 32 bit stroage can be treated as
a single macro-pixel with 3 pixels. This aligns non-byte addressable
formats with drm core where bpp is expected to be multiple of 8 bit.
Add 'ppm', pixels per macro-pixel, to note how many pixels are grouped
in a macro-pixel. 'bpm', bits per macro-pixel, specifies how many bits
are in a macro-pixel as there can be some extra padding bits.
Signed-off-by: Hyun Kwon
---
v2
- Introduce macro-pixel over scaling factors
---
---
drivers/gpu/drm/drm_fourcc.c | 136 +--
include/drm/drm_fourcc.h | 9 +++
2 files changed, 77 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index b891fe0..8fc1e35 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -105,74 +105,74 @@ EXPORT_SYMBOL(drm_get_format_name);
const struct drm_format_info *__drm_format_info(u32 format)
{
static const struct drm_format_info formats[] = {
- { .format = DRM_FORMAT_C8, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_RGB332, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_BGR233, .depth = 8,
.num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_XRGB,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_XBGR,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_RGBX,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_BGRX,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_ARGB,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_ABGR,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_RGBA,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_BGRA,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_XRGB1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_XBGR1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_RGBX5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_BGRX5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_ARGB1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_ABGR1555,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_RGBA5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_BGRA5551,.depth = 15,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_RGB565, .depth = 16,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_BGR565, .depth = 16,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_RGB888, .depth = 24,
.num_planes = 1, .cpp = { 3, 0, 0 }, .bpp = { 24, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_BGR888, .depth = 24,
.num_planes = 1, .cpp = { 3, 0, 0 }, .bpp = { 24, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_XRGB,.depth = 24,
.num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1
},
- { .format = DRM_FORMAT_XBGR,.depth = 24,
.num_planes = 1, .cpp = { 1
[RFC v2 03/10] drm: fourcc: Add drm_format_plane_width_bytes()
drm_format_plane_width_bytes() calculates and returns
the number of bytes for given width of specified format.
The calculation uses the macro pixel information to avoid
bit level rounding.
Signed-off-by: Hyun Kwon
---
v2
- This function is added
---
---
drivers/gpu/drm/drm_fourcc.c | 22 ++
include/drm/drm_fourcc.h | 2 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 8fc1e35..2070276 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -376,3 +376,25 @@ int drm_format_plane_height(int height, uint32_t format,
int plane)
return height / info->vsub;
}
EXPORT_SYMBOL(drm_format_plane_height);
+
+/**
+ * drm_format_plane_width_bytes - bytes of the given width of the plane
+ * @info: DRM format information
+ * @plane: plane index
+ * @width: width to get the number of bytes
+ *
+ * Returns:
+ * The bytes of @width of @plane.
+ */
+int drm_format_plane_width_bytes(const struct drm_format_info *info,
+int plane, int width)
+{
+ int width_bits;
+
+ if (!info || plane >= info->num_planes)
+ return 0;
+
+ width_bits = DIV_ROUND_UP(width * info->bpm[plane], info->ppm[plane]);
+ return DIV_ROUND_UP(width_bits, 8);
+}
+EXPORT_SYMBOL(drm_format_plane_width_bytes);
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 64038e9..1eafeb9 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -80,6 +80,8 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
int drm_format_vert_chroma_subsampling(uint32_t format);
int drm_format_plane_width(int width, uint32_t format, int plane);
int drm_format_plane_height(int height, uint32_t format, int plane);
+int drm_format_plane_width_bytes(const struct drm_format_info *info,
+int plane, int width);
const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf
*buf);
#endif /* __DRM_FOURCC_H__ */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 00/10] Support for formats with non-byte aligned components
Hi, This is RFC to follow up on adding new formats to DRM core. Previous discussion can be found in [1]. These new formats are not byte addressable, whereas in many places in DRM core, the assumption is that format bpp is byte aligned. Thus, in order to support these formats correctly, additiona handling is needed. Initial approach was to add the scaling factors to the format info. Those values were multiplied directly to address extra bits in color components and gaps between components. On the other hand, this series attempts to simplify such handling by adding the macro-pixel concept with some additional helper function, based on the previous discussion. Still not entirely sure if this is best / simpliest approach, so any feedback would be appreciated. This series includes some patches from downstream, but upstreaming on going, drivers [2] to demonstrate how it can be used. Patch 1 - 3 add additional information such as bpp, macro-pixel, and a helper. Patch 4 - 5 are to demonstrate how additional information can be used. Patch 6 - 7 add new formats to DRM core. New formats are added next to existing formats as it turned out those are not insance enough for a separate section Patch 8 adds new formats to the client driver as an example. Patch 9 - 10 add more fourccs which are used by downstream drivers currently in development. Thanks, -hyun [1] https://lists.freedesktop.org/archives/dri-devel/2017-November/158744.html [2] https://lists.freedesktop.org/archives/dri-devel/2018-January/162559.html Hyun Kwon (9): drm: drm:fourcc: Add bpp information to struct drm_format_info drm: drm_fourcc: Introduce macro-pixel info to drm_format_info drm: fourcc: Add drm_format_plane_width_bytes() drm: xlnx: zynqmp: use drm_format_width_bytes drm: fb_cma_helper: Use drm_format_plane_width_bytes() drm: drm_fourcc: Add new 10bit formats to drm_format_info table drm: xlnx: zynqmp: Add XV15 and XV20 formats uapi: drm: drm_fourcc: Add new formats for Xilinx IPs drm: drm_fourcc: Add new formats to the drm format table Jeffrey Mouroux (1): uapi: drm: New fourcc codes needed by Xilinx Video IP drivers/gpu/drm/drm_fb_cma_helper.c | 3 +- drivers/gpu/drm/drm_fourcc.c| 193 +++- drivers/gpu/drm/xlnx/zynqmp_disp.c | 22 +++- include/drm/drm_fourcc.h| 14 +++ include/uapi/drm/drm_fourcc.h | 15 +++ 5 files changed, 177 insertions(+), 70 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 07/10] drm: drm_fourcc: Add new 10bit formats to drm_format_info table
Add information for DRM_FORMAT_XV15 and DRM_FORMAT_XV20 to
the drm format table.
Signed-off-by: Hyun Kwon
---
v2
- Accomodate macro pixel changes
---
---
drivers/gpu/drm/drm_fourcc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 2070276..2f6c9eb 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -168,6 +168,8 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_NV61,.depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm = { 1, 1, 0 },
.bpm = { 8, 16, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_NV24,.depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm = { 1, 1, 0 },
.bpm = { 8, 16, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_NV42,.depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm = { 1, 1, 0 },
.bpm = { 8, 16, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_XV15,.depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 10, 20, 0 }, .ppm = { 3, 3, 0 },
.bpm = { 32, 64, 0 }, .hsub = 2, .vsub = 2, },
+ { .format = DRM_FORMAT_XV20,.depth = 0,
.num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 10, 20, 0 }, .ppm = { 3, 3, 0 },
.bpm = { 32, 64, 0 }, .hsub = 2, .vsub = 1, },
{ .format = DRM_FORMAT_YUYV,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm = { 1, 0, 0 },
.bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_YVYU,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm = { 1, 0, 0 },
.bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm = { 1, 0, 0 },
.bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland
https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #19 from Bong Cosca --- If I may add, compositing works by setting DRI_PRIME=1 with KMS and AccelMethod "none" despite having only the APU. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 0/4] Implement full clockgating for Kepler1 and 2
Next version of my patchseries for adding clockgating support for kepler1 and 2 on nouveau. The first version of this series can be found here: https://patchwork.freedesktop.org/series/36504/ Some minor changes: - Clarified that SLCG stands for 'secondary level clockgating', thanks for the small tip nvidia! - Removed the concept of levels, this was more useful for debugging then anything and having only a single level of clockgating enabled does technically open us up to running a configuration nvidia never tested. Additionally, this changes NvPmEnableGating into a simple boolean option. - Fixup nvkm_info() messages so that we don't mention powergating in them, since this isn't actually added in this series (and may not be for a while, only time will tell :) - Don't export unused function gk104_therm_new_() Lyude Paul (4): drm/nouveau: Add support for basic clockgating on Kepler1 drm/nouveau: Add support for BLCG on Kepler1 drm/nouveau: Add support for BLCG on Kepler2 drm/nouveau: Add support for SLCG for Kepler2 drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + .../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 17 ++ drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 25 +-- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c | 207 + drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h | 55 ++ drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c | 155 +++ drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c | 6 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c | 47 + drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h | 35 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c | 71 +++ drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h | 2 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 2 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 70 ++- drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c | 67 +++ drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h | 35 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 8 +- drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c | 136 ++ drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h | 48 + drivers/gpu/drm/nouveau/nvkm/subdev/therm/gt215.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 23 ++- 22 files changed, 988 insertions(+), 26 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 1/4] drm/nouveau: Add support for basic clockgating on Kepler1
This adds support for enabling automatic clockgating on nvidia GPUs for
Kepler1. While this is not technically a clockgating level, it does
enable clockgating using the clockgating values initially set by the
vbios (which should be safe to use).
This introduces two therm helpers for controlling basic clockgating:
nvkm_therm_clkgate_enable() - enables clockgating through
CG_CTRL, done after initializing the GPU fully
nvkm_therm_clkgate_fini() - prepares clockgating for suspend or
driver unload
As well, we add the nouveau kernel config parameter NvPmEnableGating,
which can be toggled on or off in order to enable/disable clockgating.
Since we've only had limited testing on this thus far, we disable this
by default.
A lot of this code was originally going to be based off of fermi;
however it turns out that while Fermi's the first line of GPUs that
introduced this kind of power saving, Fermi requires more fine tuned
control of the CG_CTRL registers from the driver while reclocking that
we don't entirely understand yet.
For the simple parts we will be sharing with Fermi for certain however,
we at least add those into a new subdev/therm/gf100.h header.
Signed-off-by: Lyude Paul
---
.../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 5 +
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 17 +--
drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 60 +++--
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h | 35 ++
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 8 +-
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c | 135 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h | 48
drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 15 ++-
9 files changed, 303 insertions(+), 21 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index b1ac47eb786e..240b19bb4667 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -85,17 +85,22 @@ struct nvkm_therm {
int (*attr_get)(struct nvkm_therm *, enum nvkm_therm_attr_type);
int (*attr_set)(struct nvkm_therm *, enum nvkm_therm_attr_type, int);
+
+ bool clkgating_enabled;
};
int nvkm_therm_temp_get(struct nvkm_therm *);
int nvkm_therm_fan_sense(struct nvkm_therm *);
int nvkm_therm_cstate(struct nvkm_therm *, int, int);
+void nvkm_therm_clkgate_enable(struct nvkm_therm *);
+void nvkm_therm_clkgate_fini(struct nvkm_therm *, bool);
int nv40_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int nv50_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int g84_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gt215_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gf119_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
+int gk104_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gm107_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gm200_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
int gp100_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 08e77cd55e6e..74bd09b1c893 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -28,6 +28,7 @@
#include
#include
+#include
static DEFINE_MUTEX(nv_devices_mutex);
static LIST_HEAD(nv_devices);
@@ -1682,7 +1683,7 @@ nve4_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk104_pmu_new,
- .therm = gf119_therm_new,
+ .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1721,7 +1722,7 @@ nve6_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk104_pmu_new,
- .therm = gf119_therm_new,
+ .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1760,7 +1761,7 @@ nve7_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk104_pmu_new,
- .therm = gf119_therm_new,
+ .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top = gk104_top_new,
.volt = gk104_volt_new,
@@ -1824,7 +1825,7 @@ nvf0_chipset = {
.mxm = nv50_mxm_new,
.pci = gk104_pci_new,
.pmu = gk110_pmu_new,
- .therm = gf119_therm_new,
+ .therm = gk104_therm_new,
.timer = nv41_timer_new,
.top =
[RFC v2 2/4] drm/nouveau: Add support for BLCG on Kepler1
This enables BLCG optimization for kepler1. When using clockgating,
nvidia's firmware has a set of registers which are initially programmed
by the vbios with various engine delays and other mysterious settings
that are safe enough to bring up the GPU. However, the values used by
the vbios are more power hungry then they need to be, so the nvidia driver
writes it's own more optimized set of BLCG settings before enabling
CG_CTRL. This adds support for programming the optimized BLCG values
during engine/subdev init, which enables rather significant power
savings.
This introduces the nvkm_therm_clkgate_init() helper, which we use to
program the optimized BLCG settings before enabling clockgating with
nvkm_therm_clkgate_enable.
As well, this commit shares a lot more code with Fermi since BLCG is
mostly the same there as far as we can tell. In the future, it's likely
we'll reformat the clkgate_packs for kepler1 so that they share a list
of mmio packs with Fermi.
Signed-off-by: Lyude Paul
---
.../gpu/drm/nouveau/include/nvkm/subdev/therm.h| 12 ++
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c | 207 +
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h | 55 ++
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c | 6 +
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c | 47 +
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h | 35
drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h | 2 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 10 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c | 67 +++
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/therm/gt215.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h | 8 +
14 files changed, 453 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
index 240b19bb4667..9398d9f09339 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
@@ -46,6 +46,16 @@ enum nvkm_therm_attr_type {
NVKM_THERM_ATTR_THRS_SHUTDOWN_HYST = 17,
};
+struct nvkm_therm_clkgate_init {
+ u32 addr;
+ u8 count;
+ u32 data;
+};
+
+struct nvkm_therm_clkgate_pack {
+ const struct nvkm_therm_clkgate_init *init;
+};
+
struct nvkm_therm {
const struct nvkm_therm_func *func;
struct nvkm_subdev subdev;
@@ -92,6 +102,8 @@ struct nvkm_therm {
int nvkm_therm_temp_get(struct nvkm_therm *);
int nvkm_therm_fan_sense(struct nvkm_therm *);
int nvkm_therm_cstate(struct nvkm_therm *, int, int);
+void nvkm_therm_clkgate_init(struct nvkm_therm *,
+const struct nvkm_therm_clkgate_pack *);
void nvkm_therm_clkgate_enable(struct nvkm_therm *);
void nvkm_therm_clkgate_fini(struct nvkm_therm *, bool);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
index d7c2adb9b543..c8ec3fd97155 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
@@ -137,6 +137,7 @@ struct gf100_gr_func {
int (*rops)(struct gf100_gr *);
int ppc_nr;
const struct gf100_grctx_func *grctx;
+ const struct nvkm_therm_clkgate_pack *clkgate_pack;
struct nvkm_sclass sclass[];
};
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
index 5e82f94c2245..17cea9c70f7f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
@@ -22,6 +22,7 @@
* Authors: Ben Skeggs
*/
#include "gf100.h"
+#include "gk104.h"
#include "ctxgf100.h"
#include
@@ -173,6 +174,208 @@ gk104_gr_pack_mmio[] = {
{}
};
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_main_0[] = {
+ { 0x4041f0, 1, 0x4046 },
+ { 0x409890, 1, 0x0045 },
+ { 0x4098b0, 1, 0x007f },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_rstr2d_0[] = {
+ { 0x4078c0, 1, 0x0042 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_unk_0[] = {
+ { 0x406000, 1, 0x4044 },
+ { 0x405860, 1, 0x4042 },
+ { 0x40590c, 1, 0x4042 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_gcc_0[] = {
+ { 0x408040, 1, 0x4044 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk104_clkgate_blcg_init_sked_0[] = {
+ { 0x407000, 1, 0x4044 },
+ {}
+};
+
+const struct nvkm
[RFC v2 4/4] drm/nouveau: Add support for SLCG for Kepler2
That's right, there's still more power saving to go! Starting with
kepler 2, nvidia hardware has an additional level of clockgating known
as second level clockgating. The details of this are not exact, but it
seems to work by waiting for a collection of dependent hardware blocks
to be gated before taking affect. As with the previous series, this
results in another noticeable drop in power consumption and is
programmed in the same manner.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c | 93 ++
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
index 38d3328e45f1..5ded29c790dd 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
@@ -187,6 +187,87 @@ gk110_clkgate_blcg_init_gpc_mp_0[] = {
{}
};
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_main_0[] = {
+ { 0x4041f4, 1, 0x },
+ { 0x409894, 1, 0x },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_unk_0[] = {
+ { 0x406004, 1, 0x },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_sked_0[] = {
+ { 0x407004, 1, 0x },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_ctxctl_0[] = {
+ { 0x41a894, 1, 0x },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_unk_0[] = {
+ { 0x418504, 1, 0x },
+ { 0x41860c, 1, 0x },
+ { 0x41868c, 1, 0x },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_esetup_0[] = {
+ { 0x41882c, 1, 0x },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_zcull_0[] = {
+ { 0x418974, 1, 0x },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_l1c_0[] = {
+ { 0x419cd8, 2, 0x },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_unk_1[] = {
+ { 0x419c74, 1, 0x },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_mp_0[] = {
+ { 0x419fd4, 1, 0x4a4a },
+ { 0x419fdc, 1, 0x0014 },
+ { 0x419fe4, 1, 0x },
+ { 0x419ff4, 1, 0x1724 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_gpc_ppc_0[] = {
+ { 0x41be2c, 1, 0x },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_slcg_init_pcounter_0[] = {
+ { 0x1be018, 1, 0x01ff },
+ { 0x1bc018, 1, 0x01ff },
+ { 0x1b8018, 1, 0x01ff },
+ { 0x1b4124, 1, 0x },
+ {}
+};
+
const struct nvkm_therm_clkgate_pack
gk110_clkgate_pack[] = {
{ gk104_clkgate_blcg_init_main_0 },
@@ -214,6 +295,18 @@ gk110_clkgate_pack[] = {
{ gk104_clkgate_blcg_init_rop_0 },
{ gk104_clkgate_blcg_init_rop_crop_0 },
{ gk104_clkgate_blcg_init_pxbar_0 },
+ { gk110_clkgate_slcg_init_main_0 },
+ { gk110_clkgate_slcg_init_unk_0 },
+ { gk110_clkgate_slcg_init_sked_0 },
+ { gk110_clkgate_slcg_init_gpc_ctxctl_0 },
+ { gk110_clkgate_slcg_init_gpc_unk_0 },
+ { gk110_clkgate_slcg_init_gpc_esetup_0 },
+ { gk110_clkgate_slcg_init_gpc_zcull_0 },
+ { gk110_clkgate_slcg_init_gpc_l1c_0 },
+ { gk110_clkgate_slcg_init_gpc_unk_1 },
+ { gk110_clkgate_slcg_init_gpc_mp_0 },
+ { gk110_clkgate_slcg_init_gpc_ppc_0 },
+ { gk110_clkgate_slcg_init_pcounter_0 },
{}
};
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v2 3/4] drm/nouveau: Add support for BLCG on Kepler2
Same as the previous patch, but for Kepler2 now
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +--
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c| 62
drivers/gpu/drm/nouveau/nvkm/subdev/fb/Kbuild | 1 +
drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c| 71 +++
5 files changed, 139 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
index adb78f7d083a..92be0e5269c6 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h
@@ -75,6 +75,7 @@ int mcp89_fb_new(struct nvkm_device *, int, struct nvkm_fb
**);
int gf100_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
int gf108_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
int gk104_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
+int gk110_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
int gk20a_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
int gm107_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
int gm200_fb_new(struct nvkm_device *, int, struct nvkm_fb **);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 74bd09b1c893..7590a30b7ff0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -1812,7 +1812,7 @@ nvf0_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
- .fb = gk104_fb_new,
+ .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
@@ -1850,7 +1850,7 @@ nvf1_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
- .fb = gk104_fb_new,
+ .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
@@ -1888,7 +1888,7 @@ nv106_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
- .fb = gk104_fb_new,
+ .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
@@ -1926,7 +1926,7 @@ nv108_chipset = {
.bus = gf100_bus_new,
.clk = gk104_clk_new,
.devinit = gf100_devinit_new,
- .fb = gk104_fb_new,
+ .fb = gk110_fb_new,
.fuse = gf100_fuse_new,
.gpio = gk104_gpio_new,
.i2c = gk104_i2c_new,
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
index a38e19b61c1d..38d3328e45f1 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c
@@ -22,6 +22,7 @@
* Authors: Ben Skeggs
*/
#include "gf100.h"
+#include "gk104.h"
#include "ctxgf100.h"
#include
@@ -156,6 +157,66 @@ gk110_gr_pack_mmio[] = {
{}
};
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_sked_0[] = {
+ { 0x407000, 1, 0x4041 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_gpc_gcc_0[] = {
+ { 0x419020, 1, 0x0042 },
+ { 0x419038, 1, 0x0042 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_gpc_l1c_0[] = {
+ { 0x419cd4, 2, 0x4042 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_init
+gk110_clkgate_blcg_init_gpc_mp_0[] = {
+ { 0x419fd0, 1, 0x4043 },
+ { 0x419fd8, 1, 0x4049 },
+ { 0x419fe0, 2, 0x4042 },
+ { 0x419ff0, 1, 0x0046 },
+ { 0x419ff8, 1, 0x4042 },
+ { 0x419f90, 1, 0x4042 },
+ {}
+};
+
+const struct nvkm_therm_clkgate_pack
+gk110_clkgate_pack[] = {
+ { gk104_clkgate_blcg_init_main_0 },
+ { gk104_clkgate_blcg_init_rstr2d_0 },
+ { gk104_clkgate_blcg_init_unk_0 },
+ { gk104_clkgate_blcg_init_gcc_0 },
+ { gk110_clkgate_blcg_init_sked_0 },
+ { gk104_clkgate_blcg_init_unk_1 },
+ { gk104_clkgate_blcg_init_gpc_ctxctl_0 },
+ { gk104_clkgate_blcg_init_gpc_unk_0 },
+ { gk104_clkgate_blcg_init_gpc_esetup_0 },
+ { gk104_clkgate_blcg_init_gpc_tpbus_0 },
+ { gk104_clkgate_blcg_init_gpc_zcull_0 },
+ { gk104_clkgate_blcg_init_gpc_tpconf_0 },
+ { gk104_clkgate_blcg_init_gpc_unk_1 },
+ { gk110_clkgate_blcg_init_gpc_gcc_0 },
+ { gk104_clkgate_blcg_init_gpc_ffb_0 },
+ { gk104_clkgate_blcg_init_gpc_tex_0 },
+ { gk104_clkgate_blcg_init_gpc_poly_0 },
+ { gk110_clkgate_blcg_init_gpc_l1c_0 },
+ { gk104_clkgate_blcg_init_gpc_unk_2 },
+ { gk110_clkgate_blcg_init_gpc_mp_0 },
+ { gk104_clkgate_blcg_init_gpc_ppc_0 },
+
