Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces
On Thu, Dec 21, 2017 at 12:22 AM, Kristian Kristensen wrote: > On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico > wrote: >> >> Inline. >> >> On Wed, 20 Dec 2017 11:54:10 -0800 >> Kristian Høgsberg wrote: >> >> > On Wed, Dec 20, 2017 at 11:51 AM, Daniel Vetter wrote: >> > > Since this also involves the kernel let's add dri-devel ... >> >> Yeah, I forgot. Thanks Daniel! >> >> > > >> > > On Wed, Dec 20, 2017 at 5:51 PM, Miguel Angel Vico >> > > wrote: >> > >> Hi all, >> > >> >> > >> As many of you already know, I've been working with James Jones on >> > >> the >> > >> Generic Device Allocator project lately. He started a discussion >> > >> thread >> > >> some weeks ago seeking feedback on the current prototype of the >> > >> library >> > >> and advice on how to move all this forward, from a prototype stage to >> > >> production. For further reference, see: >> > >> >> > >> >> > >> https://lists.freedesktop.org/archives/mesa-dev/2017-November/177632.html >> > >> >> > >> From the thread above, we came up with very interesting high level >> > >> design ideas for one of the currently missing parts in the library: >> > >> Usage transitions. That's something I'll personally work on during >> > >> the >> > >> following weeks. >> > >> >> > >> >> > >> In the meantime, I've been working on putting together an open source >> > >> implementation of the allocator mechanisms using the Nouveau driver >> > >> for >> > >> all to be able to play with. >> > >> >> > >> Below I'm seeking feedback on a bunch of changes I had to make to >> > >> different components of the graphics stack: >> > >> >> > >> ** Allocator ** >> > >> >> > >> An allocator driver implementation on top of Nouveau. The current >> > >> implementation only handles pitch linear layouts, but that's enough >> > >> to have the kmscube port working using the allocator and Nouveau >> > >> drivers. >> > >> >> > >> You can pull these changes from >> > >> >> > >> >> > >> https://github.com/mvicomoya/allocator/tree/wip/mvicomoya/nouveau-driver >> > >> >> > >> ** Mesa ** >> > >> >> > >> James's kmscube port to use the allocator relies on the >> > >> EXT_external_objects extension to import allocator allocations to >> > >> OpenGL as a texture object. However, the Nouveau implementation of >> > >> these mechanisms is missing in Mesa, so I went ahead and added >> > >> them. >> > >> >> > >> You can pull these changes from >> > >> >> > >> >> > >> https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/EXT_external_objects-nouveau >> > >> >> > >> Also, James's kmscube port uses the NVX_unix_allocator_import >> > >> extension to attach allocator metadata to texture objects so the >> > >> driver knows how to deal with the imported memory. >> > >> >> > >> Note that there isn't a formal spec for this extension yet. For >> > >> now, >> > >> it just serves as an experimental mechanism to import allocator >> > >> memory in OpenGL, and attach metadata to texture objects. >> > >> >> > >> You can pull these changes (written on top of the above) from: >> > >> >> > >> >> > >> https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/NVX_unix_allocator_import >> > >> >> > >> ** kmscube ** >> > >> >> > >> Mostly minor fixes and improvements on top of James's port to use >> > >> the >> > >> allocator. Main thing is the allocator initialization path will use >> > >> EGL_MESA_platform_surfaceless if EGLDevice platform isn't supported >> > >> by the underlying EGL implementation. >> > >> >> > >> You can pull these changes from: >> > >> >> > >> >> > >> https://github.com/mvicomoya/kmscube/tree/wip/mvicomoya/allocator-nouveau >> > >> >> > >> >> > >> With all the above you should be able to get kmscube working using >> > >> the >> > >> allocator on top of the Nouveau driver. >> > >> >> > >> >> > >> Another of the missing pieces before we can move this to production >> > >> is >> > >> importing allocations to DRM FB objects. This is probably one of the >> > >> most sensitive parts of the project as it requires >> > >> modification/addition >> > >> of kernel driver interfaces. >> > >> >> > >> At XDC2017, James had several hallway conversations with several >> > >> people >> > >> about this, all having different opinions. I'd like to take this >> > >> opportunity to also start a discussion about what's the best option >> > >> to >> > >> create a path to get allocator allocations added as DRM FB objects. >> > >> >> > >> These are the few options we've considered to start with: >> > >> >> > >> A) Have vendor-private ioctls to set properties on GEM objects that >> > >> are inherited by the FB objects. This is how our (NVIDIA) >> > >> desktop >> > >> DRM driver currently works. This would require every vendor to >> > >> add >> > >> their own ioctl to process allocator metadata, but the metadata >> > >> is >> > >> actually a vendor-agnostic object more like DRM modifiers. We'd >> > >> like to come up with a vendor-agnostic solutions that
Re: [PATCH 2/7] drm/ttm: use an operation ctx for ttm_mem_global_alloc
With a suitable commit log, LGTM.
Reviewed-by: Thomas Hellstrom
On 12/20/2017 11:34 AM, Roger He wrote:
Change-Id: I5279b5cd3560c4082b00f822219575a5f9c3808a
Signed-off-by: Roger He
---
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);
}
void ttm_mem_global_free_page(struct ttm_mem_global *glob, struct page *page,
diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index 26a7ad0..1aa2baa 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -325,6 +325,10 @@ int ttm_ref_object_add(struct ttm_object_file *tfile,
struct ttm_ref_object *ref;
struct drm_hash_item *hash;
struct ttm_mem_global *mem_glob = tfile->tdev->mem_glob;
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
int ret = -EINVAL;
if (base->tfile != tfile && !base->shareable)
@@ -350,7 +354,7 @@ int ttm_ref_object_add(struct ttm_object_file *tfile,
return -EPERM;
ret = ttm_mem_global_alloc(mem_glob, sizeof(*ref),
- false, false);
+
Re: [PATCH 3/7] drm/ttm: use an operation ctx for ttm_mem_global_alloc_page
On 12/21/2017 07:05 AM, He, Roger wrote:
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Wednesday, December 20, 2017 9:36 PM
To: He, Roger ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/7] drm/ttm: use an operation ctx for
ttm_mem_global_alloc_page
Commit message!
Am 20.12.2017 um 11:34 schrieb Roger He:
Change-Id: I4104a12e09a374b6477a0dd5a8fce26dce27a746
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 15 ---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 ++--
include/drm/ttm/ttm_memory.h | 3 ++-
4 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index 525d3b6..8df0755 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -539,15 +539,14 @@ int ttm_mem_global_alloc(struct ttm_mem_global *glob,
uint64_t memory,
EXPORT_SYMBOL(ttm_mem_global_alloc);
int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
- struct page *page, uint64_t size)
+ struct page *page, uint64_t size,
+ struct ttm_operation_ctx *ctx)
{
-
+ int ret;
struct ttm_mem_zone *zone = NULL;
- struct ttm_operation_ctx ctx = {
- .interruptible = false,
- .no_wait_gpu = false
- };
+ bool tmp_no_wait_gpu = ctx->no_wait_gpu;
Mhm, please drop that. That the function might wait for the GPU even
when the caller requested not to do so sounds like a bug to
Yes, I agree.
/Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] drm/ttm: enable swapout of per VM BOs during allocation and allows reaping of deleted BOs
Am 21.12.2017 um 08:58 schrieb Thomas Hellstrom:
What about
"Enable recursive locking at swapout time to make it possible to swap
out BOs that share the same reservation object."
Is "per VM BOs" an AMD specific name?
Yes, absolutely. It's even amdgpu specific, radeon uses the same
functionality but a bit different and not for user mode allocations.
In that case, I'd avoid using it in the TTM code since most people
have no idea what they are and why the need specific treatment in TTM.
Good point, going to keep that in mind when reviewing the patch set.
Christian.
/Thomas
On 12/20/2017 11:35 AM, Roger He wrote:
Change-Id: I1e87954564f38ad298bf6e4ff88c9f26f291a62d
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 15 +++
drivers/gpu/drm/ttm/ttm_memory.c | 12
include/drm/ttm/ttm_bo_api.h | 3 ++-
3 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 313925c..ecb8916 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1686,18 +1686,20 @@ EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
* A buffer object shrink method that tries to swap out the first
* buffer object on the bo_global::swap_lru list.
*/
-int ttm_bo_swapout(struct ttm_bo_global *glob)
+int ttm_bo_swapout(struct ttm_bo_global *glob, struct
ttm_operation_ctx *ctx)
{
struct ttm_buffer_object *bo;
int ret = -EBUSY;
+ bool locked;
unsigned i;
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &glob->swap_lru[i], swap) {
- ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
- if (!ret)
+ if (ttm_bo_evict_swapout_allowable(bo, ctx, &locked)) {
+ ret = 0;
break;
+ }
}
if (!ret)
break;
@@ -1773,7 +1775,12 @@ EXPORT_SYMBOL(ttm_bo_swapout);
void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
{
- while (ttm_bo_swapout(bdev->glob) == 0)
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
+
+ while (ttm_bo_swapout(bdev->glob, &ctx) == 0)
;
}
EXPORT_SYMBOL(ttm_bo_swapout_all);
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index 8df0755..8817b86 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -211,7 +211,7 @@ static bool ttm_zones_above_swap_target(struct
ttm_mem_global *glob,
*/
static void ttm_shrink(struct ttm_mem_global *glob, bool from_wq,
- uint64_t extra)
+ uint64_t extra, struct ttm_operation_ctx *ctx)
{
int ret;
@@ -219,7 +219,7 @@ static void ttm_shrink(struct ttm_mem_global
*glob, bool from_wq,
while (ttm_zones_above_swap_target(glob, from_wq, extra)) {
spin_unlock(&glob->lock);
- ret = ttm_bo_swapout(glob->bo_glob);
+ ret = ttm_bo_swapout(glob->bo_glob, ctx);
spin_lock(&glob->lock);
if (unlikely(ret != 0))
break;
@@ -230,10 +230,14 @@ static void ttm_shrink(struct ttm_mem_global
*glob, bool from_wq,
static void ttm_shrink_work(struct work_struct *work)
{
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
struct ttm_mem_global *glob =
container_of(work, struct ttm_mem_global, work);
- ttm_shrink(glob, true, 0ULL);
+ ttm_shrink(glob, true, 0ULL, &ctx);
}
static int ttm_mem_init_kernel_zone(struct ttm_mem_global *glob,
@@ -520,7 +524,7 @@ static int ttm_mem_global_alloc_zone(struct
ttm_mem_global *glob,
return -ENOMEM;
if (unlikely(count-- == 0))
return -ENOMEM;
- ttm_shrink(glob, false, memory + (memory >> 2) + 16);
+ ttm_shrink(glob, false, memory + (memory >> 2) + 16, ctx);
}
return 0;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 24a8db7..f1c74c2 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -752,7 +752,8 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev,
struct file *filp,
const char __user *wbuf, char __user *rbuf,
size_t count, loff_t *f_pos, bool write);
-int ttm_bo_swapout(struct ttm_bo_global *glob);
+int ttm_bo_swapout(struct ttm_bo_global *glob,
+ struct ttm_operation_ctx *ctx);
void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
#endif
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: move lease init after validation in drm_lease_create
On Wed, Dec 20, 2017 at 10:54:24PM -0800, Keith Packard wrote:
> Patch bd36d3bab2e3d08f80766c86487090dbceed4651 fixed a deadlock in the
> failure path of drm_lease_create. This made the partially initialized
> lease object visible for a short window of time.
>
> To avoid having the lessee state appear transiently, I've rearranged
> the code so that the lessor fields are not filled in until the
> parameters are all validated and the function will succeed.
>
> Signed-off-by: Keith Packard
Good catch, sorry I missed that. And registering the object as the very
last thing is definitely the safe pattern.
Applied, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_lease.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index 59849f02e2ad..1402c0e71b03 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -220,17 +220,6 @@ static struct drm_master *drm_lease_create(struct
> drm_master *lessor, struct idr
>
> mutex_lock(&dev->mode_config.idr_mutex);
>
> - /* Insert the new lessee into the tree */
> - id = idr_alloc(&(drm_lease_owner(lessor)->lessee_idr), lessee, 1, 0,
> GFP_KERNEL);
> - if (id < 0) {
> - error = id;
> - goto out_lessee;
> - }
> -
> - lessee->lessee_id = id;
> - lessee->lessor = drm_master_get(lessor);
> - list_add_tail(&lessee->lessee_list, &lessor->lessees);
> -
> idr_for_each_entry(leases, entry, object) {
> error = 0;
> if (!idr_find(&dev->mode_config.crtc_idr, object))
> @@ -246,6 +235,17 @@ static struct drm_master *drm_lease_create(struct
> drm_master *lessor, struct idr
> }
> }
>
> + /* Insert the new lessee into the tree */
> + id = idr_alloc(&(drm_lease_owner(lessor)->lessee_idr), lessee, 1, 0,
> GFP_KERNEL);
> + if (id < 0) {
> + error = id;
> + goto out_lessee;
> + }
> +
> + lessee->lessee_id = id;
> + lessee->lessor = drm_master_get(lessor);
> + list_add_tail(&lessee->lessee_list, &lessor->lessees);
> +
> /* Move the leases over */
> lessee->leases = *leases;
> DRM_DEBUG_LEASE("new lessee %d %p, lessor %d %p\n", lessee->lessee_id,
> lessee, lessor->lessee_id, lessor);
> --
> 2.15.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO
for the NVMe bits, Acked-by: Sagi Grimberg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ask for help] i.MX6 dual display
Hi Philipp
I have an i.MX6Q running 4.9 LTS with etnaviv.
We would like to have both the HDMI and LVDS outputs enabled a once.
If I enable hdmi and lvds in the devicetree, we have only output on the
hdmi port.
Probably both LVDS and HDMI are clocked from the video PLL (PLL5). It is
rather unlikely to have a combination of LVDS Display and HDMI mode that
can be driven from the same PLL frequency, as the LVDS serializer input
clock is 3.5 times or 7 times the LVDS pixel clock.
You can check the clock tree in /sys/kernel/debug/clk/clk_summary.
If you want to support connecting arbitrary monitors at all, you'll have
to move the LDB clock input to another PLL that can be set to the LVDS
serializer clock rate without disturbing other peripherals.
Due to a bug in the i.MX6Q LDB clock dividers, this has to be done once,
early during boot, using the assigned-clocks/assigned-clock-parents
device tree properties of the &clks node. To find example device trees,
see:
git grep -A3 assigned-clocks.*LDB_DI0_SEL arch/arm/boot/dts
I have this in my devicetree:
&clks {
assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
<&clks IMX6QDL_CLK_LDB_DI1_SEL>;
assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
};
That should be enough?
So basically I have 2 questions:
Is it possible to have both LVDS and HDMI enabled at once from the
same ipu?
Yes, if the resolution isn't too high. The IPU pixel clock / bandwidth
limitations depend on whether both DIs are active.
Also only one of the displays will have overlay plane support, if that
is relevant to you, since there's only one DP that can do composition in
each IPU.
Any way to tell if the IPU pixel clock is too high?
My LVDS display:
static const struct drm_display_mode xin_sun_xf1011280800_mode = {
.clock = 71100,
.hdisplay = 1280,
.hsync_start = 1280 + 40,
.hsync_end = 1280 + 40 + 80,
.htotal = 1280 + 40 + 80 + 40,
.vdisplay = 800,
.vsync_start = 800 + 10,
.vsync_end = 800 + 10 + 10,
.vtotal = 800 + 10 + 10 + 3,
.vrefresh = 60,
.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
}
HDMI would be fine in 720p mode.
Can i move the HDMI output to the other ipu and how?
Yes, see arch/arm/boot/dts/imx6q-utilite-pro.dts for an example: After
severing the OF graph links between the IPU1 DIs and the HDMI encoder
in the device tree, the HDMI output can only be driven by IPU2:
/delete-node/&ipu1_di0_hdmi;
/delete-node/&hdmi_mux_0;
/delete-node/&ipu1_di1_hdmi;
/delete-node/&hdmi_mux_1;
Thanks if I add this I get LVDS output and a blank HDMI output.
I have only one fb device. It it possible to get a second one for IPU2?
My prefered option would be the HDMI and LVDS mirrored.
I finally managed to get HDMI and LVDS mirrored.
I added this to my devicetree:
/delete-node/&ipu2_di0_hdmi;
/delete-node/&hdmi_mux_2;
/delete-node/&ipu2_di1_hdmi;
/delete-node/&hdmi_mux_3;
/delete-node/&ipu1_di0_lvds0;
/delete-node/&ipu1_di0_lvds1;
/delete-node/&lvds0_mux_0;
/delete-node/&lvds1_mux_0;
/delete-node/&ipu1_di1_lvds0;
/delete-node/&ipu1_di1_lvds1;
/delete-node/&lvds0_mux_1;
/delete-node/&lvds1_mux_1;
Thanks for your help :-)
/Sean
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/5] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30
On 20.12.2017 21:01, Thierry Reding wrote:
> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
>> Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
>> DRM's MODE_ADDFB IOCTL on Tegra20/30, because IOCTL uses XRGB format if
>> requested FB depth is 24bpp. As a result, Xorg doesn't work anymore with
>> both modesetting and opentegra drivers. On older Tegra's each plane has
>> a blending configuration which should be used to enable / disable alpha
>> blending and right now the blending configs are hardcoded to disabled
>> alpha blending. In order to support alpha formats properly, planes
>> blending configuration must be adjusted, until then the alpha formats
>> are equal to non-alpha.
>>
>> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/gpu/drm/tegra/dc.c| 29 ++---
>> drivers/gpu/drm/tegra/dc.h| 1 +
>> drivers/gpu/drm/tegra/fb.c| 13 -
>> drivers/gpu/drm/tegra/hub.c | 3 ++-
>> drivers/gpu/drm/tegra/plane.c | 22 +-
>> drivers/gpu/drm/tegra/plane.h | 2 +-
>> 6 files changed, 39 insertions(+), 31 deletions(-)
>
> This kept bugging me, so I spent some time looking at the blending
> programming. I came up with the attached patch which seems to work
> for all scenarios and is fairly similar to your patch. It has the
> added benefit that we can keep support for more formats.
>
> Any comments?
>
> Thierry
> --- >8 ---
> From 3d2b7d1a9b8239dc6940477d8783461ac60783bc Mon Sep 17 00:00:00 2001
> From: Thierry Reding
> Date: Wed, 20 Dec 2017 09:39:14 +0100
> Subject: [PATCH] drm/tegra: dc: Implement legacy blending
>
> This implements alpha blending on legacy display controllers (Tegra20,
> Tegra30 and Tegra114). While it's theoretically possible to support the
> zpos property to enable userspace to specify the Z-order of each plane
> individually, this is not currently supported and the same fixed Z-
> order as previously defined is used.
Perhaps one variant of implementing zpos could be by making overlays 'virtual',
so each virtual overlay will be backed by the real HW plane and we could swap
the HW planes of the virtual overlays, emulating zpos.
> Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
> the opaque formats are now supported.
>
> Reported-by: Dmitry Osipenko
> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/dc.c| 74
> ++-
> drivers/gpu/drm/tegra/dc.h| 13
> drivers/gpu/drm/tegra/fb.c| 12 ---
> drivers/gpu/drm/tegra/plane.c | 41
> drivers/gpu/drm/tegra/plane.h | 3 ++
> 5 files changed, 116 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index bc65c314e00f..07c687d7f615 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -168,32 +168,46 @@ static inline u32 compute_initial_dda(unsigned int in)
> return dfixed_frac(inf);
> }
>
> -static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)
> +static void
> +tegra_plane_setup_blending_legacy(struct tegra_plane *plane,
> + const struct tegra_dc_window *window)
> {
> + u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
> + BLEND_COLOR_KEY_NONE;
> + u32 background = BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) |
> + BLEND_COLOR_KEY_NONE;
> + u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
> +
> + /* enable alpha blending if window->alpha */
> + if (window->alpha) {
> + background |= BLEND_CONTROL_DEPENDENT;
> + foreground |= BLEND_CONTROL_ALPHA;
> + }
I think dependent weight means that window doesn't have alpha transparency. So
we should set the dependent_weight mode for opaque formats and alpha_weight for
formats with alpha channel.
If the above is correct, then I'm suggesting to not expose alpha formats, we
should properly test all combinations of blending of all the windows. In one
case you could apply my patch for now and then me/you/we could work on a proper
legacy blending implementation based on your patch. In the other case I could
take your patch into v4 (cursor patch would have to be rabased in that case) and
we will correct blending sometime later. I don't mind either case, up to you to
decide.
Is there any ready-made testsuite for the DRM planes blending? Or you have made
a test by yourself? In the latter case, could you please share the code so that
I could test it too without burden of writing testcases from scratch?
> +
> /*
>* Disable blending and assume Window A is the bottom-most window,
>* Window C is the top-most window and Window B is in the middle.
>*/
> - tegra_plane_writel(plane,
[PATCH v3 3/5] drm/tegra: Trade overlay plane for cursor on older Tegra's
Older Tegra's do not support RGBA format for the cursor, but instead
overlay plane could be used for it. Since there is no much use for the
overlays on a regular desktop and HW-accelerated cursor is much nicer
than the jerky SW cursor, let's trade one overlay plane for the cursor.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c | 75 +++---
drivers/gpu/drm/tegra/dc.h | 2 ++
2 files changed, 59 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 460510366bb8..eaff8757bbe0 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -125,9 +125,10 @@ static inline u32 compute_initial_dda(unsigned int in)
return dfixed_frac(inf);
}
-static void tegra_dc_setup_window(struct tegra_dc *dc, unsigned int index,
+static void tegra_dc_setup_window(struct tegra_dc *dc, struct drm_plane *plane,
const struct tegra_dc_window *window)
{
+ struct tegra_plane *p = to_tegra_plane(plane);
unsigned h_offset, v_offset, h_size, v_size, h_dda, v_dda, bpp;
unsigned long value, flags;
bool yuv, planar;
@@ -144,7 +145,7 @@ static void tegra_dc_setup_window(struct tegra_dc *dc,
unsigned int index,
spin_lock_irqsave(&dc->lock, flags);
- value = WINDOW_A_SELECT << index;
+ value = WINDOW_A_SELECT << p->index;
tegra_dc_writel(dc, value, DC_CMD_DISPLAY_WINDOW_HEADER);
tegra_dc_writel(dc, window->format, DC_WIN_COLOR_DEPTH);
@@ -275,23 +276,29 @@ static void tegra_dc_setup_window(struct tegra_dc *dc,
unsigned int index,
tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_NOKEY);
tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_1WIN);
- switch (index) {
+ switch (p->index) {
case 0:
tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_2WIN_X);
- tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_2WIN_Y);
+ tegra_dc_writel(dc, 0x08, DC_WIN_BLEND_2WIN_Y);
tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_3WIN_XY);
break;
case 1:
tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_2WIN_X);
- tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_2WIN_Y);
- tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_3WIN_XY);
+ tegra_dc_writel(dc, 0x08, DC_WIN_BLEND_2WIN_Y);
+ tegra_dc_writel(dc, 0x08, DC_WIN_BLEND_3WIN_XY);
break;
case 2:
- tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_2WIN_X);
- tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_2WIN_Y);
- tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_3WIN_XY);
+ if (plane->type == DRM_PLANE_TYPE_CURSOR) {
+ tegra_dc_writel(dc, 0x04, DC_WIN_BLEND_2WIN_X);
+ tegra_dc_writel(dc, 0x04, DC_WIN_BLEND_2WIN_Y);
+ tegra_dc_writel(dc, 0x04, DC_WIN_BLEND_3WIN_XY);
+ } else {
+ tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_2WIN_X);
+ tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_2WIN_Y);
+ tegra_dc_writel(dc, 0x00, DC_WIN_BLEND_3WIN_XY);
+ }
break;
}
@@ -433,7 +440,6 @@ static void tegra_plane_atomic_update(struct drm_plane
*plane,
struct tegra_plane_state *state = to_tegra_plane_state(plane->state);
struct tegra_dc *dc = to_tegra_dc(plane->state->crtc);
struct drm_framebuffer *fb = plane->state->fb;
- struct tegra_plane *p = to_tegra_plane(plane);
struct tegra_dc_window window;
unsigned int i;
@@ -475,7 +481,7 @@ static void tegra_plane_atomic_update(struct drm_plane
*plane,
window.stride[i] = fb->pitches[i];
}
- tegra_dc_setup_window(dc, p->index, &window);
+ tegra_dc_setup_window(dc, plane, &window);
}
static const struct drm_plane_helper_funcs tegra_plane_helper_funcs = {
@@ -706,6 +712,14 @@ static const u32 tegra20_overlay_formats[] = {
DRM_FORMAT_YUV422,
};
+static const u32 tegra20_overlay_cursor_formats[] = {
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_RGBA5551,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB,
+};
+
static const u32 tegra114_overlay_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_ARGB1555,
@@ -765,9 +779,11 @@ static const u32 tegra124_overlay_formats[] = {
static struct drm_plane *tegra_dc_overlay_plane_create(struct drm_device *drm,
struct tegra_dc *dc,
- unsigned int index)
+ unsigned int index,
+ bool cursor)
{
struct tegra_plane *plane;
+ enum drm_
Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW
On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote: > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible. > ... > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c > index 7a54e3083203..79d4dc785e5c 100644 > --- a/sound/soc/omap/mcbsp.c > +++ b/sound/soc/omap/mcbsp.c > @@ -854,7 +854,7 @@ static ssize_t dma_op_mode_store(struct device *dev, > return size; > } > > -static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, dma_op_mode_store); > +static DEVICE_ATTR_RW(dma_op_mode); > While I can ack this part here if it helps generic cleanup effort I don't understart would it improve code readability in general? Mode 644 is clear and don't need any grepping but for DEVICE_ATTR_RW() I had to go through all of these files in order to see what does it mean: DEVICE_ATTR_RW: include/linux/device.h __ATTR_RW: include/linux/sysfs.h S_IWUSR: include/uapi/linux/stat.h S_IRUGO: include/linux/stat.h Jarkko Nikula ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/5] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30
On 20.12.2017 23:16, Thierry Reding wrote:
> On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote:
>> On 20.12.2017 21:01, Thierry Reding wrote:
>>> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
DRM's MODE_ADDFB IOCTL on Tegra20/30, because IOCTL uses XRGB format if
requested FB depth is 24bpp. As a result, Xorg doesn't work anymore with
both modesetting and opentegra drivers. On older Tegra's each plane has
a blending configuration which should be used to enable / disable alpha
blending and right now the blending configs are hardcoded to disabled
alpha blending. In order to support alpha formats properly, planes
blending configuration must be adjusted, until then the alpha formats
are equal to non-alpha.
Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c| 29 ++---
drivers/gpu/drm/tegra/dc.h| 1 +
drivers/gpu/drm/tegra/fb.c| 13 -
drivers/gpu/drm/tegra/hub.c | 3 ++-
drivers/gpu/drm/tegra/plane.c | 22 +-
drivers/gpu/drm/tegra/plane.h | 2 +-
6 files changed, 39 insertions(+), 31 deletions(-)
>>>
>>> This kept bugging me, so I spent some time looking at the blending
>>> programming. I came up with the attached patch which seems to work
>>> for all scenarios and is fairly similar to your patch. It has the
>>> added benefit that we can keep support for more formats.
>>>
>>> Any comments?
>>>
>>> Thierry
>>> --- >8 ---
>>> From 3d2b7d1a9b8239dc6940477d8783461ac60783bc Mon Sep 17 00:00:00 2001
>>> From: Thierry Reding
>>> Date: Wed, 20 Dec 2017 09:39:14 +0100
>>> Subject: [PATCH] drm/tegra: dc: Implement legacy blending
>>>
>>> This implements alpha blending on legacy display controllers (Tegra20,
>>> Tegra30 and Tegra114). While it's theoretically possible to support the
>>> zpos property to enable userspace to specify the Z-order of each plane
>>> individually, this is not currently supported and the same fixed Z-
>>> order as previously defined is used.
>>
>> Perhaps one variant of implementing zpos could be by making overlays
>> 'virtual',
>> so each virtual overlay will be backed by the real HW plane and we could swap
>> the HW planes of the virtual overlays, emulating zpos.
>>
>>> Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
>>> the opaque formats are now supported.
>>>
>>> Reported-by: Dmitry Osipenko
>>> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
>>> Signed-off-by: Thierry Reding
>>> ---
>>> drivers/gpu/drm/tegra/dc.c| 74
>>> ++-
>>> drivers/gpu/drm/tegra/dc.h| 13
>>> drivers/gpu/drm/tegra/fb.c| 12 ---
>>> drivers/gpu/drm/tegra/plane.c | 41
>>> drivers/gpu/drm/tegra/plane.h | 3 ++
>>> 5 files changed, 116 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>>> index bc65c314e00f..07c687d7f615 100644
>>> --- a/drivers/gpu/drm/tegra/dc.c
>>> +++ b/drivers/gpu/drm/tegra/dc.c
>>> @@ -168,32 +168,46 @@ static inline u32 compute_initial_dda(unsigned int in)
>>> return dfixed_frac(inf);
>>> }
>>>
>>> -static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)
>>> +static void
>>> +tegra_plane_setup_blending_legacy(struct tegra_plane *plane,
>>> + const struct tegra_dc_window *window)
>>> {
>>> + u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
>>> +BLEND_COLOR_KEY_NONE;
>>> + u32 background = BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) |
>>> +BLEND_COLOR_KEY_NONE;
>>> + u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
>>> +
>>> + /* enable alpha blending if window->alpha */
>>> + if (window->alpha) {
>>> + background |= BLEND_CONTROL_DEPENDENT;
>>> + foreground |= BLEND_CONTROL_ALPHA;
>>> + }
>>
>> I think dependent weight means that window doesn't have alpha transparency.
>> So
>> we should set the dependent_weight mode for opaque formats and alpha_weight
>> for
>> formats with alpha channel.
>
> According to the TRM, dependent weight means that its weight will be 1 -
> the sum of the other overlapping windows. And it certainly seems to work
> that way in my tests (see below).
Yes, and you are hardcoding the blending modes regardless of the actual plane
format. So even if underlying window has alpha format, it will be treated as it
is opaque.
>> If the above is correct, then I'm suggesting to not expose alpha formats, we
>> should properly test all combinations of blending of all the windows. In one
>> case you could apply my patch for now and then me/you/we could work on a
>> proper
>> legacy blending implementation base
[PATCH v3 1/5] drm/tegra: dc: Link DC1 to DC0 on Tegra20
HW reset isn't actually broken on Tegra20, but there is a dependency on
first display controller to be taken out of reset for the second to be
enabled successfully.
Signed-off-by: Dmitry Osipenko
---
Change log:
v2: Got rid of global variable and now use driver_find_device() instead.
drivers/gpu/drm/tegra/dc.c | 80 +-
drivers/gpu/drm/tegra/dc.h | 2 +-
2 files changed, 51 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index e8a0cad5899c..5299185cea2f 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1848,7 +1848,7 @@ static const struct tegra_dc_soc_info tegra20_dc_soc_info
= {
.supports_block_linear = false,
.pitch_align = 8,
.has_powergate = false,
- .broken_reset = true,
+ .coupled_pm = true,
.has_nvdisplay = false,
.num_primary_formats = ARRAY_SIZE(tegra20_primary_formats),
.primary_formats = tegra20_primary_formats,
@@ -1863,7 +1863,7 @@ static const struct tegra_dc_soc_info tegra30_dc_soc_info
= {
.supports_block_linear = false,
.pitch_align = 8,
.has_powergate = false,
- .broken_reset = false,
+ .coupled_pm = false,
.has_nvdisplay = false,
.num_primary_formats = ARRAY_SIZE(tegra20_primary_formats),
.primary_formats = tegra20_primary_formats,
@@ -1878,7 +1878,7 @@ static const struct tegra_dc_soc_info
tegra114_dc_soc_info = {
.supports_block_linear = false,
.pitch_align = 64,
.has_powergate = true,
- .broken_reset = false,
+ .coupled_pm = false,
.has_nvdisplay = false,
.num_primary_formats = ARRAY_SIZE(tegra114_primary_formats),
.primary_formats = tegra114_primary_formats,
@@ -1893,7 +1893,7 @@ static const struct tegra_dc_soc_info
tegra124_dc_soc_info = {
.supports_block_linear = true,
.pitch_align = 64,
.has_powergate = true,
- .broken_reset = false,
+ .coupled_pm = false,
.has_nvdisplay = false,
.num_primary_formats = ARRAY_SIZE(tegra124_primary_formats),
.primary_formats = tegra114_primary_formats,
@@ -1908,7 +1908,7 @@ static const struct tegra_dc_soc_info
tegra210_dc_soc_info = {
.supports_block_linear = true,
.pitch_align = 64,
.has_powergate = true,
- .broken_reset = false,
+ .coupled_pm = false,
.has_nvdisplay = false,
.num_primary_formats = ARRAY_SIZE(tegra114_primary_formats),
.primary_formats = tegra114_primary_formats,
@@ -1957,7 +1957,7 @@ static const struct tegra_dc_soc_info
tegra186_dc_soc_info = {
.supports_block_linear = true,
.pitch_align = 64,
.has_powergate = false,
- .broken_reset = false,
+ .coupled_pm = false,
.has_nvdisplay = true,
.wgrps = tegra186_dc_wgrps,
.num_wgrps = ARRAY_SIZE(tegra186_dc_wgrps),
@@ -2025,6 +2025,11 @@ static int tegra_dc_parse_dt(struct tegra_dc *dc)
return 0;
}
+static int tegra_dc_match(struct device *dev, void *data)
+{
+ return of_device_is_compatible(dev->of_node, "nvidia,tegra20-dc");
+}
+
static int tegra_dc_probe(struct platform_device *pdev)
{
struct resource *regs;
@@ -2045,6 +2050,28 @@ static int tegra_dc_probe(struct platform_device *pdev)
if (err < 0)
return err;
+ /*
+* On Tegra20 DC1 requires DC0 to be taken out of reset in order to
+* be enabled, otherwise CPU hangs on writing to CMD_DISPLAY_COMMAND /
+* POWER_CONTROL registers during CRTC enabling.
+*/
+ if (dc->pipe == 1 && dc->soc->coupled_pm) {
+ struct device_link *link;
+ struct device *dc0_dev;
+
+ dc0_dev = driver_find_device(pdev->dev.driver, NULL, NULL,
+tegra_dc_match);
+ if (!dc0_dev)
+ return -EPROBE_DEFER;
+
+ link = device_link_add(&pdev->dev, dc0_dev,
+ DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE);
+ if (!link) {
+ dev_err(&pdev->dev, "failed to link to DC0\n");
+ return -EINVAL;
+ }
+ }
+
dc->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(dc->clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
@@ -2058,21 +2085,19 @@ static int tegra_dc_probe(struct platform_device *pdev)
}
/* assert reset and disable clock */
- if (!dc->soc->broken_reset) {
- err = clk_prepare_enable(dc->clk);
- if (err < 0)
- return err;
+ err = clk_prepare_enable(dc->clk);
+ if (err < 0)
+ return err;
- usleep_range(2000, 4000);
+ usleep_range(2000, 4000);
- err = reset_control_assert(dc->rst);
-
Re: [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO
"Rafael J. Wysocki" writes:
> On Tuesday, December 19, 2017 7:15:08 PM CET Joe Perches wrote:
>> Convert DEVICE_ATTR uses to DEVICE_ATTR_RO where possible.
>>
>> Done with perl script:
>>
>> $ git grep -w --name-only DEVICE_ATTR | \
>> xargs perl -i -e 'local $/; while (<>) {
>> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IRUGO\s*|\s*0444\s*)\)?\s*,\s*\1_show\s*,\s*NULL\s*\)/DEVICE_ATTR_RO(\1)/g;
>> print;}'
>>
>> Signed-off-by: Joe Perches
>> ---
>> arch/arm/mach-pxa/sharpsl_pm.c | 4 ++--
For mach-pxa:
Acked-by: Robert Jarzmik
Cheers.
--
Robert
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/5] drm/tegra: Trade overlay plane for cursor on older Tegra's
On 20.12.2017 23:19, Thierry Reding wrote: > On Wed, Dec 20, 2017 at 06:46:12PM +0300, Dmitry Osipenko wrote: >> Older Tegra's do not support RGBA format for the cursor, but instead >> overlay plane could be used for it. Since there is no much use for the >> overlays on a regular desktop and HW-accelerated cursor is much nicer >> than the jerky SW cursor, let's trade one overlay plane for the cursor. >> >> Signed-off-by: Dmitry Osipenko >> --- >> drivers/gpu/drm/tegra/dc.c | 75 >> +++--- >> drivers/gpu/drm/tegra/dc.h | 2 ++ >> 2 files changed, 59 insertions(+), 18 deletions(-) > > Given the dependency on the alpha formats patch and due to lack of time > because of the holidays messing up the schedule I'd like to defer this > to v4.17, unless we can settle all of it until Friday. I'll rebase and re-test this patch on top of your "Implement legacy blending" patch ASAP. I'm fine with the deferring if it won't workout well. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.
From: Jan Tuerk All recent emtrion modules based on i.mx6 make use of the DA0963. Therefore enable it with the following defaults: - CONFIG_MFD_DA9063=y - CONFIG_REGULATOR_DA9063=y - CONFIG_DA9063_WATCHDOG=m - CONFIG_RTC_DRV_DA9063=m MFD and REGULATOR are built-in to have it at Kernel boot-time. The WATCHDOG and RTC are optional and could be loaded from userspace. Signed-off-by: Jan Tuerk --- arch/arm/configs/imx_v6_v7_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 0d4494922561..09cd8048b0c1 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -215,8 +215,10 @@ CONFIG_THERMAL_WRITABLE_TRIPS=y CONFIG_CPU_THERMAL=y CONFIG_IMX_THERMAL=y CONFIG_WATCHDOG=y +CONFIG_DA9063_WATCHDOG=m CONFIG_IMX2_WDT=y CONFIG_MFD_DA9052_I2C=y +CONFIG_MFD_DA9063=y CONFIG_MFD_MC13XXX_SPI=y CONFIG_MFD_MC13XXX_I2C=y CONFIG_MFD_STMPE=y @@ -224,6 +226,7 @@ CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_ANATOP=y CONFIG_REGULATOR_DA9052=y +CONFIG_REGULATOR_DA9063=y CONFIG_REGULATOR_GPIO=y CONFIG_REGULATOR_MC13783=y CONFIG_REGULATOR_MC13892=y @@ -349,6 +352,7 @@ CONFIG_RTC_DRV_PCF8563=y CONFIG_RTC_DRV_M41T80=y CONFIG_RTC_DRV_MC13XXX=y CONFIG_RTC_DRV_MXC=y +CONFIG_RTC_DRV_DA9063=m CONFIG_RTC_DRV_SNVS=y CONFIG_DMADEVICES=y CONFIG_FSL_EDMA=y -- emtrion GmbH Alter Schlachthof 45 76131 Karlsruhe GERMANY https://www.emtrion.de Amtsgericht Mannheim HRB 110 300 Geschäftsführer: Dieter Baur, Ramona Maurer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/5] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30
On 21.12.2017 01:02, Thierry Reding wrote:
> On Thu, Dec 21, 2017 at 12:05:40AM +0300, Dmitry Osipenko wrote:
>> On 20.12.2017 23:16, Thierry Reding wrote:
>>> On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote:
On 20.12.2017 21:01, Thierry Reding wrote:
> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
>> Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
>> DRM's MODE_ADDFB IOCTL on Tegra20/30, because IOCTL uses XRGB format if
>> requested FB depth is 24bpp. As a result, Xorg doesn't work anymore with
>> both modesetting and opentegra drivers. On older Tegra's each plane has
>> a blending configuration which should be used to enable / disable alpha
>> blending and right now the blending configs are hardcoded to disabled
>> alpha blending. In order to support alpha formats properly, planes
>> blending configuration must be adjusted, until then the alpha formats
>> are equal to non-alpha.
>>
>> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/gpu/drm/tegra/dc.c| 29 ++---
>> drivers/gpu/drm/tegra/dc.h| 1 +
>> drivers/gpu/drm/tegra/fb.c| 13 -
>> drivers/gpu/drm/tegra/hub.c | 3 ++-
>> drivers/gpu/drm/tegra/plane.c | 22 +-
>> drivers/gpu/drm/tegra/plane.h | 2 +-
>> 6 files changed, 39 insertions(+), 31 deletions(-)
>
> This kept bugging me, so I spent some time looking at the blending
> programming. I came up with the attached patch which seems to work
> for all scenarios and is fairly similar to your patch. It has the
> added benefit that we can keep support for more formats.
>
> Any comments?
>
> Thierry
> --- >8 ---
> From 3d2b7d1a9b8239dc6940477d8783461ac60783bc Mon Sep 17 00:00:00 2001
> From: Thierry Reding
> Date: Wed, 20 Dec 2017 09:39:14 +0100
> Subject: [PATCH] drm/tegra: dc: Implement legacy blending
>
> This implements alpha blending on legacy display controllers (Tegra20,
> Tegra30 and Tegra114). While it's theoretically possible to support the
> zpos property to enable userspace to specify the Z-order of each plane
> individually, this is not currently supported and the same fixed Z-
> order as previously defined is used.
Perhaps one variant of implementing zpos could be by making overlays
'virtual',
so each virtual overlay will be backed by the real HW plane and we could
swap
the HW planes of the virtual overlays, emulating zpos.
> Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
> the opaque formats are now supported.
>
> Reported-by: Dmitry Osipenko
> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/dc.c| 74
> ++-
> drivers/gpu/drm/tegra/dc.h| 13
> drivers/gpu/drm/tegra/fb.c| 12 ---
> drivers/gpu/drm/tegra/plane.c | 41
> drivers/gpu/drm/tegra/plane.h | 3 ++
> 5 files changed, 116 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index bc65c314e00f..07c687d7f615 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -168,32 +168,46 @@ static inline u32 compute_initial_dda(unsigned int
> in)
> return dfixed_frac(inf);
> }
>
> -static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)
> +static void
> +tegra_plane_setup_blending_legacy(struct tegra_plane *plane,
> + const struct tegra_dc_window *window)
> {
> + u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
> + BLEND_COLOR_KEY_NONE;
> + u32 background = BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) |
> + BLEND_COLOR_KEY_NONE;
> + u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
> +
> + /* enable alpha blending if window->alpha */
> + if (window->alpha) {
> + background |= BLEND_CONTROL_DEPENDENT;
> + foreground |= BLEND_CONTROL_ALPHA;
> + }
I think dependent weight means that window doesn't have alpha
transparency. So
we should set the dependent_weight mode for opaque formats and
alpha_weight for
formats with alpha channel.
>>>
>>> According to the TRM, dependent weight means that its weight will be 1 -
>>> the sum of the other overlapping windows. And it certainly seems to work
>>> that way in my tests (see below).
>>
>> Yes, and you are hardcoding the blending modes regardless of the actual plane
>> format. So even if underlying window has alpha format, it will be treate
[PATCH 2/2] drm/rockchip: Remove analogix psr worker.
From: Sean Paul
Now that the spinlocks and timers are gone, we can remove the psr
worker located in rockchip's analogix driver and do the enable/disable
directly. This should simplify the code and remove races on disable.
Signed-off-by: Sean Paul
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 30 ++---
1 file changed, 2 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 93b7102..d32c9b3 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -71,10 +71,6 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
- struct work_struct psr_work;
- struct mutex psr_lock;
- unsigned int psr_state;
-
const struct rockchip_dp_chip_data *data;
struct analogix_dp_plat_data plat_data;
@@ -83,27 +79,13 @@ struct rockchip_dp_device {
static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
{
struct rockchip_dp_device *dp = to_dp(encoder);
+ int ret;
if (!analogix_dp_psr_supported(dp->dev))
return;
DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
- mutex_lock(&dp->psr_lock);
- if (enabled)
- dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
- else
- dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
-
- schedule_work(&dp->psr_work);
- mutex_unlock(&dp->psr_lock);
-}
-
-static void analogix_dp_psr_work(struct work_struct *work)
-{
- struct rockchip_dp_device *dp =
- container_of(work, typeof(*dp), psr_work);
- int ret;
ret = rockchip_drm_wait_vact_end(dp->encoder.crtc,
PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
@@ -112,12 +94,10 @@ static void analogix_dp_psr_work(struct work_struct *work)
return;
}
- mutex_lock(&dp->psr_lock);
- if (dp->psr_state == EDP_VSC_PSR_STATE_ACTIVE)
+ if (enabled)
analogix_dp_enable_psr(dp->dev);
else
analogix_dp_disable_psr(dp->dev);
- mutex_unlock(&dp->psr_lock);
}
static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
@@ -134,8 +114,6 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data
*plat_data)
struct rockchip_dp_device *dp = to_dp(plat_data);
int ret;
- cancel_work_sync(&dp->psr_work);
-
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "failed to enable pclk %d\n", ret);
@@ -379,10 +357,6 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
- mutex_init(&dp->psr_lock);
- dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
- INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
-
rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
return analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 00/13] Kernel based bootsplash
On Wed, Dec 20, 2017 at 11:22:36AM +, Daniel Stone wrote: > > Also plymouth grabs the escape character of HPE iLOs, which is a serious > > no-go. > > I'm not entirely sure what this means, but maybe it's best addressed > as a bug report to the Plymouth developers? One of them is in this > thread. Some server BMCs do have a serial port emulation which can be reached via ssh (apart from IPMI, etc...). HPE's particular implementaion has it's escape character bound to the Escape key. So with plymouth running, i.e. because your boot hangs, which for me working on block, scsi and friends happens at least once a week results in physically power cycling the machine as I can't exit the serial emulation and go back to the BMCs shell. I don't care too much as I'm just a developer and used to power cycle test machines, but I do care about the customer experience in this case. To me it looks like the plymouth folks have a slight disconnect from the server, or non-desktop world. We've already experienced this pattern in the world of init systems. Byte, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 00/13] Kernel based bootsplash
On Tue, Dec 19, 2017 at 05:16:30PM +0100, Daniel Vetter wrote: > Ok I've realized that my assumptions about why you need this aren't > holding up. > > So from reading these patches it sounded like you want an in-kernel boot > splash because that would be on the display faster than a userspace one > like plymouth. That's the only reasons I can see for this (if there's > another good justification, please bring it up). > > I only know of very embedded setups (tv top boxes, in vehicle > entertainment) where that kind of "time to first image" really matters, > and those systems: > - have a real hw kms driver > - don't have fbcon or fbdev emulation enabled (except for some closed > source stacks that are a bit slow to adapt to the new world, and we > don't care about those in gfx). > > But from discussions it sounds like you very much want to use this on > servers, which makes 0 sense to me. On a server something like plymouth > should do a perfectly reasonable job. For _one_ reason we'd like to see this is (I was one of the requesters of this implementation), plymouth in it's infinite wisdom also grabs the serial (IPMI) console and escape characters in a screen log are (you can think of the rest of this sentence yourself I think). Also plymouth grabs the escape character of HPE iLOs, which is a serious no-go. But for several other reasons we can't disable $BOOTSPLASH_IMPLEMENTATION as we're shipping a general purpose distro and don't know on what hardware it will be installed. This is only my peronal view on this situation. Byte, Johannes -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices.
From: Jan Tuerk
Adding the label cpu0 allows the adjustment of cpu-parameters
by reference in overlaying dtsi files in the same way as it
is possible for imx6q devices.
Signed-off-by: Jan Tuerk
Reviewed-by: Andreas Färber
---
arch/arm/boot/dts/imx6dl.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 4d693a75ce98..623c12519b81 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -21,7 +21,7 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu@0 {
+ cpu0: cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
--
emtrion GmbH
Alter Schlachthof 45
76131 Karlsruhe
GERMANY
https://www.emtrion.de
Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/5] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30
On 21.12.2017 01:23, Dmitry Osipenko wrote:
> On 21.12.2017 01:02, Thierry Reding wrote:
>> On Thu, Dec 21, 2017 at 12:05:40AM +0300, Dmitry Osipenko wrote:
>>> On 20.12.2017 23:16, Thierry Reding wrote:
On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote:
> On 20.12.2017 21:01, Thierry Reding wrote:
>> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
>>> Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
>>> DRM's MODE_ADDFB IOCTL on Tegra20/30, because IOCTL uses XRGB format if
>>> requested FB depth is 24bpp. As a result, Xorg doesn't work anymore with
>>> both modesetting and opentegra drivers. On older Tegra's each plane has
>>> a blending configuration which should be used to enable / disable alpha
>>> blending and right now the blending configs are hardcoded to disabled
>>> alpha blending. In order to support alpha formats properly, planes
>>> blending configuration must be adjusted, until then the alpha formats
>>> are equal to non-alpha.
>>>
>>> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
>>> Signed-off-by: Dmitry Osipenko
>>> ---
>>> drivers/gpu/drm/tegra/dc.c| 29 ++---
>>> drivers/gpu/drm/tegra/dc.h| 1 +
>>> drivers/gpu/drm/tegra/fb.c| 13 -
>>> drivers/gpu/drm/tegra/hub.c | 3 ++-
>>> drivers/gpu/drm/tegra/plane.c | 22 +-
>>> drivers/gpu/drm/tegra/plane.h | 2 +-
>>> 6 files changed, 39 insertions(+), 31 deletions(-)
>>
>> This kept bugging me, so I spent some time looking at the blending
>> programming. I came up with the attached patch which seems to work
>> for all scenarios and is fairly similar to your patch. It has the
>> added benefit that we can keep support for more formats.
>>
>> Any comments?
>>
>> Thierry
>> --- >8 ---
>> From 3d2b7d1a9b8239dc6940477d8783461ac60783bc Mon Sep 17 00:00:00 2001
>> From: Thierry Reding
>> Date: Wed, 20 Dec 2017 09:39:14 +0100
>> Subject: [PATCH] drm/tegra: dc: Implement legacy blending
>>
>> This implements alpha blending on legacy display controllers (Tegra20,
>> Tegra30 and Tegra114). While it's theoretically possible to support the
>> zpos property to enable userspace to specify the Z-order of each plane
>> individually, this is not currently supported and the same fixed Z-
>> order as previously defined is used.
>
> Perhaps one variant of implementing zpos could be by making overlays
> 'virtual',
> so each virtual overlay will be backed by the real HW plane and we could
> swap
> the HW planes of the virtual overlays, emulating zpos.
>
>> Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
>> the opaque formats are now supported.
>>
>> Reported-by: Dmitry Osipenko
>> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
>> Signed-off-by: Thierry Reding
>> ---
>> drivers/gpu/drm/tegra/dc.c| 74
>> ++-
>> drivers/gpu/drm/tegra/dc.h| 13
>> drivers/gpu/drm/tegra/fb.c| 12 ---
>> drivers/gpu/drm/tegra/plane.c | 41
>> drivers/gpu/drm/tegra/plane.h | 3 ++
>> 5 files changed, 116 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>> index bc65c314e00f..07c687d7f615 100644
>> --- a/drivers/gpu/drm/tegra/dc.c
>> +++ b/drivers/gpu/drm/tegra/dc.c
>> @@ -168,32 +168,46 @@ static inline u32 compute_initial_dda(unsigned int
>> in)
>> return dfixed_frac(inf);
>> }
>>
>> -static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)
>> +static void
>> +tegra_plane_setup_blending_legacy(struct tegra_plane *plane,
>> + const struct tegra_dc_window *window)
>> {
>> +u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
>> + BLEND_COLOR_KEY_NONE;
>> +u32 background = BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) |
>> + BLEND_COLOR_KEY_NONE;
>> +u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
>> +
>> +/* enable alpha blending if window->alpha */
>> +if (window->alpha) {
>> +background |= BLEND_CONTROL_DEPENDENT;
>> +foreground |= BLEND_CONTROL_ALPHA;
>> +}
>
> I think dependent weight means that window doesn't have alpha
> transparency. So
> we should set the dependent_weight mode for opaque formats and
> alpha_weight for
> formats with alpha channel.
According to the TRM, dependent weight means that its weight will be 1 -
the sum of the other overlapping window
Re: [Xen-devel] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv
On 12/20/2017 01:27 AM, Dongwon Kim wrote: This patch series contains the implementation of a new device driver, hyper_dmabuf, which provides a method for DMA-BUF sharing across different OSes running on the same virtual OS platform powered by a hypervisor. This is very interesting at least in context of embedded systems. Could you please share use-cases for this work and, if possible, sources of the test applications if any. Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces
Inline. On Wed, 20 Dec 2017 11:54:10 -0800 Kristian Høgsberg wrote: > On Wed, Dec 20, 2017 at 11:51 AM, Daniel Vetter wrote: > > Since this also involves the kernel let's add dri-devel ... Yeah, I forgot. Thanks Daniel! > > > > On Wed, Dec 20, 2017 at 5:51 PM, Miguel Angel Vico > > wrote: > >> Hi all, > >> > >> As many of you already know, I've been working with James Jones on the > >> Generic Device Allocator project lately. He started a discussion thread > >> some weeks ago seeking feedback on the current prototype of the library > >> and advice on how to move all this forward, from a prototype stage to > >> production. For further reference, see: > >> > >> > >> https://lists.freedesktop.org/archives/mesa-dev/2017-November/177632.html > >> > >> From the thread above, we came up with very interesting high level > >> design ideas for one of the currently missing parts in the library: > >> Usage transitions. That's something I'll personally work on during the > >> following weeks. > >> > >> > >> In the meantime, I've been working on putting together an open source > >> implementation of the allocator mechanisms using the Nouveau driver for > >> all to be able to play with. > >> > >> Below I'm seeking feedback on a bunch of changes I had to make to > >> different components of the graphics stack: > >> > >> ** Allocator ** > >> > >> An allocator driver implementation on top of Nouveau. The current > >> implementation only handles pitch linear layouts, but that's enough > >> to have the kmscube port working using the allocator and Nouveau > >> drivers. > >> > >> You can pull these changes from > >> > >> > >> https://github.com/mvicomoya/allocator/tree/wip/mvicomoya/nouveau-driver > >> > >> ** Mesa ** > >> > >> James's kmscube port to use the allocator relies on the > >> EXT_external_objects extension to import allocator allocations to > >> OpenGL as a texture object. However, the Nouveau implementation of > >> these mechanisms is missing in Mesa, so I went ahead and added them. > >> > >> You can pull these changes from > >> > >> > >> https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/EXT_external_objects-nouveau > >> > >> Also, James's kmscube port uses the NVX_unix_allocator_import > >> extension to attach allocator metadata to texture objects so the > >> driver knows how to deal with the imported memory. > >> > >> Note that there isn't a formal spec for this extension yet. For now, > >> it just serves as an experimental mechanism to import allocator > >> memory in OpenGL, and attach metadata to texture objects. > >> > >> You can pull these changes (written on top of the above) from: > >> > >> > >> https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/NVX_unix_allocator_import > >> > >> ** kmscube ** > >> > >> Mostly minor fixes and improvements on top of James's port to use the > >> allocator. Main thing is the allocator initialization path will use > >> EGL_MESA_platform_surfaceless if EGLDevice platform isn't supported > >> by the underlying EGL implementation. > >> > >> You can pull these changes from: > >> > >> > >> https://github.com/mvicomoya/kmscube/tree/wip/mvicomoya/allocator-nouveau > >> > >> > >> With all the above you should be able to get kmscube working using the > >> allocator on top of the Nouveau driver. > >> > >> > >> Another of the missing pieces before we can move this to production is > >> importing allocations to DRM FB objects. This is probably one of the > >> most sensitive parts of the project as it requires modification/addition > >> of kernel driver interfaces. > >> > >> At XDC2017, James had several hallway conversations with several people > >> about this, all having different opinions. I'd like to take this > >> opportunity to also start a discussion about what's the best option to > >> create a path to get allocator allocations added as DRM FB objects. > >> > >> These are the few options we've considered to start with: > >> > >> A) Have vendor-private ioctls to set properties on GEM objects that > >> are inherited by the FB objects. This is how our (NVIDIA) desktop > >> DRM driver currently works. This would require every vendor to add > >> their own ioctl to process allocator metadata, but the metadata is > >> actually a vendor-agnostic object more like DRM modifiers. We'd > >> like to come up with a vendor-agnostic solutions that can be > >> integrated to core DRM. > >> > >> B) Add a new drmModeAddFBWithMetadata() command that takes allocator > >> metadata blobs for each plane of the FB. Some people in the > >> community have mentioned this is their preferred design. This, > >> however, means we'd have to go through the exercise of adding > >> another metadata mechanism to the whole graphics stack. > >> > >> C) Shove allocator metadata into DRM by defining it to be a separate > >> plane in the image, and using the existing DRM mod
Re: [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW
On Wed, Dec 20, 2017 at 10:32:11AM +0100, Greg Kroah-Hartman wrote: > On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote: > > On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote: > > > On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote: > > > > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible. > > [] > > > > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c > > [] > > > > @@ -854,7 +854,7 @@ static ssize_t dma_op_mode_store(struct device *dev, > > > > return size; > > > > } > > > > > > > > -static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, > > > > dma_op_mode_store); > > > > +static DEVICE_ATTR_RW(dma_op_mode); > > > > > > > > > > While I can ack this part here if it helps generic cleanup effort I > > > don't understart would it improve code readability in general? Mode 644 > > > is clear and don't need any grepping but for DEVICE_ATTR_RW() I had to go > > > through all of these files in order to see what does it mean: > > Yeah, 644 is "clear", but _RW() is even more clear. Ideally I want to > get rid of all of the "non-standard" users that set random modes of > sysfs files, as we get it wrong too many times. Using the "defaults" is > much better. > Fair enough. For the sound/soc/omap/ (Acked-by was missing from my previous reply): Acked-by: Jarkko Nikula ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces
On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico wrote: > Inline. > > On Wed, 20 Dec 2017 11:54:10 -0800 > Kristian Høgsberg wrote: > > > On Wed, Dec 20, 2017 at 11:51 AM, Daniel Vetter wrote: > > > Since this also involves the kernel let's add dri-devel ... > > Yeah, I forgot. Thanks Daniel! > > > > > > > On Wed, Dec 20, 2017 at 5:51 PM, Miguel Angel Vico < > mvicom...@nvidia.com> wrote: > > >> Hi all, > > >> > > >> As many of you already know, I've been working with James Jones on the > > >> Generic Device Allocator project lately. He started a discussion > thread > > >> some weeks ago seeking feedback on the current prototype of the > library > > >> and advice on how to move all this forward, from a prototype stage to > > >> production. For further reference, see: > > >> > > >>https://lists.freedesktop.org/archives/mesa-dev/2017- > November/177632.html > > >> > > >> From the thread above, we came up with very interesting high level > > >> design ideas for one of the currently missing parts in the library: > > >> Usage transitions. That's something I'll personally work on during the > > >> following weeks. > > >> > > >> > > >> In the meantime, I've been working on putting together an open source > > >> implementation of the allocator mechanisms using the Nouveau driver > for > > >> all to be able to play with. > > >> > > >> Below I'm seeking feedback on a bunch of changes I had to make to > > >> different components of the graphics stack: > > >> > > >> ** Allocator ** > > >> > > >> An allocator driver implementation on top of Nouveau. The current > > >> implementation only handles pitch linear layouts, but that's enough > > >> to have the kmscube port working using the allocator and Nouveau > > >> drivers. > > >> > > >> You can pull these changes from > > >> > > >> https://github.com/mvicomoya/allocator/tree/wip/mvicomoya/ > nouveau-driver > > >> > > >> ** Mesa ** > > >> > > >> James's kmscube port to use the allocator relies on the > > >> EXT_external_objects extension to import allocator allocations to > > >> OpenGL as a texture object. However, the Nouveau implementation of > > >> these mechanisms is missing in Mesa, so I went ahead and added them. > > >> > > >> You can pull these changes from > > >> > > >> https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/EXT_ > external_objects-nouveau > > >> > > >> Also, James's kmscube port uses the NVX_unix_allocator_import > > >> extension to attach allocator metadata to texture objects so the > > >> driver knows how to deal with the imported memory. > > >> > > >> Note that there isn't a formal spec for this extension yet. For now, > > >> it just serves as an experimental mechanism to import allocator > > >> memory in OpenGL, and attach metadata to texture objects. > > >> > > >> You can pull these changes (written on top of the above) from: > > >> > > >> https://github.com/mvicomoya/mesa/tree/wip/mvicomoya/NVX_ > unix_allocator_import > > >> > > >> ** kmscube ** > > >> > > >> Mostly minor fixes and improvements on top of James's port to use > the > > >> allocator. Main thing is the allocator initialization path will use > > >> EGL_MESA_platform_surfaceless if EGLDevice platform isn't supported > > >> by the underlying EGL implementation. > > >> > > >> You can pull these changes from: > > >> > > >> https://github.com/mvicomoya/kmscube/tree/wip/mvicomoya/ > allocator-nouveau > > >> > > >> > > >> With all the above you should be able to get kmscube working using the > > >> allocator on top of the Nouveau driver. > > >> > > >> > > >> Another of the missing pieces before we can move this to production is > > >> importing allocations to DRM FB objects. This is probably one of the > > >> most sensitive parts of the project as it requires > modification/addition > > >> of kernel driver interfaces. > > >> > > >> At XDC2017, James had several hallway conversations with several > people > > >> about this, all having different opinions. I'd like to take this > > >> opportunity to also start a discussion about what's the best option to > > >> create a path to get allocator allocations added as DRM FB objects. > > >> > > >> These are the few options we've considered to start with: > > >> > > >> A) Have vendor-private ioctls to set properties on GEM objects that > > >> are inherited by the FB objects. This is how our (NVIDIA) desktop > > >> DRM driver currently works. This would require every vendor to > add > > >> their own ioctl to process allocator metadata, but the metadata > is > > >> actually a vendor-agnostic object more like DRM modifiers. We'd > > >> like to come up with a vendor-agnostic solutions that can be > > >> integrated to core DRM. > > >> > > >> B) Add a new drmModeAddFBWithMetadata() command that takes allocator > > >> metadata blobs for each plane of the FB. Some people in the > > >> community have mentioned this is their preferred d
Re: [-next PATCH 0/4] sysfs and DEVICE_ATTR_
Hi, Joe Perches writes: > drivers/usb/phy/phy-tahvo.c| 2 +- Acked-by: Felipe Balbi -- balbi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] Add basic support for emtrion emCON-MX6 modules
From: Jan Tuerk The following patch-series adds support for emtrion's emCON-MX6 modules with all their dependencies. The focus is based on the emtrion standard developer-kit configuration. It includes a new vendor-prefix, an new simple-panel type, a small modification of the imx6dl.dtsi, as well as modifications of the common imx_v6_v7_defconfig. And finally the board devicetrees themselves. For V2 there are some changes and small fixes following below. The smtp issue which was converting tabs into spaces should be fixed now, so checkpatch should only warn about the new Documentation files and the new devicetree bindings which are documented in the corresponding patch. The documentation for the EDT display is kept as an extra file currently, as it is done by the most displays in the documentation. Also a new new Vartiant of the EDT already arrived. So merging their documentations should be discussed separately. [PATCH v2 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6 No changes, resend. [PATCH v2 2/5] dt-bindings: Add vendor prefix for emtrion GmbH v2: - Reviewed-by: Andreas Färber - Acked-by: Rob Herring [PATCH v2 3/5] ARM: dts: imx: Add an cpu0 label for imx6dl devices. v2: - Reviewed-by: Andreas Färber [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series Changes in v2: - Fixed typo (reg_prallel.. --> reg_parallel) - Removed trailing new-line - Fix uppercase addresses as Rob H. noted - Fix warning about lcd@di0 -> rename to disp0 - Renamed some nodes regarding Rob H. [PATCH v2 5/5] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support. No changes, resend. Documentation/devicetree/bindings/arm/emtrion.txt | 13 + .../bindings/display/panel/edt,etm0700g0bdh6.txt | 9 + .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/boot/dts/Makefile | 2 + arch/arm/boot/dts/imx6dl-emcon-avari.dts | 233 ++ arch/arm/boot/dts/imx6dl-emcon.dtsi| 37 + arch/arm/boot/dts/imx6dl.dtsi | 2 +- arch/arm/boot/dts/imx6q-emcon-avari.dts| 233 ++ arch/arm/boot/dts/imx6q-emcon.dtsi | 37 + arch/arm/boot/dts/imx6qdl-emcon.dtsi | 848 arch/arm/configs/imx_v6_v7_defconfig | 4 + drivers/gpu/drm/panel/panel-simple.c | 15 + 12 files changed, 1433 insertions(+), 1 deletion(-) -- emtrion GmbH Alter Schlachthof 45 76131 Karlsruhe GERMANY https://www.emtrion.de Amtsgericht Mannheim HRB 110 300 Geschäftsführer: Dieter Baur, Ramona Maurer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/5] Some corrections and improvement for Tegra DRM
I've aggregated all Tegra DRM patches that I've sent before into a single series. What's changed: - Alpha formats been dropped in addition to restore of opaque formats on T20/30. - Reworked the HW cursor patch a tad, since alpha formats have been dropped from the overlay plane. - Fixed warning that was reported by kbuild bot for ARM64 build. Dmitry Osipenko (5): drm/tegra: dc: Link DC1 to DC0 on Tegra20 drm/tegra: Restore opaque and drop alpha formats on Tegra20/30 drm/tegra: Trade overlay plane for cursor on older Tegra's drm/tegra: gem: Correct iommu_map_sg() error checking drm/tegra: Correct timeout in tegra_syncpt_wait drivers/gpu/drm/tegra/dc.c| 184 -- drivers/gpu/drm/tegra/dc.h| 5 +- drivers/gpu/drm/tegra/drm.c | 3 +- drivers/gpu/drm/tegra/fb.c| 13 --- drivers/gpu/drm/tegra/gem.c | 15 ++-- drivers/gpu/drm/tegra/hub.c | 3 +- drivers/gpu/drm/tegra/plane.c | 22 +++-- drivers/gpu/drm/tegra/plane.h | 2 +- 8 files changed, 158 insertions(+), 89 deletions(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] dt-bindings: Add vendor prefix for emtrion GmbH
From: Jan Tuerk emtrion is a system integrator and manufacturer of embedded systems. Website: https://www.emtrion.de Signed-off-by: Jan Tuerk Reviewed-by: Andreas Färber Acked-by: Rob Herring --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 0994bdd82cd3..5215c5767260 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -102,6 +102,7 @@ eetieGalax_eMPIA Technology Inc elan Elan Microelectronic Corp. embest Shenzhen Embest Technology Co., Ltd. emmicroEM Microelectronic +emtrionemtrion GmbH energymicroSilicon Laboratories (formerly Energy Micro AS) engicamEngicam S.r.l. epcos EPCOS AG -- emtrion GmbH Alter Schlachthof 45 76131 Karlsruhe GERMANY https://www.emtrion.de Amtsgericht Mannheim HRB 110 300 Geschäftsführer: Dieter Baur, Ramona Maurer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/rockchip: Don't use atomic constructs for psr
From: Sean Paul
Instead of using timer and spinlocks, use delayed_work and
mutexes for rockchip psr. This allows us to make blocking
calls when enabling/disabling psr (which is sort of important
given we're talking over dpcd to the display).
Signed-off-by: Sean Paul
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 63 +
3 files changed, 29 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 76d63de..cd7ae12 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -134,7 +134,7 @@ static int rockchip_drm_bind(struct device *dev)
drm_dev->dev_private = private;
INIT_LIST_HEAD(&private->psr_list);
- spin_lock_init(&private->psr_list_lock);
+ mutex_init(&private->psr_list_lock);
ret = rockchip_drm_init_iommu(drm_dev);
if (ret)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 498dfbc..9c064a4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -55,7 +55,7 @@ struct rockchip_drm_private {
struct mutex mm_lock;
struct drm_mm mm;
struct list_head psr_list;
- spinlock_t psr_list_lock;
+ struct mutex psr_list_lock;
};
int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 3acfd57..a3f6ec0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -18,7 +18,7 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_psr.h"
-#define PSR_FLUSH_TIMEOUT msecs_to_jiffies(100)
+#define PSR_FLUSH_TIMEOUT_MS 100
enum psr_state {
PSR_FLUSH,
@@ -30,11 +30,11 @@ struct psr_drv {
struct list_headlist;
struct drm_encoder *encoder;
- spinlock_t lock;
+ struct mutexlock;
boolactive;
enum psr_state state;
- struct timer_list flush_timer;
+ struct delayed_work flush_work;
void (*set)(struct drm_encoder *encoder, bool enable);
};
@@ -43,9 +43,8 @@ static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
{
struct rockchip_drm_private *drm_drv = crtc->dev->dev_private;
struct psr_drv *psr;
- unsigned long flags;
- spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+ mutex_lock(&drm_drv->psr_list_lock);
list_for_each_entry(psr, &drm_drv->psr_list, list) {
if (psr->encoder->crtc == crtc)
goto out;
@@ -53,7 +52,7 @@ static struct psr_drv *find_psr_by_crtc(struct drm_crtc *crtc)
psr = ERR_PTR(-ENODEV);
out:
- spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+ mutex_unlock(&drm_drv->psr_list_lock);
return psr;
}
@@ -94,23 +93,21 @@ static void psr_set_state_locked(struct psr_drv *psr, enum
psr_state state)
static void psr_set_state(struct psr_drv *psr, enum psr_state state)
{
- unsigned long flags;
-
- spin_lock_irqsave(&psr->lock, flags);
+ mutex_lock(&psr->lock);
psr_set_state_locked(psr, state);
- spin_unlock_irqrestore(&psr->lock, flags);
+ mutex_unlock(&psr->lock);
}
-static void psr_flush_handler(struct timer_list *t)
+static void psr_flush_handler(struct work_struct *work)
{
- struct psr_drv *psr = from_timer(psr, t, flush_timer);
- unsigned long flags;
+ struct psr_drv *psr = container_of(to_delayed_work(work),
+ struct psr_drv, flush_work);
/* If the state has changed since we initiated the flush, do nothing */
- spin_lock_irqsave(&psr->lock, flags);
+ mutex_lock(&psr->lock);
if (psr->state == PSR_FLUSH)
psr_set_state_locked(psr, PSR_ENABLE);
- spin_unlock_irqrestore(&psr->lock, flags);
+ mutex_unlock(&psr->lock);
}
/**
@@ -123,14 +120,13 @@ static void psr_flush_handler(struct timer_list *t)
int rockchip_drm_psr_activate(struct drm_crtc *crtc)
{
struct psr_drv *psr = find_psr_by_crtc(crtc);
- unsigned long flags;
if (IS_ERR(psr))
return PTR_ERR(psr);
- spin_lock_irqsave(&psr->lock, flags);
+ mutex_lock(&psr->lock);
psr->active = true;
- spin_unlock_irqrestore(&psr->lock, flags);
+ mutex_unlock(&psr->lock);
return 0;
}
@@ -146,15 +142,14 @@ EXPORT_SYMBOL(rockchip_drm_psr_activate);
int rockchip_drm_psr_deactivate(struct drm_crtc *crtc)
{
struct psr_drv *psr = find_psr_by_crtc(crtc);
- uns
Re: [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO
On 12/19/2017 07:15 PM, Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_RO where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
> xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IRUGO\s*|\s*0444\s*)\)?\s*,\s*\1_show\s*,\s*NULL\s*\)/DEVICE_ATTR_RO(\1)/g;
> print;}'
>
> Signed-off-by: Joe Perches
> ---
> arch/arm/mach-pxa/sharpsl_pm.c | 4 ++--
> arch/sh/drivers/push-switch.c| 2 +-
> arch/tile/kernel/sysfs.c | 10 +-
> drivers/acpi/device_sysfs.c | 6 +++---
> drivers/char/ipmi/ipmi_msghandler.c | 17 -
> drivers/gpu/drm/i915/i915_sysfs.c| 6 +++---
> drivers/nvme/host/core.c | 10 +-
> drivers/s390/cio/css.c | 8
> drivers/s390/cio/device.c| 8
> drivers/s390/crypto/ap_card.c| 2 +-
For the s390 AP part,
ACK-by: Harald Freudenberger Thanks
> drivers/scsi/hpsa.c | 10 +-
> drivers/scsi/lpfc/lpfc_attr.c| 18 --
> drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 8
> drivers/thermal/thermal_sysfs.c | 6 +++---
> sound/soc/soc-core.c | 2 +-
> sound/soc/soc-dapm.c | 2 +-
> 16 files changed, 58 insertions(+), 61 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
> index 398ba9ba2632..ef9fd9b759cb 100644
> --- a/arch/arm/mach-pxa/sharpsl_pm.c
> +++ b/arch/arm/mach-pxa/sharpsl_pm.c
> @@ -802,8 +802,8 @@ static ssize_t battery_voltage_show(struct device *dev,
> struct device_attribute
> return sprintf(buf, "%d\n", sharpsl_pm.battstat.mainbat_voltage);
> }
>
> -static DEVICE_ATTR(battery_percentage, 0444, battery_percentage_show, NULL);
> -static DEVICE_ATTR(battery_voltage, 0444, battery_voltage_show, NULL);
> +static DEVICE_ATTR_RO(battery_percentage);
> +static DEVICE_ATTR_RO(battery_voltage);
>
> extern void (*apm_get_power_status)(struct apm_power_info *);
>
> diff --git a/arch/sh/drivers/push-switch.c b/arch/sh/drivers/push-switch.c
> index a17181160233..762bc5619910 100644
> --- a/arch/sh/drivers/push-switch.c
> +++ b/arch/sh/drivers/push-switch.c
> @@ -24,7 +24,7 @@ static ssize_t switch_show(struct device *dev,
> struct push_switch_platform_info *psw_info = dev->platform_data;
> return sprintf(buf, "%s\n", psw_info->name);
> }
> -static DEVICE_ATTR(switch, S_IRUGO, switch_show, NULL);
> +static DEVICE_ATTR_RO(switch);
>
> static void switch_timer(struct timer_list *t)
> {
> diff --git a/arch/tile/kernel/sysfs.c b/arch/tile/kernel/sysfs.c
> index af5024f0fb5a..b09456a3d77a 100644
> --- a/arch/tile/kernel/sysfs.c
> +++ b/arch/tile/kernel/sysfs.c
> @@ -38,7 +38,7 @@ static ssize_t chip_width_show(struct device *dev,
> {
> return sprintf(page, "%u\n", smp_width);
> }
> -static DEVICE_ATTR(chip_width, 0444, chip_width_show, NULL);
> +static DEVICE_ATTR_RO(chip_width);
>
> static ssize_t chip_height_show(struct device *dev,
> struct device_attribute *attr,
> @@ -46,7 +46,7 @@ static ssize_t chip_height_show(struct device *dev,
> {
> return sprintf(page, "%u\n", smp_height);
> }
> -static DEVICE_ATTR(chip_height, 0444, chip_height_show, NULL);
> +static DEVICE_ATTR_RO(chip_height);
>
> static ssize_t chip_serial_show(struct device *dev,
> struct device_attribute *attr,
> @@ -54,7 +54,7 @@ static ssize_t chip_serial_show(struct device *dev,
> {
> return get_hv_confstr(page, HV_CONFSTR_CHIP_SERIAL_NUM);
> }
> -static DEVICE_ATTR(chip_serial, 0444, chip_serial_show, NULL);
> +static DEVICE_ATTR_RO(chip_serial);
>
> static ssize_t chip_revision_show(struct device *dev,
> struct device_attribute *attr,
> @@ -62,7 +62,7 @@ static ssize_t chip_revision_show(struct device *dev,
> {
> return get_hv_confstr(page, HV_CONFSTR_CHIP_REV);
> }
> -static DEVICE_ATTR(chip_revision, 0444, chip_revision_show, NULL);
> +static DEVICE_ATTR_RO(chip_revision);
>
>
> static ssize_t type_show(struct device *dev,
> @@ -71,7 +71,7 @@ static ssize_t type_show(struct device *dev,
> {
> return sprintf(page, "tilera\n");
> }
> -static DEVICE_ATTR(type, 0444, type_show, NULL);
> +static DEVICE_ATTR_RO(type);
>
> #define HV_CONF_ATTR(name, conf) \
> static ssize_t name ## _show(struct device *dev,\
> diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
> index a041689e5701..545e91420cde 100644
> --- a/drivers/acpi/device_sysfs.c
> +++ b/drivers/acpi/device_sysfs.c
> @@ -357,7 +357,7 @@ static
RE: [alsa-devel] [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW
Does anyone know how to use Conexant CX20921 to develop our own application. I
cannot find anywhere to download the software and manuals.
Thanks to all
J.D
-Original Message-
From: alsa-devel-boun...@alsa-project.org
[mailto:alsa-devel-boun...@alsa-project.org] On Behalf Of Andy Shevchenko
Sent: 2017年12月20日 2:42
To: Joe Perches
Cc: linux-fb...@vger.kernel.org; David Airlie ; Joonas
Lahtinen ; Heiko Carstens
; ALSA Development Mailing List
; dri-devel@lists.freedesktop.org; Peter Ujfalusi
; linux-s...@vger.kernel.org; Linux OMAP Mailing List
; James E.J. Bottomley ;
linux-scsi ; Takashi Iwai ;
Sebastian Ott ; James Smart
; Cezary Jackiewicz ;
linux-ser...@vger.kernel.org; Jiri Slaby ; Darren Hart
; Zhang Rui ; Dick Kennedy
; Mathias Nyman ;
Bartlomiej Zolnierkiewicz ; Peter Oberparleiter
; intel-...@lists.freedesktop.org; Jani Nikula
; Eduardo Valentin ; Mark
Brown ; Rodrigo Vivi ; Platform
Driver ; Felipe Balbi ;
Martin K. Petersen ; Greg Kroah-Hartman
; linux...@vger.kernel.org; USB
; Liam Girdwood ;
linux-ker...@vger.kernel.org; Luis R. Rodriguez ; Andy
Shevchenko ; Martin Schwidefsky ;
Jarkko Nikula
Subject: Re: [alsa-devel] [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW
On Tue, Dec 19, 2017 at 8:15 PM, Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
> xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWUSR|\s*S_IWUSR\s*\|\s*S_IRUGO\s*|\s*0644\s*)\)?\s*,\s*\1_show\s*,\s*\1_store\s*\)/DEVICE_ATTR_RW(\1)/g;
> print;}'
> drivers/platform/x86/compal-laptop.c | 18 +--
> --- a/drivers/platform/x86/compal-laptop.c
> +++ b/drivers/platform/x86/compal-laptop.c
> @@ -679,18 +679,12 @@ static int bat_writeable_property(struct
> power_supply *psy,
> /* == */
> /* Driver Globals */
> /* == */
> -static DEVICE_ATTR(wake_up_pme,
> - 0644, wake_up_pme_show, wake_up_pme_store);
> -static DEVICE_ATTR(wake_up_modem,
> - 0644, wake_up_modem_show, wake_up_modem_store);
> -static DEVICE_ATTR(wake_up_lan,
> - 0644, wake_up_lan_show, wake_up_lan_store);
> -static DEVICE_ATTR(wake_up_wlan,
> - 0644, wake_up_wlan_show,wake_up_wlan_store);
> -static DEVICE_ATTR(wake_up_key,
> - 0644, wake_up_key_show, wake_up_key_store);
> -static DEVICE_ATTR(wake_up_mouse,
> - 0644, wake_up_mouse_show, wake_up_mouse_store);
> +static DEVICE_ATTR_RW(wake_up_pme);
> +static DEVICE_ATTR_RW(wake_up_modem); static
> +DEVICE_ATTR_RW(wake_up_lan); static DEVICE_ATTR_RW(wake_up_wlan);
> +static DEVICE_ATTR_RW(wake_up_key); static
> +DEVICE_ATTR_RW(wake_up_mouse);
Acked-by: Andy Shevchenko
for PDx86 bits.
Have to say that while it doesn't change the attributes here, it might require
still to be revisited by security people, if they wish.
--
With Best Regards,
Andy Shevchenko
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/rockchip: Fix sleeping function called from invalid context
Dear all, After enable the debug option to check sleep inside atomic section I got lots of messages from the drm/rockchip driver using current 4.15-rc4 BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238 in_atomic(): 1, irqs_disabled(): 128, pid: 3457, name: Xorg CPU: 3 PID: 3457 Comm: Xorg Tainted: GW4.15.0-rc4+ #56 Hardware name: Google Kevin (DT) Call trace: dump_backtrace+0x0/0x1a8 show_stack+0x24/0x30 dump_stack+0xb8/0xf0 ___might_sleep+0x110/0x140 __might_sleep+0x58/0x90 mutex_lock+0x2c/0x68 analogix_dp_psr_set+0x78/0x100 rockchip_drm_do_flush+0x6c/0x88 rockchip_drm_psr_flush_all+0x48/0x70 rockchip_drm_fb_dirty+0x20/0x30 drm_mode_dirtyfb_ioctl+0x1c4/0x1f8 drm_ioctl_kernel+0x74/0xd0 drm_ioctl+0x2b8/0x3c0 do_vfs_ioctl+0xb0/0x818 SyS_ioctl+0x94/0xa8 el0_svc_naked+0x20/0x24 The two patches in this patchset were sent by Sean Paul some time ago ([1][2]) but never landed in mainline, the patches in question can fix the issue reported and I think that could be interesting include both in this release cycle, hence I'm resending it. The patches were rebased on top of mainline. [1] https://patchwork.kernel.org/patch/9382847/ [2] https://patchwork.kernel.org/patch/9614679/ Best regards, Enric Sean Paul (2): drm/rockchip: Don't use atomic constructs for psr drm/rockchip: Remove analogix psr worker. drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 30 +--- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 63 +++-- 4 files changed, 31 insertions(+), 66 deletions(-) -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series
From: Jan Tuerk
This patch adds support for the emtrion GmbH emCON-MX6 modules.
They are available with imx.6 Solo, Dual-Lite, Dual and Quad
equipped with Memory from 512MB to 2GB (configured by U-Boot).
Our default developer-Kit ships with the Avari baseboard and the
EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).
The devicetree is split into the common part providing all module
components and the basic support for all SoC versions
(imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
Finally the support for the avari baseboard in the developer-kit
configuration is provided by the emcon-avari dts files.
Signed-off-by: Jan Tuerk
---
Changes in v2:
- Fixed typo (reg_prallel.. --> reg_parallel)
- Removed trailing new-line
- Fix uppercase addresses as Rob H. noted
- Fix warning about lcd@di0 -> rename to disp0
- Renamed some nodes regarding Rob H.
Documentation/devicetree/bindings/arm/emtrion.txt | 13 +
arch/arm/boot/dts/Makefile| 2 +
arch/arm/boot/dts/imx6dl-emcon-avari.dts | 233 ++
arch/arm/boot/dts/imx6dl-emcon.dtsi | 37 +
arch/arm/boot/dts/imx6q-emcon-avari.dts | 233 ++
arch/arm/boot/dts/imx6q-emcon.dtsi| 37 +
arch/arm/boot/dts/imx6qdl-emcon.dtsi | 848 ++
7 files changed, 1403 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi
diff --git a/Documentation/devicetree/bindings/arm/emtrion.txt
b/Documentation/devicetree/bindings/arm/emtrion.txt
new file mode 100644
index ..3ff6c6c2034d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/emtrion.txt
@@ -0,0 +1,13 @@
+Emtrion Devicetree Bindings
+===
+
+emCON Series:
+-
+
+Required root node properties
+ - compatible:
+ - "emtrion,emcon-mx6", "fsl,imx6q", "fsl,imx6dl"; : emCON-MX6 Generic
SoM
+ - "emtrion,emcon-mx6", "fsl,imx6q"; : emCON-MX6D or
emCON-MX6Q SoM
+ - "emtrion,emcon-mx6-avari", "fsl,imx6q"; : emCON-MX6D or
emCON-MX6Q SoM on Avari Base
+ - "emtrion,emcon-mx6", "fsl,imx6dl";: emCON-MX6S or
emCON-MX6DL SoM
+ - "emtrion,emcon-mx6-avari", "fsl,imx6dl"; : emCON-MX6S or
emCON-MX6DL SoM on Avari Base
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9caf21..5ce643ece228 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -373,6 +373,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-colibri-eval-v3.dtb \
imx6dl-cubox-i.dtb \
imx6dl-dfi-fs700-m60.dtb \
+ imx6dl-emcon-avari.dtb \
imx6dl-gw51xx.dtb \
imx6dl-gw52xx.dtb \
imx6dl-gw53xx.dtb \
@@ -424,6 +425,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-dfi-fs700-m60.dtb \
imx6q-display5-tianma-tm070-1280x768.dtb \
imx6q-dmo-edmqmx6.dtb \
+ imx6q-emcon-avari.dtb \
imx6q-evi.dtb \
imx6q-gk802.dtb \
imx6q-gw51xx.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-emcon-avari.dts
b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
new file mode 100644
index ..f1333a48d8c5
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
@@ -0,0 +1,233 @@
+/*
+ * Copyright (C) 2017 emtrion GmbH
+ * Author: Jan Tuerk
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-emcon.dtsi"
+#include "imx6dl-emcon.dtsi" /*Include camera2 pinmux*/
+
+/ {
+ model = "emtrion SoM emCON-MX6 Solo/Dual-Lite Avari";
+ compatible = "emtrion,emcon-mx6-avari", "fsl,imx6dl";
+
+ aliases {
+ mmc0 = &usdhc3;
+ mmc2 = &usdhc1;
+ mmc1 = &usdhc2;
+ mmc3 = &usdhc4;
+ };
+
+ chosen {
+ stdout-path = <&uart1>;
+ };
+
+ memory {
+ reg = <0x1000 0x4000>;
+ };
+
+ supplies {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wallplug5p0: supply@0 {
+ compatible = "regulator-fixed";
+ reg = <0>;
+ regulator-name = "WALL-PLUG";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-al
[PATCH v2] drm/i915/vlv: Add cdclk workaround for DSI
At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
colors, showing that the panel controller is starting with sampling the
datastream somewhere mid-line. This happens after the first blanking and
re-init of the panel.
After looking at drm.debug output I noticed that initially we inherit the
cdclk of 33 KHz set by the GOP, but after the re-init we picked 27
KHz, which turns out to be the cause of this problem, a quick hack to hard
code the cdclk to 33 KHz makes the problem go away.
I've tested this on various Bay Trail devices, to make sure this not
causes regressions on other devices and the higher cdclk does not cause
any problems on the following devices:
-GP-electronic T701 1024x600 33 KHz cdclk after this patch
-PEAQ C1010 1920x1200 33 KHz cdclk after this patch
-PoV mobii-wintab-800w800x1280 33 KHz cdclk after this patch
-Asus Transformer-T100TA 1368x768 32 KHz cdclk after this patch
Also interesting wrt this is the comment in vlv_calc_cdclk about the
existing workaround to avoid 200 Mhz as clock because that causes issues
in some cases.
This commit extends the "do not use 200 Mhz" workaround with an extra
check to require atleast 32 KHz (avoiding 27 KHz) when a DSI
panel is active.
Changes in v2:
-Change the commit message and the code comment to not treat the GOP as
a reference, the GOP should not be treated as a reference
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_cdclk.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 9c5ceb98d48f..a15976f55f47 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1923,6 +1923,14 @@ int intel_crtc_compute_min_cdclk(const struct
intel_crtc_state *crtc_state)
if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
min_cdclk = max(2 * 96000, min_cdclk);
+ /*
+* On Valleyview some DSI panels loose (v|h)sync when the clock is lower
+* then 32KHz.
+*/
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
+ IS_VALLEYVIEW(dev_priv))
+ min_cdclk = max(32, min_cdclk);
+
if (min_cdclk > dev_priv->max_cdclk_freq) {
DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d kHz)\n",
min_cdclk, dev_priv->max_cdclk_freq);
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/5] drm/tegra: Correct timeout in tegra_syncpt_wait
host1x_syncpt_wait() takes timeout value in jiffies, but DRM passes it in milliseconds. Signed-off-by: Dmitry Osipenko --- drivers/gpu/drm/tegra/drm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index bb98336fa8d7..57396388341b 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -629,7 +629,8 @@ static int tegra_syncpt_wait(struct drm_device *drm, void *data, if (!sp) return -EINVAL; - return host1x_syncpt_wait(sp, args->thresh, args->timeout, + return host1x_syncpt_wait(sp, args->thresh, + msecs_to_jiffies(args->timeout), &args->value); } -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
From: Jan Tuerk
The Emerging Display Technology ETM0700G0BDH6 is exactly
the same display as the ETM0700G0DH6, exept the pixelclock
polarity. Therefore re-use the ETM0700G0DH6 modes. It is
used by default on emtrion Avari based development kits.
Signed-off-by: Jan Tuerk
---
.../bindings/display/panel/edt,etm0700g0bdh6.txt | 9 +
drivers/gpu/drm/panel/panel-simple.c | 15 +++
2 files changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
new file mode 100644
index ..099e30bfa17f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
@@ -0,0 +1,9 @@
+Emerging Display Technology Corp. ETM0700G0BDH6 7.0" WVGA TFT LCD panel
+
+Required properties:
+ compatible: "edt,etm0700g0bdh6"
+
+This panel is exactly the same as ETM0700G0DH6 except the pixelclock polarity.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index b7c4709f7b34..42442034b53e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -886,6 +886,18 @@ static const struct panel_desc edt_etm0700g0dh6 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
};
+static const struct panel_desc edt_etm0700g0bdh6 = {
+ .modes = &edt_etm0700g0dh6_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
.clock = 32260,
.hdisplay = 800,
@@ -2029,6 +2041,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "edt,etm0700g0dh6",
.data = &edt_etm0700g0dh6,
}, {
+ .compatible = "edt,etm0700g0bdh6",
+ .data = &edt_etm0700g0bdh6,
+ }, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = &foxlink_fl500wvr00_a0t,
}, {
--
emtrion GmbH
Alter Schlachthof 45
76131 Karlsruhe
GERMANY
https://www.emtrion.de
Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/5] drm/tegra: gem: Correct iommu_map_sg() error checking
iommu_map_sg() doesn't return a error value, but a size of the requested
IOMMU mapping or zero in case of error.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gem.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index ab1e53d434e8..49b9bf28f872 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -114,7 +114,7 @@ static const struct host1x_bo_ops tegra_bo_ops = {
static int tegra_bo_iommu_map(struct tegra_drm *tegra, struct tegra_bo *bo)
{
int prot = IOMMU_READ | IOMMU_WRITE;
- ssize_t err;
+ int err;
if (bo->mm)
return -EBUSY;
@@ -128,22 +128,21 @@ static int tegra_bo_iommu_map(struct tegra_drm *tegra,
struct tegra_bo *bo)
err = drm_mm_insert_node_generic(&tegra->mm,
bo->mm, bo->gem.size, PAGE_SIZE, 0, 0);
if (err < 0) {
- dev_err(tegra->drm->dev, "out of I/O virtual memory: %zd\n",
+ dev_err(tegra->drm->dev, "out of I/O virtual memory: %d\n",
err);
goto unlock;
}
bo->paddr = bo->mm->start;
- err = iommu_map_sg(tegra->domain, bo->paddr, bo->sgt->sgl,
- bo->sgt->nents, prot);
- if (err < 0) {
- dev_err(tegra->drm->dev, "failed to map buffer: %zd\n", err);
+ bo->size = iommu_map_sg(tegra->domain, bo->paddr, bo->sgt->sgl,
+ bo->sgt->nents, prot);
+ if (!bo->size) {
+ dev_err(tegra->drm->dev, "failed to map buffer\n");
+ err = -ENOMEM;
goto remove;
}
- bo->size = err;
-
mutex_unlock(&tegra->mm_lock);
return 0;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/5] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30
Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
DRM's MODE_ADDFB IOCTL on Tegra20/30, because IOCTL uses XRGB format if
requested FB depth is 24bpp. As a result, Xorg doesn't work anymore with
both modesetting and opentegra drivers. On older Tegra's each plane has
a blending configuration which should be used to enable / disable alpha
blending and right now the blending configs are hardcoded to disabled
alpha blending. In order to support alpha formats properly, planes
blending configuration must be adjusted, until then the alpha formats
are equal to non-alpha.
Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c| 29 ++---
drivers/gpu/drm/tegra/dc.h| 1 +
drivers/gpu/drm/tegra/fb.c| 13 -
drivers/gpu/drm/tegra/hub.c | 3 ++-
drivers/gpu/drm/tegra/plane.c | 22 +-
drivers/gpu/drm/tegra/plane.h | 2 +-
6 files changed, 39 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 5299185cea2f..460510366bb8 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -299,12 +299,12 @@ static void tegra_dc_setup_window(struct tegra_dc *dc,
unsigned int index,
}
static const u32 tegra20_primary_formats[] = {
- DRM_FORMAT_ARGB,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB565,
- DRM_FORMAT_RGBA5551,
- DRM_FORMAT_ABGR,
- DRM_FORMAT_ARGB,
+ /* non-native formats */
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_RGBX5551,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
};
static const u32 tegra114_primary_formats[] = {
@@ -369,7 +369,8 @@ static int tegra_plane_atomic_check(struct drm_plane *plane,
err = tegra_plane_format(state->fb->format->format,
&plane_state->format,
-&plane_state->swap);
+&plane_state->swap,
+dc->soc->supports_opaque_formats);
if (err < 0)
return err;
@@ -692,12 +693,12 @@ static struct drm_plane
*tegra_dc_cursor_plane_create(struct drm_device *drm,
}
static const u32 tegra20_overlay_formats[] = {
- DRM_FORMAT_ARGB,
- DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB565,
- DRM_FORMAT_RGBA5551,
- DRM_FORMAT_ABGR,
- DRM_FORMAT_ARGB,
+ /* non-native formats */
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_RGBX5551,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
/* planar formats */
DRM_FORMAT_UYVY,
DRM_FORMAT_YUYV,
@@ -1854,6 +1855,7 @@ static const struct tegra_dc_soc_info tegra20_dc_soc_info
= {
.primary_formats = tegra20_primary_formats,
.num_overlay_formats = ARRAY_SIZE(tegra20_overlay_formats),
.overlay_formats = tegra20_overlay_formats,
+ .supports_opaque_formats = false,
};
static const struct tegra_dc_soc_info tegra30_dc_soc_info = {
@@ -1869,6 +1871,7 @@ static const struct tegra_dc_soc_info tegra30_dc_soc_info
= {
.primary_formats = tegra20_primary_formats,
.num_overlay_formats = ARRAY_SIZE(tegra20_overlay_formats),
.overlay_formats = tegra20_overlay_formats,
+ .supports_opaque_formats = false,
};
static const struct tegra_dc_soc_info tegra114_dc_soc_info = {
@@ -1884,6 +1887,7 @@ static const struct tegra_dc_soc_info
tegra114_dc_soc_info = {
.primary_formats = tegra114_primary_formats,
.num_overlay_formats = ARRAY_SIZE(tegra114_overlay_formats),
.overlay_formats = tegra114_overlay_formats,
+ .supports_opaque_formats = true,
};
static const struct tegra_dc_soc_info tegra124_dc_soc_info = {
@@ -1899,6 +1903,7 @@ static const struct tegra_dc_soc_info
tegra124_dc_soc_info = {
.primary_formats = tegra114_primary_formats,
.num_overlay_formats = ARRAY_SIZE(tegra124_overlay_formats),
.overlay_formats = tegra114_overlay_formats,
+ .supports_opaque_formats = true,
};
static const struct tegra_dc_soc_info tegra210_dc_soc_info = {
@@ -1914,6 +1919,7 @@ static const struct tegra_dc_soc_info
tegra210_dc_soc_info = {
.primary_formats = tegra114_primary_formats,
.num_overlay_formats = ARRAY_SIZE(tegra114_overlay_formats),
.overlay_formats = tegra114_overlay_formats,
+ .supports_opaque_formats = true,
};
static const struct tegra_windowgroup_soc tegra186_dc_wgrps[] = {
@@ -1961,6 +1967,7 @@ static const struct tegra_dc_soc_info
tegra186_dc_soc_info = {
.has_nvdisplay = true,
.wgrps = tegra186_dc_wgrps,
.num_wgrps = ARRAY_SIZE(tegra186_dc_wgrps),
+ .supports_opaque_formats = true,
};
static const struct of_device_id tegra_dc_of_match[] = {
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 8098f49c0d96..3a66a1127ee7 100644
--- a/
RE: [PATCH 1/7] drm/ttm: call ttm_bo_swapout directly when ttm shrink
Hi Thomas:
Also I wonder what testing is being performed on these changes prior to
submission?
Vulkan CTS test with Per VM BO enabled.
After that, Command submit will not need to provide BO list it will use. It is
helpful for performance to CPU bound games.
The reason why we enable eviction and swapout here is the test always
overalloction.
Thanks
Roger(Hongbo.He)
-Original Message-
From: Thomas Hellstrom [mailto:tho...@shipmail.org]
Sent: Thursday, December 21, 2017 3:34 PM
To: He, Roger ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/7] drm/ttm: call ttm_bo_swapout directly when ttm shrink
Roger,
5 out of 7 patches in this series are completely lacking a commit log message,
and thats not OK. Really.
https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html#describe-your-changes
I'll review these, but IIRC the no_wait in the memory accounting code is
different in that it doesn't allow sleeping, whereas in the bo code we had
originally had no_wait_gpu and also no_wait. (IIRC Maarten or Jerome removed
the latter due to lack of
users.) Seems like these patches confuse the to. At the very least that
requires some form of motivation.
Also I wonder what testing is being performed on these changes prior to
submission?
We have pretty high number of critical deployments out there, that we need to
support.
/Thomas
On 12/20/2017 11:34 AM, Roger He wrote:
> then remove superfluous functions
>
> Change-Id: Iea020f0e30a239e0265e7a1500168c7d7f819bd9
> Signed-off-by: Roger He
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 21 +++-
> drivers/gpu/drm/ttm/ttm_memory.c | 12 ++-
> include/drm/ttm/ttm_bo_api.h | 1 +
> include/drm/ttm/ttm_bo_driver.h | 1 -
> include/drm/ttm/ttm_memory.h | 69
> +---
> 5 files changed, 9 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> b/drivers/gpu/drm/ttm/ttm_bo.c index 60bb5c1..fa57aa8 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -42,7 +42,6 @@
> #include
> #include
>
> -static int ttm_bo_swapout(struct ttm_mem_shrink *shrink);
> static void ttm_bo_global_kobj_release(struct kobject *kobj);
>
> static struct attribute ttm_bo_count = { @@ -1454,7 +1453,6 @@
> static void ttm_bo_global_kobj_release(struct kobject *kobj)
> struct ttm_bo_global *glob =
> container_of(kobj, struct ttm_bo_global, kobj);
>
> - ttm_mem_unregister_shrink(glob->mem_glob, &glob->shrink);
> __free_page(glob->dummy_read_page);
> kfree(glob);
> }
> @@ -1479,6 +1477,7 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
> mutex_init(&glob->device_list_mutex);
> spin_lock_init(&glob->lru_lock);
> glob->mem_glob = bo_ref->mem_glob;
> + glob->mem_glob->bo_glob = glob;
> glob->dummy_read_page = alloc_page(__GFP_ZERO | GFP_DMA32);
>
> if (unlikely(glob->dummy_read_page == NULL)) { @@ -1489,14 +1488,6
> @@ int ttm_bo_global_init(struct drm_global_reference *ref)
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
> INIT_LIST_HEAD(&glob->swap_lru[i]);
> INIT_LIST_HEAD(&glob->device_list);
> -
> - ttm_mem_init_shrink(&glob->shrink, ttm_bo_swapout);
> - ret = ttm_mem_register_shrink(glob->mem_glob, &glob->shrink);
> - if (unlikely(ret != 0)) {
> - pr_err("Could not register buffer object swapout\n");
> - goto out_no_shrink;
> - }
> -
> atomic_set(&glob->bo_count, 0);
>
> ret = kobject_init_and_add(
> @@ -1504,8 +1495,6 @@ int ttm_bo_global_init(struct drm_global_reference *ref)
> if (unlikely(ret != 0))
> kobject_put(&glob->kobj);
> return ret;
> -out_no_shrink:
> - __free_page(glob->dummy_read_page);
> out_no_drp:
> kfree(glob);
> return ret;
> @@ -1688,11 +1677,8 @@ EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
>* A buffer object shrink method that tries to swap out the first
>* buffer object on the bo_global::swap_lru list.
>*/
> -
> -static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
> +int ttm_bo_swapout(struct ttm_bo_global *glob)
> {
> - struct ttm_bo_global *glob =
> - container_of(shrink, struct ttm_bo_global, shrink);
> struct ttm_buffer_object *bo;
> int ret = -EBUSY;
> unsigned i;
> @@ -1774,10 +1760,11 @@ static int ttm_bo_swapout(struct ttm_mem_shrink
> *shrink)
> kref_put(&bo->list_kref, ttm_bo_release_list);
> return ret;
> }
> +EXPORT_SYMBOL(ttm_bo_swapout);
>
> void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
> {
> - while (ttm_bo_swapout(&bdev->glob->shrink) == 0)
> + while (ttm_bo_swapout(bdev->glob) == 0)
> ;
> }
> EXPORT_SYMBOL(ttm_bo_swapout_all);
> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
> b/drivers/gpu/drm/ttm/ttm_memory.c
> index e963749..9130bdf 100644
> ---
[Bug 104347] AMD RX 580: Hide/Show window sometimes corrupts screen (see screenshot)
https://bugs.freedesktop.org/show_bug.cgi?id=104347 --- Comment #6 from Michel Dänzer --- Arthur, can you try if it also happens with Mesa 17.2 (or maybe even older versions)? -- 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 2/5] drm/ttm: use an operation ctx for ttm_tt_populate in ttm_bo_driver
forward the operation context to ttm_tt_populate as well,
and the ultimate goal is swapout enablement for per vm BOs.
Change-Id: If8dfa0f500429d1420e0da67eb6901f0bfbca57b
Reviewed-by: Christian König
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
drivers/gpu/drm/ast/ast_ttm.c | 5 +++--
drivers/gpu/drm/cirrus/cirrus_ttm.c | 5 +++--
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 5 +++--
drivers/gpu/drm/mgag200/mgag200_ttm.c | 5 +++--
drivers/gpu/drm/nouveau/nouveau_bo.c| 8
drivers/gpu/drm/qxl/qxl_ttm.c | 5 +++--
drivers/gpu/drm/radeon/radeon_ttm.c | 9 +
drivers/gpu/drm/ttm/ttm_agp_backend.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 11 ---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 7 ++-
drivers/gpu/drm/ttm/ttm_page_alloc.c| 13 +
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c| 11 ---
drivers/gpu/drm/ttm/ttm_tt.c| 6 +-
drivers/gpu/drm/virtio/virtgpu_object.c | 6 +-
drivers/gpu/drm/virtio/virtgpu_ttm.c| 5 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 13 +
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 13 +++--
include/drm/ttm/ttm_bo_driver.h | 5 +++--
include/drm/ttm/ttm_page_alloc.h| 11 +++
20 files changed, 92 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index f1b7d98..044f5b5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -990,7 +990,8 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct
ttm_bo_device *bdev,
return >t->ttm.ttm;
}
-static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
+static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
+ struct ttm_operation_ctx *ctx)
{
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
@@ -1018,11 +1019,11 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm)
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
- return ttm_dma_populate(>t->ttm, adev->dev);
+ return ttm_dma_populate(>t->ttm, adev->dev, ctx);
}
#endif
- return ttm_populate_and_map_pages(adev->dev, >t->ttm);
+ return ttm_populate_and_map_pages(adev->dev, >t->ttm, ctx);
}
static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 28da7c2..1413e94 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -216,9 +216,10 @@ static struct ttm_tt *ast_ttm_tt_create(struct
ttm_bo_device *bdev,
return tt;
}
-static int ast_ttm_tt_populate(struct ttm_tt *ttm)
+static int ast_ttm_tt_populate(struct ttm_tt *ttm,
+ struct ttm_operation_ctx *ctx)
{
- return ttm_pool_populate(ttm);
+ return ttm_pool_populate(ttm, ctx);
}
static void ast_ttm_tt_unpopulate(struct ttm_tt *ttm)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 2a5b54d..65ae960 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -216,9 +216,10 @@ static struct ttm_tt *cirrus_ttm_tt_create(struct
ttm_bo_device *bdev,
return tt;
}
-static int cirrus_ttm_tt_populate(struct ttm_tt *ttm)
+static int cirrus_ttm_tt_populate(struct ttm_tt *ttm,
+ struct ttm_operation_ctx *ctx)
{
- return ttm_pool_populate(ttm);
+ return ttm_pool_populate(ttm, ctx);
}
static void cirrus_ttm_tt_unpopulate(struct ttm_tt *ttm)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index ab4ee59..8516e00 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -223,9 +223,10 @@ static struct ttm_tt *hibmc_ttm_tt_create(struct
ttm_bo_device *bdev,
return tt;
}
-static int hibmc_ttm_tt_populate(struct ttm_tt *ttm)
+static int hibmc_ttm_tt_populate(struct ttm_tt *ttm,
+ struct ttm_operation_ctx *ctx)
{
- return ttm_pool_populate(ttm);
+ return ttm_pool_populate(ttm, ctx);
}
static void hibmc_ttm_tt_unpopulate(struct ttm_tt *ttm)
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index f03da63..6fa8076 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -216,9 +216,10 @@ static struct ttm_tt *mgag200_ttm_tt_create(struct
ttm_bo_device *bdev,
return tt;
}
-static int mgag200_ttm_tt_populate(struct ttm_tt *ttm)
+static int mgag200_ttm_tt_populate(struct ttm_tt *ttm,
+ struct ttm_operation_ctx *ctx)
{
- return ttm_pool_populate(ttm);
+ return ttm_pool_popu
[PATCH 3/5] drm/ttm: use an operation ctx for ttm_tt_bind
forward the operation context to ttm_tt_bind as well,
and the ultimate goal is swapout enablement for per vm BOs.
Change-Id: I42a7df8c50e1ce3b527ee9cb78809f8e58136f07
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c| 9 +++--
include/drm/ttm/ttm_bo_driver.h | 3 ++-
7 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 044f5b5..e4bb435 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -497,7 +497,7 @@ static int amdgpu_move_vram_ram(struct ttm_buffer_object
*bo, bool evict,
goto out_cleanup;
}
- r = ttm_tt_bind(bo->ttm, &tmp_mem);
+ r = ttm_tt_bind(bo->ttm, &tmp_mem, ctx);
if (unlikely(r)) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index b141c27..a83ba6a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1218,7 +1218,7 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool
evict, bool intr,
if (ret)
return ret;
- ret = ttm_tt_bind(bo->ttm, &tmp_reg);
+ ret = ttm_tt_bind(bo->ttm, &tmp_reg, &ctx);
if (ret)
goto out;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 9424b81..2b74ba1b 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -339,7 +339,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object
*bo,
goto out_cleanup;
}
- r = ttm_tt_bind(bo->ttm, &tmp_mem);
+ r = ttm_tt_bind(bo->ttm, &tmp_mem, &ctx);
if (unlikely(r)) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c59f572..e7595b4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -300,7 +300,7 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
goto out_err;
if (mem->mem_type != TTM_PL_SYSTEM) {
- ret = ttm_tt_bind(bo->ttm, mem);
+ ret = ttm_tt_bind(bo->ttm, mem, ctx);
if (ret)
goto out_err;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index b7eb507..153de1b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -73,7 +73,7 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
return ret;
if (new_mem->mem_type != TTM_PL_SYSTEM) {
- ret = ttm_tt_bind(ttm, new_mem);
+ ret = ttm_tt_bind(ttm, new_mem, ctx);
if (unlikely(ret != 0))
return ret;
}
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index b48d7a0..5a046a3 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -261,12 +261,9 @@ void ttm_tt_unbind(struct ttm_tt *ttm)
}
}
-int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg *bo_mem)
+int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg *bo_mem,
+ struct ttm_operation_ctx *ctx)
{
- struct ttm_operation_ctx ctx = {
- .interruptible = false,
- .no_wait_gpu = false
- };
int ret = 0;
if (!ttm)
@@ -275,7 +272,7 @@ int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg
*bo_mem)
if (ttm->state == tt_bound)
return 0;
- ret = ttm->bdev->driver->ttm_tt_populate(ttm, &ctx);
+ ret = ttm->bdev->driver->ttm_tt_populate(ttm, ctx);
if (ret)
return ret;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 84860ec..94064b1 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -650,7 +650,8 @@ void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma);
*
* Bind the pages of @ttm to an aperture location identified by @bo_mem
*/
-int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg *bo_mem);
+int ttm_tt_bind(struct ttm_tt *ttm, struct ttm_mem_reg *bo_mem,
+ struct ttm_operation_ctx *ctx);
/**
* ttm_ttm_destroy:
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/ttm: add new function to check if bo is allowable to evict or swapout
extract a function as ttm_bo_evict_swapout_allowable since eviction and
swapout can share same logic
Change-Id: I80a475a93fceed8d66d74a1832c815a0756341ac
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e7595b4..313925c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -706,6 +706,23 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_eviction_valuable);
+static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
+ struct ttm_operation_ctx *ctx, bool *locked)
+{
+ bool ret = false;
+
+ *locked = false;
+ if (bo->resv == ctx->resv) {
+ if (ctx->allow_reserved_eviction || !list_empty(&bo->ddestroy))
+ ret = true;
+ } else {
+ *locked = reservation_object_trylock(bo->resv);
+ ret = *locked;
+ }
+
+ return ret;
+}
+
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
uint32_t mem_type,
const struct ttm_place *place,
@@ -721,21 +738,13 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
- if (bo->resv == ctx->resv) {
- if (!ctx->allow_reserved_eviction &&
- list_empty(&bo->ddestroy))
- continue;
- } else {
- locked = reservation_object_trylock(bo->resv);
- if (!locked)
- continue;
- }
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked))
+ continue;
if (place && !bdev->driver->eviction_valuable(bo,
place)) {
if (locked)
reservation_object_unlock(bo->resv);
- locked = false;
continue;
}
break;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO
Hi Joe,
On Tue, Dec 19, 2017 at 10:15:08AM -0800, Joe Perches wrote:
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
> b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
> index a1c81c12718c..4338b8a1309f 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
> @@ -158,10 +158,10 @@ static ssize_t dynamic_pool_show(struct device *dev,
> return ret;
> };
>
> -static DEVICE_ATTR(active_bo, 0444, active_bo_show, NULL);
> -static DEVICE_ATTR(free_bo, 0444, free_bo_show, NULL);
> -static DEVICE_ATTR(reserved_pool, 0444, reserved_pool_show, NULL);
> -static DEVICE_ATTR(dynamic_pool, 0444, dynamic_pool_show, NULL);
> +static DEVICE_ATTR_RO(active_bo);
> +static DEVICE_ATTR_RO(free_bo);
> +static DEVICE_ATTR_RO(reserved_pool);
> +static DEVICE_ATTR_RO(dynamic_pool);
>
> static struct attribute *sysfs_attrs_ctrl[] = {
> &dev_attr_active_bo.attr,
I have the exact same changes queued up in my tree. As there seem to be no
dependencies to other patches in your set, how about dropping this chunk?
Thanks.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/ttm: enable swapout of per VM BOs during allocation
if the bo shares same reservation object then not lock it again
at swapout time to make it possible to swap out.
Change-Id: I1e87954564f38ad298bf6e4ff88c9f26f291a62d
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 15 +++
drivers/gpu/drm/ttm/ttm_memory.c | 12
include/drm/ttm/ttm_bo_api.h | 3 ++-
3 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 313925c..ecb8916 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1686,18 +1686,20 @@ EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
* A buffer object shrink method that tries to swap out the first
* buffer object on the bo_global::swap_lru list.
*/
-int ttm_bo_swapout(struct ttm_bo_global *glob)
+int ttm_bo_swapout(struct ttm_bo_global *glob, struct ttm_operation_ctx *ctx)
{
struct ttm_buffer_object *bo;
int ret = -EBUSY;
+ bool locked;
unsigned i;
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &glob->swap_lru[i], swap) {
- ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
- if (!ret)
+ if (ttm_bo_evict_swapout_allowable(bo, ctx, &locked)) {
+ ret = 0;
break;
+ }
}
if (!ret)
break;
@@ -1773,7 +1775,12 @@ EXPORT_SYMBOL(ttm_bo_swapout);
void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
{
- while (ttm_bo_swapout(bdev->glob) == 0)
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
+
+ while (ttm_bo_swapout(bdev->glob, &ctx) == 0)
;
}
EXPORT_SYMBOL(ttm_bo_swapout_all);
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 102b326..aa0c381 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -211,7 +211,7 @@ static bool ttm_zones_above_swap_target(struct
ttm_mem_global *glob,
*/
static void ttm_shrink(struct ttm_mem_global *glob, bool from_wq,
- uint64_t extra)
+ uint64_t extra, struct ttm_operation_ctx *ctx)
{
int ret;
@@ -219,7 +219,7 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool
from_wq,
while (ttm_zones_above_swap_target(glob, from_wq, extra)) {
spin_unlock(&glob->lock);
- ret = ttm_bo_swapout(glob->bo_glob);
+ ret = ttm_bo_swapout(glob->bo_glob, ctx);
spin_lock(&glob->lock);
if (unlikely(ret != 0))
break;
@@ -230,10 +230,14 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool
from_wq,
static void ttm_shrink_work(struct work_struct *work)
{
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
struct ttm_mem_global *glob =
container_of(work, struct ttm_mem_global, work);
- ttm_shrink(glob, true, 0ULL);
+ ttm_shrink(glob, true, 0ULL, &ctx);
}
static int ttm_mem_init_kernel_zone(struct ttm_mem_global *glob,
@@ -520,7 +524,7 @@ static int ttm_mem_global_alloc_zone(struct ttm_mem_global
*glob,
return -ENOMEM;
if (unlikely(count-- == 0))
return -ENOMEM;
- ttm_shrink(glob, false, memory + (memory >> 2) + 16);
+ ttm_shrink(glob, false, memory + (memory >> 2) + 16, ctx);
}
return 0;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 24a8db7..f1c74c2 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -752,7 +752,8 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file
*filp,
const char __user *wbuf, char __user *rbuf,
size_t count, loff_t *f_pos, bool write);
-int ttm_bo_swapout(struct ttm_bo_global *glob);
+int ttm_bo_swapout(struct ttm_bo_global *glob,
+ struct ttm_operation_ctx *ctx);
void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
#endif
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 00/13] Kernel based bootsplash
On Wed, Dec 13, 2017 at 08:47:42PM +0100, Max Staudt wrote: > Dear fbdev and fbcon developers, > > Thank you very much for your input for the first patch series. > > I've included your feedback into this second roll, and kindly ask for > your opinion on the new patch series. > > > Changes from v1 to v2: > > + Added a user space tool to create splash theme files > + Bumped the file format version: > - Larger structs for easy future expansion > - 2-byte corner offset > - Offset either from corner or from center > - Fixed padding before header->frame_ms > + Moved bootsplash_file.h to uapi/linux > + Merged several patches > + Theme files are now loaded via request_firmware() > + sysfs hook to allow loading of theme files via request_firmware() > + Dropped the .enable cmdline option and the default file name. >The splash will be shown as soon as a file is specified. > + Dropped custom workqueue in favor of the kernel queue >and cancel_delayed_work_sync() > + Marked loaded data as const, and load/enable it atomically > + Reduced global state by moving data into other structures > + EXPORT_SYMBOL_GPL for fbcon_set_dummyops() > + Atomic and barrier for splash enabled state instead of spinlock > + Reduced warnings to infos > + Rate limited printk > + Changed the multi-line comment layout to kernel style > + Simplified the file headers > + reST-ed the documentation Ok, here's my expectation: - fix plymouth and driver loading If the plymouth maintainer tells me that's impossible, I'll look at this again. And no, this does not require killing drivers with SIGBUS, at least not with drm. Meanwhile I don't think this RFC makes sense to be merged. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 1/3] drm/msm/mdp5: Add global state as a private atomic object
On Thu, Dec 21, 2017 at 11:44:23AM +0530, Archit Taneja wrote:
> Global shared resources (hwpipes, hwmixers and SMP) for MDP5 are
> implemented as a part of atomic state by subclassing drm_atomic_state.
>
> The preferred approach is to use the drm_private_obj infrastructure
> available in the atomic core.
>
> mdp5_global_state is introduced as a drm atomic private object. The two
> funcs mdp5_get_global_state() and mdp5_get_existing_global_state() are
> the two variants that will be used to access mdp5_global_state.
>
> This will replace the existing mdp5_state struct (which subclasses
> drm_atomic_state) and the funcs around it. These will be removed later
> once we mdp5_global_state is put to use everywhere.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 86
> +
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 27 +++
> 2 files changed, 113 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index f7c0698fec40..dfc4d81124d5 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -106,6 +106,86 @@ static void mdp5_swap_state(struct msm_kms *kms, struct
> drm_atomic_state *state)
> swap(to_kms_state(state)->state, mdp5_kms->state);
> }
>
> +/* Global/shared object state funcs */
> +
> +/*
> + * This is a helper that returns the private state currently in operation.
> + * Note that this would return the "old_state" if called in the atomic check
> + * path, and the "new_state" after the atomic swap has been done.
> + */
> +struct mdp5_global_state *
> +mdp5_get_existing_global_state(struct mdp5_kms *mdp5_kms)
> +{
> + return to_mdp5_global_state(mdp5_kms->glob_base.state);
This doesn't match the existing state stuff for everything else. Here you
look at the global state, but not at the one hanging off drm_atomic_state.
Maybe we should add a drm_atomic_get_existing_private_obj_state function
to make this easier?
I'm also not 100% sure on what semantics you want precisely.
> +}
> +
> +/*
> + * This acquires the modeset lock set aside for global state, creates
> + * a new duplicated private object state.
> + */
> +struct mdp5_global_state *mdp5_get_global_state(struct drm_atomic_state *s)
> +{
> + struct msm_drm_private *priv = s->dev->dev_private;
> + struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
> + struct drm_private_state *priv_state;
> + int ret;
> +
> + ret = drm_modeset_lock(&mdp5_kms->glob_state_lock, s->acquire_ctx);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + priv_state = drm_atomic_get_private_obj_state(s, &mdp5_kms->glob_base);
> + if (IS_ERR(priv_state))
> + return ERR_CAST(priv_state);
> +
> + return to_mdp5_global_state(priv_state);
> +}
> +
> +static struct drm_private_state *
> +mdp5_global_duplicate_state(struct drm_private_obj *obj)
> +{
> + struct mdp5_global_state *state;
> +
> + state = kmemdup(obj->state, sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return NULL;
> +
> + __drm_atomic_helper_private_obj_duplicate_state(obj, &state->base);
> +
> + return &state->base;
> +}
> +
> +static void mdp5_global_destroy_state(struct drm_private_obj *obj,
> + struct drm_private_state *state)
> +{
> + struct mdp5_global_state *mdp5_state = to_mdp5_global_state(state);
> +
> + kfree(mdp5_state);
> +}
> +
> +static const struct drm_private_state_funcs mdp5_global_state_funcs = {
> + .atomic_duplicate_state = mdp5_global_duplicate_state,
> + .atomic_destroy_state = mdp5_global_destroy_state,
> +};
> +
> +static int mdp5_global_obj_init(struct mdp5_kms *mdp5_kms)
> +{
> + struct mdp5_global_state *state;
> +
> + state = kzalloc(sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return -ENOMEM;
> +
> + drm_modeset_lock_init(&mdp5_kms->glob_state_lock);
I thought a bit the last few days about how to integrate modeset locking
into driver private state objects. I think the simplest solution would be
if we just add a drm_modeset_lock to drm_private_obj, and push the locking
(both here and in the mst helper) into the core private obj code.
Per-object locking might be a bit overkill (it's definitely overkill for
mst), but it's also easier to avoid special cases.
That would reduce the boilerplate here a bit more, essentially converting
the wrappers into type casting functions.
-Daniel
> +
> + state->mdp5_kms = mdp5_kms;
> +
> + drm_atomic_private_obj_init(&mdp5_kms->glob_base,
> + &state->base,
> + &mdp5_global_state_funcs);
> + return 0;
> +}
> +
> static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state
> *state)
> {
> struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
> @@ -727,6 +807,8 @@ static
[PATCH 1/5] drm/ttm: use an operation ctx for ttm_mem_global_alloc_page
forward the operation context to ttm_mem_global_alloc_page as well,
and the ultimate goal is swapout enablement for per vm BOs.
Per vm BOs refer to all BOs which share same reservation object.
Change-Id: I4104a12e09a374b6477a0dd5a8fce26dce27a746
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 10 +++---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 ++--
include/drm/ttm/ttm_memory.h | 3 ++-
4 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 525d3b6..102b326 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -539,14 +539,10 @@ int ttm_mem_global_alloc(struct ttm_mem_global *glob,
uint64_t memory,
EXPORT_SYMBOL(ttm_mem_global_alloc);
int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
- struct page *page, uint64_t size)
+ struct page *page, uint64_t size,
+ struct ttm_operation_ctx *ctx)
{
-
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
@@ -560,7 +556,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, &ctx);
+ return ttm_mem_global_alloc_zone(glob, zone, size, ctx);
}
void ttm_mem_global_free_page(struct ttm_mem_global *glob, struct page *page,
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba644..8f93ff3 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1061,6 +1061,10 @@ void ttm_page_alloc_fini(void)
int ttm_pool_populate(struct ttm_tt *ttm)
{
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
unsigned i;
int ret;
@@ -1076,7 +1080,7 @@ int ttm_pool_populate(struct ttm_tt *ttm)
for (i = 0; i < ttm->num_pages; ++i) {
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
- PAGE_SIZE);
+ PAGE_SIZE, &ctx);
if (unlikely(ret != 0)) {
ttm_pool_unpopulate(ttm);
return -ENOMEM;
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index bda00b2..8aac86a 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -927,6 +927,10 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
{
struct ttm_tt *ttm = &ttm_dma->ttm;
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
unsigned long num_pages = ttm->num_pages;
struct dma_pool *pool;
enum pool_type type;
@@ -962,7 +966,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
break;
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
- pool->size);
+ pool->size, &ctx);
if (unlikely(ret != 0)) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
@@ -998,7 +1002,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
}
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
- pool->size);
+ pool->size, &ctx);
if (unlikely(ret != 0)) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 755c107..8936285 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -84,7 +84,8 @@ extern int ttm_mem_global_alloc(struct ttm_mem_global *glob,
uint64_t memory,
extern void ttm_mem_global_free(struct ttm_mem_global *glob,
uint64_t amount);
extern int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
-struct page *page, uint64_t size);
+struct page *page, uint64_t size,
+struct ttm_operation_ctx *ctx
Re: [PATCH 3/3] drm/i915: Disable all planes for load detection, v2.
Op 20-12-17 om 11:28 schreef Daniel Vetter: > On Wed, Dec 20, 2017 at 10:35:45AM +0100, Maarten Lankhorst wrote: >> From: Ville Syrjälä >> >> We don't need any active planes during load detection, so just disable >> them all. This saves us from having to come up with a suitable >> framebuffer. And we also avoid leaving sprite/cursor planes on and >> potentially presenting them at a peculiar location during the load >> detection. >> >> Changes since v1 (Maarten): >> - Add missing call to add_all_affected_planes. >> >> Signed-off-by: Ville Syrjälä >> Signed-off-by: Maarten Lankhorst >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102707 > Less code, I like. And I think we have enough load-detect machines (+ plus > the nasty igt to do it anywhere we still have native vga) to have > reasonable ensurance it actually works. > > But maybe let's soak this in -next first for a while, then cherry-pick > over after a few weeks once it's solid. > > With the missing Fixes: line added. > > Reviewed-by: Daniel Vetter Pushed, didn't add fixes since it's an ancient bug, for a piece of code that changed a lot. Since in most cases the fbcon fb will be leaked, the impact is just a warning and not even a real leak. :) Thanks for review, ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/ttm: use an operation ctx for ttm_mem_global_alloc_page
Am 21.12.2017 um 10:42 schrieb Roger He:
forward the operation context to ttm_mem_global_alloc_page as well,
and the ultimate goal is swapout enablement for per vm BOs.
As Thomas commented as well, better write "reserved BOs" in the commit
message.
The term "per vm BOs" is something completely amdgpu specific.
With that fixed the patch is Reviewed-by: Christian König
.
Regards,
Christian.
Per vm BOs refer to all BOs which share same reservation object.
Change-Id: I4104a12e09a374b6477a0dd5a8fce26dce27a746
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 10 +++---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 ++--
include/drm/ttm/ttm_memory.h | 3 ++-
4 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 525d3b6..102b326 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -539,14 +539,10 @@ int ttm_mem_global_alloc(struct ttm_mem_global *glob,
uint64_t memory,
EXPORT_SYMBOL(ttm_mem_global_alloc);
int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
- struct page *page, uint64_t size)
+ struct page *page, uint64_t size,
+ struct ttm_operation_ctx *ctx)
{
-
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
@@ -560,7 +556,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, &ctx);
+ return ttm_mem_global_alloc_zone(glob, zone, size, ctx);
}
void ttm_mem_global_free_page(struct ttm_mem_global *glob, struct page *page,
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index b5ba644..8f93ff3 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1061,6 +1061,10 @@ void ttm_page_alloc_fini(void)
int ttm_pool_populate(struct ttm_tt *ttm)
{
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
unsigned i;
int ret;
@@ -1076,7 +1080,7 @@ int ttm_pool_populate(struct ttm_tt *ttm)
for (i = 0; i < ttm->num_pages; ++i) {
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
- PAGE_SIZE);
+ PAGE_SIZE, &ctx);
if (unlikely(ret != 0)) {
ttm_pool_unpopulate(ttm);
return -ENOMEM;
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index bda00b2..8aac86a 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -927,6 +927,10 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
{
struct ttm_tt *ttm = &ttm_dma->ttm;
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
unsigned long num_pages = ttm->num_pages;
struct dma_pool *pool;
enum pool_type type;
@@ -962,7 +966,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
break;
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
- pool->size);
+ pool->size, &ctx);
if (unlikely(ret != 0)) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
@@ -998,7 +1002,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
}
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
- pool->size);
+ pool->size, &ctx);
if (unlikely(ret != 0)) {
ttm_dma_unpopulate(ttm_dma, dev);
return -ENOMEM;
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 755c107..8936285 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -84,7 +84,8 @@ extern int ttm_mem_global_alloc(struct ttm_mem_global *glob,
uint64_t memory,
extern void ttm_mem_global_free(struct ttm_mem_global *glob,
uint64_t amount);
ext
Re: [PATCH 1/3] drm/prime: forward begin_cpu_access callback to drivers
On Wed, Dec 20, 2017 at 08:54:33PM +0100, Christian König wrote: > Am 20.12.2017 um 20:43 schrieb Daniel Vetter: > > On Wed, Dec 20, 2017 at 6:20 PM, Li, Samuel wrote: > > > Ping... can someone please review this patch? > > Might be simpler to implement your own dma-buf backend instead of > > going through the drm_prime midlayer. That was mostly written to give > > nvidia a set of non-EXPORT_GPL symbols to support dma-buf. Or > > something like that. > > Ah, that explains that. Well the alternative Sam suggest was to export most > of the functions implementing that. Yeah that sounds like a good idea, makes it feel less midlayer-y. > But then we have a hard time having a common detection logic if a DMA-buf > has a GEM object behind it or not. Hm, why do you need that? I guess you'll care whether it's an amdgpu-exported one, and you can still do that by checking against your own dma_buf_ops table. We do the same in i915, without using the core drm_prime helpers. > > Also don't expect people to look at patches when CI bots spot issues. > > That is either a false positive or a one liner. Hey it's holiday seasons, leave me some cheap excuses pls :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]
On Thu, Dec 21, 2017 at 12:00:39AM +, Carroll, Lewis wrote: > The discussion sounds similar as well - related to load_lut() not being > called. > > Perhaps after the drm-next-4.14 merge, whatever call stack used to cause > load_lut to always get called is now gone. Even if FB_VISUAL_TRUECOLOR > doesn't support a clut, some hardware may still need a default gamma lut > loaded (appears to be the case with the AST2500). Perhaps checking for > that profile and loading the default LUT prepared by > drm_mode_crtc_set_gamma_size when FB_VISUAL_TRUECOLOR...? Yeah drivers should load that somehow. Unfortunately I'm going on vacations now, so I'm not going to fix anything anytime soon. Might be good to ping Peter Rosin, he did all the fbdev emulation gamma handling rework (which is the patch that removed the superflously-looking call to ->load_lut that some drivers relied on to have a consistent lut state). -Daniel > > Lewis > > -Original Message- > From: Wentland, Harry > Sent: Wednesday, December 20, 2017 6:29 PM > To: Carroll, Lewis ; dri-devel@lists.freedesktop.org > Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table > [patch proposed] > > This looks similar to this bug that I spotted while finally going through my > large dri-devel backlog: https://bugzilla.kernel.org/show_bug.cgi?id=198123 > > The discussion continues here > https://lists.freedesktop.org/archives/dri-devel/2017-December/160667.html > > Not sure if this is related but the symptoms sound quite similar. > > Harry > > On 2017-12-17 07:08 PM, Carroll, Lewis wrote: > > Happy Holidays. > > > > > > > > Test-driving Linux 4.14 from the Ubuntu Bionic repo on an AMD EPYC server > > using the A-Speed AST2500 BMC and the AST DRM driver and framebuffer > > console configured into the kernel, I have observed multiple systems where > > the analog VGA color palette for the framebuffer console is incorrect. > > Background is blue and all text colors other than white / gray are > > incorrect. > > > > > > > > Instrumenting the AST DRM driver, it seems the default gamma table isn't > > loaded to the silicon until there is a DPMS action. When there is a DPMS > > action other than DPMS OFF, the gamma table is loaded and all is well. On > > these boards, the kernel is not calling for a DPMS event at driver init so > > the gamma table is not loaded. > > > > > > > > The attached proposed patch adds a DPMS ON event to the commit callback > > after a kernel modeset call. This solves the problem, however there may be > > a better / more proper way to solve this. > > > > > > > > Assuming no one on the mailing list has hardware on which to verify this, I > > am happy to be a test driver for any suggested fixes. > > > > > > > > Regards, > > > > > > > > Lewis Carroll > > > > Principal Solutions Architect > > > > AMD Enterprise Business Group > > > > > > > > > > > > ___ > > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-tip:drm-tip 2/8] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:219:6: error: redefinition of 'dm_dp_mst_dc_sink_create'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: e421f7f2b48c47438cd22d673a2c025562d1f728
commit: d4afdbb09e6b347d3ae084331e8b5d70aa168564 [2/8] Merge remote-tracking
branch 'airlied/drm-next' into drm-tip
config: i386-randconfig-i1-201751 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout d4afdbb09e6b347d3ae084331e8b5d70aa168564
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:219:6:
>> error: redefinition of 'dm_dp_mst_dc_sink_create'
void dm_dp_mst_dc_sink_create(struct drm_connector *connector)
^~~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:183:6:
note: previous definition of 'dm_dp_mst_dc_sink_create' was here
void dm_dp_mst_dc_sink_create(struct drm_connector *connector)
^~~~
vim +/dm_dp_mst_dc_sink_create +219
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c
54427651 Jerry Zuo 2017-09-20 218
becd0875 Jerry (Fangzhi Zuo 2017-12-01 @219) void
dm_dp_mst_dc_sink_create(struct drm_connector *connector)
becd0875 Jerry (Fangzhi Zuo 2017-12-01 220) {
becd0875 Jerry (Fangzhi Zuo 2017-12-01 221) struct amdgpu_dm_connector
*aconnector = to_amdgpu_dm_connector(connector);
becd0875 Jerry (Fangzhi Zuo 2017-12-01 222) struct edid *edid;
becd0875 Jerry (Fangzhi Zuo 2017-12-01 223) struct dc_sink *dc_sink;
becd0875 Jerry (Fangzhi Zuo 2017-12-01 224) struct dc_sink_init_data
init_params = {
becd0875 Jerry (Fangzhi Zuo 2017-12-01 225) .link =
aconnector->dc_link,
becd0875 Jerry (Fangzhi Zuo 2017-12-01 226) .sink_signal =
SIGNAL_TYPE_DISPLAY_PORT_MST };
becd0875 Jerry (Fangzhi Zuo 2017-12-01 227)
becd0875 Jerry (Fangzhi Zuo 2017-12-01 228) edid =
drm_dp_mst_get_edid(connector, &aconnector->mst_port->mst_mgr,
aconnector->port);
becd0875 Jerry (Fangzhi Zuo 2017-12-01 229)
becd0875 Jerry (Fangzhi Zuo 2017-12-01 230) if (!edid) {
becd0875 Jerry (Fangzhi Zuo 2017-12-01 231)
drm_mode_connector_update_edid_property(
becd0875 Jerry (Fangzhi Zuo 2017-12-01 232)
&aconnector->base,
becd0875 Jerry (Fangzhi Zuo 2017-12-01 233) NULL);
becd0875 Jerry (Fangzhi Zuo 2017-12-01 234) return;
becd0875 Jerry (Fangzhi Zuo 2017-12-01 235) }
becd0875 Jerry (Fangzhi Zuo 2017-12-01 236)
becd0875 Jerry (Fangzhi Zuo 2017-12-01 237) aconnector->edid = edid;
becd0875 Jerry (Fangzhi Zuo 2017-12-01 238)
becd0875 Jerry (Fangzhi Zuo 2017-12-01 239) dc_sink =
dc_link_add_remote_sink(
becd0875 Jerry (Fangzhi Zuo 2017-12-01 240) aconnector->dc_link,
becd0875 Jerry (Fangzhi Zuo 2017-12-01 241) (uint8_t
*)aconnector->edid,
becd0875 Jerry (Fangzhi Zuo 2017-12-01 242)
(aconnector->edid->extensions + 1) * EDID_LENGTH,
becd0875 Jerry (Fangzhi Zuo 2017-12-01 243) &init_params);
becd0875 Jerry (Fangzhi Zuo 2017-12-01 244)
becd0875 Jerry (Fangzhi Zuo 2017-12-01 245) dc_sink->priv = aconnector;
becd0875 Jerry (Fangzhi Zuo 2017-12-01 246) aconnector->dc_sink = dc_sink;
becd0875 Jerry (Fangzhi Zuo 2017-12-01 247)
becd0875 Jerry (Fangzhi Zuo 2017-12-01 248)
amdgpu_dm_add_sink_to_freesync_module(
becd0875 Jerry (Fangzhi Zuo 2017-12-01 249) connector,
aconnector->edid);
becd0875 Jerry (Fangzhi Zuo 2017-12-01 250)
becd0875 Jerry (Fangzhi Zuo 2017-12-01 251)
drm_mode_connector_update_edid_property(
becd0875 Jerry (Fangzhi Zuo 2017-12-01 252)
&aconnector->base, aconnector->edid);
becd0875 Jerry (Fangzhi Zuo 2017-12-01 253) }
becd0875 Jerry (Fangzhi Zuo 2017-12-01 254)
:: The code at line 219 was first introduced by commit
:: becd0875f4393a992afbf57aa323f7bf1a71c3ff drm/amd/display: Fix rehook MST
display not light back on
:: TO: Jerry (Fangzhi) Zuo
:: CC: Alex Deucher
---
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
Re: [PATCH v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight
Den 11.12.2017 18.56, skrev Noralf Trønnes:
Den 11.12.2017 18.45, skrev Noralf Trønnes:
Den 11.12.2017 15.58, skrev Meghana Madhyastha:
On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:
Den 11.12.2017 14.17, skrev Meghana Madhyastha:
On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:
Den 21.10.2017 13.55, skrev Meghana Madhyastha:
Changes in v14:
- s/backlight_get/of_find_backlight/ in patch 2/3
- Change commit message in patch 3/3 from requiring to acquiring
Meghana Madhyastha (3):
drm/tinydrm: Move helper functions from tinydrm-helpers to
backlight.h
drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
drm/tinydrm: Add devres versions of of_find_backlight
I tried the patchset and this is what I got:
[ 8.057792] Unable to handle kernel paging request at virtual
address
fe6b
[ 9.144181] ---[ end trace 149c05934b6a6dcc ]---
Is the reason possibly because we have omitted error checking on the
return value of backlight_enable function ?
tinydrm_enable_backlight and
tinydrm_disable_baclight do this.
Eg.
ret = backlight_update_status(backlight);
if (ret)
DRM_ERROR("Failed to enable backlight %d\n", ret);
I'm not sure, just asking whether this could be a possible reason
for the above trace.
The crash happens during probe.
I guess you'll figure this out when you get some hw to test on.
I have set up the raspberry pi and have built and boot into the
custom kernel
but I am waiting for the panel to arrive. Meanwhile, any thoughts on
error message ? Sorry for the trivial question, but I did not quite
understand the crash message and how to replicate it.
of_find_backlight() can return an error pointer (-EPROBE_DEFER):
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 4bb7bf3ee443..57370c5d51f0 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -635,8 +635,8 @@ struct backlight_device
*devm_of_find_backlight(struct device *dev)
int ret;
bd = of_find_backlight(dev);
- if (!bd)
- return NULL;
+ if (IS_ERR_OR_NULL(bd))
+ return bd;
ret = devm_add_action(dev, devm_backlight_put, bd);
if (ret) {
That solved the crash, but the backlight didn't turn on.
I had to do this as well:
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5c441d4c049c..6f9925f10a7c 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -139,6 +139,8 @@ static inline int backlight_enable(struct
backlight_device *bd)
if (!bd)
return 0;
+ if (!bd->props.brightness)
+ bd->props.brightness = bd->props.max_brightness;
No, this is wrong, it should happen on probe, not every time it's
enabled.
So maybe it should be done in of_find_backlight() or something.
I see that I'm currently doing it in tinydrm_of_find_backlight().
I'm not happy with this brightness hack of mine really.
Since I last looked at this I see that pwm_bl has gained the ability to
start in a power off state (pwm_backlight_initial_power_state()).
However the gpio_backlight driver doesn't do this. gpio_backlight has a
'default-on' property, but the problem is that it sets brightness, not
power state. So the absense of the property sets brightness to zero,
which makes the driver turn off backlight on probe. This seems to be
fine, but then systemd-backlight comes along and restores brightness
to 1, since that's what it was on shutdown. This turns on backlight and
now I have a glaring white uninitialized panel waiting for the display
driver to set it up.
This patch would solve my problem:
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index e470da95d806..54bb722e1ea3 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -142,7 +142,8 @@ static int gpio_backlight_probe(struct
platform_device *pdev)
return PTR_ERR(bl);
}
- bl->props.brightness = gbl->def_value;
+ bl->props.brightness = 1;
+ bl->props.state = gbl->def_value ? 0 : BL_CORE_FBBLANK;
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
The problem is that this will most likely break 2 in-kernel users of
gpio-backlight which doesn't set the 'default-on' property:
arch/arm/boot/dts/omap4-var-dvk-om44.dts
arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
AFAICT they rely on systemd-backlight to turn on backlight by setting
brightness to 1.
So maybe my hack is _the_ soulution after all, but I'm no expert on
the backlight subsystem and it's corner cases.
Noralf.
bd->props.power = FB_BLANK_UNBLANK;
bd->props.state &= ~BL_CORE_FBBLANK;
This is my backlight node[1]:
backlight: backlight {
compatible = "gpio-backlight";
gpios = <&gpio 18 0>; // GPIO_ACTIVE_HIGH
};
Not certain that this is the "correct" solu
[PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property
The power-supply property is used by a vast majority of panels, including panel-simple. Let's document it as a common property Reviewed-by: Rob Herring Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++ Documentation/devicetree/bindings/display/panel/panel-lvds.txt | 1 + Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +- 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt b/Documentation/devicetree/bindings/display/panel/panel-common.txt index ec52c472c845..125ea68052af 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt @@ -78,6 +78,12 @@ used for panels that implement compatible control signals. while active. Active high reset signals can be supported by inverting the GPIO specifier polarity flag. +Power +- + +- power-supply: many display panels need an additional power supply in + order to be fully powered-up. For such panels, power-supply contains + a phandle to the regulator powering the panel. Backlight - diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt index b938269f841e..250850a2150b 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt @@ -32,6 +32,7 @@ Optional properties: - label: See panel-common.txt. - gpios: See panel-common.txt. - backlight: See panel-common.txt. +- power-supply: See panel-common.txt. - data-mirror: If set, reverse the bit order described in the data mappings below on all data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6. diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt index 1341bbf4aa3d..16d8ff088b7d 100644 --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt @@ -1,7 +1,7 @@ Simple display panel Required properties: -- power-supply: regulator to provide the supply voltage +- power-supply: See panel-common.txt Optional properties: - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 11/12] ARM: dts: sun8i: a83t: Add LVDS pins group
The A83T has an LVDS bus that can be connected to a panel or a bridge. Add
the pinctrl group for it.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index ae34d22d6d47..a37517d4472a 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -415,6 +415,12 @@
#interrupt-cells = <3>;
#gpio-cells = <3>;
+ lcd_lvds_pins: lcd-lvds-pins {
+ pins = "PD18", "PD19", "PD20", "PD21", "PD22",
+ "PD23", "PD24", "PD25", "PD26", "PD27";
+ function = "lvds0";
+ };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2",
"PF3", "PF4", "PF5";
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 04/12] dt-bindings: display: sun4i-drm: Add A83T pipeline
The A83T has two video pipelines in parallel that looks quite similar to the other SoCs. The video planes are handled through a controller called the mixer, and the video signal is then passed to the timing controller (TCON). And while there is two instances of the mixers and TCONs, they have a significant number of differences. The TCONs are quite easy to deal with, one is supposed to generate TV (in the broader term, so including things like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs call them TCON-TV and TCON-LCD, which seems more appropriate. However, the mixers differ mostly by their capabilities, with some features being available only in the first one, or the number of planes they expose, but also through their register layout. And while the capabilities could be represented as properties, the register layout differences would need to express all the registers offsets as properties, which is usually quite bad. Especially since documentation on that hardware block is close to non-existant and we don't even have the list of all those registers in the first place. So let's call them mixer 0 and 1 in our compatibles, even though the name is pretty bad... At the moment, we only have tested the code on a board that has a single display output, so we're leaving the tcon-tv and mixer1 out. Reviewed-by: Rob Herring Reviewed-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 1e21cfaac9e2..9f073af4c711 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -93,6 +93,7 @@ Required properties: * allwinner,sun6i-a31s-tcon * allwinner,sun7i-a20-tcon * allwinner,sun8i-a33-tcon + * allwinner,sun8i-a83t-tcon-lcd * allwinner,sun8i-v3s-tcon - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP @@ -225,6 +226,7 @@ supported. Required properties: - compatible: value must be one of: +* allwinner,sun8i-a83t-de2-mixer-0 * allwinner,sun8i-v3s-de2-mixer - reg: base address and size of the memory-mapped region. - clocks: phandles to the clocks feeding the mixer @@ -254,6 +256,7 @@ Required properties: * allwinner,sun6i-a31s-display-engine * allwinner,sun7i-a20-display-engine * allwinner,sun8i-a33-display-engine +* allwinner,sun8i-a83t-display-engine * allwinner,sun8i-v3s-display-engine - allwinner,pipelines: list of phandle to the display engine -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 09/12] ARM: dts: sun8i: a83t: Add display pipeline
The display pipeline on the A83T is mainly composed of the mixers and
TCONs, plus various encoders.
Let's add the first mixer and TCON to the DTSI since the only board I have
can use only the LVDS output on the first TCON. The other parts will be
added eventually.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 79 -
1 file changed, 79 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 19acae1b4089..e4db38c717d9 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -45,8 +45,10 @@
#include
#include
+#include
#include
#include
+#include
#include
/ {
@@ -151,6 +153,12 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-a83t-display-engine";
+ allwinner,pipelines = <&mixer0>;
+ status = "disabled";
+ };
+
memory {
reg = <0x4000 0x8000>;
device_type = "memory";
@@ -162,6 +170,44 @@
#size-cells = <1>;
ranges;
+ display_clocks: clock@100 {
+ compatible = "allwinner,sun8i-a83t-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_PLL_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ mixer0: mixer@110 {
+ compatible = "allwinner,sun8i-a83t-de2-mixer-0";
+ reg = <0x0110 0x10>;
+ clocks = <&display_clocks CLK_BUS_MIXER0>,
+<&display_clocks CLK_MIXER0>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_MIXER0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer0_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon0_in_mixer0>;
+ };
+ };
+ };
+ };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-a83t-system-controller",
"syscon";
@@ -177,6 +223,39 @@
#dma-cells = <1>;
};
+ tcon0: lcd-controller@1c0c000 {
+ compatible = "allwinner,sun8i-a83t-tcon-lcd";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
+ clock-names = "ahb", "tcon-ch0";
+ clock-output-names = "tcon-pixel-clock";
+ resets = <&ccu RST_BUS_TCON0>, <&ccu RST_BUS_LVDS>;
+ reset-names = "lcd", "lvds";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_mixer0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun8i-a83t-mmc",
"allwinner,sun7i-a20-mmc";
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 03/12] dt-bindings: display: sun4i-drm: Add LVDS properties
Some clocks and resets supposed to drive the LVDS logic in the display engine have been overlooked when the driver was first introduced. Add those additional resources to the binding, and we'll deal with the ABI stability in the code. Reviewed-by: Chen-Yu Tsai Reviewed-by: Rob Herring Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 9 +++- 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 50cc72ee1168..1e21cfaac9e2 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -121,6 +121,15 @@ Required properties: On SoCs other than the A33 and V3s, there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1 +On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you +need one more reset line: + - 'lvds': The reset line driving the LVDS logic + +And on the SoCs newer than the A31 (sun6i and sun8i families), you +need one more clock line: + - 'lvds-alt': An alternative clock source, separate from the TCON channel 0 + clock, that can be used to drive the LVDS clock + DRC --- -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 00/12] drm/sun4i: Add A83t LVDS support
Hi, Here is an attempt at supporting the LVDS output in our DRM driver. This has been tested on the A83T (with DE2), but since everything is basically in the TCON, it should also be usable on the older SoCs with minor modifications. This was the occasion to refactor a bunch of things. The most notable ones would be the documentation, and split of the UI layers in the mixer code, and the switch to kfifo for our endpoint parsing code in the driver that fixes an issue introduced by the switch to BFS. Let me know what you think, Maxime Changes from v4: - Changed the order of the clk_prepare_enable and clk_set_rate for the mixer module clock - Squash the two DT PWM patches - Removed the output pins muxing - Changed the flag to tell if you have an LVDS alternate clock to has_lvds_alt - Used SPDX headers Changes from v3: - Collect the tags - Use SPDX headers when possible - Added the new mixer configuration options - Changed the LVDS clock for lvds-alt instead of lvds-pll - Removed the MIPI PLL from the A31s - Changed the LVDS_ANA0 macros name to reflect the generation they were introduced in, and added a comment to mention the changes needed to support the older SoCs Changes from v2: - Move the module clock rate to the mixer structure - Adjusted the simple-panel documentation for power-supply - Changed the compatible for the first A83t mixer to mixer 0 - Rebased on top of current drm-misc - Split out the A83t bindings in its separate patch Changes from v1: - Added a fix for the error path handling in the TCON - Enable the TCON by default - Removed the patch that changes the channels offset but kept most of the modifications as a cleanup - Deal with the LVDS clock being able to have another PLL parent on some SoCs - Renamed the TCON compatible to TCON-TV, following the convention used on newer SoCs - Removed the hardcoded timings - Moved LVDS enable quirks to a separate function - Used clock indices define in the DT - Removed the hardcoded clock rate in the DT and moved it to the driver - Changed sun8i_mixer_planes to sun8i_mixer_ui_planes to be consistent - Added the various tags collected - Rebased on top of 4.15 Maxime Ripard (12): dt-bindings: panel: lvds: Document power-supply property drm/panel: lvds: Add support for the power-supply property dt-bindings: display: sun4i-drm: Add LVDS properties dt-bindings: display: sun4i-drm: Add A83T pipeline drm/sun4i: Force the mixer rate at 150MHz drm/sun4i: Create minimal multipliers and dividers drm/sun4i: Add LVDS support drm/sun4i: Add A83T support ARM: dts: sun8i: a83t: Add display pipeline ARM: dts: sun8i: a83t: Enable the PWM ARM: dts: sun8i: a83t: Add LVDS pins group ARM: dts: sun8i: a711: Enable the LCD Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++- Documentation/devicetree/bindings/display/panel/panel-lvds.txt | 1 +- Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt| 12 - arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts| 61 ++- arch/arm/boot/dts/sun8i-a83t.dtsi| 99 +- drivers/gpu/drm/panel/panel-lvds.c | 23 +++- drivers/gpu/drm/sun4i/Makefile | 1 +- drivers/gpu/drm/sun4i/sun4i_dotclock.c | 10 ++- drivers/gpu/drm/sun4i/sun4i_drv.c| 1 +- drivers/gpu/drm/sun4i/sun4i_lvds.c | 177 - drivers/gpu/drm/sun4i/sun4i_lvds.h | 12 - drivers/gpu/drm/sun4i/sun4i_tcon.c | 244 +++- drivers/gpu/drm/sun4i/sun4i_tcon.h | 31 +- drivers/gpu/drm/sun4i/sun8i_mixer.c | 21 ++- drivers/gpu/drm/sun4i/sun8i_mixer.h | 3 +- 16 files changed, 699 insertions(+), 5 deletions(-) create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h base-commit: 99239c7ba0214ec99011378a6ca1bcd589c3dc98 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 02/12] drm/panel: lvds: Add support for the power-supply property
A significant number of panels need to power up a regulator in order to
operate properly. Add support for the power-supply property to enable and
disable such a regulator whenever needed.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/panel/panel-lvds.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-lvds.c
b/drivers/gpu/drm/panel/panel-lvds.c
index e2d57c01200b..57e38a9e7ab4 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -39,6 +40,7 @@ struct panel_lvds {
bool data_mirror;
struct backlight_device *backlight;
+ struct regulator *supply;
struct gpio_desc *enable_gpio;
struct gpio_desc *reset_gpio;
@@ -69,6 +71,9 @@ static int panel_lvds_unprepare(struct drm_panel *panel)
if (lvds->enable_gpio)
gpiod_set_value_cansleep(lvds->enable_gpio, 0);
+ if (lvds->supply)
+ regulator_disable(lvds->supply);
+
return 0;
}
@@ -76,6 +81,17 @@ static int panel_lvds_prepare(struct drm_panel *panel)
{
struct panel_lvds *lvds = to_panel_lvds(panel);
+ if (lvds->supply) {
+ int err;
+
+ err = regulator_enable(lvds->supply);
+ if (err < 0) {
+ dev_err(lvds->dev, "failed to enable supply: %d\n",
+ err);
+ return err;
+ }
+ }
+
if (lvds->enable_gpio)
gpiod_set_value_cansleep(lvds->enable_gpio, 1);
@@ -196,6 +212,13 @@ static int panel_lvds_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
+ lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
+ if (IS_ERR(lvds->supply)) {
+ ret = PTR_ERR(lvds->supply);
+ dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
+ return ret;
+ }
+
/* Get GPIOs and backlight controller. */
lvds->enable_gpio = devm_gpiod_get_optional(lvds->dev, "enable",
GPIOD_OUT_LOW);
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 05/12] drm/sun4i: Force the mixer rate at 150MHz
It seems like the mixer can only run properly when clocked at 150MHz. In
order to have something more robust than simply a fire-and-forget
assigned-clocks-rate, let's put that in the code.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 10 ++
drivers/gpu/drm/sun4i/sun8i_mixer.h | 3 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 29ceeb016d72..3a610a87cbd2 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -398,6 +398,15 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
ret = PTR_ERR(mixer->mod_clk);
goto err_disable_bus_clk;
}
+
+ /*
+* It seems that we need to enforce that rate for whatever
+* reason for the mixer to be functional. Make sure it's the
+* case.
+*/
+ if (mixer->cfg->mod_rate)
+ clk_set_rate(mixer->mod_clk, mixer->cfg->mod_rate);
+
clk_prepare_enable(mixer->mod_clk);
list_add_tail(&mixer->engine.list, &drv->engine_list);
@@ -474,6 +483,7 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.ui_num = 1,
.scaler_mask = 0x3,
.ccsc = 0,
+ .mod_rate = 15000,
};
static const struct of_device_id sun8i_mixer_of_table[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index bc58040a88f9..f34e70c42adf 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -121,12 +121,15 @@ struct de2_fmt_info {
* Set value to 0 if this is first mixer or second mixer with VEP support.
* Set value to 1 if this is second mixer without VEP support. Other values
* are invalid.
+ * @mod_rate: module clock rate that needs to be set in order to have
+ * a functional block.
*/
struct sun8i_mixer_cfg {
int vi_num;
int ui_num;
int scaler_mask;
int ccsc;
+ unsigned long mod_rate;
};
struct sun8i_mixer {
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 08/12] drm/sun4i: Add A83T support
Add support for the A83T display pipeline.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +
drivers/gpu/drm/sun4i/sun8i_mixer.c | 11 +++
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 49215d91c853..6f5e721b545e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -347,6 +347,7 @@ static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun7i-a20-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
+ { .compatible = "allwinner,sun8i-a83t-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ }
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 33b1a493fc0a..b78fed809992 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1133,6 +1133,10 @@ static const struct sun4i_tcon_quirks sun8i_a33_quirks =
{
.has_lvds_alt = true,
};
+static const struct sun4i_tcon_quirks sun8i_a83t_lcd_quirks = {
+ /* nothing is supported */
+};
+
static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
/* nothing is supported */
};
@@ -1145,6 +1149,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun6i-a31s-tcon", .data = &sun6i_a31s_quirks
},
{ .compatible = "allwinner,sun7i-a20-tcon", .data = &sun7i_a20_quirks },
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
+ { .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data =
&sun8i_a83t_lcd_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks },
{ }
};
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 3a610a87cbd2..2cbb2de6d39c 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -478,6 +478,13 @@ static int sun8i_mixer_remove(struct platform_device *pdev)
return 0;
}
+static const struct sun8i_mixer_cfg sun8i_a83t_mixer0_cfg = {
+ .ccsc = 0,
+ .scaler_mask= 0xf,
+ .ui_num = 3,
+ .vi_num = 1,
+};
+
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -488,6 +495,10 @@ static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
static const struct of_device_id sun8i_mixer_of_table[] = {
{
+ .compatible = "allwinner,sun8i-a83t-de2-mixer-0",
+ .data = &sun8i_a83t_mixer0_cfg,
+ },
+ {
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
},
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 07/12] drm/sun4i: Add LVDS support
The TCON supports the LVDS interface to output to a panel or a bridge.
Let's add support for it.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Makefile | 1 +-
drivers/gpu/drm/sun4i/sun4i_lvds.c | 177 ++-
drivers/gpu/drm/sun4i/sun4i_lvds.h | 12 ++-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 239 +-
drivers/gpu/drm/sun4i/sun4i_tcon.h | 29 -
5 files changed, 456 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 82a6ac57fbe3..2b37a6abbb1d 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -15,6 +15,7 @@ sun8i-mixer-y += sun8i_mixer.o
sun8i_ui_layer.o \
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_dotclock.o
+sun4i-tcon-y += sun4i_lvds.o
sun4i-tcon-y += sun4i_tcon.o
sun4i-tcon-y += sun4i_rgb.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
new file mode 100644
index ..be3f14d7746d
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2017 Free Electrons
+ * Maxime Ripard
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "sun4i_crtc.h"
+#include "sun4i_tcon.h"
+#include "sun4i_lvds.h"
+
+struct sun4i_lvds {
+ struct drm_connectorconnector;
+ struct drm_encoder encoder;
+
+ struct sun4i_tcon *tcon;
+};
+
+static inline struct sun4i_lvds *
+drm_connector_to_sun4i_lvds(struct drm_connector *connector)
+{
+ return container_of(connector, struct sun4i_lvds,
+ connector);
+}
+
+static inline struct sun4i_lvds *
+drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
+{
+ return container_of(encoder, struct sun4i_lvds,
+ encoder);
+}
+
+static int sun4i_lvds_get_modes(struct drm_connector *connector)
+{
+ struct sun4i_lvds *lvds =
+ drm_connector_to_sun4i_lvds(connector);
+ struct sun4i_tcon *tcon = lvds->tcon;
+
+ return drm_panel_get_modes(tcon->panel);
+}
+
+static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
+ .get_modes = sun4i_lvds_get_modes,
+};
+
+static void
+sun4i_lvds_connector_destroy(struct drm_connector *connector)
+{
+ struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
+ struct sun4i_tcon *tcon = lvds->tcon;
+
+ drm_panel_detach(tcon->panel);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs sun4i_lvds_con_funcs = {
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy= sun4i_lvds_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
+{
+ struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
+ struct sun4i_tcon *tcon = lvds->tcon;
+
+ DRM_DEBUG_DRIVER("Enabling LVDS output\n");
+
+ if (!IS_ERR(tcon->panel)) {
+ drm_panel_prepare(tcon->panel);
+ drm_panel_enable(tcon->panel);
+ }
+}
+
+static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
+{
+ struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
+ struct sun4i_tcon *tcon = lvds->tcon;
+
+ DRM_DEBUG_DRIVER("Disabling LVDS output\n");
+
+ if (!IS_ERR(tcon->panel)) {
+ drm_panel_disable(tcon->panel);
+ drm_panel_unprepare(tcon->panel);
+ }
+}
+
+static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
+ .disable= sun4i_lvds_encoder_disable,
+ .enable = sun4i_lvds_encoder_enable,
+};
+
+static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
+ .destroy= drm_encoder_cleanup,
+};
+
+int sun4i_lvds_init(struct drm_device *drm, struct sun4i_tcon *tcon)
+{
+ struct drm_encoder *encoder;
+ struct drm_bridge *bridge;
+ struct sun4i_lvds *lvds;
+ int ret;
+
+ lvds = devm_kzalloc(drm->dev, sizeof(*lvds), GFP_KERNEL);
+ if (!lvds)
+ return -ENOMEM;
+ lvds->tcon = tcon;
+ encoder = &lvds->encoder;
+
+ ret = drm_of_find_panel_or_bridge(tcon->dev->of_node, 1, 0,
+ &tcon->panel, &bridge);
+ if (ret) {
+ dev_info(drm->dev, "No panel or bridge found... LVDS output
disabled\n");
+ return 0;
+ }
+
[PATCH v5 06/12] drm/sun4i: Create minimal multipliers and dividers
The various outputs the TCON can provide have different constraints on the
dotclock divider. Let's make them configurable by the various mode_set
functions.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_dotclock.c | 10 +++---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 ++
drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
index d401156490f3..023f39bda633 100644
--- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
+++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
@@ -17,8 +17,9 @@
#include "sun4i_dotclock.h"
struct sun4i_dclk {
- struct clk_hw hw;
- struct regmap *regmap;
+ struct clk_hw hw;
+ struct regmap *regmap;
+ struct sun4i_tcon *tcon;
};
static inline struct sun4i_dclk *hw_to_dclk(struct clk_hw *hw)
@@ -73,11 +74,13 @@ static unsigned long sun4i_dclk_recalc_rate(struct clk_hw
*hw,
static long sun4i_dclk_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate)
{
+ struct sun4i_dclk *dclk = hw_to_dclk(hw);
+ struct sun4i_tcon *tcon = dclk->tcon;
unsigned long best_parent = 0;
u8 best_div = 1;
int i;
- for (i = 6; i <= 127; i++) {
+ for (i = tcon->dclk_min_div; i <= tcon->dclk_max_div; i++) {
unsigned long ideal = rate * i;
unsigned long rounded;
@@ -167,6 +170,7 @@ int sun4i_dclk_create(struct device *dev, struct sun4i_tcon
*tcon)
dclk = devm_kzalloc(dev, sizeof(*dclk), GFP_KERNEL);
if (!dclk)
return -ENOMEM;
+ dclk->tcon = tcon;
init.name = clk_name;
init.ops = &sun4i_dclk_ops;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index ea056a3d2131..46e28ca1f676 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -177,6 +177,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
u8 clk_delay;
u32 val = 0;
+ tcon->dclk_min_div = 6;
+ tcon->dclk_max_div = 127;
sun4i_tcon0_mode_set_common(tcon, mode);
/* Adjust clock delay */
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 839266a38505..bd3ad7684870 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -169,6 +169,8 @@ struct sun4i_tcon {
/* Pixel clock */
struct clk *dclk;
+ u8 dclk_max_div;
+ u8 dclk_min_div;
/* Reset control */
struct reset_control*lcd_rst;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 12/12] ARM: dts: sun8i: a711: Enable the LCD
The A711 has 1024x600 LVDS panel, with a PWM-based backlight. Add it to our
DT.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 61 -
1 file changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index a021ee6da396..511fca491fe8 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -45,6 +45,7 @@
#include "sun8i-a83t.dtsi"
#include
+#include
/ {
model = "TBS A711 Tablet";
@@ -59,6 +60,44 @@
stdout-path = "serial0:115200n8";
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ enable-gpios = <&pio 3 29 GPIO_ACTIVE_HIGH>;
+
+ brightness-levels = <0 1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <9>;
+ };
+
+ panel {
+ compatible = "tbs,a711-panel", "panel-lvds";
+ backlight = <&backlight>;
+ power-supply = <®_sw>;
+
+ width-mm = <153>;
+ height-mm = <90>;
+ data-mapping = "vesa-24";
+
+ panel-timing {
+ /* 1024x600 @60Hz */
+ clock-frequency = <5200>;
+ hactive = <1024>;
+ vactive = <600>;
+ hsync-len = <20>;
+ hfront-porch = <180>;
+ hback-porch = <160>;
+ vfront-porch = <12>;
+ vback-porch = <23>;
+ vsync-len = <5>;
+ };
+
+ port {
+ panel_input: endpoint {
+ remote-endpoint = <&tcon0_out_lcd>;
+ };
+ };
+ };
+
reg_vbat: reg-vbat {
compatible = "regulator-fixed";
regulator-name = "vbat";
@@ -89,6 +128,10 @@
};
};
+&de {
+ status = "okay";
+};
+
/*
* An USB-2 hub is connected here, which also means we don't need to
* enable the OHCI controller.
@@ -142,6 +185,12 @@
status = "okay";
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_pin>;
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
@@ -323,6 +372,18 @@
regulator-name = "vcc-lcd";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_lvds_pins>;
+};
+
+&tcon0_out {
+ tcon0_out_lcd: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 10/12] ARM: dts: sun8i: a83t: Enable the PWM
The A83T has the same PWM block than the H3. Add it to our DT.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index e4db38c717d9..ae34d22d6d47 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -440,6 +440,11 @@
bias-pull-up;
};
+ pwm_pin: pwm-pin {
+ pins = "PD28";
+ function = "pwm";
+ };
+
spdif_tx_pin: spdif-tx-pin {
pins = "PE18";
function = "spdif";
@@ -497,6 +502,15 @@
status = "disabled";
};
+ pwm: pwm@1c21400 {
+ compatible = "allwinner,sun8i-a83t-pwm",
+"allwinner,sun8i-h3-pwm";
+ reg = <0x01c21400 0x400>;
+ clocks = <&osc24M>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
uart0: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane
Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
Signed-off-by: Lukasz Spintzyk
---
drivers/gpu/drm/drm_atomic.c | 10 ++
drivers/gpu/drm/drm_mode_config.c | 6 ++
drivers/gpu/drm/drm_plane.c | 1 +
include/drm/drm_mode_config.h | 5 +
include/drm/drm_plane.h | 3 +++
5 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b76d49218cf1..cd3b4ed7b04c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+ } else if (property == config->dirty_rects_property) {
+ bool replaced = false;
+ int ret = drm_atomic_replace_property_blob_from_id(dev,
+ &state->dirty_blob,
+ val,
+ -1,
+ &replaced);
+ return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+ } else if (property == config->dirty_rects_property) {
+ *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index bc5c46306b3d..d5f1021c6ece 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -293,6 +293,12 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_crtc_id = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "DIRTY_RECTS", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.dirty_rects_property = prop;
+
prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
"ACTIVE");
if (!prop)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 37a93cdffb4a..add110f025e5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device *dev, struct
drm_plane *plane,
drm_object_attach_property(&plane->base, config->prop_src_y, 0);
drm_object_attach_property(&plane->base, config->prop_src_w, 0);
drm_object_attach_property(&plane->base, config->prop_src_h, 0);
+ drm_object_attach_property(&plane->base,
config->dirty_rects_property, 0);
}
if (config->allow_fb_modifiers)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index e5f3b43014e1..65f64eb04c0c 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -599,6 +599,11 @@ struct drm_mode_config {
* &drm_crtc.
*/
struct drm_property *prop_crtc_id;
+ /**
+* @dirty_rects_property: Optional plane property to mark damaged
+* regions on the plane framebuffer.
+*/
+ struct drm_property *dirty_rects_property;
/**
* @prop_active: Default atomic CRTC property to control the active
* state, which is the simplified implementation for DPMS in atomic
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 8185e3468a23..7d45b164ccce 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -131,6 +131,9 @@ struct drm_plane_state {
*/
struct drm_crtc_commit *commit;
+ /* Optional blob property with damaged regions. */
+ struct drm_property_blob *dirty_blob;
+
struct drm_atomic_state *state;
};
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/1] Damage rectangles interface for DRM
This is a draft of damage interface for drm. Alluding to the topic "RFC: page-flip with damage?" on dri-devel https://lists.freedesktop.org/archives/dri-devel/2017-September/153235.html The following patch is a proof of concept, how we can deliver dirty rectangles to the drm drivers. Patch was tested on Chromium OS to deliver damage regions to atomic version of evdi driver. Hence this supports atomic drivers for now. We should agree on the approach how this can be implemented. In the patch, I intend to use drm blob properties to pass c-style array of drm_clip_rects. Is DRM properties framework suitable for this solution? The only doubt I have is that it requires to create and destroy property blob every atomic_commit/page flip as this is the only way to update blob with damage regions. This is associated with kmalloc and free for each flip. Do you think if this approach relates to some performance risk? The proposed solution is attaching DIRTY_RECTS property to the drm_plane. The property means to hold list of rectangles in plane coordinates. This is opposite to initial plan in thread from September 2017. I wanted to present our rationale for this. Single rect vs rect list: Some compositors like Chromium can have quite precise damage information that would be lost if we would collapse them. Damage rectangles on crtc vs per plane The property is attached to drm plane initially. We had a talk with guys from Chromium compositor. The plan is to use overlay planes more extensively. Also, Chromium compositor operates on dirty rects per plane so it would be easier to use them as is. In my opinion this is more natural to deliver information about damage per plane. Damage information is used primarily for bandwidth savings. For driver that deliver plane data it is more useful to know what parts of the plane have changed so it can send only these memory areas. I don't know if this reasoning is valid. Probably it depends on hardware and driver. I can speak about use cases I have faced. One of them is additional cursor plane. With damage regions on crtc I don't know if it is related to primary plane, or it is connected to cursor movement. Also, user space applications must generate additional damage regions when such cursor plane is moving over primary plane. For such cases passing dirty rectangles for planes seems to be more straightforward. This is draft with minimal functionality. I would like to hear what is your opinion on it. I am happy to hear what are the requirements of other driver vendors. Thanks Lukasz Spintzyk Lukasz Spintzyk (1): drm: Add dirty_rects atomic blob property for drm_plane drivers/gpu/drm/drm_atomic.c | 10 ++ drivers/gpu/drm/drm_mode_config.c | 6 ++ drivers/gpu/drm/drm_plane.c | 1 + include/drm/drm_mode_config.h | 5 + include/drm/drm_plane.h | 3 +++ 5 files changed, 25 insertions(+) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Signed-off-by missing for commits in the drm tree
Hi,
On 21/12/17 07:12, Stephen Rothwell wrote:
Hi all,
Commits
bb5cdf8d1c76 ("drm: omapdrm: Remove filename from header and fix copyright
tag")
d66c36a3ee79 ("drm: omapdrm: Simplify platform registration")
are missing a Signed-off-by from their committer.
Sorry about that, I missed those.
I think I need to create a script to verify my pull requests for things
like this...
Tomi
--
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 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos
Make sure that the primary plane will get normalized_zpos=0 if it's zpos is set to 0, avoiding other planes to be placed in the background. If user space wants to move the primary plane forward, it can set the zpos of the plane. Signed-off-by: Peter Ujfalusi --- drivers/gpu/drm/drm_blend.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index 4c62dff14893..bdc4f714afb8 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -301,7 +301,11 @@ static int drm_atomic_state_zpos_cmp(const void *a, const void *b) const struct drm_plane_state *sa = *(struct drm_plane_state **)a; const struct drm_plane_state *sb = *(struct drm_plane_state **)b; - if (sa->zpos != sb->zpos) + if (sa->plane == sa->crtc->primary && sa->zpos == 0) + return -1; + else if (sb->plane == sb->crtc->primary && sb->zpos == 0) + return 1; + else if (sa->zpos != sb->zpos) return sa->zpos - sb->zpos; else return sa->plane->base.id - sb->plane->base.id; -- 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 0/2] drm blend/omap: normalized zpos handling
Hi, The following two patch will change the omapdrm to use the normalized_zpos when configuring the zpos/zorder of the planes. In OMAP it is possible to move planes between crtcs freely and it is possible to move even the primary plane from one crtc to another, where it should not be treated as primary anymore (the crtc's primary plane is the primary for the crtc). The first patch will adjust the sorting of the planes for the given crtc to make sure that the crtc's primary plane, if it has zpos=0 is going to be the bottom plane. If the zpos of the primary plane is changed by user space then we obey this and don't force the bottom position. Regards, Peter --- Peter Ujfalusi (2): drm/blend: Account also the primary plane of the crtc for normalized_zpos drm/omap: Normalize the zpos and use the normalized_zpos in runtime drivers/gpu/drm/drm_blend.c | 6 +- drivers/gpu/drm/omapdrm/omap_drv.c | 26 +- drivers/gpu/drm/omapdrm/omap_plane.c | 2 +- 3 files changed, 31 insertions(+), 3 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 2/2] drm/omap: Normalize the zpos and use the normalized_zpos in runtime
To avoid zpos collision, use the normalized_zpos when configuring the
zorder of the plane.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 26 +-
drivers/gpu/drm/omapdrm/omap_plane.c | 2 +-
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 6bfc2d9ebb46..230df6d8edd1 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include
@@ -54,6 +55,29 @@ MODULE_PARM_DESC(displays,
* devices
*/
+int omap_atomic_helper_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;
+
+ if (state->legacy_cursor_update)
+ state->async_update = !drm_atomic_helper_async_check(dev,
state);
+
+ return ret;
+}
+
static void omap_atomic_wait_for_completion(struct drm_device *dev,
struct drm_atomic_state *old_state)
{
@@ -133,7 +157,7 @@ static const struct drm_mode_config_helper_funcs
omap_mode_config_helper_funcs =
static const struct drm_mode_config_funcs omap_mode_config_funcs = {
.fb_create = omap_framebuffer_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
- .atomic_check = drm_atomic_helper_check,
+ .atomic_check = omap_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index bbbdd560e503..abd78b511e6d 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
[Bug 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games
https://bugs.freedesktop.org/show_bug.cgi?id=104289 --- Comment #5 from Vedran Miletić --- (In reply to Christian König from comment #4) > You can restrict that to changes to drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c. > > The problem is that we use more dw than expected for clearing the page > tables. No idea what exactly goes wrong, but bisecting the commit which > introduced it would certainly help. I'm sorry, but I will not be able to bisect this. Checkouts of relevant commits don't boot and simple reverts do apply cleanly, but don't compile. -- 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 104319] AMDGPU/DC: Internal display corrupted when connecting (mirroring/extending) an external monitor on HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=104319 --- Comment #3 from Daniel Drake --- Need to do more testing to be sure, but it appears that this is not reproducible on the development branch https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next -- 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 104281] black / corrupted screen when resuming from S3 [AMDGPU]
https://bugs.freedesktop.org/show_bug.cgi?id=104281 --- Comment #3 from Daniel Drake --- Need to do more testing to be sure, but it appears that this is not reproducible on the development branch https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next -- 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 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games
https://bugs.freedesktop.org/show_bug.cgi?id=104289 --- Comment #6 from Christian König --- Created attachment 136340 --> https://bugs.freedesktop.org/attachment.cgi?id=136340&action=edit Possible fix Complete shot into the dark, but while double checking the code I've found that at least this calculation isn't correct. -- 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: [Intel-gfx] [PATCH v2 6/8] drm/i915: Use an atomic_t array to track power domain use count.
Hey,
Op 19-12-17 om 06:26 schreef Dhinakaran Pandiyan:
> Convert the power_domains->domain_use_count array that tracks per-domain
> use count to atomic_t type. This is needed to be able to read/write the use
> counts outside of the power domain mutex.
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +--
> 3 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1a7b28f62570..1f1d9162f2c2 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2764,7 +2764,7 @@ static int i915_power_domain_info(struct seq_file *m,
> void *unused)
> for_each_power_domain(power_domain, power_well->domains)
> seq_printf(m, " %-23s %d\n",
>intel_display_power_domain_str(power_domain),
> - power_domains->domain_use_count[power_domain]);
> +
> atomic_read(&power_domains->domain_use_count[power_domain]));
> }
>
> mutex_unlock(&power_domains->lock);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1e4e613e7b41..ddadeb9eaf49 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1489,7 +1489,7 @@ struct i915_power_domains {
> int power_well_count;
>
> struct mutex lock;
> - int domain_use_count[POWER_DOMAIN_NUM];
> + atomic_t domain_use_count[POWER_DOMAIN_NUM];
> struct i915_power_well *power_wells;
> };
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 96ab74f3d101..992caec1fbc4 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1453,7 +1453,7 @@ __intel_display_power_get_domain(struct
> drm_i915_private *dev_priv,
> for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain))
> intel_power_well_get(dev_priv, power_well);
>
> - power_domains->domain_use_count[domain]++;
> + atomic_inc(&power_domains->domain_use_count[domain]);
> }
>
> /**
> @@ -1539,10 +1539,9 @@ void intel_display_power_put(struct drm_i915_private
> *dev_priv,
>
> mutex_lock(&power_domains->lock);
>
> - WARN(!power_domains->domain_use_count[domain],
> - "Use count on domain %s is already zero\n",
> + WARN(atomic_dec_return(&power_domains->domain_use_count[domain]) < 0,
> + "Use count on domain %s was already zero\n",
>intel_display_power_domain_str(domain));
> - power_domains->domain_use_count[domain]--;
>
> for_each_power_domain_well_rev(dev_priv, power_well, BIT_ULL(domain))
> intel_power_well_put(dev_priv, power_well);
> @@ -3049,7 +3048,7 @@ static void intel_power_domains_dump_info(struct
> drm_i915_private *dev_priv)
> for_each_power_domain(domain, power_well->domains)
> DRM_DEBUG_DRIVER(" %-23s %d\n",
>intel_display_power_domain_str(domain),
> -
> power_domains->domain_use_count[domain]);
> +
> atomic_read(&power_domains->domain_use_count[domain]));
> }
> }
>
> @@ -3092,7 +3091,7 @@ void intel_power_domains_verify_state(struct
> drm_i915_private *dev_priv)
>
> domains_count = 0;
> for_each_power_domain(domain, power_well->domains)
> - domains_count +=
> power_domains->domain_use_count[domain];
> + domains_count +=
> atomic_read(&power_domains->domain_use_count[domain]);
>
> if (power_well->count != domains_count) {
> DRM_ERROR("power well %s refcount/domain refcount
> mismatch "
I can imagine this will start failing really badly. The previous code assumed
that
everything is protected by power_domains->lock, and now this changes makes it no
longer the case..
I see the rest of the code changes things even more, but it would be better if
the
locking rework was done in a single patch, and not bolted on..
And instead of using atomic_t, there is a refcount implementation in refcount.h,
it could be used here for locking power wells only if it would drop to zero..
Cheers,
Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane
On Thu, Dec 21, 2017 at 12:10:08PM +0100, Lukasz Spintzyk wrote:
> Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
> Signed-off-by: Lukasz Spintzyk
> ---
> drivers/gpu/drm/drm_atomic.c | 10 ++
> drivers/gpu/drm/drm_mode_config.c | 6 ++
> drivers/gpu/drm/drm_plane.c | 1 +
> include/drm/drm_mode_config.h | 5 +
> include/drm/drm_plane.h | 3 +++
> 5 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index b76d49218cf1..cd3b4ed7b04c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> state->rotation = val;
> } else if (property == plane->zpos_property) {
> state->zpos = val;
> + } else if (property == config->dirty_rects_property) {
> + bool replaced = false;
> + int ret = drm_atomic_replace_property_blob_from_id(dev,
> + &state->dirty_blob,
> + val,
> + -1,
> + &replaced);
> + return ret;
> } else if (plane->funcs->atomic_set_property) {
> return plane->funcs->atomic_set_property(plane, state,
> property, val);
> @@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> *val = state->zpos;
> + } else if (property == config->dirty_rects_property) {
> + *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane, state,
> property, val);
> } else {
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index bc5c46306b3d..d5f1021c6ece 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -293,6 +293,12 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.prop_crtc_id = prop;
>
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> + "DIRTY_RECTS", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.dirty_rects_property = prop;
> +
> prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
> "ACTIVE");
> if (!prop)
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 37a93cdffb4a..add110f025e5 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> drm_object_attach_property(&plane->base, config->prop_src_y, 0);
> drm_object_attach_property(&plane->base, config->prop_src_w, 0);
> drm_object_attach_property(&plane->base, config->prop_src_h, 0);
> + drm_object_attach_property(&plane->base,
> config->dirty_rects_property, 0);
> }
>
> if (config->allow_fb_modifiers)
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index e5f3b43014e1..65f64eb04c0c 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -599,6 +599,11 @@ struct drm_mode_config {
>* &drm_crtc.
>*/
> struct drm_property *prop_crtc_id;
> + /**
> + * @dirty_rects_property: Optional plane property to mark damaged
> + * regions on the plane framebuffer.
What exactly would the blob contain?
The comment seems to be implying these are in fb coordiantes as
opposed to plane crtc coordinates? Not sure which would be more
convenient. At least if they're fb coordinates then you probably
want some helpers to translate/rotate/scale those rects to the
crtc coordinates. Actual use depends on the driver/hw I suppose.
> + */
> + struct drm_property *dirty_rects_property;
> /**
>* @prop_active: Default atomic CRTC property to control the active
>* state, which is the simplified implementation for DPMS in atomic
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 8185e3468a23..7d45b164ccce 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -131,6 +131,9 @@ struct drm_plane_state {
>*/
> struct drm_crtc_commit *commit;
>
> + /* Optional blob property with damaged regions. */
> + struct drm_property_blob *dirty_blob;
> +
> struct drm_atomic_state *state;
> };
>
> --
> 2.15.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri
Re: [PATCH] drm/sun4i: hdmi: Fix sun4i_tmds_determine_rate
Hi,
On Thu, Dec 21, 2017 at 10:24:11PM +1100, Jonathan Liu wrote:
> There are several issues in sun4i_tmds_determine_rate:
> - doesn't check if the best match was already set before comparing it
> with the enumerated parameters which could result in integer divide
> by zero
> - doesn't consider rate halving when determining closest match if it
> can't match the requested rate exactly
> - sets best_div to i which corresponds to rate halving when it should be
> set to j which corresponds to the divider
>
> Fix these issues.
>
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> Signed-off-by: Jonathan Liu
Please make separate patches for each of these issues, if possible
detailing how do you reproduce them.
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 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos
On Thu, Dec 21, 2017 at 02:11:00PM +0200, Peter Ujfalusi wrote: > Make sure that the primary plane will get normalized_zpos=0 if it's zpos is > set to 0, avoiding other planes to be placed in the background. Can you describe the actual "bad" configuration? Without knowing the details this looks like it's making things more complicated for no particularly good reason. If you're worried about clients that don't set zpos, then I think you should just assign the default zpos values better and/or allocate the planes in a better order. But it's definitely possible I'm missing the reason why you're doing this. > > If user space wants to move the primary plane forward, it can set the zpos > of the plane. > > Signed-off-by: Peter Ujfalusi > --- > drivers/gpu/drm/drm_blend.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > index 4c62dff14893..bdc4f714afb8 100644 > --- a/drivers/gpu/drm/drm_blend.c > +++ b/drivers/gpu/drm/drm_blend.c > @@ -301,7 +301,11 @@ static int drm_atomic_state_zpos_cmp(const void *a, > const void *b) > const struct drm_plane_state *sa = *(struct drm_plane_state **)a; > const struct drm_plane_state *sb = *(struct drm_plane_state **)b; > > - if (sa->zpos != sb->zpos) > + if (sa->plane == sa->crtc->primary && sa->zpos == 0) > + return -1; > + else if (sb->plane == sb->crtc->primary && sb->zpos == 0) > + return 1; > + else if (sa->zpos != sb->zpos) > return sa->zpos - sb->zpos; > else > return sa->plane->base.id - sb->plane->base.id; > -- > 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 -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave, drm-misc-fixes-2017-12-21: drm-misc-fixes before holidays: - fixup for the lease fixup (Keith) - fb leak in the ww mutex fallback code (Maarten) - sun4i fixes (Maxime, Hans) I'll be away for two weeks, but I think Sean and Gustavo are somewhat around-ish. But there's also not really much going on anyway. Cheers, Daniel The following changes since commit bd36d3bab2e3d08f80766c86487090dbceed4651: drm/drm_lease: Prevent deadlock in case drm_lease_create() fails (2017-12-14 08:25:37 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2017-12-21 for you to fetch changes up to d2a48e52541cdf474ef35d51e8d73ded5be33122: drm: move lease init after validation in drm_lease_create (2017-12-21 09:49:40 +0100) drm-misc-fixes before holidays: - fixup for the lease fixup (Keith) - fb leak in the ww mutex fallback code (Maarten) - sun4i fixes (Maxime, Hans) Hans Verkuil (1): drm/sun4i: validate modes for HDMI Keith Packard (1): drm: move lease init after validation in drm_lease_create Maarten Lankhorst (1): drm/plane: Make framebuffer refcounting the responsibility of setplane_internal callers Maxime Ripard (2): drm/sun4i: Fix error path handling drm/sun4i: hdmi: Move the mode_valid callback to the encoder drivers/gpu/drm/drm_lease.c| 22 +- drivers/gpu/drm/drm_plane.c| 42 -- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 20 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++-- 4 files changed, 53 insertions(+), 35 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight
On Thu, Dec 21, 2017 at 11:52:43AM +0100, Noralf Trønnes wrote:
>
> Den 11.12.2017 18.56, skrev Noralf Trønnes:
> >
> > Den 11.12.2017 18.45, skrev Noralf Trønnes:
> > >
> > > Den 11.12.2017 15.58, skrev Meghana Madhyastha:
> > > > On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:
> > > > > Den 11.12.2017 14.17, skrev Meghana Madhyastha:
> > > > > > On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:
> > > > > > > Den 21.10.2017 13.55, skrev Meghana Madhyastha:
> > > > > > > > Changes in v14:
> > > > > > > > - s/backlight_get/of_find_backlight/ in patch 2/3
> > > > > > > > - Change commit message in patch 3/3 from requiring to acquiring
> > > > > > > >
> > > > > > > > Meghana Madhyastha (3):
> > > > > > > > drm/tinydrm: Move helper functions from
> > > > > > > > tinydrm-helpers to backlight.h
> > > > > > > > drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
> > > > > > > > drm/tinydrm: Add devres versions of of_find_backlight
> > > > > > > I tried the patchset and this is what I got:
> > > > > > >
> > > > > > > [ 8.057792] Unable to handle kernel paging
> > > > > > > request at virtual address
> > > > > > > fe6b
> >
> > > > > > > [ 9.144181] ---[ end trace 149c05934b6a6dcc ]---
> > > > > > Is the reason possibly because we have omitted error checking on the
> > > > > > return value of backlight_enable function ?
> > > > > > tinydrm_enable_backlight and
> > > > > > tinydrm_disable_baclight do this.
> > > > > > Eg.
> > > > > > ret = backlight_update_status(backlight);
> > > > > > if (ret)
> > > > > > DRM_ERROR("Failed to enable backlight %d\n", ret);
> > > > > >
> > > > > > I'm not sure, just asking whether this could be a possible reason
> > > > > > for the above trace.
> > > > > The crash happens during probe.
> > > > > I guess you'll figure this out when you get some hw to test on.
> > > > I have set up the raspberry pi and have built and boot into the
> > > > custom kernel
> > > > but I am waiting for the panel to arrive. Meanwhile, any thoughts on
> > > > error message ? Sorry for the trivial question, but I did not quite
> > > > understand the crash message and how to replicate it.
> > >
> > > of_find_backlight() can return an error pointer (-EPROBE_DEFER):
> > >
> > > diff --git a/drivers/video/backlight/backlight.c
> > > b/drivers/video/backlight/backlight.c
> > > index 4bb7bf3ee443..57370c5d51f0 100644
> > > --- a/drivers/video/backlight/backlight.c
> > > +++ b/drivers/video/backlight/backlight.c
> > > @@ -635,8 +635,8 @@ struct backlight_device
> > > *devm_of_find_backlight(struct device *dev)
> > > int ret;
> > >
> > > bd = of_find_backlight(dev);
> > > - if (!bd)
> > > - return NULL;
> > > + if (IS_ERR_OR_NULL(bd))
> > > + return bd;
> > >
> > > ret = devm_add_action(dev, devm_backlight_put, bd);
> > > if (ret) {
> > >
> > > That solved the crash, but the backlight didn't turn on.
> > > I had to do this as well:
> > >
> > > diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> > > index 5c441d4c049c..6f9925f10a7c 100644
> > > --- a/include/linux/backlight.h
> > > +++ b/include/linux/backlight.h
> > > @@ -139,6 +139,8 @@ static inline int backlight_enable(struct
> > > backlight_device *bd)
> > > if (!bd)
> > > return 0;
> > >
> > > + if (!bd->props.brightness)
> > > + bd->props.brightness = bd->props.max_brightness;
> >
> > No, this is wrong, it should happen on probe, not every time it's
> > enabled.
> > So maybe it should be done in of_find_backlight() or something.
> > I see that I'm currently doing it in tinydrm_of_find_backlight().
> >
>
> I'm not happy with this brightness hack of mine really.
>
> Since I last looked at this I see that pwm_bl has gained the ability to
> start in a power off state (pwm_backlight_initial_power_state()).
> However the gpio_backlight driver doesn't do this. gpio_backlight has a
> 'default-on' property, but the problem is that it sets brightness, not
> power state. So the absense of the property sets brightness to zero,
> which makes the driver turn off backlight on probe. This seems to be
> fine, but then systemd-backlight comes along and restores brightness
> to 1, since that's what it was on shutdown. This turns on backlight and
> now I have a glaring white uninitialized panel waiting for the display
> driver to set it up.
>
> This patch would solve my problem:
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index e470da95d806..54bb722e1ea3 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -142,7 +142,8 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> return PTR_ERR(bl);
> }
>
> - bl->props.brightness = gbl->def_value;
> + bl->props.brightness = 1;
> + bl->props.state = gbl->def
Re: linux-next: Signed-off-by missing for commits in the drm tree
On Thu, Dec 21, 2017 at 01:40:28PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> On 21/12/17 07:12, Stephen Rothwell wrote:
> > Hi all,
> >
> > Commits
> >
> >bb5cdf8d1c76 ("drm: omapdrm: Remove filename from header and fix
> > copyright tag")
> >d66c36a3ee79 ("drm: omapdrm: Simplify platform registration")
> >
> > are missing a Signed-off-by from their committer.
>
> Sorry about that, I missed those.
>
> I think I need to create a script to verify my pull requests for things like
> this...
We have one, but it's tied to the entire group maintainership thing ...
But omap is defacto group-maintained between you and Laurent already, so
might be worth to check out.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane
On Thu, Dec 21, 2017 at 02:46:55PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 21, 2017 at 12:10:08PM +0100, Lukasz Spintzyk wrote:
> > Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
> > Signed-off-by: Lukasz Spintzyk
> > ---
> > drivers/gpu/drm/drm_atomic.c | 10 ++
> > drivers/gpu/drm/drm_mode_config.c | 6 ++
> > drivers/gpu/drm/drm_plane.c | 1 +
> > include/drm/drm_mode_config.h | 5 +
> > include/drm/drm_plane.h | 3 +++
> > 5 files changed, 25 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index b76d49218cf1..cd3b4ed7b04c 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > state->rotation = val;
> > } else if (property == plane->zpos_property) {
> > state->zpos = val;
> > + } else if (property == config->dirty_rects_property) {
> > + bool replaced = false;
> > + int ret = drm_atomic_replace_property_blob_from_id(dev,
> > + &state->dirty_blob,
> > + val,
> > + -1,
> > + &replaced);
> > + return ret;
> > } else if (plane->funcs->atomic_set_property) {
> > return plane->funcs->atomic_set_property(plane, state,
> > property, val);
> > @@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > *val = state->rotation;
> > } else if (property == plane->zpos_property) {
> > *val = state->zpos;
> > + } else if (property == config->dirty_rects_property) {
> > + *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0;
> > } else if (plane->funcs->atomic_get_property) {
> > return plane->funcs->atomic_get_property(plane, state,
> > property, val);
> > } else {
> > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > b/drivers/gpu/drm/drm_mode_config.c
> > index bc5c46306b3d..d5f1021c6ece 100644
> > --- a/drivers/gpu/drm/drm_mode_config.c
> > +++ b/drivers/gpu/drm/drm_mode_config.c
> > @@ -293,6 +293,12 @@ static int drm_mode_create_standard_properties(struct
> > drm_device *dev)
> > return -ENOMEM;
> > dev->mode_config.prop_crtc_id = prop;
> >
> > + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> > + "DIRTY_RECTS", 0);
> > + if (!prop)
> > + return -ENOMEM;
> > + dev->mode_config.dirty_rects_property = prop;
> > +
> > prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
> > "ACTIVE");
> > if (!prop)
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 37a93cdffb4a..add110f025e5 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device *dev,
> > struct drm_plane *plane,
> > drm_object_attach_property(&plane->base, config->prop_src_y, 0);
> > drm_object_attach_property(&plane->base, config->prop_src_w, 0);
> > drm_object_attach_property(&plane->base, config->prop_src_h, 0);
> > + drm_object_attach_property(&plane->base,
> > config->dirty_rects_property, 0);
> > }
> >
> > if (config->allow_fb_modifiers)
> > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > index e5f3b43014e1..65f64eb04c0c 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -599,6 +599,11 @@ struct drm_mode_config {
> > * &drm_crtc.
> > */
> > struct drm_property *prop_crtc_id;
> > + /**
> > +* @dirty_rects_property: Optional plane property to mark damaged
> > +* regions on the plane framebuffer.
>
> What exactly would the blob contain?
>
> The comment seems to be implying these are in fb coordiantes as
> opposed to plane crtc coordinates? Not sure which would be more
> convenient. At least if they're fb coordinates then you probably
> want some helpers to translate/rotate/scale those rects to the
> crtc coordinates. Actual use depends on the driver/hw I suppose.
Yeah I think we also should add a decoded state to the drm_plane_state,
which has the full structure and all the details.
And when we discussed this iirc we've identified a clear need for at least
some drivers to deal in crtc dirty rectangles. I think the initial core
support should include a helper which takes an atomic update for a given
crtc, and converts all the plane dirty rectangles into crtc rectangles.
Including any full-plane or full-crtc upgrades needed due to e.g.
reposition, changed gamma, changed blendign/zpos or anything else really
that would affect the entire plane respectively crtc. That would also
provide a really good model for what damage actually m
Re: [PATCH 2/2] drm/omap: Normalize the zpos and use the normalized_zpos in runtime
On Thu, Dec 21, 2017 at 02:11:01PM +0200, Peter Ujfalusi wrote:
> To avoid zpos collision, use the normalized_zpos when configuring the
> zorder of the plane.
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 26 +-
> drivers/gpu/drm/omapdrm/omap_plane.c | 2 +-
> 2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 6bfc2d9ebb46..230df6d8edd1 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -21,6 +21,7 @@
>
> #include
> #include
> +#include
> #include
> #include
>
> @@ -54,6 +55,29 @@ MODULE_PARM_DESC(displays,
> * devices
> */
>
> +int omap_atomic_helper_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;
Maybe we should call this by default from helpers instead of forcing
everyone to reinvent this particular wheel?
exynos and sti have the exact same code as you do here, ans rcar could
also reuse it. That feels like we should just fix up
drm_atomic_helper_check instead of patching all the drivers. And as long
as you never change zpos it shouldn't ever run.
-Daniel
> +
> + ret = drm_atomic_helper_check_planes(dev, state);
> + if (ret)
> + return ret;
> +
> + if (state->legacy_cursor_update)
> + state->async_update = !drm_atomic_helper_async_check(dev,
> state);
> +
> + return ret;
> +}
> +
> static void omap_atomic_wait_for_completion(struct drm_device *dev,
> struct drm_atomic_state *old_state)
> {
> @@ -133,7 +157,7 @@ static const struct drm_mode_config_helper_funcs
> omap_mode_config_helper_funcs =
> static const struct drm_mode_config_funcs omap_mode_config_funcs = {
> .fb_create = omap_framebuffer_create,
> .output_poll_changed = drm_fb_helper_output_poll_changed,
> - .atomic_check = drm_atomic_helper_check,
> + .atomic_check = omap_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
> };
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index bbbdd560e503..abd78b511e6d 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
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight
Den 21.12.2017 14.05, skrev Daniel Vetter:
On Thu, Dec 21, 2017 at 11:52:43AM +0100, Noralf Trønnes wrote:
Den 11.12.2017 18.56, skrev Noralf Trønnes:
Den 11.12.2017 18.45, skrev Noralf Trønnes:
Den 11.12.2017 15.58, skrev Meghana Madhyastha:
On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:
Den 11.12.2017 14.17, skrev Meghana Madhyastha:
On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:
Den 21.10.2017 13.55, skrev Meghana Madhyastha:
Changes in v14:
- s/backlight_get/of_find_backlight/ in patch 2/3
- Change commit message in patch 3/3 from requiring to acquiring
Meghana Madhyastha (3):
drm/tinydrm: Move helper functions from
tinydrm-helpers to backlight.h
drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
drm/tinydrm: Add devres versions of of_find_backlight
I tried the patchset and this is what I got:
[ 8.057792] Unable to handle kernel paging
request at virtual address
fe6b
[ 9.144181] ---[ end trace 149c05934b6a6dcc ]---
Is the reason possibly because we have omitted error checking on the
return value of backlight_enable function ?
tinydrm_enable_backlight and
tinydrm_disable_baclight do this.
Eg.
ret = backlight_update_status(backlight);
if (ret)
DRM_ERROR("Failed to enable backlight %d\n", ret);
I'm not sure, just asking whether this could be a possible reason
for the above trace.
The crash happens during probe.
I guess you'll figure this out when you get some hw to test on.
I have set up the raspberry pi and have built and boot into the
custom kernel
but I am waiting for the panel to arrive. Meanwhile, any thoughts on
error message ? Sorry for the trivial question, but I did not quite
understand the crash message and how to replicate it.
of_find_backlight() can return an error pointer (-EPROBE_DEFER):
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 4bb7bf3ee443..57370c5d51f0 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -635,8 +635,8 @@ struct backlight_device
*devm_of_find_backlight(struct device *dev)
int ret;
bd = of_find_backlight(dev);
- if (!bd)
- return NULL;
+ if (IS_ERR_OR_NULL(bd))
+ return bd;
ret = devm_add_action(dev, devm_backlight_put, bd);
if (ret) {
That solved the crash, but the backlight didn't turn on.
I had to do this as well:
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5c441d4c049c..6f9925f10a7c 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -139,6 +139,8 @@ static inline int backlight_enable(struct
backlight_device *bd)
if (!bd)
return 0;
+ if (!bd->props.brightness)
+ bd->props.brightness = bd->props.max_brightness;
No, this is wrong, it should happen on probe, not every time it's
enabled.
So maybe it should be done in of_find_backlight() or something.
I see that I'm currently doing it in tinydrm_of_find_backlight().
I'm not happy with this brightness hack of mine really.
Since I last looked at this I see that pwm_bl has gained the ability to
start in a power off state (pwm_backlight_initial_power_state()).
However the gpio_backlight driver doesn't do this. gpio_backlight has a
'default-on' property, but the problem is that it sets brightness, not
power state. So the absense of the property sets brightness to zero,
which makes the driver turn off backlight on probe. This seems to be
fine, but then systemd-backlight comes along and restores brightness
to 1, since that's what it was on shutdown. This turns on backlight and
now I have a glaring white uninitialized panel waiting for the display
driver to set it up.
This patch would solve my problem:
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index e470da95d806..54bb722e1ea3 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -142,7 +142,8 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
return PTR_ERR(bl);
}
- bl->props.brightness = gbl->def_value;
+ bl->props.brightness = 1;
+ bl->props.state = gbl->def_value ? 0 : BL_CORE_FBBLANK;
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
The problem is that this will most likely break 2 in-kernel users of
gpio-backlight which doesn't set the 'default-on' property:
arch/arm/boot/dts/omap4-var-dvk-om44.dts
arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
AFAICT they rely on systemd-backlight to turn on backlight by setting
brightness to 1.
So maybe my hack is _the_ soulution after all, but I'm no expert on
the backlight subsystem and it's corner cases.
Can we fix the dts instead?
Isn't Device Tree ABI, ie. new kernels should work backwards with
existing dtb's? We will break that contract if we change gpio_backlight
like
Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos
On 21/12/17 14:55, Ville Syrjälä wrote: On Thu, Dec 21, 2017 at 02:11:00PM +0200, Peter Ujfalusi wrote: Make sure that the primary plane will get normalized_zpos=0 if it's zpos is set to 0, avoiding other planes to be placed in the background. Can you describe the actual "bad" configuration? Without knowing the details this looks like it's making things more complicated for no particularly good reason. If you're worried about clients that don't set zpos, then I think you should just assign the default zpos values better and/or allocate the planes in a better order. But it's definitely possible I'm missing the reason why you're doing this. Let's say we have two displays and two planes. First display will use crtc0 and plane0 as primary plane, the second display crtc1, plane1. The zpos of primary planes will be set to 0 by default. The userspace wants to use the second display, with an overlay plane. So it takes the plane0 and moves it to crtc1. Now the second display has two planes with zpos 0, and normalize_zpos will fix it according to the plane id, i.e. the primary plane of the second display will be on top of the "overlay" plane. I don't think other default zpos values and/or allocating planes in better order can solve this. If the userspace is required to understand and set zpos, then this patch is not needed. But at least in my test scripts I've hit this a few times =). Tomi -- 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
AMD DC test results
Hi, Thanks for the hard work on AMD DC development! Here are some new test results - hope they are interesting/useful. CONTEXT We have been tracking DC for a while as we work with multiple products where amdgpu previously was not able to support the HDMI audio output. We are hoping to ship the new driver as soon as possible to fix this Linux compatibility issue. TEST SETUP With an eye to shipping this ASAP, we backported DC to the current stable release, Linux 4.14. To do this we took the amdgpu/DC commits from: https://cgit.freedesktop.org/~agd5f/linux/log/?h=upstream-4.14-drm-next-amd-dc-staging-chrome And added these two pull requests: https://www.spinics.net/lists/dri-devel/msg156828.html https://lists.freedesktop.org/archives/dri-devel/2017-November/157687.html At this point we diff the resultant amdgpu directories with Linus tree as of commit f6705bf959efac87bca76d40050d342f1d212587 (when he accepted the DC driver) and the diff is zero. This is published on the master branch of https://github.com/endlessm/linux There have been more AMD DC changes merged into Linus tree since then, however we tried and the backporting seems like loads of work, so we have not gone beyond the initial merge into Linus tree for now. We then asked our QA team to run our standard tests with this kernel. They tested 3 platforms: Acer Aspire E5-553G (AMD FX-9800P RADEON R7) Acer Aspire E5-523G (AMD E2-9010 RADEON R2) Acer Aspire A315-21 (AMD A4-9120 RADEON R3) CONFIG_DRM_AMD_DC_PRE_VEGA was set in order to have AMD DC support this hardware. TEST RESULTS HDMI audio works now, however we have encountered some regressions. In all cases the 3 platforms behaved the same (either all 3 pass the individual tests, or all 3 show the same problem). The regressions are: 1. System hangs on S3 resume. Bug can't be reproduced when booting with amdgpu.dc=0 Also reproduced with DC on Linus master (4.15-rc), but appears fixed on agd5f/amd-staging-drm-next https://bugs.freedesktop.org/show_bug.cgi?id=104281 2. Display corruption when using multiple displays Bug can't be reproduced when booting with amdgpu.dc=0 Also reproduced with DC on Linus master (4.15-rc), but appears fixed on agd5f/amd-staging-drm-next https://bugs.freedesktop.org/show_bug.cgi?id=104319 3. HDMI audio device still shown as present and active even after disconnecting HDMI cable Bug can't be reproduced when booting with amdgpu.dc=0 Appears fixed with DC on Linus master (4.15-rc). Full test results spreadsheet (including tests passed): http://goo.gl/oqnMDx Thanks to my colleagues: Carlo Caione for doing the backport and Vanessa Chang for managing the testing. NEXT STEPS Unfortunately we can't ship the driver in current state with these regressions, but on the positive side it looks like it will be in better shape for Linux 4.16. We will now focus on making 4.15 regression-free before revisiting the idea of backporting DC to earlier kernels. After the holiday break we will try to identify the relevant fixes in amd-staging-drm-next and see if they can be included in Linux 4.15. We'll send these backports upstream as soon as we find them. Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games
https://bugs.freedesktop.org/show_bug.cgi?id=104289 --- Comment #7 from Michel Dänzer --- (In reply to Vedran Miletić from comment #5) > I'm sorry, but I will not be able to bisect this. Checkouts of relevant > commits don't boot and simple reverts do apply cleanly, but don't compile. FWIW, you may still be able to at least narrow things down with git bisect. If you can't test a selected commit, run "git bisect skip". That will select another commit to test. You can also manually check out another commit to test. In the worst case, the bisection process will end with identifying the minimal set of candidates instead of a single commit. -- 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] drm/tegra: dc: Implement legacy blending
From: Thierry Reding
This implements alpha blending on legacy display controllers (Tegra20,
Tegra30 and Tegra114). While it's theoretically possible to support the
zpos property to enable userspace to specify the Z-order of each plane
individually, this is not currently supported and the same fixed Z-
order as previously defined is used.
Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
the opaque formats are now supported.
Reported-by: Dmitry Osipenko
Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
Signed-off-by: Thierry Reding
---
Changes in v2:
- properly implement blending if windows have different pixel formats
drivers/gpu/drm/tegra/dc.c| 81 +
drivers/gpu/drm/tegra/dc.h| 12
drivers/gpu/drm/tegra/fb.c| 12
drivers/gpu/drm/tegra/plane.c | 138 ++
drivers/gpu/drm/tegra/plane.h | 8 +++
5 files changed, 226 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 2a0c1e93f82e..4507063029e0 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -154,30 +154,53 @@ static inline u32 compute_initial_dda(unsigned int in)
static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)
{
+ u32 background[3] = {
+ BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) | BLEND_COLOR_KEY_NONE,
+ BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) | BLEND_COLOR_KEY_NONE,
+ BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) | BLEND_COLOR_KEY_NONE,
+ };
+ u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
+BLEND_COLOR_KEY_NONE;
+ u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
+ struct tegra_plane_state *state;
+ unsigned int i;
+
+ state = to_tegra_plane_state(plane->base.state);
+
+ /* alpha contribution is 1 minus sum of overlapping windows */
+ for (i = 0; i < 3; i++) {
+ if (state->dependent[i])
+ background[i] |= BLEND_CONTROL_DEPENDENT;
+ }
+
+ /* enable alpha blending if pixel format has an alpha component */
+ if (!state->opaque)
+ foreground |= BLEND_CONTROL_ALPHA;
+
/*
* Disable blending and assume Window A is the bottom-most window,
* Window C is the top-most window and Window B is in the middle.
*/
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_NOKEY);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_1WIN);
+ tegra_plane_writel(plane, blendnokey, DC_WIN_BLEND_NOKEY);
+ tegra_plane_writel(plane, foreground, DC_WIN_BLEND_1WIN);
switch (plane->index) {
case 0:
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
+ tegra_plane_writel(plane, background[0], DC_WIN_BLEND_2WIN_X);
+ tegra_plane_writel(plane, background[1], DC_WIN_BLEND_2WIN_Y);
+ tegra_plane_writel(plane, background[2], DC_WIN_BLEND_3WIN_XY);
break;
case 1:
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
+ tegra_plane_writel(plane, foreground, DC_WIN_BLEND_2WIN_X);
+ tegra_plane_writel(plane, background[1], DC_WIN_BLEND_2WIN_Y);
+ tegra_plane_writel(plane, background[2], DC_WIN_BLEND_3WIN_XY);
break;
case 2:
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
+ tegra_plane_writel(plane, foreground, DC_WIN_BLEND_2WIN_X);
+ tegra_plane_writel(plane, foreground, DC_WIN_BLEND_2WIN_Y);
+ tegra_plane_writel(plane, foreground, DC_WIN_BLEND_3WIN_XY);
break;
}
}
@@ -353,6 +376,11 @@ static const u32 tegra20_primary_formats[] = {
DRM_FORMAT_RGBA5551,
DRM_FORMAT_ABGR,
DRM_FORMAT_ARGB,
+ /* non-native formats */
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_RGBX5551,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
};
static const u32 tegra114_primary_formats[] = {
@@ -409,18 +437,40 @@ static int tegra_plane_atomic_check(struct drm_plane
*plane,
struct tegra_bo_tiling *tiling = &plane_state->tiling;
struct tegra_plane *tegra = to_tegra_plane(plane);
struct tegra_dc *dc = to_tegra_dc(state->crtc);
+ unsigned int format;
int err;
/* no need for further checks if the plane is being disabled */
Re: [PATCH v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight
On Thu, Dec 21, 2017 at 2:44 PM, Noralf Trønnes wrote:
>
> Den 21.12.2017 14.05, skrev Daniel Vetter:
>>
>> On Thu, Dec 21, 2017 at 11:52:43AM +0100, Noralf Trønnes wrote:
>>>
>>> Den 11.12.2017 18.56, skrev Noralf Trønnes:
Den 11.12.2017 18.45, skrev Noralf Trønnes:
>
> Den 11.12.2017 15.58, skrev Meghana Madhyastha:
>>
>> On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:
>>>
>>> Den 11.12.2017 14.17, skrev Meghana Madhyastha:
On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:
>
> Den 21.10.2017 13.55, skrev Meghana Madhyastha:
>>
>> Changes in v14:
>> - s/backlight_get/of_find_backlight/ in patch 2/3
>> - Change commit message in patch 3/3 from requiring to acquiring
>>
>> Meghana Madhyastha (3):
>> drm/tinydrm: Move helper functions from
>> tinydrm-helpers to backlight.h
>> drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
>> drm/tinydrm: Add devres versions of of_find_backlight
>
> I tried the patchset and this is what I got:
>
> [8.057792] Unable to handle kernel paging
> request at virtual address
> fe6b
>
> [9.144181] ---[ end trace 149c05934b6a6dcc ]---
Is the reason possibly because we have omitted error checking on the
return value of backlight_enable function ?
tinydrm_enable_backlight and
tinydrm_disable_baclight do this.
Eg.
ret = backlight_update_status(backlight);
if (ret)
DRM_ERROR("Failed to enable backlight %d\n", ret);
I'm not sure, just asking whether this could be a possible reason
for the above trace.
>>>
>>> The crash happens during probe.
>>> I guess you'll figure this out when you get some hw to test on.
>>
>> I have set up the raspberry pi and have built and boot into the
>> custom kernel
>> but I am waiting for the panel to arrive. Meanwhile, any thoughts on
>> error message ? Sorry for the trivial question, but I did not quite
>> understand the crash message and how to replicate it.
>
> of_find_backlight() can return an error pointer (-EPROBE_DEFER):
>
> diff --git a/drivers/video/backlight/backlight.c
> b/drivers/video/backlight/backlight.c
> index 4bb7bf3ee443..57370c5d51f0 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -635,8 +635,8 @@ struct backlight_device
> *devm_of_find_backlight(struct device *dev)
> int ret;
>
> bd = of_find_backlight(dev);
> - if (!bd)
> - return NULL;
> + if (IS_ERR_OR_NULL(bd))
> + return bd;
>
> ret = devm_add_action(dev, devm_backlight_put, bd);
> if (ret) {
>
> That solved the crash, but the backlight didn't turn on.
> I had to do this as well:
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 5c441d4c049c..6f9925f10a7c 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -139,6 +139,8 @@ static inline int backlight_enable(struct
> backlight_device *bd)
> if (!bd)
> return 0;
>
> + if (!bd->props.brightness)
> + bd->props.brightness = bd->props.max_brightness;
No, this is wrong, it should happen on probe, not every time it's
enabled.
So maybe it should be done in of_find_backlight() or something.
I see that I'm currently doing it in tinydrm_of_find_backlight().
>>> I'm not happy with this brightness hack of mine really.
>>>
>>> Since I last looked at this I see that pwm_bl has gained the ability to
>>> start in a power off state (pwm_backlight_initial_power_state()).
>>> However the gpio_backlight driver doesn't do this. gpio_backlight has a
>>> 'default-on' property, but the problem is that it sets brightness, not
>>> power state. So the absense of the property sets brightness to zero,
>>> which makes the driver turn off backlight on probe. This seems to be
>>> fine, but then systemd-backlight comes along and restores brightness
>>> to 1, since that's what it was on shutdown. This turns on backlight and
>>> now I have a glaring white uninitialized panel waiting for the display
>>> driver to set it up.
>>>
>>> This patch would solve my problem:
>>>
>>> diff --git a/drivers/video/backlight/gpio_backlight.c
>>> b/drivers/video/backlight/gpio_backlight.c
>>> index e470da95d806..54bb722e1ea3 100644
>>> --- a/drivers/video/backlight/gpio_backlight.c
>>> +++ b/drivers/video/backlight/gpio_backlight.c
>>> @@ -142,7 +142,8 @@ static int gpio_backlight_probe(struct
>>> platform_device
>>> *pdev)
>>> return PTR_ERR(bl);
>
Re: [PATCH v3 2/5] drm/tegra: Restore opaque and drop alpha formats on Tegra20/30
On Thu, Dec 21, 2017 at 01:38:31AM +0300, Dmitry Osipenko wrote:
> On 21.12.2017 01:23, Dmitry Osipenko wrote:
> > On 21.12.2017 01:02, Thierry Reding wrote:
> >> On Thu, Dec 21, 2017 at 12:05:40AM +0300, Dmitry Osipenko wrote:
> >>> On 20.12.2017 23:16, Thierry Reding wrote:
> On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote:
> > On 20.12.2017 21:01, Thierry Reding wrote:
> >> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
> >>> Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
> >>> DRM's MODE_ADDFB IOCTL on Tegra20/30, because IOCTL uses XRGB format
> >>> if
> >>> requested FB depth is 24bpp. As a result, Xorg doesn't work anymore
> >>> with
> >>> both modesetting and opentegra drivers. On older Tegra's each plane
> >>> has
> >>> a blending configuration which should be used to enable / disable
> >>> alpha
> >>> blending and right now the blending configs are hardcoded to disabled
> >>> alpha blending. In order to support alpha formats properly, planes
> >>> blending configuration must be adjusted, until then the alpha formats
> >>> are equal to non-alpha.
> >>>
> >>> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
> >>> Signed-off-by: Dmitry Osipenko
> >>> ---
> >>> drivers/gpu/drm/tegra/dc.c| 29 ++---
> >>> drivers/gpu/drm/tegra/dc.h| 1 +
> >>> drivers/gpu/drm/tegra/fb.c| 13 -
> >>> drivers/gpu/drm/tegra/hub.c | 3 ++-
> >>> drivers/gpu/drm/tegra/plane.c | 22 +-
> >>> drivers/gpu/drm/tegra/plane.h | 2 +-
> >>> 6 files changed, 39 insertions(+), 31 deletions(-)
> >>
> >> This kept bugging me, so I spent some time looking at the blending
> >> programming. I came up with the attached patch which seems to work
> >> for all scenarios and is fairly similar to your patch. It has the
> >> added benefit that we can keep support for more formats.
> >>
> >> Any comments?
> >>
> >> Thierry
> >> --- >8 ---
> >> From 3d2b7d1a9b8239dc6940477d8783461ac60783bc Mon Sep 17 00:00:00 2001
> >> From: Thierry Reding
> >> Date: Wed, 20 Dec 2017 09:39:14 +0100
> >> Subject: [PATCH] drm/tegra: dc: Implement legacy blending
> >>
> >> This implements alpha blending on legacy display controllers (Tegra20,
> >> Tegra30 and Tegra114). While it's theoretically possible to support the
> >> zpos property to enable userspace to specify the Z-order of each plane
> >> individually, this is not currently supported and the same fixed Z-
> >> order as previously defined is used.
> >
> > Perhaps one variant of implementing zpos could be by making overlays
> > 'virtual',
> > so each virtual overlay will be backed by the real HW plane and we
> > could swap
> > the HW planes of the virtual overlays, emulating zpos.
> >
> >> Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats")
> >> since
> >> the opaque formats are now supported.
> >>
> >> Reported-by: Dmitry Osipenko
> >> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
> >> Signed-off-by: Thierry Reding
> >> ---
> >> drivers/gpu/drm/tegra/dc.c| 74
> >> ++-
> >> drivers/gpu/drm/tegra/dc.h| 13
> >> drivers/gpu/drm/tegra/fb.c| 12 ---
> >> drivers/gpu/drm/tegra/plane.c | 41
> >> drivers/gpu/drm/tegra/plane.h | 3 ++
> >> 5 files changed, 116 insertions(+), 27 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> >> index bc65c314e00f..07c687d7f615 100644
> >> --- a/drivers/gpu/drm/tegra/dc.c
> >> +++ b/drivers/gpu/drm/tegra/dc.c
> >> @@ -168,32 +168,46 @@ static inline u32 compute_initial_dda(unsigned
> >> int in)
> >>return dfixed_frac(inf);
> >> }
> >>
> >> -static void tegra_plane_setup_blending_legacy(struct tegra_plane
> >> *plane)
> >> +static void
> >> +tegra_plane_setup_blending_legacy(struct tegra_plane *plane,
> >> +const struct tegra_dc_window *window)
> >> {
> >> + u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
> >> + BLEND_COLOR_KEY_NONE;
> >> + u32 background = BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) |
> >> + BLEND_COLOR_KEY_NONE;
> >> + u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
> >> +
> >> + /* enable alpha blending if window->alpha */
> >> + if (window->alpha) {
> >> + background |= BLEND_CONTROL_DEPENDENT;
> >> + foreground |= BLEND_CONTROL_ALPHA;
> >> + }
> >
> > I think dependent weight means that window
[Bug 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games
https://bugs.freedesktop.org/show_bug.cgi?id=104289 --- Comment #8 from Christian König --- I think I've figured out what is going on here. Give me a moment to provide a new patch. -- 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/3] drm/panel: Add Ilitek ILI9322 driver
On Fri, Dec 01, 2017 at 05:16:58PM +0100, Linus Walleij wrote: > This adds support for the Ilitek ILI9322 QVGA (320x240) > TFT panel driver. > > This panel driver supports serial or parallel RGB or > YUV input and also ITU-T BT.656 input streams. > > The controller is combined with a physical panel and > configured through the device tree. > > Cc: David Lechner > Cc: Stefano Babic > Cc: Ben Dooks > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Dropped all DT parsing code in favor of open-coding the > display config on a per-system basis based on system-specific > compatible strings, after feedback from the DT maintainers. > - Define a set of configs for the D-Link DIR-685 router. > - Tested on the D-Link DIR-685. > --- > drivers/gpu/drm/panel/Kconfig| 8 + > drivers/gpu/drm/panel/Makefile | 1 + > drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 962 > +++ > 3 files changed, 971 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9322.c checkpatch.pl gives me these: -:30: WARNING: please write a paragraph that describes the config symbol fully #30: FILE: drivers/gpu/drm/panel/Kconfig:31: +config DRM_PANEL_ILITEK_IL9322 -:54: WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? #54: new file mode 100644 -:130: CHECK: Prefer using the BIT macro #130: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:72: +#define ILI9322_ENTRY_PAL (1 << 2) -:134: CHECK: Prefer using the BIT macro #134: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:76: +#define ILI9322_ENTRY_SERIAL_RGB_ALIGNED (1 << 4) -:196: CHECK: spaces preferred around that '|' (ctx:VxV) #196: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:138: +#define ILI9322_IF_CTRL_SYNC_DISABLED (BIT(2)|BIT(3)) ^ -:551: WARNING: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt #551: FILE: drivers/gpu/drm/panel/panel-ilitek-ili9322.c:493: + msleep(10); total: 0 errors, 3 warnings, 3 checks, 983 lines checked I'd like to see at least the warnings fixed. You can probably skip the entry in MAINTAINERS, though. I don't mind fixing these up while applying, but I don't know what to put in Kconfig. If you can send out a short paragraph for me to include I'll add it when I apply. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos
On Thu, Dec 21, 2017 at 03:44:56PM +0200, Tomi Valkeinen wrote: > On 21/12/17 14:55, Ville Syrjälä wrote: > > On Thu, Dec 21, 2017 at 02:11:00PM +0200, Peter Ujfalusi wrote: > >> Make sure that the primary plane will get normalized_zpos=0 if it's zpos is > >> set to 0, avoiding other planes to be placed in the background. > > > > Can you describe the actual "bad" configuration? > > > > Without knowing the details this looks like it's making things > > more complicated for no particularly good reason. If you're worried > > about clients that don't set zpos, then I think you should just > > assign the default zpos values better and/or allocate the planes > > in a better order. But it's definitely possible I'm missing the > > reason why you're doing this. > > Let's say we have two displays and two planes. First display will use > crtc0 and plane0 as primary plane, the second display crtc1, plane1. The > zpos of primary planes will be set to 0 by default. > > The userspace wants to use the second display, with an overlay plane. So > it takes the plane0 and moves it to crtc1. Now the second display has > two planes with zpos 0, and normalize_zpos will fix it according to the > plane id, i.e. the primary plane of the second display will be on top of > the "overlay" plane. > > I don't think other default zpos values and/or allocating planes in > better order can solve this. Hmm. True. OTOH this messes up the simple "plane id is used to resolve zpos conflicts" logic. Also since you have multiple primary planes on the same crtc, which primary plane is the "real primary" for the crtc? How would userspace even determine that? I guess the rule could be that the primary planes have to be registered in the same order as the crtcs? > > If the userspace is required to understand and set zpos, then this patch > is not needed. But at least in my test scripts I've hit this a few times =). I think it would be nice if we can just make it a rule that any userspace that moves planes between crtcs has to know about zpos. Otherwise it's pretty much pure luck what stacking order you would get. And my idea for planes that can move between crtcs is that the default zpos should be assigned globally, probably matching the plane id order as well. Ie. no two planes would default to the same zpos value. And only in case of hardware that has no planes that can move between crtcs you would allocate the default zpos per-crtc. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[ANNOUNCE] Wayland/Weston/Mesa HDR support (proof of concept)
Here's a quick proof of concept implementation of HDR support for Wayland/Weston/Mesa. I'm not posting this as patches right now because I'm not sure that would do much good given how rough this is. But here are all the repos/branches: git://github.com/vsyrjala/wayland.git hdr_poc git://github.com/vsyrjala/wayland-protocols.git hdr_poc git://github.com/vsyrjala/weston.git hdr_poc git://github.com/vsyrjala/mesa.git hdr_poc git://github.com/vsyrjala/linux.git hdr_poc The kernel HDR bits were partially done by Uma Shankar, the rest I hacked together myself. As far as Wayland protocol goes I'm adding three new extensions (should probably just have one with several requests?): - zwp_colorspace_v1 - Specify the primaries/whitepoint chromacities and transfer function for a surface - zwp_ycbcr_encoding_v1 - Specify the encoding for YCbCr surfaces - zwp_hdr_metadata_v1 - Allow the client to pass HDR metadata to the compositor Note that I've not given any thought to how the compositor might advertize its capabilities. I also hacked in a bunch of 10bpc+ YCbCr support to the protocol and Weston so that I can actually get some HDR video onto the screen. On the Mesa side I've crudely implementated the following egl/vk extesions: - EXT_gl_colorspace_* - EXT_surface_SMPTE2086_metadata - EXT_surface_CTA861_3_metadata (sidenote: these egl extension don't seem to match CTA-861.3 nicely when it comes to the min/max luminance stuff) - VK_EXT_hdr_metadata VK_EXT_hdr_metadata I plugged in for anv only, but the implementation is in the common wayland wsi code. Note that I haven't actually tested the vulkan stuff at all because I don't talk Vulkan (at least not yet). Also note that I've not connected up the HDR metadata pipeline properly. The client can provide the metadata, but the compositor doesn't actually pass it on to the display. For the time being the HDR metadata that gets passed to the display is partially specified in weston.ini and partially just hardocded (see libweston/compositor-drm.c). The Weston implementation involves a bunch of shaders and matrices to do the ycbcr->rgb, "degamma", csc for each surface, blend it all as linear RGB into an fp16 fbo, and finally blit that out to the final framebuffer while applying the ST2084 PQ transfer function in the process. The reason for the fp16 fbo is that we store the full 1 nits of linear RGB. That needs plenty of precisions in the low end so your regular 10bpc fb doesn't seem to cut it. And also the display gamma LUT doesn't have enough input precision for it either. Sadly there's no fixed function hardware in the GPU to do the ST2084 PQ when blending. When the output is not HDR I do skip the fp16 fbo step and use the gamma LUT in the display engine instead. Another approach to the precisions problem might be to not store the entire 1 nits of linear, and just cut off the super bright stuff (your display can't show it anyway). But I've not really bothered to figure out how low in nits we'd have to go here, probably too low. Maybe blending as sRGB and the doing sRGB->PQ with the gamma LUT might help a little bit? Ideally we would bypass this all for a single fullscreen HDR surface and just pass the PQ encoded data directly through. But I've not implemented that. In fact I even disable the buffer_age damage stuff when using the fp16 fbo, so we'll recompose the entire screen every time. Yeah, I'm lazy. Another thought that occurred to me was that it shouldn't be too hard to make Weston do some tone mapping when there's a HDR client and no HDR screen. To that end I included the ACES colorspaces in my colorspace list, but I didn't actually look into plugging the ACES tone mapping curve into the shaders. Might be a fun excercise, even though the practical applications might be close to nil. Probably better to not advertize HDR/wide gamuts when we can't actually output the stuff, and instead let the client do its own tone mapping. OK, so what can you do with this? I've included a few test clients: - simple-colorspace Just a copy of simple-egl but it uses the egl extension to specify the colorspace, and produces ST2084 PQ encoded data when asked - simple-hdr-video Uses ffmpeg to decode video into shm buffers, and sets the colorspace/ycbcr encoding etc. appropriately. Ie. this one can actually output HDR video Here's a weston.ini snippet that gets you outputting HDR: [core] gbm-format=xrgb2101010 [output] name=HDMI-A-2 colorspace=BT.2020 gamma=ST2084 max_sdr_nits=100 Hardware wise you'll need a HDR capable display obviously, and you'll need an Intel Geminilake GPU. Older Intel platforms don't support the HDR infoframe, so the display wouldn't know what to do with the data you're feeding it. As for the future, right now I don't really have any solid plans on continuing to develop this. I might dabble with it a bit more out of curiosity, but I'm more hoping we can find other people to move this forward properly. -- Ville Syrjälä Int
Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos
On 21/12/17 16:20, Ville Syrjälä wrote: On Thu, Dec 21, 2017 at 03:44:56PM +0200, Tomi Valkeinen wrote: On 21/12/17 14:55, Ville Syrjälä wrote: On Thu, Dec 21, 2017 at 02:11:00PM +0200, Peter Ujfalusi wrote: Make sure that the primary plane will get normalized_zpos=0 if it's zpos is set to 0, avoiding other planes to be placed in the background. Can you describe the actual "bad" configuration? Without knowing the details this looks like it's making things more complicated for no particularly good reason. If you're worried about clients that don't set zpos, then I think you should just assign the default zpos values better and/or allocate the planes in a better order. But it's definitely possible I'm missing the reason why you're doing this. Let's say we have two displays and two planes. First display will use crtc0 and plane0 as primary plane, the second display crtc1, plane1. The zpos of primary planes will be set to 0 by default. The userspace wants to use the second display, with an overlay plane. So it takes the plane0 and moves it to crtc1. Now the second display has two planes with zpos 0, and normalize_zpos will fix it according to the plane id, i.e. the primary plane of the second display will be on top of the "overlay" plane. I don't think other default zpos values and/or allocating planes in better order can solve this. Hmm. True. OTOH this messes up the simple "plane id is used to resolve zpos conflicts" logic. Also since you have multiple primary planes on the same crtc, which primary plane is the "real primary" for the crtc? How would userspace even determine that? I guess the rule could be that the primary planes have to be registered in the same order as the crtcs? Hmm, true. If the userspace is required to understand and set zpos, then this patch is not needed. But at least in my test scripts I've hit this a few times =). I think it would be nice if we can just make it a rule that any userspace that moves planes between crtcs has to know about zpos. Otherwise it's pretty much pure luck what stacking order you would get. Yes, but how does the userspace know when it is moving planes between crtcs? If the userspace knows this, then it knows which primary plane is for which crtc, right? And if it doesn't know this, then the userspace cannot associate any plane to any crtc (except what it configures itself). So... If using legacy modesetting (and non-universal planes), there's no problem, primary planes are fixed and at low zpos. If using atomic modesetting and universal planes, there's really no (default) association between planes and crtcs, and "primary plane" doesn't have much meaning. Is that correct? If so... Then I guess the atomic modesetting client essentially randomly picks which plane it uses as a "root plane" (if it even needs such), and which planes as overlay planes? If that's the case, then this patch doesn't quite fix the issue... Tomi -- 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
[Bug 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games
https://bugs.freedesktop.org/show_bug.cgi?id=104289 Christian König changed: What|Removed |Added Attachment #136340|0 |1 is obsolete|| --- Comment #9 from Christian König --- Created attachment 136343 --> https://bugs.freedesktop.org/attachment.cgi?id=136343&action=edit Possible fix v2 Please try that one instead. -- 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
