Re: [PATCH 5/8] xen/gntdev: Add initial support for dma-buf UAPI
On 05/30/2018 01:34 AM, Boris Ostrovsky wrote: On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: +/* + * Create a dma-buf [1] from grant references @refs of count @count provided + * by the foreign domain @domid with flags @flags. + * + * By default dma-buf is backed by system memory pages, but by providing + * one of the GNTDEV_DMA_FLAG_XXX flags it can also be created as + * a DMA write-combine or coherent buffer, e.g. allocated with dma_alloc_wc/ + * dma_alloc_coherent. + * + * Returns 0 if dma-buf was successfully created and the corresponding + * dma-buf's file descriptor is returned in @fd. + * + * [1] https://elixir.bootlin.com/linux/latest/source/Documentation/driver-api/dma-buf.rst Documentation/driver-api/dma-buf.rst. Indeed ;) -boris Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] xen/gntdev: Add initial support for dma-buf UAPI
On 05/25/2018 06:33 PM, Oleksandr Andrushchenko wrote: diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 3431fe210624..eaf63a2c7ae6 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -152,6 +152,16 @@ config XEN_GNTDEV help Allows userspace processes to use grants. +config XEN_GNTDEV_DMABUF + bool "Add support for dma-buf grant access device driver extension" + depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC This must be "depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && *DMA_SHARED_BUFFER*" + help + Allows userspace processes and kernel modules to use Xen backed + dma-buf implementation. With this extension grant references to + the pages of an imported dma-buf can be exported for other domain + use and grant references coming from a foreign domain can be + converted into a local dma-buf for local export. + ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] xen/gntdev: Allow mappings for DMA buffers
On 05/30/2018 12:52 AM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
struct unmap_notify {
@@ -96,10 +104,28 @@ struct grant_map {
struct gnttab_unmap_grant_ref *kunmap_ops;
struct page **pages;
unsigned long pages_vm_start;
+
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ /*
+* If dmabuf_vaddr is not NULL then this mapping is backed by DMA
+* capable memory.
+*/
+
+ /* Device for which DMA memory is allocated. */
+ struct device *dma_dev;
+ /* Flags used to create this DMA buffer: GNTDEV_DMABUF_FLAG_XXX. */
+ bool dma_flags;
Again, I think most of the comments here can be dropped. Except possibly
for the flags.
will drop most of those
+ /* Virtual/CPU address of the DMA buffer. */
+ void *dma_vaddr;
+ /* Bus address of the DMA buffer. */
+ dma_addr_t dma_bus_addr;
+#endif
};
static int unmap_grant_pages(struct grant_map *map, int offset, int pages);
+static struct miscdevice gntdev_miscdev;
+
/* -- */
static void gntdev_print_maps(struct gntdev_priv *priv,
@@ -121,8 +147,26 @@ static void gntdev_free_map(struct grant_map *map)
if (map == NULL)
return;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ if (map->dma_vaddr) {
+ struct gnttab_dma_alloc_args args;
+
+ args.dev = map->dma_dev;
+ args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT;
+ args.nr_pages = map->count;
+ args.pages = map->pages;
+ args.vaddr = map->dma_vaddr;
+ args.dev_bus_addr = map->dma_bus_addr;
+
+ gnttab_dma_free_pages(&args);
+ } else if (map->pages) {
+ gnttab_free_pages(map->count, map->pages);
+ }
+#else
if (map->pages)
gnttab_free_pages(map->count, map->pages);
+#endif
+
} else
#endif
if (map->pages)
gnttab_free_pages(map->count, map->pages);
(and elsewhere)
ok, just wasn't sure if it is ok to violate kernel coding style here ;)
kfree(map->pages);
kfree(map->grants);
kfree(map->map_ops);
diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
index 6d1163456c03..2d5a4672f07c 100644
--- a/include/uapi/xen/gntdev.h
+++ b/include/uapi/xen/gntdev.h
@@ -200,4 +200,19 @@ struct ioctl_gntdev_grant_copy {
/* Send an interrupt on the indicated event channel */
#define UNMAP_NOTIFY_SEND_EVENT 0x2
+/*
+ * Flags to be used while requesting memory mapping's backing storage
+ * to be allocated with DMA API.
+ */
+
+/*
+ * The buffer is backed with memory allocated with dma_alloc_wc.
+ */
+#define GNTDEV_DMA_FLAG_WC (1 << 1)
Is there a reason you are not using bit 0?
No reason for that, will start from 0
-boris
Thank you,
Oleksandr
+
+/*
+ * The buffer is backed with memory allocated with dma_alloc_coherent.
+ */
+#define GNTDEV_DMA_FLAG_COHERENT (1 << 2)
+
#endif /* __LINUX_PUBLIC_GNTDEV_H__ */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 72785, which changed state. Bug 72785 Summary: bfgminer --scrypt OpenCL on Clover RadeonSI https://bugs.freedesktop.org/show_bug.cgi?id=72785 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 72785] bfgminer --scrypt OpenCL on Clover RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=72785 Jan Vesely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #42 from Jan Vesely --- (In reply to Vedran Miletić from comment #41) > It has been a while. What is the current state of bfgminer on Clover? works OK on my carrizo/topaz nb: ./bfgminer -S opencl:auto --scrypt --benchmark [2018-05-30 02:38:36] Summary of per device statistics: [2018-05-30 02:38:36] OCL0| 20s: 25.9 avg: 23.5 u: 10.6 kh/s | A:89 R:0+0(none) HW:0/none [2018-05-30 02:38:36] OCL1| 20s: 31.1 avg: 28.1 u: 13.9 kh/s | A:117 R:0+0(none) HW:0/none [2018-05-30 02:38:36] which is the same result as comment #25 -- 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 1/2] drm/amdgpu: fix 'ISO C90 forbids mixed declarations'
Please add something like "Fixing a compiler warning." as commit message.
With that done the series is Reviewed-by: Christian König
.
Thanks,
Christian.
Am 30.05.2018 um 05:14 schrieb Chunming Zhou:
Change-Id: I412f5783e2839c53841e6ab665f939236bdc5bf1
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 9ea8fb077aba..12f0d18c6ee8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -657,12 +657,12 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser
*p,
p->bytes_moved_vis);
if (p->bo_list) {
- gds = p->bo_list->gds_obj;
- gws = p->bo_list->gws_obj;
- oa = p->bo_list->oa_obj;
struct amdgpu_vm *vm = &fpriv->vm;
unsigned i;
+ gds = p->bo_list->gds_obj;
+ gws = p->bo_list->gws_obj;
+ oa = p->bo_list->oa_obj;
for (i = 0; i < p->bo_list->num_entries; i++) {
struct amdgpu_bo *bo = p->bo_list->array[i].robj;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA
On 05/29/2018 10:10 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in terms that proper memory reservation is made
({increase|decrease}_reservation and VA mappings updated if needed).
This is useful for sharing foreign buffers with HW drivers which
cannot work with scattered buffers provided by the balloon driver,
but require DMAable memory instead.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Kconfig | 13
drivers/xen/grant-table.c | 124 ++
include/xen/grant_table.h | 25
3 files changed, 162 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index e5d0c28372ea..3431fe210624 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -161,6 +161,19 @@ config XEN_GRANT_DEV_ALLOC
to other domains. This can be used to implement frontend drivers
or as part of an inter-domain shared memory channel.
+config XEN_GRANT_DMA_ALLOC
+ bool "Allow allocating DMA capable buffers with grant reference module"
+ depends on XEN
Should it depend on anything from DMA? CONFIG_HAS_DMA for example?
Yes, it must be "depends on XEN && HAS_DMA",
thank you
+ help
+ Extends grant table module API to allow allocating DMA capable
+ buffers and mapping foreign grant references on top of it.
+ The resulting buffer is similar to one allocated by the balloon
+ driver in terms that proper memory reservation is made
+ ({increase|decrease}_reservation and VA mappings updated if needed).
+ This is useful for sharing foreign buffers with HW drivers which
+ cannot work with scattered buffers provided by the balloon driver,
+ but require DMAable memory instead.
+
config SWIOTLB_XEN
def_bool y
select SWIOTLB
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index d7488226e1f2..06fe6e7f639c 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -45,6 +45,9 @@
#include
#include
#include
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+#include
+#endif
#include
#include
@@ -57,6 +60,7 @@
#ifdef CONFIG_X86
#include
#endif
+#include
#include
#include
@@ -811,6 +815,82 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
}
EXPORT_SYMBOL(gnttab_alloc_pages);
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+/**
+ * gnttab_dma_alloc_pages - alloc DMAable pages suitable for grant mapping into
+ * @args: arguments to the function
+ */
+int gnttab_dma_alloc_pages(struct gnttab_dma_alloc_args *args)
+{
+ unsigned long pfn, start_pfn;
+ xen_pfn_t *frames;
+ size_t size;
+ int i, ret;
+
+ frames = kcalloc(args->nr_pages, sizeof(*frames), GFP_KERNEL);
+ if (!frames)
+ return -ENOMEM;
+
+ size = args->nr_pages << PAGE_SHIFT;
+ if (args->coherent)
+ args->vaddr = dma_alloc_coherent(args->dev, size,
+&args->dev_bus_addr,
+GFP_KERNEL | __GFP_NOWARN);
+ else
+ args->vaddr = dma_alloc_wc(args->dev, size,
+ &args->dev_bus_addr,
+ GFP_KERNEL | __GFP_NOWARN);
+ if (!args->vaddr) {
+ pr_err("Failed to allocate DMA buffer of size %zu\n", size);
+ ret = -ENOMEM;
+ goto fail_free_frames;
+ }
+
+ start_pfn = __phys_to_pfn(args->dev_bus_addr);
+ for (pfn = start_pfn, i = 0; pfn < start_pfn + args->nr_pages;
+ pfn++, i++) {
+ struct page *page = pfn_to_page(pfn);
+
+ args->pages[i] = page;
+ frames[i] = xen_page_to_gfn(page);
+ xenmem_reservation_scrub_page(page);
+ }
+
+ xenmem_reservation_va_mapping_reset(args->nr_pages, args->pages);
+
+ ret = xenmem_reservation_decrease(args->nr_pages, frames);
+ if (ret != args->nr_pages) {
+ pr_err("Failed to decrease reservation for DMA buffer\n");
+ xenmem_reservation_increase(ret, frames);
+ ret = -EFAULT;
+ goto fail_free_dma;
+ }
+
+ ret = gnttab_pages_set_private(args->nr_pages, args->pages);
+ if (ret < 0)
+ goto fail_clear_private;
+
+ kfree(frames);
+ return 0;
+
+fail_clear_private:
+ gnttab_pages_clear_private(args->nr_pages, args->pages);
+fail_free_dma:
Do you need to xenmem_reservation_increase()?
Yes, missed that on fail_clear_private error path, will fix
+ xenmem_reservation_va_mapping_update(args->nr
[Bug 64225] [clover/turks] bfgminer --scrypt generates Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=64225 --- Comment #12 from Jan Vesely --- (In reply to Vedran Miletić from comment #11) > Does this still happen? It no longer segfaults, but still fails to build. [2018-05-30 02:32:30] Initialising kernel scrypt.cl without bitalign, 2 vectors and worksize 256 [2018-05-30 02:32:30] Error -46: Creating Kernel from program. (clCreateKernel) [2018-05-30 02:32:30] OCL 0: Failed to load kernel -- 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 64225] [clover/turks] bfgminer --scrypt generates Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=64225 Jan Vesely changed: What|Removed |Added Summary|bfgminer --scyte generates |[clover/turks] bfgminer |Segmentation Fault on |--scrypt generates |Northern Island |Segmentation Fault -- 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 1/8] xen/grant-table: Make set/clear page private code shared
On 05/30/2018 07:24 AM, Juergen Gross wrote:
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 54 +--
include/xen/grant_table.h | 3 +++
2 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 27be107d6480..d7488226e1f2 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
}
EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
-/**
- * gnttab_alloc_pages - alloc pages suitable for grant mapping into
- * @nr_pages: number of pages to alloc
- * @pages: returns the pages
- */
-int gnttab_alloc_pages(int nr_pages, struct page **pages)
+int gnttab_pages_set_private(int nr_pages, struct page **pages)
{
int i;
- int ret;
-
- ret = alloc_xenballooned_pages(nr_pages, pages);
- if (ret < 0)
- return ret;
for (i = 0; i < nr_pages; i++) {
#if BITS_PER_LONG < 64
struct xen_page_foreign *foreign;
foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
- if (!foreign) {
- gnttab_free_pages(nr_pages, pages);
+ if (!foreign)
return -ENOMEM;
- }
+
set_page_private(pages[i], (unsigned long)foreign);
#endif
SetPagePrivate(pages[i]);
@@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
return 0;
}
-EXPORT_SYMBOL(gnttab_alloc_pages);
+EXPORT_SYMBOL(gnttab_pages_set_private);
EXPORT_SYMBOL_GPL()
Sure, I was confused by the fact that there are only 2 functions in the file
which are exported as:
- EXPORT_SYMBOL(gnttab_alloc_pages);
- EXPORT_SYMBOL(gnttab_free_pages);
and those were the base for the new
gnttab_pages_set_private/gnttab_pages_clear_private
This made me think I have to retain the same EXPORT_SYMBOL for them.
Do you want me to add one more patch into this series and change
gnttab_alloc_pages/gnttab_free_pages to GPL as well?
/**
- * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
- * @nr_pages; number of pages to free
- * @pages: the pages
+ * gnttab_alloc_pages - alloc pages suitable for grant mapping into
+ * @nr_pages: number of pages to alloc
+ * @pages: returns the pages
*/
-void gnttab_free_pages(int nr_pages, struct page **pages)
+int gnttab_alloc_pages(int nr_pages, struct page **pages)
+{
+ int ret;
+
+ ret = alloc_xenballooned_pages(nr_pages, pages);
+ if (ret < 0)
+ return ret;
+
+ ret = gnttab_pages_set_private(nr_pages, pages);
+ if (ret < 0)
+ gnttab_free_pages(nr_pages, pages);
+
+ return ret;
+}
+EXPORT_SYMBOL(gnttab_alloc_pages);
+
+void gnttab_pages_clear_private(int nr_pages, struct page **pages)
{
int i;
@@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
ClearPagePrivate(pages[i]);
}
}
+}
+EXPORT_SYMBOL(gnttab_pages_clear_private);
EXPORT_SYMBOL_GPL()
Will change
Juergen
Thank you,
Oleksandr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106639] System display has noise when amdgpu module is being loaded
https://bugs.freedesktop.org/show_bug.cgi?id=106639 --- Comment #5 from jian-h...@endlessm.com --- Hi Michel, The patch which you mentioned works better than before. Will it be back ported to Linux kernel 4.16 or 4.17? Thanks -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm/amdgpu: fix 'ISO C90 forbids mixed declarations'
Reviewed-by: Emily Deng
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chunming Zhou
> Sent: Wednesday, May 30, 2018 11:15 AM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Deng, Emily ; Zhou, David(ChunMing)
>
> Subject: [PATCH 1/2] drm/amdgpu: fix 'ISO C90 forbids mixed declarations'
>
> Change-Id: I412f5783e2839c53841e6ab665f939236bdc5bf1
> Signed-off-by: Chunming Zhou
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 9ea8fb077aba..12f0d18c6ee8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -657,12 +657,12 @@ static int amdgpu_cs_parser_bos(struct
> amdgpu_cs_parser *p,
>p->bytes_moved_vis);
>
> if (p->bo_list) {
> - gds = p->bo_list->gds_obj;
> - gws = p->bo_list->gws_obj;
> - oa = p->bo_list->oa_obj;
> struct amdgpu_vm *vm = &fpriv->vm;
> unsigned i;
>
> + gds = p->bo_list->gds_obj;
> + gws = p->bo_list->gws_obj;
> + oa = p->bo_list->oa_obj;
> for (i = 0; i < p->bo_list->num_entries; i++) {
> struct amdgpu_bo *bo = p->bo_list->array[i].robj;
>
> --
> 2.14.1
>
> ___
> 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
[PATCH 2/2] drm/amdgpu: gds bo must not be per-vm-bo
In per-vm-bo case, there could be no bo list.
But gds bo created from user space must be passed to bo list.
So adding a check to prevent creat per-vm gds bo.
Change-Id: Idfa58c40447df0db2883413f9f7ccf56b47579f5
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 556406a44da3..5fb156a01774 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -236,6 +236,13 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void
*data,
/* create a gem object to contain this object in */
if (args->in.domains & (AMDGPU_GEM_DOMAIN_GDS |
AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA)) {
+ if (flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID) {
+ /* if gds bo is created from user space, it must be
+* passed to bo list
+*/
+ DRM_ERROR("GDS bo cannot be per-vm-bo\n");
+ return -EINVAL;
+ }
flags |= AMDGPU_GEM_CREATE_NO_CPU_ACCESS;
if (args->in.domains == AMDGPU_GEM_DOMAIN_GDS)
size = size << AMDGPU_GDS_SHIFT;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/amdgpu: fix 'ISO C90 forbids mixed declarations'
Change-Id: I412f5783e2839c53841e6ab665f939236bdc5bf1
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 9ea8fb077aba..12f0d18c6ee8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -657,12 +657,12 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser
*p,
p->bytes_moved_vis);
if (p->bo_list) {
- gds = p->bo_list->gds_obj;
- gws = p->bo_list->gws_obj;
- oa = p->bo_list->oa_obj;
struct amdgpu_vm *vm = &fpriv->vm;
unsigned i;
+ gds = p->bo_list->gds_obj;
+ gws = p->bo_list->gws_obj;
+ oa = p->bo_list->oa_obj;
for (i = 0; i < p->bo_list->num_entries; i++) {
struct amdgpu_bo *bo = p->bo_list->array[i].robj;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH] drm/msm: make pclk_rate u64 to avoid truncation
Higher values of pclk can exceed 32 bits when multiplied
by a factor.
Make the pclk_rate u64 to accommodate higher pixel clock
rates.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index b916f46..4935387 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -668,7 +668,7 @@ static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
u8 lanes = msm_host->lanes;
u32 bpp = dsi_get_bpp(msm_host->format);
- u32 pclk_rate;
+ u64 pclk_rate;
if (!mode) {
pr_err("%s: mode not set\n", __func__);
@@ -683,7 +683,7 @@ static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)
msm_host->byte_clk_rate = (pclk_rate * bpp) / 8;
}
- DBG("pclk=%d, bclk=%d", pclk_rate, msm_host->byte_clk_rate);
+ DBG("pclk=%llu, bclk=%d", pclk_rate, msm_host->byte_clk_rate);
msm_host->esc_clk_rate = clk_get_rate(msm_host->esc_clk);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106670] AMD GPU Error, random lockup, Ryzen 2500U Vega 8 GPU
https://bugs.freedesktop.org/show_bug.cgi?id=106670 --- Comment #4 from JerryD --- Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD RAVEN (DRM 3.23.0 / 4.16.12-300.fc28.x86_64, LLVM 6.0.0) (0x15dd) Version: 18.0.2 Accelerated: yes Video memory: 223MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.1 Memory info (GL_ATI_meminfo): VBO free memory - total: 223 MB, largest block: 223 MB VBO free aux. memory - total: 3067 MB, largest block: 3067 MB Texture free memory - total: 223 MB, largest block: 223 MB Texture free aux. memory - total: 3067 MB, largest block: 3067 MB Renderbuffer free memory - total: 223 MB, largest block: 223 MB Renderbuffer free aux. memory - total: 3067 MB, largest block: 3067 MB Memory info (GL_NVX_gpu_memory_info): Dedicated video memory: 223 MB Total available memory: 3291 MB Currently available dedicated video memory: 223 MB OpenGL vendor string: X.Org OpenGL renderer string: AMD RAVEN (DRM 3.23.0 / 4.16.12-300.fc28.x86_64, LLVM 6.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.0.2 OpenGL core profile shading language version string: 4.50 -- 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 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||106619 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=106619 [Bug 106619] [OpenCL][llvm-svn]build failure addPassesToEmitFile candidate expects 6 arguments, 3 provided -- 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 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 106619, which changed state. Bug 106619 Summary: [OpenCL][llvm-svn]build failure addPassesToEmitFile candidate expects 6 arguments, 3 provided https://bugs.freedesktop.org/show_bug.cgi?id=106619 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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
[pull] amdgpu drm-fixes-4.17
Hi Dave, One last fix for 4.17. Fix a suspend regression in DC. The following changes since commit 72777fe79768ec30ac2163d26de68a89edc9849f: Merge branch 'drm-fixes-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2018-05-11 10:37:17 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.17 for you to fetch changes up to 20fa2ff0441eabc8e6263b428191228d9599ea9d: drm/amd/display: Fix BUG_ON during CRTC atomic check update (2018-05-29 14:22:28 -0500) Leo (Sunpeng) Li (1): drm/amd/display: Fix BUG_ON during CRTC atomic check update drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104391] DC R9 285 HDMI audio regression since drm/amd/display: try to find matching audio inst for enc inst first
https://bugs.freedesktop.org/show_bug.cgi?id=104391 Roman Li changed: What|Removed |Added CC||roman...@amd.com --- Comment #7 from Roman Li --- There were a couple of fixes wrt HDMI audio in DC v3.1.47. They've been merged today to 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
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/29/2018 09:24 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
+
+void xenmem_reservation_va_mapping_update(unsigned long count,
+ struct page **pages,
+ xen_pfn_t *frames)
+{
+#ifdef CONFIG_XEN_HAVE_PVMMU
+ int i;
+
+ for (i = 0; i < count; i++) {
+ struct page *page;
+
+ page = pages[i];
+ BUG_ON(page == NULL);
+
+ /*
+* We don't support PV MMU when Linux and Xen is using
+* different page granularity.
+*/
+ BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
+
+ if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+ unsigned long pfn = page_to_pfn(page);
+
+ set_phys_to_machine(pfn, frames[i]);
+
+ /* Link back into the page tables if not highmem. */
+ if (!PageHighMem(page)) {
+ int ret;
+
+ ret = HYPERVISOR_update_va_mapping(
+ (unsigned long)__va(pfn <<
PAGE_SHIFT),
+ mfn_pte(frames[i], PAGE_KERNEL),
+ 0);
+ BUG_ON(ret);
+ }
+ }
+ }
+#endif
+}
+EXPORT_SYMBOL(xenmem_reservation_va_mapping_update);
+
+void xenmem_reservation_va_mapping_reset(unsigned long count,
+struct page **pages)
+{
+#ifdef CONFIG_XEN_HAVE_PVMMU
+ int i;
+
+ for (i = 0; i < count; i++) {
+ /*
+* We don't support PV MMU when Linux and Xen is using
+* different page granularity.
+*/
+ BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
+
+ if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+ struct page *page = pages[i];
+ unsigned long pfn = page_to_pfn(page);
+
+ if (!PageHighMem(page)) {
+ int ret;
+
+ ret = HYPERVISOR_update_va_mapping(
+ (unsigned long)__va(pfn <<
PAGE_SHIFT),
+ __pte_ma(0), 0);
+ BUG_ON(ret);
+ }
+ __set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+ }
+ }
+#endif
+}
+EXPORT_SYMBOL(xenmem_reservation_va_mapping_reset);
One other thing I noticed --- both of these can be declared as NOPs in
the header file if !CONFIG_XEN_HAVE_PVMMU.
Will rework it to be NOp for !CONFIG_XEN_HAVE_PVMMU
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/29/2018 09:04 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated module
IIUIC this is not really a module, it's a common file.
Sure, will put "file" here
for the shared code and export corresponding
symbols for other kernel modules.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 71 ++
drivers/xen/mem-reservation.c | 134 ++
include/xen/mem_reservation.h | 29
4 files changed, 170 insertions(+), 65 deletions(-)
create mode 100644 drivers/xen/mem-reservation.c
create mode 100644 include/xen/mem_reservation.h
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 451e833f5931..3c87b0c3aca6 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
obj-$(CONFIG_X86) += fallback.o
obj-y += grant-table.o features.o balloon.o manage.o preempt.o time.o
+obj-y += mem-reservation.o
obj-y += events/
obj-y += xenbus/
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 065f0b607373..57b482d67a3a 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -71,6 +71,7 @@
#include
#include
#include
+#include
static int xen_hotplug_unpopulated;
@@ -157,13 +158,6 @@ static DECLARE_DELAYED_WORK(balloon_worker, balloon_process);
#define GFP_BALLOON \
(GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC)
-static void scrub_page(struct page *page)
-{
-#ifdef CONFIG_XEN_SCRUB_PAGES
- clear_highpage(page);
-#endif
-}
-
/* balloon_append: add the given page to the balloon. */
static void __balloon_append(struct page *page)
{
@@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
int rc;
unsigned long i;
struct page *page;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid= DOMID_SELF
- };
if (nr_pages > ARRAY_SIZE(frame_list))
nr_pages = ARRAY_SIZE(frame_list);
@@ -486,9 +475,7 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
page = balloon_next_page(page);
}
- set_xen_guest_handle(reservation.extent_start, frame_list);
- reservation.nr_extents = nr_pages;
- rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
+ rc = xenmem_reservation_increase(nr_pages, frame_list);
if (rc <= 0)
return BP_EAGAIN;
@@ -496,29 +483,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
page = balloon_retrieve(false);
BUG_ON(page == NULL);
-#ifdef CONFIG_XEN_HAVE_PVMMU
- /*
-* We don't support PV MMU when Linux and Xen is using
-* different page granularity.
-*/
- BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
-
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- unsigned long pfn = page_to_pfn(page);
-
- set_phys_to_machine(pfn, frame_list[i]);
-
- /* Link back into the page tables if not highmem. */
- if (!PageHighMem(page)) {
- int ret;
- ret = HYPERVISOR_update_va_mapping(
- (unsigned long)__va(pfn <<
PAGE_SHIFT),
- mfn_pte(frame_list[i],
PAGE_KERNEL),
- 0);
- BUG_ON(ret);
- }
- }
-#endif
+ xenmem_reservation_va_mapping_update(1, &page, &frame_list[i]);
Can you make a single call to xenmem_reservation_va_mapping_update(rc,
...)? You need to keep track of pages but presumable they can be put
into an array (or a list). In fact, perhaps we can have
balloon_retrieve() return a set of pages.
This is actually how it is used later on for dma-buf, but I just didn't want
to alter original balloon code too much, but this can be done, in order
of simplicity:
1. Similar to frame_list, e.g. static array of struct page* of size
ARRAY_SIZE(frame_list):
more static memory is used, but no allocations
2. Allocated at run-time with kcalloc: allocation can fail
3. Make balloon_retrieve() return a set of pages: will require
list/array allocation
and handling, allocation may fail, balloon_retrieve prototype change
Could you please tell which
Re: [PATCH v2 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
On 29/05/18 13:17, Heiko Stübner wrote:
Am Dienstag, 29. Mai 2018, 13:59:42 CEST schrieb Robin Murphy:
On 28/05/18 14:20, Heiko Stuebner wrote:
From: Sandy Huang
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled, but the vop irq handler gets called.
But there is no real need to disable the irq, as the vop can simply
also track its enabled state and ignore irqs in that case.
For this we can simply check the power-domain state of the vop,
similar to how the iommu driver does it.
So remove the enable/disable handling and add appropriate condition
to the irq handler.
changes in v2:
- move to just check the power-domain state
- add clock handling
Signed-off-by: Sandy Huang
[add commit message, moved to pm_runtime_get_if_in_use]
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ++---
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index
b55156b8ba3b..615a5b44bfe9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -573,8 +573,6 @@ static int vop_enable(struct drm_crtc *crtc)
spin_unlock(&vop->reg_lock);
- enable_irq(vop->irq);
-
drm_crtc_vblank_on(crtc);
return 0;
@@ -618,8 +616,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc
*crtc,>
vop_dsp_hold_valid_irq_disable(vop);
- disable_irq(vop->irq);
-
vop->is_enabled = false;
/*
@@ -1195,6 +1191,16 @@ static irqreturn_t vop_isr(int irq, void *data)
uint32_t active_irqs;
int ret = IRQ_NONE;
+ /*
+* The irq is shared with the iommu. If the power-domain is off
+* the irq has to be targetted at the iommu.
Hmm, aren't the IOMMUs in the same power domain as their respective
master, though? I would naively assume so, and it does look that way
from the DTs in the BSP kernel.
AFAICS the IOMMU usage count should never be greater than the VOP usage
count (except before the VOP driver has probed, but I don't think that
matters), so although this looks like a sensible change in general I
can't help be a little bit puzzled at how and why the flow works.
Ok, the comment might be misleading. It actually means to use the runtime-pm
state of the vop-_device_ as a check.
I.e. in vop_initials(), Marc added the patch clearing and masking all vop
interrupts. In vop_enable() we have runtime_get_... + enablement of
vop interrupts, which get disabled in vop_disable again.
That way, checking the runtime_pm state should be an indicator if the
irq is for the vop and not the iommu.
Right, but whenever the VOP is nominally-disabled, the IOMMU should also
be nominally-disabled, in which case if it's even possible for the IRQ
to be asserted, both drivers would ignore it for the same reason (plus
the IOMMU driver would also spew a WARN(), which I'm not sure is always
appropriate...). That's what I couldn't quite make sense of.
However, from serendipitously stumbling across [1] I see that the IOMMU
is in fact going to get explicitly enabled by the driver core around
probing the VOP, which does give a window during which the imbalance is
present. I can imagine that the IOMMU reset via the VOP driver's
dma_configure_call() might misbehave if e.g. the VOP was left running
from a bootloader splash screen, but in that case I would expect to see
various screaming from the IOMMU driver which wasn't apparent in
Ezequiel's log. Oh well, as I said before the patch looks sane
regardless of my ability to reason about it ;)
Robin.
[1] https://patchwork.kernel.org/patch/10408825/
+*/
+ if (!pm_runtime_get_if_in_use(vop->dev))
+ return IRQ_NONE;
+
+ if (WARN_ON(vop_core_clks_enable(vop)))
+ goto out;
+
/*
* interrupt register has interrupt status, enable and clear bits, we
* must hold irq_lock to avoid a race with enable/disable_vblank().
@@ -1209,8 +1215,11 @@ static irqreturn_t vop_isr(int irq, void *data)
spin_unlock(&vop->irq_lock);
/* This is expected for vop iommu irqs, since the irq is shared */
- if (!active_irqs)
- return IRQ_NONE;
+ if (!active_irqs) {
+ ret = IRQ_NONE;
+ vop_core_clks_disable(vop);
+ goto out;
+ }
if (active_irqs & DSP_HOLD_VALID_INTR) {
complete(&vop->dsp_hold_completion);
@@ -1236,6 +1245,10 @@ static irqreturn_t vop_isr(int irq, void *data)
DRM_DEV_ERROR(vop->dev, "Unknown VOP IRQs: %#02x\n",
active_irqs);
+ vop_core_clks_disable(vop);
+
+out
[PULL] drm-misc-fixes for 4.17
Hi Dave, Although we didn't have anything for you last week, we have a couple of one-liners this week. Tomi is fixing a regression introduced in 4.17, and Dhinakaran added a previously unsupported psr setup time which could be affecting displays in the wild. drm-misc-fixes-2018-05-29: core: Add 220us psr setup time (Dhinakaran) omap: Fix NULL deref (Tomi) Cc: Dhinakaran Pandiyan Cc: Tomi Valkeinen Cheers, Sean The following changes since commit 2b6207291b7b277a5df9d1aab44b56815a292dba: drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl() (2018-05-16 17:56:06 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-05-29 for you to fetch changes up to 2bc5ff0bdc00d81d719dad74589317a260d583ed: drm/omap: fix NULL deref crash with SDI displays (2018-05-24 19:14:46 +0300) core: Add 220us psr setup time (Dhinakaran) omap: Fix NULL deref (Tomi) Cc: Dhinakaran Pandiyan Cc: Tomi Valkeinen Dhinakaran Pandiyan (1): drm/psr: Fix missed entry in PSR setup time table. Tomi Valkeinen (1): drm/omap: fix NULL deref crash with SDI displays drivers/gpu/drm/drm_dp_helper.c | 1 + drivers/gpu/drm/omapdrm/dss/sdi.c | 5 - 2 files changed, 5 insertions(+), 1 deletion(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] display: panel: Add KOE tx14d24vm1bpa display support (320x240)
On Tue, May 29, 2018 at 05:33:38PM +0200, Lukasz Majewski wrote: > Hi Thierry, > > > On Tue, May 29, 2018 at 05:01:48PM +0200, Lukasz Majewski wrote: > > > Hi Thierry, > > > > > > > On Mon, May 28, 2018 at 09:55:19AM +0200, Lukasz Majewski wrote: > > > > > Hi, > > > > > > > > > > > Hi Thierry, > > > > > > > > > > > > > This commit adds support for KOE's 5.7" display. > > > > > > > > > > > > > > > > > > > Thierry, shall I perform some more work on this code, or is it > > > > > > eligible for applying to your tree? > > > > > > > > > > Gentle ping. If Thierry is overworked - maybe there is a > > > > > co-maintainer so he/she could apply this patch? > > > > > > > > Please use the proper prefix for the commit subject to increase > > > > the chances of this being noticed. > > > > > > Ok. Is there any list of prefixes in the kernel repository, so I > > > could look for them (like get_prefix.py - similar to get_maintainer > > > script)? > > > > I don't think there is. A good rule of thumb that I use is to go over > > the git log for the last couple of commits and see if there's a clear > > pattern. This doesn't work for every subsystem, but drm/panel is very > > consistent in this regard, on purpose. > > I see. > > Is the DRM/panel tree hosted on git.kernel.org? > > The tree maintained by you there seems to be: > kernel/git/thierry.reding/linux-pwm.git > > IIRC it is hosted elsewhere. Am I right? drm/panel is part of drm-misc: https://cgit.freedesktop.org/drm/drm-misc/ Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, One potential Spectre vector plugging patch, a NULL deref fix and a DMI info fix reported by user. This is still based on -rc6 as my flight was delayed last week to the extent I missed possibility of sending the PR. For 4.19, Rodrigo will be picking up drm-next after Jani is done with 4.18, while I get to slack off. Regards, Joonas drm-intel-fixes-2018-05-29: - Fix for potential Spectre vector in the new query uAPI - Fix NULL pointer deref (FDO #106559) - DMI fix to hide LVDS for Radiant P845 (FDO #105468) The following changes since commit 771c577c23bac90597c685971d7297ea00f99d11: Linux 4.17-rc6 (2018-05-20 15:31:38 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-05-29 for you to fetch changes up to 65b3bdc807ac7bd83f5b27bc2c29a3c631eed7dd: drm/i915/query: nospec expects no more than an unsigned long (2018-05-29 13:53:07 +0300) - Fix for potential Spectre vector in the new query uAPI - Fix NULL pointer deref (FDO #106559) - DMI fix to hide LVDS for Radiant P845 (FDO #105468) Chris Wilson (3): drm/i915/lvds: Move acpi lid notification registration to registration phase drm/i915/query: Protect tainted function pointer lookup drm/i915/query: nospec expects no more than an unsigned long Ondrej Zary (1): drm/i915: Disable LVDS on Radiant P845 drivers/gpu/drm/i915/i915_query.c | 15 +--- drivers/gpu/drm/i915/intel_lvds.c | 51 ++- 2 files changed, 51 insertions(+), 15 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] display: panel: Add KOE tx14d24vm1bpa display support (320x240)
On Tue, May 29, 2018 at 05:01:48PM +0200, Lukasz Majewski wrote: > Hi Thierry, > > > On Mon, May 28, 2018 at 09:55:19AM +0200, Lukasz Majewski wrote: > > > Hi, > > > > > > > Hi Thierry, > > > > > > > > > This commit adds support for KOE's 5.7" display. > > > > > > > > > > > > > Thierry, shall I perform some more work on this code, or is it > > > > eligible for applying to your tree? > > > > > > Gentle ping. If Thierry is overworked - maybe there is a > > > co-maintainer so he/she could apply this patch? > > > > Please use the proper prefix for the commit subject to increase the > > chances of this being noticed. > > Ok. Is there any list of prefixes in the kernel repository, so I could > look for them (like get_prefix.py - similar to get_maintainer script)? I don't think there is. A good rule of thumb that I use is to go over the git log for the last couple of commits and see if there's a clear pattern. This doesn't work for every subsystem, but drm/panel is very consistent in this regard, on purpose. > I've used "display: panel" prefix, but I should have used "drm/panel" > > > > > This is also still missing a Reviewed-by or Acked-by from Rob. > > Rob has already reviewed this patch. I will send v2 > with Rob's Reviewed-by tag. Okay, I'll apply that v2 then. Thanks, Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Boot failures in -next on Jetson TK1
On Sat, May 26, 2018 at 11:36:29AM +0100, Mark Brown wrote: > Currently -next is failing to boot on Jetson TK1. The problem looks to > be the Nouveau driver, during initialization it reports an address > decode error then starts printing error messages saying "nouveau > 5700.gpu: fifo: SCHED_ERROR 20 []" over and over again. > > I've pasted the start of the errors below, you can see a full log and > more details at: > >https://kernelci.org/boot/id/5b0882a259b514339779a881/ > > The warnings about Spectre are a separate issue and don't seem to affect > the boot. > > [ 15.194484] nouveau 5700.gpu: NVIDIA GK20A (0ea000a1) > [ 15.200109] udevd[109]: could not rename interface '3' from 'eth0' to > 'enp1s0': Device or resource busy > [ 15.206399] nouveau 5700.gpu: imem: using IOMMU > [ 15.315122] CPU2: Spectre v2: firmware did not set auxiliary control > register IBE bit, system vulnerable > [ 15.320021] nouveau 5700.gpu: Direct firmware load for > nvidia/gk20a/fecs_inst.bin failed with error -2 > [ 15.384841] nouveau 5700.gpu: Direct firmware load for > nouveau/nvea_fuc409c failed with error -2 > [ 15.393972] nouveau 5700.gpu: Direct firmware load for nouveau/fuc409c > failed with error -2 > [ 15.402679] nouveau 5700.gpu: gr: failed to load fuc409c > [ 15.409434] CPU1: Spectre v2: firmware did not set auxiliary control > register IBE bit, system vulnerable > [ 15.419398] CPU1: Spectre v2: firmware did not set auxiliary control > register IBE bit, system vulnerable > [ 15.482568] tegra-mc 70019000.memory-controller: gpusrd: read @0x00041200: > EMEM address decode error (EMEM decode error) > [ 15.491232] [TTM] Zone kernel: Available graphics memory: 375202 kiB > [ 15.502768] [TTM] Zone highmem: Available graphics memory: 1030050 kiB > [ 15.509290] [TTM] Initializing pool allocator > [ 15.513658] nouveau 5700.gpu: DRM: VRAM: 0 MiB > [ 15.518451] nouveau 5700.gpu: DRM: GART: 1048576 MiB > [ 15.526546] CPU1: Spectre v2: firmware did not set auxiliary control > register IBE bit, system vulnerable > [ 15.527290] tegra-mc 70019000.memory-controller: gpusrd: read @0x00072000: > EMEM address decode error (EMEM decode error) > [ 15.537050] CPU1: Spectre v2: firmware did not set auxiliary control > register IBE bit, system vulnerable > [ 15.546928] nouveau 5700.gpu: fifo: SCHED_ERROR 20 [] This is a known issue that was introduced in v4.16 by a combination of the 32-bit ARM DMA/IOMMU glue and an Tegra SMMU driver change. There is a fix here: http://patchwork.ozlabs.org/patch/902830/ Which got remotely NAK'ed by the DMA API maintainer. I then came up with this, based on feedback from Christoph: http://patchwork.ozlabs.org/project/linux-tegra/list/?series=40853 But that's kind of blocked right now, awaiting feedback. I'll send out another version, which will hopefully strike the right balance. 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 8/8] drm/bridge: cdns: mark PM functions as __maybe_unused
On Mon, May 28, 2018 at 04:32:43PM +0200, Boris Brezillon wrote:
> +Thierry
>
> Hi Arnd,
>
> On Fri, 25 May 2018 17:50:15 +0200
> Arnd Bergmann wrote:
>
> > These two functions are unused in some configurations, and using
> > __maybe_unused
> > is the easiest way to shut up the harmless warnings:
> >
> > drivers/gpu/drm/bridge/cdns-dsi.c:1353:12: error: 'cdns_dsi_suspend'
> > defined but not used [-Werror=unused-function]
> > static int cdns_dsi_suspend(struct device *dev)
> > ^~~~
> > drivers/gpu/drm/bridge/cdns-dsi.c:1340:12: error: 'cdns_dsi_resume' defined
> > but not used [-Werror=unused-function]
> > static int cdns_dsi_resume(struct device *dev)
> >
> > Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
> > Signed-off-by: Arnd Bergmann
>
> Hm, I thought such a patch had already been applied by Thierry [1].
>
> [1]https://www.spinics.net/lists/dri-devel/msg174363.html
Yeah, that's in drm-misc-next, but didn't seem to have made it into
linux-next until today.
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 RESEND] display: panel: Add KOE tx14d24vm1bpa display support (320x240)
On Mon, May 28, 2018 at 09:55:19AM +0200, Lukasz Majewski wrote: > Hi, > > > Hi Thierry, > > > > > This commit adds support for KOE's 5.7" display. > > > > > > > Thierry, shall I perform some more work on this code, or is it > > eligible for applying to your tree? > > Gentle ping. If Thierry is overworked - maybe there is a co-maintainer > so he/she could apply this patch? Please use the proper prefix for the commit subject to increase the chances of this being noticed. This is also still missing a Reviewed-by or Acked-by from Rob. 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 v3 RESEND] display: panel: Add AUO g070vvn01 display support (800x480)
On Mon, May 14, 2018 at 09:08:49PM +0200, Lukasz Majewski wrote: > This commit adds support for AUO's 7.0" display. > > Signed-off-by: Lukasz Majewski > Reviewed-by: Rob Herring > > --- > Changes for v3: > - Remove not used 'bus-format-override = "rgb565";' property > > Changes for v2: > - Add *.txt suffix to the auo,g070wn01 file > --- > .../bindings/display/panel/auo,g070vvn01.txt | 29 > drivers/gpu/drm/panel/panel-simple.c | 31 > ++ > 2 files changed, 60 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt Next time, please use the standard "drm/panel: " prefix, which increases the chances of me seeing the patch. Also, it's usually a good idea to split patches up into one that has the device tree bindings and another one that has the driver changes. Applied, thanks. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] drm/msm/dsi: replace version checks with helper functions
Replace version checks with the helper functions bound to
cfg_handler for DSI v2, DSI 6G 1.x and DSI 6G v2.0+ controllers
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 241 -
1 file changed, 29 insertions(+), 212 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 1f42c891142f..a351f2243ff8 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -427,19 +427,6 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
- if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G &&
- cfg_hnd->minor >= MSM_DSI_6G_VER_MINOR_V2_2_1) {
- msm_host->byte_intf_clk = msm_clk_get(pdev, "byte_intf");
- if (IS_ERR(msm_host->byte_intf_clk)) {
- ret = PTR_ERR(msm_host->byte_intf_clk);
- pr_err("%s: can't find byte_intf clock. ret=%d\n",
- __func__, ret);
- goto exit;
- }
- } else {
- msm_host->byte_intf_clk = NULL;
- }
-
msm_host->byte_clk_src = clk_get_parent(msm_host->byte_clk);
if (!msm_host->byte_clk_src) {
ret = -ENODEV;
@@ -454,31 +441,8 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
- if (cfg_hnd->major == MSM_DSI_VER_MAJOR_V2) {
- msm_host->src_clk = msm_clk_get(pdev, "src");
- if (IS_ERR(msm_host->src_clk)) {
- ret = PTR_ERR(msm_host->src_clk);
- pr_err("%s: can't find src clock. ret=%d\n",
- __func__, ret);
- msm_host->src_clk = NULL;
- goto exit;
- }
-
- msm_host->esc_clk_src = clk_get_parent(msm_host->esc_clk);
- if (!msm_host->esc_clk_src) {
- ret = -ENODEV;
- pr_err("%s: can't get esc clock parent. ret=%d\n",
- __func__, ret);
- goto exit;
- }
-
- msm_host->dsi_clk_src = clk_get_parent(msm_host->src_clk);
- if (!msm_host->dsi_clk_src) {
- ret = -ENODEV;
- pr_err("%s: can't get src clock parent. ret=%d\n",
- __func__, ret);
- }
- }
+ if (cfg_hnd->ops->clk_init_ver)
+ ret = cfg_hnd->ops->clk_init_ver(msm_host);
exit:
return ret;
}
@@ -682,16 +646,6 @@ int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host)
return ret;
}
-static int dsi_link_clk_enable(struct msm_dsi_host *msm_host)
-{
- const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-
- if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G)
- return dsi_link_clk_enable_6g(msm_host);
- else
- return dsi_link_clk_enable_v2(msm_host);
-}
-
void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
{
clk_disable_unprepare(msm_host->esc_clk);
@@ -709,24 +663,6 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
}
-static void dsi_link_clk_disable(struct msm_dsi_host *msm_host)
-{
- const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-
- if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
- clk_disable_unprepare(msm_host->esc_clk);
- clk_disable_unprepare(msm_host->pixel_clk);
- if (msm_host->byte_intf_clk)
- clk_disable_unprepare(msm_host->byte_intf_clk);
- clk_disable_unprepare(msm_host->byte_clk);
- } else {
- clk_disable_unprepare(msm_host->pixel_clk);
- clk_disable_unprepare(msm_host->src_clk);
- clk_disable_unprepare(msm_host->esc_clk);
- clk_disable_unprepare(msm_host->byte_clk);
- }
-}
-
int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host)
{
struct drm_display_mode *mode = msm_host->mode;
@@ -805,73 +741,6 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host)
return 0;
}
-static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)
-{
- struct drm_display_mode *mode = msm_host->mode;
- const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
- u8 lanes = msm_host->lanes;
- u32 bpp = dsi_get_bpp(msm_host->format);
- u32 pclk_rate;
-
- if (!mode) {
- pr_err("%s: mode not set\n", __func__);
- return -EINVAL;
- }
-
- pclk_rate = mode->clock * 1000;
- if (lanes > 0) {
- msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
- } else {
- pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
- msm_host->byte_clk_rate = (pclk_rate * bp
[PATCH v4 2/3] drm/msm/dsi: add implementation for helper functions
Add dsi host helper function implementation for DSI v2
DSI 6G 1.x and DSI 6G v2.0+ controllers
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi.h | 15 ++
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 56 ++--
drivers/gpu/drm/msm/dsi/dsi_host.c | 218 -
3 files changed, 278 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 80be83e8fdec..dfa049d876bd 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -183,6 +183,21 @@ int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
int msm_dsi_host_init(struct msm_dsi *msm_dsi);
int msm_dsi_runtime_suspend(struct device *dev);
int msm_dsi_runtime_resume(struct device *dev);
+int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
+int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
+int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
+void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
+void *dsi_tx_buf_get_v2(struct msm_dsi_host *msm_host);
+void dsi_tx_buf_put_6g(struct msm_dsi_host *msm_host);
+int dsi_dma_base_get_6g(struct msm_dsi_host *msm_host, uint64_t *iova);
+int dsi_dma_base_get_v2(struct msm_dsi_host *msm_host, uint64_t *iova);
+int dsi_clk_init_v2(struct msm_dsi_host *msm_host);
+int dsi_clk_init_6g_v2(struct msm_dsi_host *msm_host);
+int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host);
+int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host);
/* dsi phy */
struct msm_dsi_phy;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 0327bb54b01b..dcdfb1bb54f9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -136,20 +136,58 @@ static const struct msm_dsi_config sdm845_dsi_cfg = {
.num_dsi = 2,
};
+const static struct msm_dsi_host_cfg_ops msm_dsi_v2_host_ops = {
+ .link_clk_enable = dsi_link_clk_enable_v2,
+ .link_clk_disable = dsi_link_clk_disable_v2,
+ .clk_init_ver = dsi_clk_init_v2,
+ .tx_buf_alloc = dsi_tx_buf_alloc_v2,
+ .tx_buf_get = dsi_tx_buf_get_v2,
+ .tx_buf_put = NULL,
+ .dma_base_get = dsi_dma_base_get_v2,
+ .calc_clk_rate = dsi_calc_clk_rate_v2,
+};
+
+const static struct msm_dsi_host_cfg_ops msm_dsi_6g_host_ops = {
+ .link_clk_enable = dsi_link_clk_enable_6g,
+ .link_clk_disable = dsi_link_clk_disable_6g,
+ .clk_init_ver = NULL,
+ .tx_buf_alloc = dsi_tx_buf_alloc_6g,
+ .tx_buf_get = dsi_tx_buf_get_6g,
+ .tx_buf_put = dsi_tx_buf_put_6g,
+ .dma_base_get = dsi_dma_base_get_6g,
+ .calc_clk_rate = dsi_calc_clk_rate_6g,
+};
+
+const static struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {
+ .link_clk_enable = dsi_link_clk_enable_6g,
+ .link_clk_disable = dsi_link_clk_disable_6g,
+ .clk_init_ver = dsi_clk_init_6g_v2,
+ .tx_buf_alloc = dsi_tx_buf_alloc_6g,
+ .tx_buf_get = dsi_tx_buf_get_6g,
+ .tx_buf_put = dsi_tx_buf_put_6g,
+ .dma_base_get = dsi_dma_base_get_6g,
+ .calc_clk_rate = dsi_calc_clk_rate_6g,
+};
+
static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
- {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064, &apq8064_dsi_cfg},
+ {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064,
+ &apq8064_dsi_cfg, &msm_dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
- &msm8974_apq8084_dsi_cfg},
+ &msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
- &msm8974_apq8084_dsi_cfg},
+ &msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
- &msm8974_apq8084_dsi_cfg},
+ &msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_2,
- &msm8974_apq8084_dsi_cfg},
- {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3, &msm8994_dsi_cfg},
- {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1, &msm8916_dsi_cfg},
- {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1, &msm8996_dsi_cfg},
- {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1, &sdm845_dsi_cfg},
+ &msm8974_apq8084_dsi_cfg, &msm_dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3,
+ &msm8994_dsi_cfg, &msm_dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1,
+ &msm8916_dsi_cfg, &msm_dsi_6g_host_ops},
+ {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1,
+ &msm8996_
[PATCH v4 1/3] drm/msm/dsi: add dsi host helper functions support
Add dsi host helper functions support for DSI v2 and DSI 6G 1.x
controllers that are under version checks
Signed-off-by: Sibi Sankar
---
drivers/gpu/drm/msm/dsi/dsi.h | 1 +
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 12
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a47acd..80be83e8fdec 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -149,6 +149,7 @@ static inline int msm_dsi_pll_set_usecase(struct
msm_dsi_pll *pll,
#endif
/* dsi host */
+struct msm_dsi_host;
int msm_dsi_host_xfer_prepare(struct mipi_dsi_host *host,
const struct mipi_dsi_msg *msg);
void msm_dsi_host_xfer_restore(struct mipi_dsi_host *host,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 9cfdcf1c95d5..a795a062b779 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -40,10 +40,22 @@ struct msm_dsi_config {
const int num_dsi;
};
+struct msm_dsi_host_cfg_ops {
+ int (*link_clk_enable)(struct msm_dsi_host *msm_host);
+ void (*link_clk_disable)(struct msm_dsi_host *msm_host);
+ int (*clk_init_ver)(struct msm_dsi_host *msm_host);
+ int (*tx_buf_alloc)(struct msm_dsi_host *msm_host, int size);
+ void* (*tx_buf_get)(struct msm_dsi_host *msm_host);
+ void (*tx_buf_put)(struct msm_dsi_host *msm_host);
+ int (*dma_base_get)(struct msm_dsi_host *msm_host, uint64_t *iova);
+ int (*calc_clk_rate)(struct msm_dsi_host *msm_host);
+};
+
struct msm_dsi_cfg_handler {
u32 major;
u32 minor;
const struct msm_dsi_config *cfg;
+ const struct msm_dsi_host_cfg_ops *ops;
};
const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/3] Cleanup excessive DSI host controller version checks
This patch series aims to create and bind dsi host controller helper functions to functionalities that vary across DSI v2, DSI 6G 1.x and DSI 6G v2.0+ controllers. These functionalities are currently under excessive version checks which is now replaced with the corresponding helper function. V4: None (seems like the unbalanced mutex unlock is already fixed now) V3: Removed redundant mode checks in calc_clk_rate_6g/v2 Removed dev->struct_mutex unlock in tx_buf_alloc_6g Use msm_gem_kernel_new in tx_buf_alloc_6g Modified author to first name/last name format Reviewed-by: Archit Taneja V2: Removes command broadcast support for DSI 6G v2.0+ controllers from the patch series and incorporates all the suggested corrections Sibi Sankar (3): drm/msm/dsi: add dsi host helper functions support drm/msm/dsi: add implementation for helper functions drm/msm/dsi: replace version checks with helper functions drivers/gpu/drm/msm/dsi/dsi.h | 16 ++ drivers/gpu/drm/msm/dsi/dsi_cfg.c | 56 - drivers/gpu/drm/msm/dsi/dsi_cfg.h | 12 + drivers/gpu/drm/msm/dsi/dsi_host.c | 355 - 4 files changed, 268 insertions(+), 171 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: make map_atomic and map function pointers optional
So drivers don't need dummy functions just returning NULL.
Cc: Daniel Vetter
Signed-off-by: Gerd Hoffmann
---
include/linux/dma-buf.h | 4 ++--
drivers/dma-buf/dma-buf.c | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 085db2fee2..88917fa796 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -39,12 +39,12 @@ struct dma_buf_attachment;
/**
* struct dma_buf_ops - operations possible on struct dma_buf
- * @map_atomic: maps a page from the buffer into kernel address
+ * @map_atomic: [optional] maps a page from the buffer into kernel address
* space, users may not block until the subsequent unmap call.
* This callback must not sleep.
* @unmap_atomic: [optional] unmaps a atomically mapped page from the buffer.
* This Callback must not sleep.
- * @map: maps a page from the buffer into kernel address space.
+ * @map: [optional] maps a page from the buffer into kernel address space.
* @unmap: [optional] unmaps a page from the buffer.
* @vmap: [optional] creates a virtual mapping for the buffer into kernel
* address space. Same restrictions as for vmap and friends apply.
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d78d5fc173..4c45e31258 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -872,6 +872,8 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned
long page_num)
{
WARN_ON(!dmabuf);
+ if (!dmabuf->ops->map_atomic)
+ return NULL;
return dmabuf->ops->map_atomic(dmabuf, page_num);
}
EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
@@ -907,6 +909,8 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long
page_num)
{
WARN_ON(!dmabuf);
+ if (!dmabuf->ops->map)
+ return NULL;
return dmabuf->ops->map(dmabuf, page_num);
}
EXPORT_SYMBOL_GPL(dma_buf_kmap);
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106631] PALM: clpeak: Bus error (core dumped) & lots of GPU lockup
https://bugs.freedesktop.org/show_bug.cgi?id=106631 --- Comment #11 from Ricardo Ribalda --- Seems that it is in release mode root@qt5022:~# llvm-config --assertion-mode OFF root@qt5022:~# llvm-config --build-mode Release -- 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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #71 from MirceaKitsune --- The Mesa 18.1.0 update, which was supposed to fix several GPU crashes, seems to have managed to expand this freeze instead: I now get it even when playing simple 3D games with low-poly models and low-res textures, such as MegaGlest. At this moment the issue is at a point where it may have real life implications: I may be constrained to buy a new video card just to stop this, and if I do that I literally won't have money to eat for a month. As I make my living from animation and game development, it's either that or this issue can be solved. I know it has to be software related, but in some mind boggling way every way to see what's doing it gets covered up and no kernel or MESA parameters make it go away. Can someone please ask other developers and people experienced with the video drivers to subscribe to this and post their ideas? iive helped me with a lot of advice, but somehow whatever is doing it managed to dodge everything even he could think of. Perhaps someone else has some new suggestions? -- 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/2] drm/etnaviv: properly implement mmaping of imported buffers
On Tue, May 29, 2018 at 11:08 AM, Lucas Stach wrote:
> Am Dienstag, den 29.05.2018, 10:20 +0200 schrieb Daniel Vetter:
>> On Fri, May 25, 2018 at 03:42:54PM +0200, Lucas Stach wrote:
>> > The intention of the existing code was to deflect the actual work
>> > of mmaping a dma-buf to the exporter, as that one probably knows best
>> > how to handle the buffer. Unfortunately the call to drm_gem_mmap did
>> > more than what etnaviv needs in this case by actually setting up the
>> > mapping.
>> >
>> > Move mapping setup to the shm buffer type mmap implementation so we
>> > only need to look up the BO and call the buffer type mmap function
>> > from the handler.
>> >
>> > Fixes mmap behavior with dma-buf imported and userptr buffers.
>>
>> You allow mmap on userptr buffers? That sounds really nasty ...
>
> No, we don't because that's obviously crazy, even more so on ARM with
> it's special rules about aliasing mappings. The current code is buggy
> in that it first sets up the mapping and then tells userspace the mmap
> failed. After this patch we properly reject userptr mmap outright.
Ah, I didn't realize that. It sounded more like making userptr mmap
work, not rejecting it. Can't you instead just never register the mmap
offset for userptr objects? That would catch the invalid request even
earlier, and make it more obvious that mmap is not ok for userptr.
Would also remove the need to hand-roll an etnaviv version of
drm_gem_obj_mmap.
>> Also not really thrilled about dma-buf mmap forwarding either, since you
>> don't seem to forward the begin/end_cpu_access stuff either.
>
> Yeah, that's still missing, but IMHO more of a correctness fix (which
> can be done in a follow on patch), distinct of the bugfix in this
> patch.
Yeah drm_gem_obj_mmap should check for obj->import_attach imo and
scream. Maybe we should even have that check when allocating the mmap
offset, since having an mmap offset for something you can never mmap
is silly. And obj->import_attach isn't allowed to change over the
lifetime of an object.
-Daniel
>
> Regards,
> Lucas
>> -Daniel
>>
>> > Signed-off-by: Lucas Stach
>> > ---
>> > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 30 ---
>> > 1 file changed, 23 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
>> > b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
>> > index fcc969fa0e69..f38989960d7f 100644
>> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
>> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
>> > @@ -138,6 +138,13 @@ static int etnaviv_gem_mmap_obj(struct
>> > etnaviv_gem_object *etnaviv_obj,
>> > struct vm_area_struct *vma)
>> > {
>> > pgprot_t vm_page_prot;
>> > + int ret;
>> > +
>> > + ret = drm_gem_mmap_obj(&etnaviv_obj->base,
>> > + drm_vma_node_size(&etnaviv_obj->base.vma_node) << PAGE_SHIFT,
>> > + vma);
>> > + if (ret)
>> > + return ret;
>> >
>> > vma->vm_flags &= ~VM_PFNMAP;
>> > vma->vm_flags |= VM_MIXEDMAP;
>> > @@ -167,17 +174,26 @@ static int etnaviv_gem_mmap_obj(struct
>> > etnaviv_gem_object *etnaviv_obj,
>> >
>> > int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct *vma)
>> > {
>> > - struct etnaviv_gem_object *obj;
>> > + struct drm_file *priv = filp->private_data;
>> > + struct etnaviv_gem_object *etnaviv_obj;
>> > + struct drm_gem_object *obj;
>> > int ret;
>> >
>> > - ret = drm_gem_mmap(filp, vma);
>> > - if (ret) {
>> > - DBG("mmap failed: %d", ret);
>> > - return ret;
>> > + obj = drm_gem_bo_vm_lookup(filp, vma);
>> > + if (!obj)
>> > + return -EINVAL;
>> > +
>> > + if (!drm_vma_node_is_allowed(&obj->vma_node, priv)) {
>> > + drm_gem_object_put_unlocked(obj);
>> > + return -EACCES;
>> > }
>> >
>> > - obj = to_etnaviv_bo(vma->vm_private_data);
>> > - return obj->ops->mmap(obj, vma);
>> > + etnaviv_obj = to_etnaviv_bo(obj);
>> > +
>> > + ret = etnaviv_obj->ops->mmap(etnaviv_obj, vma);
>> > + drm_gem_object_put_unlocked(obj);
>> > +
>> > + return ret;
>> > }
>> >
>> > int etnaviv_gem_fault(struct vm_fault *vmf)
>> > --
>> > 2.17.0
>> >
>> > ___
>> > dri-devel mailing list
>> > dri-devel@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] Add udmabuf misc device
On Tue, May 29, 2018 at 10:48 AM, Gerd Hoffmann wrote:
> Hi,
>
>> > +static void *kmap_atomic_udmabuf(struct dma_buf *buf, unsigned long
>> > page_num)
>> > +{
>> > + struct udmabuf *ubuf = buf->priv;
>> > + struct page *page = ubuf->pages[page_num];
>> > +
>> > + return kmap_atomic(page);
>> > +}
>> > +
>> > +static void *kmap_udmabuf(struct dma_buf *buf, unsigned long page_num)
>> > +{
>> > + struct udmabuf *ubuf = buf->priv;
>> > + struct page *page = ubuf->pages[page_num];
>> > +
>> > + return kmap(page);
>> > +}
>>
>> The above leaks like mad since no kunamp?
>
> /me checks code. Oops. Yes.
>
> The docs say map() is required and unmap() is not (for both atomic and
> non-atomic cases), so I assumed there is a default implementation just
> doing kunmap(page). Which is not the case. /me looks a bit surprised.
>
> I'll fix it for v4.
>
>> Also I think we have 0 users of the kmap atomic interfaces ... so not sure
>> whether it's worth it to implement those.
>
> Well, the docs are correct. kmap_atomic() is required, dma-buf.c calls
> the function pointer without checking it exists beforehand ...
Frankly with the pletoria of dummy kmap functions that just return
NULL; it might be better to move that into core dma-buf code and make
it optional for real. Since it's indeed very surprising.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH v3] Add udmabuf misc device
On Tue, May 29, 2018 at 12:48 PM, Gerd Hoffmann wrote: > Hi, > >> > > qemu test branch: >> > > https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf > ^^ > >> > > + if (!shmem_mapping(file_inode(ubuf->filp)->i_mapping)) >> > > + goto err_free_ubuf; >> >> Can/should we test here that the memfd has a locked down size here? > > Makes sense. Suggested way to check that? unstatic memfd_get_seals() > function (mm/shmem.c)? Or is there some better way? > > Also which seals should we require? Is F_SEAL_SHRINK enough? Yes I think that's enough. Hm ... I think we also need to prevent the F_SEAL_WRITE, because there's no way to stop dma from tampering with the buffer once it's a dma-buf. Otherwise evil userspace could create a memfd, F_SEAL_SHRINK it, make a dma-buf out of it, F_SEAL_WRITE it, hand it to some unsuspecting priviledged service and then pull it over the table with a few dma-buf writes. >> On that: Link to userspace patches/git tree using this would be nice. > > See above. Ow, I was blind :-) Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199653] [AMDGPU][DC] BUG: unable to handle kernel NULL pointer dereference (trace decoded)
https://bugzilla.kernel.org/show_bug.cgi?id=199653 James Le Cuirot (ch...@gentoo.org) changed: What|Removed |Added CC||ch...@gentoo.org --- Comment #4 from James Le Cuirot (ch...@gentoo.org) --- I have almost exactly the same hardware but the Ryzen 7 (2700U) version. I also get multiple daily freezes. Many thanks for the additional info, I never managed to get any. I did try kdump but it never triggers, even when forcing a kernel panic. I'm now running OpenSUSE 15.0 with kernels from the "stable" repository (currently 4.16.12-1.g39c7522) and recent Mesa 18.2 prerelease builds. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
Am Dienstag, 29. Mai 2018, 13:59:42 CEST schrieb Robin Murphy:
> On 28/05/18 14:20, Heiko Stuebner wrote:
> > From: Sandy Huang
> >
> > The vop irq is shared between vop and iommu and irq probing in the
> > iommu driver moved to the probe function recently. This can in some
> > cases lead to a stall if the irq is triggered while the vop driver
> > still has it disabled, but the vop irq handler gets called.
> >
> > But there is no real need to disable the irq, as the vop can simply
> > also track its enabled state and ignore irqs in that case.
> > For this we can simply check the power-domain state of the vop,
> > similar to how the iommu driver does it.
> >
> > So remove the enable/disable handling and add appropriate condition
> > to the irq handler.
> >
> > changes in v2:
> > - move to just check the power-domain state
> > - add clock handling
> >
> > Signed-off-by: Sandy Huang
> > [add commit message, moved to pm_runtime_get_if_in_use]
> > Signed-off-by: Heiko Stuebner
> > ---
> >
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ++---
> > 1 file changed, 19 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index
> > b55156b8ba3b..615a5b44bfe9 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -573,8 +573,6 @@ static int vop_enable(struct drm_crtc *crtc)
> >
> > spin_unlock(&vop->reg_lock);
> >
> > - enable_irq(vop->irq);
> > -
> >
> > drm_crtc_vblank_on(crtc);
> >
> > return 0;
> >
> > @@ -618,8 +616,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc
> > *crtc,>
> > vop_dsp_hold_valid_irq_disable(vop);
> >
> > - disable_irq(vop->irq);
> > -
> >
> > vop->is_enabled = false;
> >
> > /*
> >
> > @@ -1195,6 +1191,16 @@ static irqreturn_t vop_isr(int irq, void *data)
> >
> > uint32_t active_irqs;
> > int ret = IRQ_NONE;
> >
> > + /*
> > +* The irq is shared with the iommu. If the power-domain is off
> > +* the irq has to be targetted at the iommu.
>
> Hmm, aren't the IOMMUs in the same power domain as their respective
> master, though? I would naively assume so, and it does look that way
> from the DTs in the BSP kernel.
>
> AFAICS the IOMMU usage count should never be greater than the VOP usage
> count (except before the VOP driver has probed, but I don't think that
> matters), so although this looks like a sensible change in general I
> can't help be a little bit puzzled at how and why the flow works.
Ok, the comment might be misleading. It actually means to use the runtime-pm
state of the vop-_device_ as a check.
I.e. in vop_initials(), Marc added the patch clearing and masking all vop
interrupts. In vop_enable() we have runtime_get_... + enablement of
vop interrupts, which get disabled in vop_disable again.
That way, checking the runtime_pm state should be an indicator if the
irq is for the vop and not the iommu.
> > +*/
> > + if (!pm_runtime_get_if_in_use(vop->dev))
> > + return IRQ_NONE;
> > +
> > + if (WARN_ON(vop_core_clks_enable(vop)))
> > + goto out;
> > +
> >
> > /*
> >
> > * interrupt register has interrupt status, enable and clear bits, we
> > * must hold irq_lock to avoid a race with enable/disable_vblank().
> >
> > @@ -1209,8 +1215,11 @@ static irqreturn_t vop_isr(int irq, void *data)
> >
> > spin_unlock(&vop->irq_lock);
> >
> > /* This is expected for vop iommu irqs, since the irq is shared */
> >
> > - if (!active_irqs)
> > - return IRQ_NONE;
> > + if (!active_irqs) {
> > + ret = IRQ_NONE;
> > + vop_core_clks_disable(vop);
> > + goto out;
> > + }
> >
> > if (active_irqs & DSP_HOLD_VALID_INTR) {
> >
> > complete(&vop->dsp_hold_completion);
> >
> > @@ -1236,6 +1245,10 @@ static irqreturn_t vop_isr(int irq, void *data)
> >
> > DRM_DEV_ERROR(vop->dev, "Unknown VOP IRQs: %#02x\n",
> >
> > active_irqs);
> >
> > + vop_core_clks_disable(vop);
> > +
> > +out:
> > + pm_runtime_put(vop->dev);
> >
> > return ret;
> >
> > }
> >
> > @@ -1614,9 +1627,6 @@ static int vop_bind(struct device *dev, struct
> > device *master, void *data)>
> > if (ret)
> >
> > goto err_disable_pm_runtime;
> >
> > - /* IRQ is initially disabled; it gets enabled in power_on */
> > - disable_irq(vop->irq);
> > -
> >
> > return 0;
> >
> > err_disable_pm_runtime:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/rockchip: vop: fix irq disabled after vop driver probed
On 28/05/18 14:20, Heiko Stuebner wrote:
From: Sandy Huang
The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled, but the vop irq handler gets called.
But there is no real need to disable the irq, as the vop can simply
also track its enabled state and ignore irqs in that case.
For this we can simply check the power-domain state of the vop,
similar to how the iommu driver does it.
So remove the enable/disable handling and add appropriate condition
to the irq handler.
changes in v2:
- move to just check the power-domain state
- add clock handling
Signed-off-by: Sandy Huang
[add commit message, moved to pm_runtime_get_if_in_use]
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ++---
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index b55156b8ba3b..615a5b44bfe9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -573,8 +573,6 @@ static int vop_enable(struct drm_crtc *crtc)
spin_unlock(&vop->reg_lock);
- enable_irq(vop->irq);
-
drm_crtc_vblank_on(crtc);
return 0;
@@ -618,8 +616,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
vop_dsp_hold_valid_irq_disable(vop);
- disable_irq(vop->irq);
-
vop->is_enabled = false;
/*
@@ -1195,6 +1191,16 @@ static irqreturn_t vop_isr(int irq, void *data)
uint32_t active_irqs;
int ret = IRQ_NONE;
+ /*
+* The irq is shared with the iommu. If the power-domain is off
+* the irq has to be targetted at the iommu.
Hmm, aren't the IOMMUs in the same power domain as their respective
master, though? I would naively assume so, and it does look that way
from the DTs in the BSP kernel.
AFAICS the IOMMU usage count should never be greater than the VOP usage
count (except before the VOP driver has probed, but I don't think that
matters), so although this looks like a sensible change in general I
can't help be a little bit puzzled at how and why the flow works.
Robin.
+*/
+ if (!pm_runtime_get_if_in_use(vop->dev))
+ return IRQ_NONE;
+
+ if (WARN_ON(vop_core_clks_enable(vop)))
+ goto out;
+
/*
* interrupt register has interrupt status, enable and clear bits, we
* must hold irq_lock to avoid a race with enable/disable_vblank().
@@ -1209,8 +1215,11 @@ static irqreturn_t vop_isr(int irq, void *data)
spin_unlock(&vop->irq_lock);
/* This is expected for vop iommu irqs, since the irq is shared */
- if (!active_irqs)
- return IRQ_NONE;
+ if (!active_irqs) {
+ ret = IRQ_NONE;
+ vop_core_clks_disable(vop);
+ goto out;
+ }
if (active_irqs & DSP_HOLD_VALID_INTR) {
complete(&vop->dsp_hold_completion);
@@ -1236,6 +1245,10 @@ static irqreturn_t vop_isr(int irq, void *data)
DRM_DEV_ERROR(vop->dev, "Unknown VOP IRQs: %#02x\n",
active_irqs);
+ vop_core_clks_disable(vop);
+
+out:
+ pm_runtime_put(vop->dev);
return ret;
}
@@ -1614,9 +1627,6 @@ static int vop_bind(struct device *dev, struct device *master, void *data)
if (ret)
goto err_disable_pm_runtime;
- /* IRQ is initially disabled; it gets enabled in power_on */
- disable_irq(vop->irq);
-
return 0;
err_disable_pm_runtime:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/edid: Quirk Vive Pro VR headset non-desktop.
This adds the Vive Pro's EDID information and
sets EDID_QUIRK_NON_DESKTOP.
Signed-off-by: Lubosz Sarnecki
---
drivers/gpu/drm/drm_edid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 39f1db4acda4..2697ff51f1ac 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -163,8 +163,9 @@ static const struct edid_quirk {
/* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
{ "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
- /* HTC Vive VR Headset */
+ /* HTC Vive and Vive Pro VR Headsets */
{ "HVR", 0xaa01, EDID_QUIRK_NON_DESKTOP },
+ { "HVR", 0xaa02, EDID_QUIRK_NON_DESKTOP },
/* Oculus Rift DK1, DK2, and CV1 VR Headsets */
{ "OVR", 0x0001, EDID_QUIRK_NON_DESKTOP },
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/3] [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display
On Tue, May 29, 2018 at 11:49 AM, Maxime Ripard wrote: > The BananaPi M2M has an optional 1280x720 DSI panel. Since that panel is > optional, we can only show a DT patch that would show how to enable it. > > Signed-off-by: Maxime Ripard This looks very nice. Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/3] drm/panel: Add Ilitek ILI9881c panel driver
On Tue, May 29, 2018 at 11:49 AM, Maxime Ripard wrote: > The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is > based on the Ilitek ILI9881c Controller. Add a driver for it, modelled > after the other Ilitek controller drivers. > > Signed-off-by: Maxime Ripard Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/3] dt-bindings: panel: Add the Ilitek ILI9881c panel documentation
On Tue, May 29, 2018 at 11:49 AM, Maxime Ripard wrote: > The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the > ILI9881c from Ilitek. > > Acked-by: Rob Herring > Signed-off-by: Maxime Ripard Looks good to me. Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] ARM: dts: Restructure Vexpress motherboard includes
On Tue, May 29, 2018 at 11:25 AM, Sudeep Holla wrote: > On 28/05/18 13:26, Linus Walleij wrote: >> This is a purely syntactic change that result in the same >> DTB files from the DTS/DTSI files. > Is it different from v1/earlier version you had posted ? Don't think so. Just resent it as part of the rest. > I have already sent this to ARM SoC and it should be in -next by now. Awesome! > I will add the remaining 3 patches for v4.19 once you confirm > that I can drop this patch as it's already queued. Drop it :) Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-intel-fixes tree
Quoting Stephen Rothwell (2018-05-29 12:26:05)
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (i386
> defconfig) failed like this:
Thanks for reporting. I've added a patch to fix the issue now.
I'll talk with our CI team about testing 32-bit building to try to
avoid these in the future.
Regards, Joonas
>
> In file included from include/asm-generic/barrier.h:20:0,
> from arch/x86/include/asm/barrier.h:86,
> from include/linux/nospec.h:8,
> from drivers/gpu/drm/i915/i915_query.c:7:
> drivers/gpu/drm/i915/i915_query.c: In function 'i915_query_ioctl':
> include/linux/compiler.h:339:38: error: call to '__compiletime_assert_119'
> declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^
> include/linux/compiler.h:319:4: note: in definition of macro
> '__compiletime_assert'
> prefix ## suffix();\
> ^~
> include/linux/compiler.h:339:2: note: in expansion of macro
> '_compiletime_assert'
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^~~
> include/linux/build_bug.h:45:37: note: in expansion of macro
> 'compiletime_assert'
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~
> include/linux/build_bug.h:69:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
> BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> ^~~~
> include/linux/nospec.h:55:2: note: in expansion of macro 'BUILD_BUG_ON'
> BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \
> ^~~~
> drivers/gpu/drm/i915/i915_query.c:118:15: note: in expansion of macro
> 'array_index_nospec'
> func_idx = array_index_nospec(func_idx,
>^~
>
> Caused by commit
>
> 540ead8c5a0e ("drm/i915/query: Protect tainted function pointer lookup")
>
> I have reverted that commit for today.
>
> --
> Cheers,
> Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106709] Requesting new account for IGT
https://bugs.freedesktop.org/show_bug.cgi?id=106709 Bug ID: 106709 Summary: Requesting new account for IGT Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: katarzyna@intel.com CC: arkadiusz.hi...@intel.com, dan...@ffwll.ch, dan...@fooishbar.org, martin.pe...@free.fr, petri.latv...@intel.com Created attachment 139830 --> https://bugs.freedesktop.org/attachment.cgi?id=139830&action=edit Keys Hello, I would like to request a new account. Name: Katarzyna Dec Email: katarzyna@intel.com Account name: kdec5 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] Add udmabuf misc device
On 05/29/2018 01:50 PM, Gerd Hoffmann wrote: Hi, +config UDMABUF + bool "userspace dmabuf misc driver" + default n + depends on DMA_SHARED_BUFFER Don't you want "select DMA_SHARED_BUFFER" here instead? Why do you think so? After thinking a bit more your code looks ok, sorry for the noise cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] Add udmabuf misc device
Hi, > > +config UDMABUF > > + bool "userspace dmabuf misc driver" > > + default n > > + depends on DMA_SHARED_BUFFER > Don't you want "select DMA_SHARED_BUFFER" here instead? Why do you think so? cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] Add udmabuf misc device
Hi, > > > qemu test branch: > > > https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf ^^ > > > + if (!shmem_mapping(file_inode(ubuf->filp)->i_mapping)) > > > + goto err_free_ubuf; > > Can/should we test here that the memfd has a locked down size here? Makes sense. Suggested way to check that? unstatic memfd_get_seals() function (mm/shmem.c)? Or is there some better way? Also which seals should we require? Is F_SEAL_SHRINK enough? > On that: Link to userspace patches/git tree using this would be nice. See above. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/3] drm/panel: Add Ilitek ILI9881c panel driver
The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is
based on the Ilitek ILI9881c Controller. Add a driver for it, modelled
after the other Ilitek controller drivers.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/panel/Kconfig | 9 +-
drivers/gpu/drm/panel/Makefile| 1 +-
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 503 +++-
3 files changed, 513 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 25682ff3449a..6020c30a33b3 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -46,6 +46,15 @@ config DRM_PANEL_ILITEK_IL9322
Say Y here if you want to enable support for Ilitek IL9322
QVGA (320x240) RGB, YUV and ITU-T BT.656 panels.
+config DRM_PANEL_ILITEK_ILI9881C
+ tristate "Ilitek ILI9881C-based panels"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y if you want to enable support for panels based on the
+ Ilitek ILI9881c controller.
+
config DRM_PANEL_INNOLUX_P079ZCA
tristate "Innolux P079ZCA panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f26efc11d746..5ccaaa9d13af 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
+obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
new file mode 100644
index ..e848af235df5
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -0,0 +1,503 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017-2018, Bootlin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+
+struct ili9881c {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+
+ struct backlight_device *backlight;
+ struct regulator*power;
+ struct gpio_desc*reset;
+};
+
+enum ili9881c_op {
+ ILI9881C_SWITCH_PAGE,
+ ILI9881C_COMMAND,
+};
+
+struct ili9881c_instr {
+ enum ili9881c_opop;
+
+ union arg {
+ struct cmd {
+ u8 cmd;
+ u8 data;
+ } cmd;
+ u8 page;
+ } arg;
+};
+
+#define ILI9881C_SWITCH_PAGE_INSTR(_page) \
+ { \
+ .op = ILI9881C_SWITCH_PAGE, \
+ .arg = {\
+ .page = (_page),\
+ }, \
+ }
+
+#define ILI9881C_COMMAND_INSTR(_cmd, _data)\
+ { \
+ .op = ILI9881C_COMMAND, \
+ .arg = {\
+ .cmd = {\
+ .cmd = (_cmd), \
+ .data = (_data),\
+ }, \
+ }, \
+ }
+
+static const struct ili9881c_instr ili9881c_init[] = {
+ ILI9881C_SWITCH_PAGE_INSTR(3),
+ ILI9881C_COMMAND_INSTR(0x01, 0x00),
+ ILI9881C_COMMAND_INSTR(0x02, 0x00),
+ ILI9881C_COMMAND_INSTR(0x03, 0x73),
+ ILI9881C_COMMAND_INSTR(0x04, 0x03),
+ ILI9881C_COMMAND_INSTR(0x05, 0x00),
+ ILI9881C_COMMAND_INSTR(0x06, 0x06),
+ ILI9881C_COMMAND_INSTR(0x07, 0x06),
+ ILI9881C_COMMAND_INSTR(0x08, 0x00),
+ ILI9881C_COMMAND_INSTR(0x09, 0x18),
+ ILI9881C_COMMAND_INSTR(0x0a, 0x04),
+ ILI9881C_COMMAND_INSTR(0x0b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0c, 0x02),
+ ILI9881C_COMMAND_INSTR(0x0d, 0x03),
+ ILI9881C_COMMAND_INSTR(0x0e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0f, 0x25),
+ ILI9881C_COMMAND_INSTR(0x10, 0x25),
+ ILI9881C_COMMAND_INSTR(0x11, 0x00),
+ ILI9881C_COMMAND_INSTR(0x12, 0x00),
+ ILI9881C_COMMAND_INSTR(0x13, 0x00),
+ ILI9881C_COMMAND_INSTR(0x14, 0x00),
+ ILI9881C_COMMAND_INSTR(0x15, 0x00),
+ ILI9881C_COMMAND_INSTR(0x16, 0x0C),
+ ILI9881C_COMMAND_INSTR(0x17, 0x00),
+ ILI9881C_C
[PATCH v5 1/3] dt-bindings: panel: Add the Ilitek ILI9881c panel documentation
The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the
ILI9881c from Ilitek.
Acked-by: Rob Herring
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt | 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
new file mode 100644
index ..4a041acb4e18
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt
@@ -0,0 +1,20 @@
+Ilitek ILI9881c based MIPI-DSI panels
+
+Required properties:
+ - compatible: must be "ilitek,ili9881c" and one of:
+* "bananapi,lhr050h41"
+ - reg: DSI virtual channel used by that screen
+ - power-supply: phandle to the power regulator
+ - reset-gpios: a GPIO phandle for the reset pin
+
+Optional properties:
+ - backlight: phandle to the backlight used
+
+Example:
+panel@0 {
+ compatible = "bananapi,lhr050h41", "ilitek,ili9881c";
+ reg = <0>;
+ power-supply = <®_display>;
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+ backlight = <&pwm_bl>;
+};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/3] [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display
The BananaPi M2M has an optional 1280x720 DSI panel. Since that panel is
optional, we can only show a DT patch that would show how to enable it.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 48 +-
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
index 0dbdb29a8fff..16ee662b06d6 100644
--- a/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
+++ b/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts
@@ -44,6 +44,7 @@
#include "sun8i-a33.dtsi"
#include
+#include
/ {
model = "BananaPi M2 Magic";
@@ -81,6 +82,23 @@
};
};
+ pwm_bl: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <8>;
+ enable-gpios = <&r_pio 0 4 GPIO_ACTIVE_HIGH>; /* PG10 */
+ };
+
+ reg_panel: reg-panel {
+ compatible = "regulator-fixed";
+ regulator-name = "panel";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&pio 1 7 GPIO_ACTIVE_HIGH>; /* PB07 */
+ enable-active-high;
+ };
+
reg_vcc5v0: vcc5v0 {
compatible = "regulator-fixed";
regulator-name = "vcc5v0";
@@ -120,6 +138,26 @@
status = "okay";
};
+&de {
+ status = "okay";
+};
+
+&dphy {
+ status = "okay";
+};
+
+&dsi {
+ status = "okay";
+
+ panel@0 {
+ compatible = "bananapi,lhr050h41", "ilitek,ili9881c";
+ reg = <0>;
+ reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+ power-supply = <®_panel>;
+ backlight = <&pwm_bl>;
+ };
+};
+
&ehci0 {
status = "okay";
};
@@ -178,6 +216,12 @@
status = "okay";
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pins>;
+ status = "okay";
+};
+
&r_rsb {
status = "okay";
@@ -290,6 +334,10 @@
status = "okay";
};
+&tcon0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_b>;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/3] drm/panel: Add Ilitek ILI9881c controller driver
Hi, Here is the next version of the patches to add the support for the Ilitek ILI9881c panel controller. This used to be a part of the larger DSI support series for the Allwinner SoCs whose patches have been since merged and are obviously not part of this series anymore. Let me know what you think, Maxime Changes from v5: - Switched to a regulator for the power line - Changed the mode name to reflect that this should be only for the bananapi - Fixed a compilation warning - Added a comment to explain the interface with the display Changes from v4: - Updated the copyright notice - Made the init structure const Changes from v3: - Rebased on top of current drm-misc-next - Switched to SPDX license header - Made the ECC array const - Split the big DSI patch into two, one to add the DSI driver and one to add the TCON bits. - Removed the dithering code - Changed the DT labels to remove the indices - Used sleeps instead of delays in the panel driver - Used the backlight_enable / _disable functions - Added Chen-Yu's Reviewed-by Changes from v2: - Added a ports node under the DSI node - Changed the huarui panel driver to an ili9881c driver - Changed the panel vendor to bananapi - Made the init table static in the panel driver - Dropped the huarui vendor patch for the DT doc. Changes from v1: - Rebased on 4.16-rc1 - Constified a few function arguments and structures - Reworked the DT binding example a bit - Reworked the panel driver to check for DSI return codes, and use DCS helpers when possible Maxime Ripard (3): dt-bindings: panel: Add the Ilitek ILI9881c panel documentation drm/panel: Add Ilitek ILI9881c panel driver [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt | 20 +++- arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts| 48 +++- drivers/gpu/drm/panel/Kconfig | 9 +- drivers/gpu/drm/panel/Makefile | 1 +- drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 503 - 5 files changed, 581 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c base-commit: fbbe3b8c2c9c5f84caf668703c26154cb4fbb9d1 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 00/41] drm/i915: Implement HDCP2.2
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter > Sent: Tuesday, May 29, 2018 2:01 PM > To: C, Ramalingam > Cc: Daniel Vetter ; intel-...@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; seanp...@chromium.org; chris@chris- > wilson.co.uk; jani.nik...@linux.intel.com; Winkler, Tomas > ; Usyskin, Alexander > ; Shankar, Uma ; > Sharma, Shashank > Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2 > > On Tue, May 29, 2018 at 07:51:56AM +, C, Ramalingam wrote: > > > -Original Message- > > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of > > > Daniel Vetter > > > Sent: Tuesday, May 29, 2018 12:27 PM > > > To: C, Ramalingam > > > Cc: intel-...@lists.freedesktop.org; > > > dri-devel@lists.freedesktop.org; seanp...@chromium.org; > > > dan...@ffwll.ch; ch...@chris-wilson.co.uk; > > > jani.nik...@linux.intel.com; Winkler, Tomas > > > ; Usyskin, Alexander > > > ; Shankar, Uma ; > > > Sharma, Shashank > > > Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2 > > > > > > On Mon, May 21, 2018 at 06:23:19PM +0530, Ramalingam C wrote: > > > > The sequence for HDCP2.2 authentication and encryption is > > > > implemented in I915. Encoder specific implementations are moved into > hdcp_shim. > > > > > > > > Intel HWs supports HDCP2.2 through ME FW. Hence this series > > > > introduces a client driver for mei bus, so that for HDCP2.2 > > > > authentication, > > > > HDCP2.2 stack in I915 can avail the services from ME FW. > > > > > > > > DRM_I915 selects INTEL_MEI_HDCP, which selects INTEL_MEI_ME and > > > > INTEL_MEI. If we are interested in disabling the MEI_HDCP and MEI > > > > Bus then we need an option to disable the HDCP2.2 in I915 (like > > > > DRM_I915_HDCP2.2!?). Till then they are binded. > > > > > > > > Userspace interface remains unchanged as version agnostic. When > > > > userspace request for HDCP enable, Kernel will detect the HDCP > > > > source and sink's HDCP version(1.4/2.2)capability and enable the > > > > best capable version for that combination. > > > > > > > > This series enables the HDCP2.2 for Type0 content streams. > > > > > > > > Thanks a lot for Usyskin, Alexander and Uma shankar for the review of > > > > v3. > > > > Thanks Daniel vetter for guiding me to test and confirm that there > > > > is no locking issue with respect to notifier usage between I915 and > MEI_HDCP. > > > > > > > > Major Changes in v4: > > > > - GMBus Changes to implement the burst read as generic > > > > [Jani, Ville and Daniel] > > > > - Polling is added for extra Notifier notification when I915 and > > > > MEI_HDCP are modules. > > > > - Comment and style issues and typos are fixed [Uma and Alexander] > > > > - INTEL_MEI_HDCP, INTEL_MEI_ME and INTEL_MEI are selected by I915. > > > > - Fixed the #if in include/linux/mei_hdcp.h for build issues. > > > > > > > > GMBus changes are added here for completeness of the series. They > > > > are in review at https://patchwork.freedesktop.org/series/41632/ also. > > > > > > Please reply with a link to your github here (and include it in your > > > next cover letter too). I can't ever find it when I need it :-/ > > > > You can find a github repo for HDCP2.2 v4 series at > > https://github.com/ramalingampc2008/drm-tip > > Even nicer if you directly supply what I need to feed to git fetch (like a > git pull > request over email): > > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v4 > > Then I can do a git fetch && git checkout FETCH_HEAD. Ok. Sure. Thanks, Ram. > > Thanks, Daniel > > > > > Thanks, > > Ram > > > > > > > > Thanks, Daniel > > > > > > > > > > > Ramalingam C (40): > > > > drm: hdcp2.2 authentication msg definitions > > > > drm: HDMI and DP specific HDCP2.2 defines > > > > misc/mei/hdcp: Client driver for HDCP application > > > > misc/mei/hdcp: Notifier chain for mei cldev state change > > > > misc/mei/hdcp: Define ME FW interface for HDCP2.2 > > > > linux/mei: Header for mei_hdcp driver interface > > > > misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session > > > > misc/mei/hdcp: Verify Receiver Cert and prepare km > > > > misc/mei/hdcp: Verify H_prime > > > > misc/mei/hdcp: Store the HDCP Pairing info > > > > misc/mei/hdcp: Initiate Locality check > > > > misc/mei/hdcp: Verify L_prime > > > > misc/mei/hdcp: Prepare Session Key > > > > misc/mei/hdcp: Repeater topology verification and ack > > > > misc/mei/hdcp: Verify M_prime > > > > misc/mei/hdcp: Enabling the HDCP authentication > > > > misc/mei/hdcp: Closing wired HDCP2.2 Tx Session > > > > drm/i915: wrapping all hdcp var into intel_hdcp > > > > drm/i915: Define HDCP2.2 related variables > > > > drm/i915: Define Intel HDCP2.2 registers > > > > drm/i915: Wrappers for mei HDCP2.2 services > > > > drm/i915: Implement HDCP2.2 receiver authentication > > > > drm/i915: Implement HDCP2.2 repeater authentication > > > > drm/i915
Re: [PATCH v4 30/41] drm/i915: Initialize HDCP2.2 and its MEI interface
On Tuesday 29 May 2018 02:12 PM, Daniel Vetter wrote:
On Tue, May 29, 2018 at 08:53:37AM +0200, Daniel Vetter wrote:
On Fri, May 25, 2018 at 04:42:52PM +0530, Ramalingam C wrote:
On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote:
Initialize HDCP2.2 support. This includes the mei interface
initialization along with required notifier registration.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out of mem [Uma]
Inline req for init function removed [Uma]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 3 +-
drivers/gpu/drm/i915/intel_drv.h | 5 +-
drivers/gpu/drm/i915/intel_hdcp.c | 117
+-
drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
4 files changed, 122 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..276eb49113e9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6368,7 +6368,8 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dp_add_properties(intel_dp, connector);
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
- int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
+ int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim,
+ false);
if (ret)
DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ac943ec73987..750fc19f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -442,7 +442,7 @@ struct intel_hdcp {
/* mei interface related information */
struct mei_cl_device *cldev;
struct mei_hdcp_data mei_data;
-
+ struct notifier_block mei_cldev_nb;
struct delayed_work hdcp2_check_work;
};
@@ -1940,7 +1940,8 @@ void intel_hdcp_atomic_check(struct drm_connector
*connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
int intel_hdcp_init(struct intel_connector *connector,
- const struct intel_hdcp_shim *hdcp_shim);
+ const struct intel_hdcp_shim *hdcp_shim,
+ bool hdcp2_supported);
int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
int intel_hdcp_check_link(struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index f3f935046c31..9948e4b4e203 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
@@ -25,6 +26,7 @@ static int _intel_hdcp2_enable(struct intel_connector
*connector);
static int _intel_hdcp2_disable(struct intel_connector *connector);
static void intel_hdcp2_check_work(struct work_struct *work);
static int intel_hdcp2_check_link(struct intel_connector *connector);
+static int intel_hdcp2_init(struct intel_connector *connector);
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
*intel_dig_port,
const struct intel_hdcp_shim *shim)
@@ -766,11 +768,15 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
enum port port)
}
int intel_hdcp_init(struct intel_connector *connector,
- const struct intel_hdcp_shim *hdcp_shim)
+ const struct intel_hdcp_shim *hdcp_shim,
+ bool hdcp2_supported)
{
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
+ if (!hdcp_shim)
+ return -EINVAL;
+
ret = drm_connector_attach_content_protection_property(
&connector->base);
if (ret)
@@ -779,7 +785,12 @@ int intel_hdcp_init(struct intel_connector *connector,
hdcp->hdcp_shim = hdcp_shim;
mutex_init(&hdcp->hdcp_mutex);
INIT_DELAYED_WORK(&hdcp->hdcp_check_work, intel_hdcp_check_work);
+ INIT_DELAYED_WORK(&hdcp->hdcp2_check_work, intel_hdcp2_check_work);
INIT_WORK(&hdcp->hdcp_prop_work, intel_hdcp_prop_work);
+
+ if (hdcp2_supported)
+ intel_hdcp2_init(connector);
+
return 0;
}
@@ -1637,3 +1648,107 @@ static void intel_hdcp2_check_work(struct work_struct
*work)
schedule_delayed_work(&hdcp->hdcp2_check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
}
+
+static int initialize_mei_hdcp_data(struct intel_connector *connector)
+{
+
Re: [PATCH v2 0/6] omapdrm: struct_mutex removal
On 25/05/18 19:39, Laurent Pinchart wrote: > Hello, > > This patch series removes the usage of struct_mutex from the omapdrm driver in > order to switch to gem_free_object_unlocked(). The series is inspired by > Daniel Vetter's recent gem_free_object_unlocked() patches (starting with > "[PATCH 1/5] staging/vboxvideo: Use gem_free_object_unlocked") and > includes patches "[PATCH 4/5] drm/omapdrm: Fix mm_list locking" and > "[PATCH] drm/omapdrm: Switch to gem_free_object_unlocked" (the latter > modified due to the rebase). > > When reviewing Daniel's patches I noticed a potential issue in lock handling > which prompted me to go and remove all usage of struct_mutex from the omapdrm > driver. Instead of replacing it with a device-wide lock, I have decided to > create per-GEM object locks as there is no need, as far as I can see, to > serialize operations across separate GEM objects. > > The series starts with a bit of cleanup in the form of renaming (1/6) and > refactoring (2/6), followed by removal of struct_mutex (3/6 and 4/6). It then > ends with Daniel's patches that switch to gem_free_object_unlocked(). > > The patches are based on top of the latest drm-misc. They have been tested on > a Pandaboard. Thanks! I'll queue these for v4.19 (I think we're a bit late for v4.18). 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
linux-next: build failure after merge of the drm-intel-fixes tree
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (i386
defconfig) failed like this:
In file included from include/asm-generic/barrier.h:20:0,
from arch/x86/include/asm/barrier.h:86,
from include/linux/nospec.h:8,
from drivers/gpu/drm/i915/i915_query.c:7:
drivers/gpu/drm/i915/i915_query.c: In function 'i915_query_ioctl':
include/linux/compiler.h:339:38: error: call to '__compiletime_assert_119'
declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:319:4: note: in definition of macro
'__compiletime_assert'
prefix ## suffix();\
^~
include/linux/compiler.h:339:2: note: in expansion of macro
'_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~
include/linux/build_bug.h:45:37: note: in expansion of macro
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
include/linux/build_bug.h:69:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^~~~
include/linux/nospec.h:55:2: note: in expansion of macro 'BUILD_BUG_ON'
BUILD_BUG_ON(sizeof(_i) > sizeof(long)); \
^~~~
drivers/gpu/drm/i915/i915_query.c:118:15: note: in expansion of macro
'array_index_nospec'
func_idx = array_index_nospec(func_idx,
^~
Caused by commit
540ead8c5a0e ("drm/i915/query: Protect tainted function pointer lookup")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpp8L4ICRE4L.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] drm/panel: Add Ilitek ILI9881c panel driver
Hi Linus,
On Fri, May 11, 2018 at 05:54:27PM +0200, Linus Walleij wrote:
> Hi Maxime,
>
> sorry that noone had much time to look at the driver.
> But I can help out, hopefully.
Thanks for your feedback :)
> On Fri, May 4, 2018 at 5:23 PM, Maxime Ripard
> wrote:
>
> > The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is
> > based on the Ilitek ILI9881c Controller. Add a driver for it, modelled
> > after the other Ilitek controller drivers.
> >
> > Signed-off-by: Maxime Ripard
>
> Nice, I have some experience with those.
>
> > +config DRM_PANEL_ILITEK_ILI9881C
> > + tristate "Ilitek ILI9881C-based panels"
> > + depends on OF
> > + depends on DRM_MIPI_DSI
> > + depends on BACKLIGHT_CLASS_DEVICE
>
> If it absolutely needs DRM_MIPI_DSI and
> BACKLIGHT_CLASS_DEVICE it maybe you should
> be more helpful to the user to just select it?
>
> Depending on OF is fine, that is more of a platform
> property.
All the other panels in this file seems to be using a depends on for
these two, so I'd rather remain consistent on this.
> > +struct ili9881c {
> > + struct drm_panelpanel;
> > + struct mipi_dsi_device *dsi;
> > +
> > + struct backlight_device *backlight;
> > + struct gpio_desc*power;
>
> Should this not be modeled using a fixed regulator instead?
Probably, yes. On my board it's a GPIO that goes through the
connector, but it seems like the controller itself takes a regulator,
so there's probably a GPIO-controlled regulator on the display PCB
somewhere. I'll change it.
> > +static const struct ili9881c_instr ili9881c_init[] = {
> > + ILI9881C_SWITCH_PAGE_INSTR(3),
> > + ILI9881C_COMMAND_INSTR(0x01, 0x00),
> > + ILI9881C_COMMAND_INSTR(0x02, 0x00),
> > + ILI9881C_COMMAND_INSTR(0x03, 0x73),
> > + ILI9881C_COMMAND_INSTR(0x04, 0x03),
> > + ILI9881C_COMMAND_INSTR(0x05, 0x00),
> > + ILI9881C_COMMAND_INSTR(0x06, 0x06),
> > + ILI9881C_COMMAND_INSTR(0x07, 0x06),
> (...)
>
> This is a bit hard to understand to say the least.
I know :/
> If this comes from a datasheet some more elaborate construction of
> the commands would be nice, maybe using some #defines?
>
> If this just comes from some code drop or reverse engineering,
> OK bad luck, I can live with it :)
This comes from a code drop (or rather, an obscure initialisation
sequence coming straight from the vendor without any documentation or
comment associated to it).
> It looks a bit like you're uploading a small firmware.
>
> > +static int ili9881c_switch_page(struct ili9881c *ctx, u8 page)
> > +{
> > + u8 buf[4] = { 0xff, 0x98, 0x81, page };
>
> That is also a bit unclear wrt what is going on.
My understanding is that the controller maps some registers (that
might be accessible through other buses if the controller is setup to
use something other than DCS) to DCS commands. Since there's more
commands than DCS would allow, it's setup in several pages, with each
pages having its own set of commands, and the page 0 accepting the
usual standard DCS commands.
It really doesn't look to me like a firmware, but just a poorly
documented initialisation sequence.. I'll add a comment
> > +static const struct drm_display_mode default_mode = {
> > + .clock = 62000,
> > + .vrefresh = 60,
> > +
> > + .hdisplay = 720,
> > + .hsync_start= 720 + 10,
> > + .hsync_end = 720 + 10 + 20,
> > + .htotal = 720 + 10 + 20 + 30,
> > +
> > + .vdisplay = 1280,
> > + .vsync_start= 1280 + 10,
> > + .vsync_end = 1280 + 10 + 10,
> > + .vtotal = 1280 + 10 + 10 + 20,
> > +};
>
> Is that the default mode for this Ilitek device or just for the
> BananaPi? If it is the latter it should be named
> bananapi_default_mode or something so as not to confuse
> the next user of this driver.
I'll do it, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] Add udmabuf misc device
On 05/25/2018 05:08 PM, Gerd Hoffmann wrote:
A driver to let userspace turn memfd regions into dma-bufs.
Use case: Allows qemu create dmabufs for the vga framebuffer or
virtio-gpu ressources. Then they can be passed around to display
those guest things on the host. To spice client for classic full
framebuffer display, and hopefully some day to wayland server for
seamless guest window display.
Note: Initial revision which supports a single region only so it
can't handle virtio-gpu ressources yet.
qemu test branch:
https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
Cc: David Airlie
Cc: Tomeu Vizoso
Cc: Daniel Vetter
Signed-off-by: Gerd Hoffmann
---
include/uapi/linux/udmabuf.h | 19 ++
drivers/dma-buf/udmabuf.c | 240 ++
tools/testing/selftests/drivers/dma-buf/udmabuf.c | 95 +
drivers/dma-buf/Kconfig | 7 +
drivers/dma-buf/Makefile | 1 +
tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
6 files changed, 367 insertions(+)
create mode 100644 include/uapi/linux/udmabuf.h
create mode 100644 drivers/dma-buf/udmabuf.c
create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
new file mode 100644
index 00..2fbe69cf05
--- /dev/null
+++ b/include/uapi/linux/udmabuf.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_UDMABUF_H
+#define _UAPI_LINUX_UDMABUF_H
+
+#include
+#include
+
+#define UDMABUF_FLAGS_CLOEXEC 0x01
+
+struct udmabuf_create {
+ __u32 memfd;
+ __u32 flags;
+ __u64 offset;
+ __u64 size;
+};
+
+#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create)
+
+#endif /* _UAPI_LINUX_UDMABUF_H */
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
new file mode 100644
index 00..f9600dc985
--- /dev/null
+++ b/drivers/dma-buf/udmabuf.c
@@ -0,0 +1,240 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct udmabuf {
+ struct file *filp;
+ u32 pagecount;
+ struct page **pages;
+};
+
+static int udmabuf_vm_fault(struct vm_fault *vmf)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct udmabuf *ubuf = vma->vm_private_data;
+
+ if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
+ return VM_FAULT_SIGBUS;
+
+ vmf->page = ubuf->pages[vmf->pgoff];
+ get_page(vmf->page);
+ return 0;
+}
+
+static const struct vm_operations_struct udmabuf_vm_ops = {
+ .fault = udmabuf_vm_fault,
+};
+
+static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
+{
+ struct udmabuf *ubuf = buf->priv;
+
+ if ((vma->vm_flags & VM_SHARED) == 0)
+ return -EINVAL;
+
+ vma->vm_ops = &udmabuf_vm_ops;
+ vma->vm_private_data = ubuf;
+ return 0;
+}
+
+static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
+ enum dma_data_direction direction)
+{
+ struct udmabuf *ubuf = at->dmabuf->priv;
+ struct sg_table *sg;
+
+ sg = kzalloc(sizeof(*sg), GFP_KERNEL);
+ if (!sg)
+ goto err1;
+ if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
+ 0, ubuf->pagecount << PAGE_SHIFT,
+ GFP_KERNEL) < 0)
+ goto err2;
+ if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
+ goto err3;
+
+ return sg;
+
+err3:
+ sg_free_table(sg);
+err2:
+ kfree(sg);
+err1:
+ return ERR_PTR(-ENOMEM);
+}
+
+static void unmap_udmabuf(struct dma_buf_attachment *at,
+ struct sg_table *sg,
+ enum dma_data_direction direction)
+{
+ sg_free_table(sg);
+ kfree(sg);
+}
+
+static void release_udmabuf(struct dma_buf *buf)
+{
+ struct udmabuf *ubuf = buf->priv;
+ pgoff_t pg;
+
+ for (pg = 0; pg < ubuf->pagecount; pg++)
+ put_page(ubuf->pages[pg]);
+ fput(ubuf->filp);
+ kfree(ubuf->pages);
+ kfree(ubuf);
+}
+
+static void *kmap_atomic_udmabuf(struct dma_buf *buf, unsigned long page_num)
+{
+ struct udmabuf *ubuf = buf->priv;
+ struct page *page = ubuf->pages[page_num];
+
+ return kmap_atomic(page);
+}
+
+static void *kmap_udmabuf(struct dma_buf *buf, unsigned long page_num)
+{
+ struct udmabuf *ubuf = buf->priv;
+ struct page *page = ubuf->pages[page_num];
+
+ return kmap(page);
+}
+
+static str
Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
Hi Kieran,
On Tue, May 29, 2018 at 11:08 AM, Kieran Bingham
wrote:
> On 28/05/18 10:06, Geert Uytterhoeven wrote:
>> On Fri, Apr 27, 2018 at 6:57 PM, Kieran Bingham
>> wrote:
>>> The DU1 external dot clock is provided by the fixed frequency clock
>>> generator X21, while the DU0 and DU3 clocks are provided by the
>>> programmable Versaclock5 clock generator.
>>>
>>> Enable the clocks, and the HDMI encoder for the M3-N Salvator-X board
>>> and hook it up to the HDMI connector.
>>>
>>> Based on patches from Takeshi Kihara
>>>
>>> Signed-off-by: Kieran Bingham
>>>
>>> ---
>>> v2:
>>> - Remove LVDS clocks from DU node
>>> - Merge DU Clocks and HDMI enablement
>>> ---
>>> .../boot/dts/renesas/r8a77965-salvator-x.dts | 28 +++
>>> 1 file changed, 28 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
>>> b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
>>> index 75d890d91df9..340a3c72b65a 100644
>>> --- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
>>> +++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
>>> @@ -19,3 +19,31 @@
>>> reg = <0x0 0x4800 0x0 0x7800>;
>>> };
>>> };
>>> +
>>> +&du {
>>> + clocks = <&cpg CPG_MOD 724>,
>>> +<&cpg CPG_MOD 723>,
>>> +<&cpg CPG_MOD 721>,
>>> +<&versaclock5 1>,
>>> +<&x21_clk>,
>>> +<&versaclock5 2>;
>>> + clock-names = "du.0", "du.1", "du.3",
>>> + "dclkin.0", "dclkin.1", "dclkin.3";
>>> +};
>>> +
>>> +&hdmi0 {
>>> + status = "okay";
>>> +
>>> + ports {
>>> + port@1 {
>>> + reg = <1>;
>>> + rcar_dw_hdmi0_out: endpoint {
>>> + remote-endpoint = <&hdmi0_con>;
>>> + };
>>> + };
>>> + };
>>> +};
>>> +
>>> +&hdmi0_con {
>>> + remote-endpoint = <&rcar_dw_hdmi0_out>;
>>> +};
>>
>> I think the hdmi0 and hdmi0_con parts can be moved to salvator-common.dtsi.
>> Can we do that now (with stubs?), or does this have to wait until r8a77965
>> has
>> received HDMI sound support?
>
> I don't know about the sound integration I'm afraid, but common HDMI
> connections
> would certainly be a benefit I believe.
>
> Is this something you're looking to tackle? Or would you like
> me/Morimoto-san/media team to look at it?
Feel free to give it a try.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
Hi Geert,
On 28/05/18 10:06, Geert Uytterhoeven wrote:
> Hi Kieran, Morimoto-san,
>
> On Fri, Apr 27, 2018 at 6:57 PM, Kieran Bingham
> wrote:
>> The DU1 external dot clock is provided by the fixed frequency clock
>> generator X21, while the DU0 and DU3 clocks are provided by the
>> programmable Versaclock5 clock generator.
>>
>> Enable the clocks, and the HDMI encoder for the M3-N Salvator-X board
>> and hook it up to the HDMI connector.
>>
>> Based on patches from Takeshi Kihara
>>
>> Signed-off-by: Kieran Bingham
>>
>> ---
>> v2:
>> - Remove LVDS clocks from DU node
>> - Merge DU Clocks and HDMI enablement
>> ---
>> .../boot/dts/renesas/r8a77965-salvator-x.dts | 28 +++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
>> b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
>> index 75d890d91df9..340a3c72b65a 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-x.dts
>> @@ -19,3 +19,31 @@
>> reg = <0x0 0x4800 0x0 0x7800>;
>> };
>> };
>> +
>> +&du {
>> + clocks = <&cpg CPG_MOD 724>,
>> +<&cpg CPG_MOD 723>,
>> +<&cpg CPG_MOD 721>,
>> +<&versaclock5 1>,
>> +<&x21_clk>,
>> +<&versaclock5 2>;
>> + clock-names = "du.0", "du.1", "du.3",
>> + "dclkin.0", "dclkin.1", "dclkin.3";
>> +};
>> +
>> +&hdmi0 {
>> + status = "okay";
>> +
>> + ports {
>> + port@1 {
>> + reg = <1>;
>> + rcar_dw_hdmi0_out: endpoint {
>> + remote-endpoint = <&hdmi0_con>;
>> + };
>> + };
>> + };
>> +};
>> +
>> +&hdmi0_con {
>> + remote-endpoint = <&rcar_dw_hdmi0_out>;
>> +};
>
> I think the hdmi0 and hdmi0_con parts can be moved to salvator-common.dtsi.
> Can we do that now (with stubs?), or does this have to wait until r8a77965 has
> received HDMI sound support?
I don't know about the sound integration I'm afraid, but common HDMI connections
would certainly be a benefit I believe.
Is this something you're looking to tackle? Or would you like
me/Morimoto-san/media team to look at it?
--
Regards
Kieran
> Gr{oetje,eeting}s,
>
> Geert
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/etnaviv: properly implement mmaping of imported buffers
Am Dienstag, den 29.05.2018, 10:20 +0200 schrieb Daniel Vetter:
> On Fri, May 25, 2018 at 03:42:54PM +0200, Lucas Stach wrote:
> > The intention of the existing code was to deflect the actual work
> > of mmaping a dma-buf to the exporter, as that one probably knows best
> > how to handle the buffer. Unfortunately the call to drm_gem_mmap did
> > more than what etnaviv needs in this case by actually setting up the
> > mapping.
> >
> > Move mapping setup to the shm buffer type mmap implementation so we
> > only need to look up the BO and call the buffer type mmap function
> > from the handler.
> >
> > Fixes mmap behavior with dma-buf imported and userptr buffers.
>
> You allow mmap on userptr buffers? That sounds really nasty ...
No, we don't because that's obviously crazy, even more so on ARM with
it's special rules about aliasing mappings. The current code is buggy
in that it first sets up the mapping and then tells userspace the mmap
failed. After this patch we properly reject userptr mmap outright.
> Also not really thrilled about dma-buf mmap forwarding either, since you
> don't seem to forward the begin/end_cpu_access stuff either.
Yeah, that's still missing, but IMHO more of a correctness fix (which
can be done in a follow on patch), distinct of the bugfix in this
patch.
Regards,
Lucas
> -Daniel
>
> > Signed-off-by: Lucas Stach
> > ---
> > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 30 ---
> > 1 file changed, 23 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > index fcc969fa0e69..f38989960d7f 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > @@ -138,6 +138,13 @@ static int etnaviv_gem_mmap_obj(struct
> > etnaviv_gem_object *etnaviv_obj,
> > struct vm_area_struct *vma)
> > {
> > pgprot_t vm_page_prot;
> > + int ret;
> > +
> > + ret = drm_gem_mmap_obj(&etnaviv_obj->base,
> > + drm_vma_node_size(&etnaviv_obj->base.vma_node) << PAGE_SHIFT,
> > + vma);
> > + if (ret)
> > + return ret;
> >
> > vma->vm_flags &= ~VM_PFNMAP;
> > vma->vm_flags |= VM_MIXEDMAP;
> > @@ -167,17 +174,26 @@ static int etnaviv_gem_mmap_obj(struct
> > etnaviv_gem_object *etnaviv_obj,
> >
> > int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct *vma)
> > {
> > - struct etnaviv_gem_object *obj;
> > + struct drm_file *priv = filp->private_data;
> > + struct etnaviv_gem_object *etnaviv_obj;
> > + struct drm_gem_object *obj;
> > int ret;
> >
> > - ret = drm_gem_mmap(filp, vma);
> > - if (ret) {
> > - DBG("mmap failed: %d", ret);
> > - return ret;
> > + obj = drm_gem_bo_vm_lookup(filp, vma);
> > + if (!obj)
> > + return -EINVAL;
> > +
> > + if (!drm_vma_node_is_allowed(&obj->vma_node, priv)) {
> > + drm_gem_object_put_unlocked(obj);
> > + return -EACCES;
> > }
> >
> > - obj = to_etnaviv_bo(vma->vm_private_data);
> > - return obj->ops->mmap(obj, vma);
> > + etnaviv_obj = to_etnaviv_bo(obj);
> > +
> > + ret = etnaviv_obj->ops->mmap(etnaviv_obj, vma);
> > + drm_gem_object_put_unlocked(obj);
> > +
> > + return ret;
> > }
> >
> > int etnaviv_gem_fault(struct vm_fault *vmf)
> > --
> > 2.17.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] Add udmabuf misc device
Hi,
> > +static void *kmap_atomic_udmabuf(struct dma_buf *buf, unsigned long
> > page_num)
> > +{
> > + struct udmabuf *ubuf = buf->priv;
> > + struct page *page = ubuf->pages[page_num];
> > +
> > + return kmap_atomic(page);
> > +}
> > +
> > +static void *kmap_udmabuf(struct dma_buf *buf, unsigned long page_num)
> > +{
> > + struct udmabuf *ubuf = buf->priv;
> > + struct page *page = ubuf->pages[page_num];
> > +
> > + return kmap(page);
> > +}
>
> The above leaks like mad since no kunamp?
/me checks code. Oops. Yes.
The docs say map() is required and unmap() is not (for both atomic and
non-atomic cases), so I assumed there is a default implementation just
doing kunmap(page). Which is not the case. /me looks a bit surprised.
I'll fix it for v4.
> Also I think we have 0 users of the kmap atomic interfaces ... so not sure
> whether it's worth it to implement those.
Well, the docs are correct. kmap_atomic() is required, dma-buf.c calls
the function pointer without checking it exists beforehand ...
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] Add udmabuf misc device
On Tue, May 29, 2018 at 10:23:27AM +0200, Daniel Vetter wrote:
> On Fri, May 25, 2018 at 04:08:08PM +0200, Gerd Hoffmann wrote:
> > A driver to let userspace turn memfd regions into dma-bufs.
> >
> > Use case: Allows qemu create dmabufs for the vga framebuffer or
> > virtio-gpu ressources. Then they can be passed around to display
> > those guest things on the host. To spice client for classic full
> > framebuffer display, and hopefully some day to wayland server for
> > seamless guest window display.
> >
> > Note: Initial revision which supports a single region only so it
> > can't handle virtio-gpu ressources yet.
> >
> > qemu test branch:
> > https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
> >
> > Cc: David Airlie
> > Cc: Tomeu Vizoso
> > Cc: Daniel Vetter
> > Signed-off-by: Gerd Hoffmann
> > ---
> > include/uapi/linux/udmabuf.h | 19 ++
> > drivers/dma-buf/udmabuf.c | 240
> > ++
> > tools/testing/selftests/drivers/dma-buf/udmabuf.c | 95 +
> > drivers/dma-buf/Kconfig | 7 +
> > drivers/dma-buf/Makefile | 1 +
> > tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
> > 6 files changed, 367 insertions(+)
> > create mode 100644 include/uapi/linux/udmabuf.h
> > create mode 100644 drivers/dma-buf/udmabuf.c
> > create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
> > create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
> >
> > diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
> > new file mode 100644
> > index 00..2fbe69cf05
> > --- /dev/null
> > +++ b/include/uapi/linux/udmabuf.h
> > @@ -0,0 +1,19 @@
> > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > +#ifndef _UAPI_LINUX_UDMABUF_H
> > +#define _UAPI_LINUX_UDMABUF_H
> > +
> > +#include
> > +#include
> > +
> > +#define UDMABUF_FLAGS_CLOEXEC 0x01
> > +
> > +struct udmabuf_create {
> > + __u32 memfd;
> > + __u32 flags;
> > + __u64 offset;
> > + __u64 size;
> > +};
> > +
> > +#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create)
> > +
> > +#endif /* _UAPI_LINUX_UDMABUF_H */
> > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> > new file mode 100644
> > index 00..f9600dc985
> > --- /dev/null
> > +++ b/drivers/dma-buf/udmabuf.c
> > @@ -0,0 +1,240 @@
> > +/*
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +struct udmabuf {
> > + struct file *filp;
> > + u32 pagecount;
> > + struct page **pages;
> > +};
> > +
> > +static int udmabuf_vm_fault(struct vm_fault *vmf)
> > +{
> > + struct vm_area_struct *vma = vmf->vma;
> > + struct udmabuf *ubuf = vma->vm_private_data;
> > +
> > + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
> > + return VM_FAULT_SIGBUS;
> > +
> > + vmf->page = ubuf->pages[vmf->pgoff];
> > + get_page(vmf->page);
> > + return 0;
> > +}
> > +
> > +static const struct vm_operations_struct udmabuf_vm_ops = {
> > + .fault = udmabuf_vm_fault,
> > +};
> > +
> > +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
> > +{
> > + struct udmabuf *ubuf = buf->priv;
> > +
> > + if ((vma->vm_flags & VM_SHARED) == 0)
> > + return -EINVAL;
> > +
> > + vma->vm_ops = &udmabuf_vm_ops;
> > + vma->vm_private_data = ubuf;
> > + return 0;
> > +}
> > +
> > +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
> > + enum dma_data_direction direction)
> > +{
> > + struct udmabuf *ubuf = at->dmabuf->priv;
> > + struct sg_table *sg;
> > +
> > + sg = kzalloc(sizeof(*sg), GFP_KERNEL);
> > + if (!sg)
> > + goto err1;
> > + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
> > + 0, ubuf->pagecount << PAGE_SHIFT,
> > + GFP_KERNEL) < 0)
> > + goto err2;
> > + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
> > + goto err3;
> > +
> > + return sg;
> > +
> > +err3:
> > + sg_free_table(sg);
> > +err2:
> > + kfree(sg);
> > +err1:
> > + return ERR_PTR(-ENOMEM);
> > +}
> > +
> > +static void unmap_udmabuf(struct dma_buf_attachment *at,
> > + struct sg_table *sg,
> > + enum dma_data_direction direction)
> > +{
> > + sg_free_table(sg);
> > + kfree(sg);
> > +}
> > +
> > +static void release_udmabuf(struct dma_buf *buf)
> > +{
> > + struct udmabuf *ubuf = buf->priv;
> > + pgoff_t pg;
> > +
> > + for (pg = 0; pg < ubuf->pagecount; pg++)
> > + put_page(ubuf->
Re: [PATCH v4 30/41] drm/i915: Initialize HDCP2.2 and its MEI interface
On Tue, May 29, 2018 at 08:53:37AM +0200, Daniel Vetter wrote:
> On Fri, May 25, 2018 at 04:42:52PM +0530, Ramalingam C wrote:
> >
> >
> > On Thursday 24 May 2018 01:36 PM, Daniel Vetter wrote:
> > > On Mon, May 21, 2018 at 06:23:49PM +0530, Ramalingam C wrote:
> > > > Initialize HDCP2.2 support. This includes the mei interface
> > > > initialization along with required notifier registration.
> > > >
> > > > v2:
> > > >mei interface handle is protected with mutex. [Chris Wilson]
> > > > v3:
> > > >Notifiers are used for the mei interface state.
> > > > v4:
> > > >Poll for mei client device state
> > > >Error msg for out of mem [Uma]
> > > >Inline req for init function removed [Uma]
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 3 +-
> > > > drivers/gpu/drm/i915/intel_drv.h | 5 +-
> > > > drivers/gpu/drm/i915/intel_hdcp.c | 117
> > > > +-
> > > > drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
> > > > 4 files changed, 122 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 62f82c4298ac..276eb49113e9 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -6368,7 +6368,8 @@ intel_dp_init_connector(struct intel_digital_port
> > > > *intel_dig_port,
> > > > intel_dp_add_properties(intel_dp, connector);
> > > > if (is_hdcp_supported(dev_priv, port) &&
> > > > !intel_dp_is_edp(intel_dp)) {
> > > > - int ret = intel_hdcp_init(intel_connector,
> > > > &intel_dp_hdcp_shim);
> > > > + int ret = intel_hdcp_init(intel_connector,
> > > > &intel_dp_hdcp_shim,
> > > > + false);
> > > > if (ret)
> > > > DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
> > > > }
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index ac943ec73987..750fc19f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -442,7 +442,7 @@ struct intel_hdcp {
> > > > /* mei interface related information */
> > > > struct mei_cl_device *cldev;
> > > > struct mei_hdcp_data mei_data;
> > > > -
> > > > + struct notifier_block mei_cldev_nb;
> > > > struct delayed_work hdcp2_check_work;
> > > > };
> > > > @@ -1940,7 +1940,8 @@ void intel_hdcp_atomic_check(struct drm_connector
> > > > *connector,
> > > > struct drm_connector_state *old_state,
> > > > struct drm_connector_state *new_state);
> > > > int intel_hdcp_init(struct intel_connector *connector,
> > > > - const struct intel_hdcp_shim *hdcp_shim);
> > > > + const struct intel_hdcp_shim *hdcp_shim,
> > > > + bool hdcp2_supported);
> > > > int intel_hdcp_enable(struct intel_connector *connector);
> > > > int intel_hdcp_disable(struct intel_connector *connector);
> > > > int intel_hdcp_check_link(struct intel_connector *connector);
> > > > diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> > > > b/drivers/gpu/drm/i915/intel_hdcp.c
> > > > index f3f935046c31..9948e4b4e203 100644
> > > > --- a/drivers/gpu/drm/i915/intel_hdcp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> > > > @@ -11,6 +11,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include "intel_drv.h"
> > > > #include "i915_reg.h"
> > > > @@ -25,6 +26,7 @@ static int _intel_hdcp2_enable(struct intel_connector
> > > > *connector);
> > > > static int _intel_hdcp2_disable(struct intel_connector *connector);
> > > > static void intel_hdcp2_check_work(struct work_struct *work);
> > > > static int intel_hdcp2_check_link(struct intel_connector *connector);
> > > > +static int intel_hdcp2_init(struct intel_connector *connector);
> > > > static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port
> > > > *intel_dig_port,
> > > > const struct intel_hdcp_shim *shim)
> > > > @@ -766,11 +768,15 @@ bool is_hdcp_supported(struct drm_i915_private
> > > > *dev_priv, enum port port)
> > > > }
> > > > int intel_hdcp_init(struct intel_connector *connector,
> > > > - const struct intel_hdcp_shim *hdcp_shim)
> > > > + const struct intel_hdcp_shim *hdcp_shim,
> > > > + bool hdcp2_supported)
> > > > {
> > > > struct intel_hdcp *hdcp = &connector->hdcp;
> > > > int ret;
> > > > + if (!hdcp_shim)
> > > > + return -EINVAL;
> > > > +
> > > > ret = drm_connector_attach_content_protection_property(
> > > > &connector->base);
> > > > if (ret)
> > > > @@ -779,7 +785,12 @@ in
Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2
On Tue, May 29, 2018 at 07:51:56AM +, C, Ramalingam wrote: > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Tuesday, May 29, 2018 12:27 PM > > To: C, Ramalingam > > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > > seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk; > > jani.nik...@linux.intel.com; Winkler, Tomas ; > > Usyskin, Alexander ; Shankar, Uma > > ; Sharma, Shashank > > Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2 > > > > On Mon, May 21, 2018 at 06:23:19PM +0530, Ramalingam C wrote: > > > The sequence for HDCP2.2 authentication and encryption is implemented > > > in I915. Encoder specific implementations are moved into hdcp_shim. > > > > > > Intel HWs supports HDCP2.2 through ME FW. Hence this series introduces > > > a client driver for mei bus, so that for HDCP2.2 authentication, > > > HDCP2.2 stack in I915 can avail the services from ME FW. > > > > > > DRM_I915 selects INTEL_MEI_HDCP, which selects INTEL_MEI_ME and > > > INTEL_MEI. If we are interested in disabling the MEI_HDCP and MEI Bus > > > then we need an option to disable the HDCP2.2 in I915 (like > > > DRM_I915_HDCP2.2!?). Till then they are binded. > > > > > > Userspace interface remains unchanged as version agnostic. When > > > userspace request for HDCP enable, Kernel will detect the HDCP source > > > and sink's HDCP version(1.4/2.2)capability and enable the best capable > > > version for that combination. > > > > > > This series enables the HDCP2.2 for Type0 content streams. > > > > > > Thanks a lot for Usyskin, Alexander and Uma shankar for the review of v3. > > > Thanks Daniel vetter for guiding me to test and confirm that there is > > > no locking issue with respect to notifier usage between I915 and MEI_HDCP. > > > > > > Major Changes in v4: > > > - GMBus Changes to implement the burst read as generic > > > [Jani, Ville and Daniel] > > > - Polling is added for extra Notifier notification when I915 and > > > MEI_HDCP are modules. > > > - Comment and style issues and typos are fixed [Uma and Alexander] > > > - INTEL_MEI_HDCP, INTEL_MEI_ME and INTEL_MEI are selected by I915. > > > - Fixed the #if in include/linux/mei_hdcp.h for build issues. > > > > > > GMBus changes are added here for completeness of the series. They are > > > in review at https://patchwork.freedesktop.org/series/41632/ also. > > > > Please reply with a link to your github here (and include it in your next > > cover > > letter too). I can't ever find it when I need it :-/ > > You can find a github repo for HDCP2.2 v4 series at > https://github.com/ramalingampc2008/drm-tip Even nicer if you directly supply what I need to feed to git fetch (like a git pull request over email): https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_v4 Then I can do a git fetch && git checkout FETCH_HEAD. Thanks, Daniel > > Thanks, > Ram > > > > > Thanks, Daniel > > > > > > > > Ramalingam C (40): > > > drm: hdcp2.2 authentication msg definitions > > > drm: HDMI and DP specific HDCP2.2 defines > > > misc/mei/hdcp: Client driver for HDCP application > > > misc/mei/hdcp: Notifier chain for mei cldev state change > > > misc/mei/hdcp: Define ME FW interface for HDCP2.2 > > > linux/mei: Header for mei_hdcp driver interface > > > misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session > > > misc/mei/hdcp: Verify Receiver Cert and prepare km > > > misc/mei/hdcp: Verify H_prime > > > misc/mei/hdcp: Store the HDCP Pairing info > > > misc/mei/hdcp: Initiate Locality check > > > misc/mei/hdcp: Verify L_prime > > > misc/mei/hdcp: Prepare Session Key > > > misc/mei/hdcp: Repeater topology verification and ack > > > misc/mei/hdcp: Verify M_prime > > > misc/mei/hdcp: Enabling the HDCP authentication > > > misc/mei/hdcp: Closing wired HDCP2.2 Tx Session > > > drm/i915: wrapping all hdcp var into intel_hdcp > > > drm/i915: Define HDCP2.2 related variables > > > drm/i915: Define Intel HDCP2.2 registers > > > drm/i915: Wrappers for mei HDCP2.2 services > > > drm/i915: Implement HDCP2.2 receiver authentication > > > drm/i915: Implement HDCP2.2 repeater authentication > > > drm/i915: Enable and Disable HDCP2.2 port encryption > > > drm/i915: Implement HDCP2.2 En/Dis-able > > > drm/i915: Implement HDCP2.2 link integrity check > > > drm/i915: Handle HDCP2.2 downstream topology change > > > drm/i915: Pullout the bksv read and validation > > > drm/i915: Initialize HDCP2.2 and its MEI interface > > > drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable > > > drm/i915: Enable superior HDCP ver that is capable > > > drm/i915: Enable HDCP1.4 incase of HDCP2.2 failure > > > drm/i915: hdcp_check_link only on CP_IRQ > > > drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ > > > drm/i915/gmbus: Increase the Bytes per Rd/Wr Op > > > drm/i915/gmbus: Enable burst read > > > drm/i915: Implem
Re: [PATCH v7 1/4] drm/bridge: add support for sn65dsi86 bridge driver
On 24.05.2018 18:41, Sandeep Panda wrote: > Add support for TI's sn65dsi86 dsi2edp bridge chip. > The chip converts DSI transmitted signal to eDP signal, > which is fed to the connected eDP panel. > > This chip can be controlled via either i2c interface or > dsi interface. Currently in driver all the control registers > are being accessed through i2c interface only. > Also as of now HPD support has not been added to bridge > chip driver. > > Changes in v1: > - Split the dt-bindings and the driver support into separate patches >(Andrzej Hajda). > - Use of gpiod APIs to parse and configure gpios instead of obsolete ones >(Andrzej Hajda). > - Use macros to define the register offsets (Andrzej Hajda). > > Changes in v2: > - Separate out edp panel specific HW resource handling from bridge >driver and create a separate edp panel drivers to handle panel >specific mode information and HW resources (Sean Paul). > - Replace pr_* APIs to DRM_* APIs to log error or debug information >(Sean Paul). > - Remove some of the unnecessary structure/variable from driver (Sean >Paul). > - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge" >(Sean Paul / Rob Herring). > - Remove most of the hard-coding and modified the bridge init sequence >based on current mode (Sean Paul). > - Remove the existing function to retrieve the EDID data and >implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul). > - Remove the dummy irq handler implementation, will add back the >proper irq handling later (Sean Paul). > - Capture the required enable gpios in a single array based on dt entry >instead of having individual descriptor for each gpio (Sean Paul). > > Changes in v3: > - Remove usage of irq_gpio and replace it as "interrupts" property (Rob >Herring). > - Remove the unnecessary header file inclusions (Sean Paul). > - Rearrange the header files in alphabetical order (Sean Paul). > - Use regmap interface to perform i2c transactions. > - Update Copyright/License field and address other review comments >(Jordan Crouse). > > Changes in v4: > - Update License/Copyright (Sean Paul). > - Add Kconfig and Makefile changes (Sean Paul). > - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios >will be handled by i2c master. > - Update required supplies names. > - Remove unnecessary goto statements (Sean Paul). > - Add mutex lock to power_ctrl API to avoid race conditions (Sean >Paul). > - Add support to parse reference clk frequency from dt(optional). > - Update the bridge chip enable/disable sequence. > > Changes in v5: > - Fixed Kbuild test service reported warnings. > > Changes in v6: > - Use PM runtime based ref-counting instead of local ref_count mechanism >(Stephen Boyd). > - Clean up some debug logs and indentations (Sean Paul). > - Simplify dp rate calculation (Sean Paul). > - Add support to configure refclk based on input REFCLK pin or DACP/N >pin (Stephen Boyd). > > Changes in v7: > - Use static supply entries instead of dynamic allocation (Andrzej >Hajda). > - Defer bridge driver probe if panel is not probed (Andrzej Hajda). > - Update of_graph APIs for correct node reference management. (Andrzej >Hajda). > - Remove local display_mode object (Andrzej Hajda). > - Remove version id check function from driver. > > Signed-off-by: Sandeep Panda > --- > drivers/gpu/drm/bridge/Kconfig| 9 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 675 > ++ > 3 files changed, 685 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 3b99d5a..8153150 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -108,6 +108,15 @@ config DRM_TI_TFP410 > ---help--- > Texas Instruments TFP410 DVI/HDMI Transmitter driver > > +config DRM_TI_SN65DSI86 > + tristate "TI SN65DSI86 DSI to eDP bridge" > + depends on OF > + select DRM_KMS_HELPER > + select REGMAP_I2C > + select DRM_PANEL > + ---help--- > + Texas Instruments SN65DSI86 DSI to eDP Bridge driver > + > source "drivers/gpu/drm/bridge/analogix/Kconfig" > > source "drivers/gpu/drm/bridge/adv7511/Kconfig" > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index 373eb28..3711be8 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -12,4 +12,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/ > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > +obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-y += synopsys/ > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > new file mode 100644
Re: [PATCH v3] Add udmabuf misc device
On Fri, May 25, 2018 at 04:08:08PM +0200, Gerd Hoffmann wrote:
> A driver to let userspace turn memfd regions into dma-bufs.
>
> Use case: Allows qemu create dmabufs for the vga framebuffer or
> virtio-gpu ressources. Then they can be passed around to display
> those guest things on the host. To spice client for classic full
> framebuffer display, and hopefully some day to wayland server for
> seamless guest window display.
>
> Note: Initial revision which supports a single region only so it
> can't handle virtio-gpu ressources yet.
>
> qemu test branch:
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
>
> Cc: David Airlie
> Cc: Tomeu Vizoso
> Cc: Daniel Vetter
> Signed-off-by: Gerd Hoffmann
> ---
> include/uapi/linux/udmabuf.h | 19 ++
> drivers/dma-buf/udmabuf.c | 240
> ++
> tools/testing/selftests/drivers/dma-buf/udmabuf.c | 95 +
> drivers/dma-buf/Kconfig | 7 +
> drivers/dma-buf/Makefile | 1 +
> tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
> 6 files changed, 367 insertions(+)
> create mode 100644 include/uapi/linux/udmabuf.h
> create mode 100644 drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
> create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
>
> diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
> new file mode 100644
> index 00..2fbe69cf05
> --- /dev/null
> +++ b/include/uapi/linux/udmabuf.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef _UAPI_LINUX_UDMABUF_H
> +#define _UAPI_LINUX_UDMABUF_H
> +
> +#include
> +#include
> +
> +#define UDMABUF_FLAGS_CLOEXEC0x01
> +
> +struct udmabuf_create {
> + __u32 memfd;
> + __u32 flags;
> + __u64 offset;
> + __u64 size;
> +};
> +
> +#define UDMABUF_CREATE _IOW(0x42, 0x23, struct udmabuf_create)
> +
> +#endif /* _UAPI_LINUX_UDMABUF_H */
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> new file mode 100644
> index 00..f9600dc985
> --- /dev/null
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -0,0 +1,240 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct udmabuf {
> + struct file *filp;
> + u32 pagecount;
> + struct page **pages;
> +};
> +
> +static int udmabuf_vm_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct udmabuf *ubuf = vma->vm_private_data;
> +
> + if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
> + return VM_FAULT_SIGBUS;
> +
> + vmf->page = ubuf->pages[vmf->pgoff];
> + get_page(vmf->page);
> + return 0;
> +}
> +
> +static const struct vm_operations_struct udmabuf_vm_ops = {
> + .fault = udmabuf_vm_fault,
> +};
> +
> +static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
> +{
> + struct udmabuf *ubuf = buf->priv;
> +
> + if ((vma->vm_flags & VM_SHARED) == 0)
> + return -EINVAL;
> +
> + vma->vm_ops = &udmabuf_vm_ops;
> + vma->vm_private_data = ubuf;
> + return 0;
> +}
> +
> +static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
> + enum dma_data_direction direction)
> +{
> + struct udmabuf *ubuf = at->dmabuf->priv;
> + struct sg_table *sg;
> +
> + sg = kzalloc(sizeof(*sg), GFP_KERNEL);
> + if (!sg)
> + goto err1;
> + if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
> + 0, ubuf->pagecount << PAGE_SHIFT,
> + GFP_KERNEL) < 0)
> + goto err2;
> + if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
> + goto err3;
> +
> + return sg;
> +
> +err3:
> + sg_free_table(sg);
> +err2:
> + kfree(sg);
> +err1:
> + return ERR_PTR(-ENOMEM);
> +}
> +
> +static void unmap_udmabuf(struct dma_buf_attachment *at,
> + struct sg_table *sg,
> + enum dma_data_direction direction)
> +{
> + sg_free_table(sg);
> + kfree(sg);
> +}
> +
> +static void release_udmabuf(struct dma_buf *buf)
> +{
> + struct udmabuf *ubuf = buf->priv;
> + pgoff_t pg;
> +
> + for (pg = 0; pg < ubuf->pagecount; pg++)
> + put_page(ubuf->pages[pg]);
> + fput(ubuf->filp);
> + kfree(ubuf->pages);
> + kfree(ubuf);
> +}
> +
> +static void *kmap_atomic_udmabuf(struct dma_buf *buf, unsigned long page_num)
> +{
> + struct udmabuf *ubuf = buf->priv;
> + struct page *page = ubuf->pages[page_num];
> +
> +
Re: [PATCH 2/2] drm/etnaviv: properly implement mmaping of imported buffers
On Fri, May 25, 2018 at 03:42:54PM +0200, Lucas Stach wrote:
> The intention of the existing code was to deflect the actual work
> of mmaping a dma-buf to the exporter, as that one probably knows best
> how to handle the buffer. Unfortunately the call to drm_gem_mmap did
> more than what etnaviv needs in this case by actually setting up the
> mapping.
>
> Move mapping setup to the shm buffer type mmap implementation so we
> only need to look up the BO and call the buffer type mmap function
> from the handler.
>
> Fixes mmap behavior with dma-buf imported and userptr buffers.
You allow mmap on userptr buffers? That sounds really nasty ...
Also not really thrilled about dma-buf mmap forwarding either, since you
don't seem to forward the begin/end_cpu_access stuff either.
-Daniel
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 30 ---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index fcc969fa0e69..f38989960d7f 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -138,6 +138,13 @@ static int etnaviv_gem_mmap_obj(struct
> etnaviv_gem_object *etnaviv_obj,
> struct vm_area_struct *vma)
> {
> pgprot_t vm_page_prot;
> + int ret;
> +
> + ret = drm_gem_mmap_obj(&etnaviv_obj->base,
> + drm_vma_node_size(&etnaviv_obj->base.vma_node) << PAGE_SHIFT,
> + vma);
> + if (ret)
> + return ret;
>
> vma->vm_flags &= ~VM_PFNMAP;
> vma->vm_flags |= VM_MIXEDMAP;
> @@ -167,17 +174,26 @@ static int etnaviv_gem_mmap_obj(struct
> etnaviv_gem_object *etnaviv_obj,
>
> int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct *vma)
> {
> - struct etnaviv_gem_object *obj;
> + struct drm_file *priv = filp->private_data;
> + struct etnaviv_gem_object *etnaviv_obj;
> + struct drm_gem_object *obj;
> int ret;
>
> - ret = drm_gem_mmap(filp, vma);
> - if (ret) {
> - DBG("mmap failed: %d", ret);
> - return ret;
> + obj = drm_gem_bo_vm_lookup(filp, vma);
> + if (!obj)
> + return -EINVAL;
> +
> + if (!drm_vma_node_is_allowed(&obj->vma_node, priv)) {
> + drm_gem_object_put_unlocked(obj);
> + return -EACCES;
> }
>
> - obj = to_etnaviv_bo(vma->vm_private_data);
> - return obj->ops->mmap(obj, vma);
> + etnaviv_obj = to_etnaviv_bo(obj);
> +
> + ret = etnaviv_obj->ops->mmap(etnaviv_obj, vma);
> + drm_gem_object_put_unlocked(obj);
> +
> + return ret;
> }
>
> int etnaviv_gem_fault(struct vm_fault *vmf)
> --
> 2.17.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/scheduler: add documentation
On Mon, May 28, 2018 at 02:01:49PM +0530, Nayan Deshmukh wrote:
> I have done that already, sent a patch with this one. The last patch
> of this series. I have tried to take care of all the hyperlinks.
Oh great, was jumping to conclusions. Usually I do that first, so that I
can see mistakes while I write out the docs. But doing it last also works
...
Ack on the series fwiw.
-Daniel
>
> On Mon, May 28, 2018 at 1:39 PM, Daniel Vetter wrote:
> > On Fri, May 25, 2018 at 6:45 AM, Nayan Deshmukh
> > wrote:
> >> convert existing raw comments into kernel-doc format as well
> >> as add new documentation
> >>
> >> Signed-off-by: Alex Deucher
> >> Signed-off-by: Nayan Deshmukh
> >> ---
> >> drivers/gpu/drm/scheduler/gpu_scheduler.c | 214
> >> --
> >> include/drm/gpu_scheduler.h | 153 +
> >> 2 files changed, 296 insertions(+), 71 deletions(-)
> >
> > Please also include all the new scheduler docs into
> > Documentation/gpu/drm-mm.rst (I think that's the most suitable place)
> > and make sure the resulting docs look good and hyperlinks all work
> > correctly using
> >
> > $ make htmldocs
> >
> > Thanks, Daniel
> >
> >>
> >> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> >> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> >> index 44d480768dfe..c70c983e3e74 100644
> >> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> >> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> >> @@ -21,6 +21,29 @@
> >> *
> >> */
> >>
> >> +/**
> >> + * DOC: Overview
> >> + *
> >> + * The GPU scheduler provides entities which allow userspace to push jobs
> >> + * into software queues which are then scheduled on a hardware run queue.
> >> + * The software queues have a priority among them. The scheduler selects
> >> the entities
> >> + * from the run queue using FIFO. The scheduler provides dependency
> >> handling
> >> + * features among jobs. The driver is supposed to provide functions for
> >> backend
> >> + * operations to the scheduler like submitting a job to hardware run
> >> queue,
> >> + * returning the dependency of a job etc.
> >> + *
> >> + * The organisation of the scheduler is the following:-
> >> + *
> >> + * 1. Each ring buffer has one scheduler
> >> + * 2. Each scheduler has multiple run queues with different priorities
> >> + *(i.e. HIGH_HW,HIGH_SW, KERNEL, NORMAL)
> >> + * 3. Each run queue has a queue of entities to schedule
> >> + * 4. Entities themselves maintain a queue of jobs that will be scheduled
> >> on
> >> + *the hardware.
> >> + *
> >> + * The jobs in a entity are always scheduled in the order that they were
> >> pushed.
> >> + */
> >> +
> >> #include
> >> #include
> >> #include
> >> @@ -39,7 +62,13 @@ static bool drm_sched_entity_is_ready(struct
> >> drm_sched_entity *entity);
> >> static void drm_sched_wakeup(struct drm_gpu_scheduler *sched);
> >> static void drm_sched_process_job(struct dma_fence *f, struct
> >> dma_fence_cb *cb);
> >>
> >> -/* Initialize a given run queue struct */
> >> +/**
> >> + * drm_sched_rq_init - initialize a given run queue struct
> >> + *
> >> + * @rq: scheduler run queue
> >> + *
> >> + * Initializes a scheduler runqueue.
> >> + */
> >> static void drm_sched_rq_init(struct drm_sched_rq *rq)
> >> {
> >> spin_lock_init(&rq->lock);
> >> @@ -47,6 +76,14 @@ static void drm_sched_rq_init(struct drm_sched_rq *rq)
> >> rq->current_entity = NULL;
> >> }
> >>
> >> +/**
> >> + * drm_sched_rq_add_entity - add an entity
> >> + *
> >> + * @rq: scheduler run queue
> >> + * @entity: scheduler entity
> >> + *
> >> + * Adds a scheduler entity to the run queue.
> >> + */
> >> static void drm_sched_rq_add_entity(struct drm_sched_rq *rq,
> >> struct drm_sched_entity *entity)
> >> {
> >> @@ -57,6 +94,14 @@ static void drm_sched_rq_add_entity(struct drm_sched_rq
> >> *rq,
> >> spin_unlock(&rq->lock);
> >> }
> >>
> >> +/**
> >> + * drm_sched_rq_remove_entity - remove an entity
> >> + *
> >> + * @rq: scheduler run queue
> >> + * @entity: scheduler entity
> >> + *
> >> + * Removes a scheduler entity from the run queue.
> >> + */
> >> static void drm_sched_rq_remove_entity(struct drm_sched_rq *rq,
> >>struct drm_sched_entity *entity)
> >> {
> >> @@ -70,9 +115,9 @@ static void drm_sched_rq_remove_entity(struct
> >> drm_sched_rq *rq,
> >> }
> >>
> >> /**
> >> - * Select an entity which could provide a job to run
> >> + * drm_sched_rq_select_entity - Select an entity which could provide a
> >> job to run
> >> *
> >> - * @rq The run queue to check.
> >> + * @rq: scheduler run queue to check.
> >> *
> >> * Try to find a ready entity, returns NULL if none found.
> >> */
> >> @@ -112,15 +157,16 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
> >> }
> >>
> >> /**
> >> - * Init a context entity used by scheduler when submit to HW ring.
> >> + * drm_sched_entity_init - Init a
Re: [PATCH] drm: Add checks for NULL drm_*_helper_funcs
On Fri, May 25, 2018 at 05:20:08AM +0300, Haneen Mohammed wrote:
> This patch add checks for NULL drm_[connector/crtc/plane]_helper_funcs
> pointers before derefrencing the variable to avoid NULL pointer
> dereference and make the helper functions as optional as possible.
>
> Signed-off-by: Haneen Mohammed
I started reviewing this, and then realized it's a bit a can of worms.
E.g. connector->funcs->detect shouldn't be there, it's a helper callback
really (but placed in the wrong function table). So connector->funcs isn't
optional, but connector->funcs->detect maybe should be optional.
So I'm not sure anymore whether doing this holesale is a good idea. Do we
still need this for vkms? If yes, then a more focused patch to just make
the things optional that vkms does not (yet) provide might be better.
Including an explanation of what exactly blows up in vkms.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 42 +++--
> drivers/gpu/drm/drm_probe_helper.c | 11
> 2 files changed, 28 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c35654591c12..52092deb741d 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -112,9 +112,9 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state,
> if (!new_conn_state->crtc)
> continue;
>
> - if (funcs->atomic_best_encoder)
> + if (funcs && funcs->atomic_best_encoder)
> new_encoder = funcs->atomic_best_encoder(connector,
> new_conn_state);
> - else if (funcs->best_encoder)
> + else if (funcs && funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> else
> new_encoder = drm_atomic_helper_best_encoder(connector);
> @@ -308,10 +308,10 @@ update_connector_routing(struct drm_atomic_state *state,
>
> funcs = connector->helper_private;
>
> - if (funcs->atomic_best_encoder)
> + if (funcs && funcs->atomic_best_encoder)
> new_encoder = funcs->atomic_best_encoder(connector,
>new_connector_state);
> - else if (funcs->best_encoder)
> + else if (funcs && funcs->best_encoder)
> new_encoder = funcs->best_encoder(connector);
> else
> new_encoder = drm_atomic_helper_best_encoder(connector);
> @@ -438,7 +438,7 @@ mode_fixup(struct drm_atomic_state *state)
> continue;
>
> funcs = crtc->helper_private;
> - if (!funcs->mode_fixup)
> + if (!funcs || !funcs->mode_fixup)
> continue;
>
> ret = funcs->mode_fixup(crtc, &new_crtc_state->mode,
> @@ -639,7 +639,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> new_crtc_state->connectors_changed = true;
> }
>
> - if (funcs->atomic_check)
> + if (funcs && funcs->atomic_check)
> ret = funcs->atomic_check(connector,
> new_connector_state);
> if (ret)
> return ret;
> @@ -681,7 +681,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (connectors_mask & BIT(i))
> continue;
>
> - if (funcs->atomic_check)
> + if (funcs && funcs->atomic_check)
> ret = funcs->atomic_check(connector,
> new_connector_state);
> if (ret)
> return ret;
> @@ -972,14 +972,16 @@ disable_outputs(struct drm_device *dev, struct
> drm_atomic_state *old_state)
>
>
> /* Right function depends upon target state. */
> - if (new_crtc_state->enable && funcs->prepare)
> - funcs->prepare(crtc);
> - else if (funcs->atomic_disable)
> - funcs->atomic_disable(crtc, old_crtc_state);
> - else if (funcs->disable)
> - funcs->disable(crtc);
> - else
> - funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> + if (funcs) {
> + if (new_crtc_state->enable && funcs->prepare)
> + funcs->prepare(crtc);
> + else if (funcs->atomic_disable)
> + funcs->atomic_disable(crtc, old_crtc_state);
> + else if (funcs->disable)
> + funcs->disable(crtc);
> + else
> + funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> + }
>
> if (!(dev->irq_enabled && dev->num_crtcs))
> continue;
> @@ -1093,7 +1095,7 @@ crtc_set_mode(struct drm_device *dev, struct
> drm_atomic_state *old_state)
>
>
Re: [Xen-devel] [PATCH 3/8] drm/xen-front: fix 32-bit build warning
On Tue, May 29, 2018 at 7:58 AM, Oleksandr Andrushchenko
wrote:
> On 05/25/2018 06:50 PM, Arnd Bergmann wrote:
>> b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
>> index 8099cb343ae3..d333b67cc1a0 100644
>> --- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
>> +++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
>> @@ -122,7 +122,7 @@ static void guest_calc_num_grefs(struct
>> xen_drm_front_shbuf *buf)
>> }
>> #define xen_page_to_vaddr(page) \
>> - ((phys_addr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
>> + ((uintptr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
>> static int backend_unmap(struct xen_drm_front_shbuf *buf)
>> {
>
> Thank you for your patch: this issue was already discussed [1] and applied
> [2] to
> drm-misc-next.
Ok, thanks, and sorry for the duplicate. Linux-next releases have been
a bit sporadic recently so I didn't run the latest tree for all cases.
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add checks for atomic_[duplicate/destroy]_state with atomic drivers
On Thu, May 24, 2018 at 09:43:50PM -0400, Sean Paul wrote:
> On Thu, May 24, 2018, 9:26 PM Haneen Mohammed
> wrote:
>
> > This patch add checks for atomic_[duplicate/destroy]_state of
> > drm_[connector/crtc/plane]_funcs for atomic drivers in the relevant
> > drm_*_init functions since these callback are mandatory for atomic drivers.
> >
> > Update the kerneldoc comments for those callbacks.
> >
> > Signed-off-by: Haneen Mohammed
> >
>
> Reviewed-by: Sean Paul
Applied, thanks for the patch&review.
-Daniel
>
> ---
> > drivers/gpu/drm/drm_connector.c | 4
> > drivers/gpu/drm/drm_crtc.c | 4
> > drivers/gpu/drm/drm_plane.c | 4
> > include/drm/drm_connector.h | 4
> > include/drm/drm_crtc.h | 4
> > include/drm/drm_plane.h | 4
> > 6 files changed, 24 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index b3cde897cd80..ab291f4f339a 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -195,6 +195,10 @@ int drm_connector_init(struct drm_device *dev,
> > struct ida *connector_ida =
> > &drm_connector_enum_list[connector_type].ida;
> >
> > + WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
> > + (!funcs->atomic_destroy_state ||
> > +!funcs->atomic_duplicate_state));
> > +
> > ret = __drm_mode_object_add(dev, &connector->base,
> > DRM_MODE_OBJECT_CONNECTOR,
> > false, drm_connector_free);
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 03583887cfec..d1933c5f2524 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -286,6 +286,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> > struct drm_crtc *crtc,
> > if (WARN_ON(config->num_crtc >= 32))
> > return -EINVAL;
> >
> > + WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
> > + (!funcs->atomic_destroy_state ||
> > +!funcs->atomic_duplicate_state));
> > +
> > crtc->dev = dev;
> > crtc->funcs = funcs;
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 6d2a6e428a3e..e0efb06eec31 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -177,6 +177,10 @@ int drm_universal_plane_init(struct drm_device *dev,
> > struct drm_plane *plane,
> > if (WARN_ON(config->num_total_plane >= 32))
> > return -EINVAL;
> >
> > + WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
> > + (!funcs->atomic_destroy_state ||
> > +!funcs->atomic_duplicate_state));
> > +
> > ret = drm_mode_object_add(dev, &plane->base,
> > DRM_MODE_OBJECT_PLANE);
> > if (ret)
> > return ret;
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 675cc3f8cf85..65b6c86ecd50 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -608,6 +608,8 @@ struct drm_connector_funcs {
> > * cleaned up by calling the @atomic_destroy_state hook in this
> > * structure.
> > *
> > +* This callback is mandatory for atomic drivers.
> > +*
> > * Atomic drivers which don't subclass &struct drm_connector_state
> > should use
> > * drm_atomic_helper_connector_duplicate_state(). Drivers that
> > subclass the
> > * state structure to extend it with driver-private state should
> > use
> > @@ -634,6 +636,8 @@ struct drm_connector_funcs {
> > *
> > * Destroy a state duplicated with @atomic_duplicate_state and
> > release
> > * or unreference all resources it references
> > +*
> > +* This callback is mandatory for atomic drivers.
> > */
> > void (*atomic_destroy_state)(struct drm_connector *connector,
> > struct drm_connector_state *state);
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index a2d81d2907a9..26511d6775d7 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -503,6 +503,8 @@ struct drm_crtc_funcs {
> > * cleaned up by calling the @atomic_destroy_state hook in this
> > * structure.
> > *
> > +* This callback is mandatory for atomic drivers.
> > +*
> > * Atomic drivers which don't subclass &struct drm_crtc_state
> > should use
> > * drm_atomic_helper_crtc_duplicate_state(). Drivers that subclass
> > the
> > * state structure to extend it with driver-private state should
> > use
> > @@ -529,6 +531,8 @@ struct drm_crtc_funcs {
> > *
> > * Destroy a state duplicated with @atomic_duplicate_state and
> > release
> > * or unreference all resources it references
> >
Re: [PATCH 5/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function
On Fri, May 25, 2018 at 02:42:02PM +0200, Noralf Trønnes wrote:
>
> Den 24.05.2018 11.16, skrev Daniel Vetter:
> > On Wed, May 23, 2018 at 04:34:07PM +0200, Noralf Trønnes wrote:
> > > This is the first step in getting generic fbdev emulation.
> > > A drm_fb_helper_funcs.fb_probe function is added which uses the
> > > DRM client API to get a framebuffer backed by a dumb buffer.
> > >
> > > A transitional hack for tinydrm is needed in order to switch over all
> > > CMA helper drivers in a later patch. This hack will be removed when
> > > tinydrm moves to vmalloc buffers.
> > >
> > > Signed-off-by: Noralf Trønnes
> > > ---
> > > drivers/gpu/drm/drm_fb_helper.c | 164
> > >
> > > include/drm/drm_fb_helper.h | 26 +++
> > > 2 files changed, 190 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 2ee1eaa66188..444c2b4040ea 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -30,11 +30,13 @@
> > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -2928,6 +2930,168 @@ void drm_fb_helper_output_poll_changed(struct
> > > drm_device *dev)
> > > }
> > > EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
> > > +/* @user: 1=userspace, 0=fbcon */
> > > +static int drm_fbdev_fb_open(struct fb_info *info, int user)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > +
> > > + if (!try_module_get(fb_helper->dev->driver->fops->owner))
> > > + return -ENODEV;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int drm_fbdev_fb_release(struct fb_info *info, int user)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > +
> > > + module_put(fb_helper->dev->driver->fops->owner);
> > > +
> > > + return 0;
> > > +}
> > Hm, I thought earlier versions of your patch series had this separately,
> > for everyone. What's the reasons for merging this into the fb_probe
> > implementation.
>
> This is only necessary when struct fb_ops is defined in a library where
> the owner field is the library module and not the driver module.
> I realised that with this generic version it's highly unlikely that we
> get another library that defines struct fb_ops, so it's only needed here.
Hm, I'm still not 100% convinced we can fully subsume the tinydrm fbdev
code with the generic one, due to the varios slight issues around defio
tracking that we still have.
But it's also easy to export this later on. If you add a comment
explaining what you explained here to the commit message I think this is
all fine with me as-is.
-Daniel
>
> Noralf.
>
> > > +
> > > +/*
> > > + * fb_ops.fb_destroy is called by the last put_fb_info() call at the end
> > > of
> > > + * unregister_framebuffer() or fb_release().
> > > + */
> > > +static void drm_fbdev_fb_destroy(struct fb_info *info)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > + struct fb_ops *fbops = NULL;
> > > +
> > > + DRM_DEBUG("\n");
> > > +
> > > + if (fb_helper->fbdev->fbdefio) {
> > > + fb_deferred_io_cleanup(fb_helper->fbdev);
> > > + fbops = fb_helper->fbdev->fbops;
> > > + }
> > > +
> > > + drm_fb_helper_fini(fb_helper);
> > > + drm_client_framebuffer_delete(fb_helper->buffer);
> > > + drm_client_free(fb_helper->client);
> > > + kfree(fb_helper);
> > > + kfree(fbops);
> > > +}
> > Hm, if we go with the idea that drm_clients could auto-unregister through
> > a callback, then I expect this will lead to some control inversion. But we
> > can fix that later on.
> >
> > > +
> > > +static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct
> > > *vma)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > +
> > > + if (fb_helper->dev->driver->gem_prime_mmap)
> > > + return
> > > fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
> > > + else
> > > + return -ENODEV;
> > > +}
> > > +
> > > +static struct fb_ops drm_fbdev_fb_ops = {
> > > + /* No need to set owner, this module is already pinned by the driver. */
> > I'd still set it, means less thinking since more obviously correct.
> >
> > > + DRM_FB_HELPER_DEFAULT_OPS,
> > > + .fb_open= drm_fbdev_fb_open,
> > > + .fb_release = drm_fbdev_fb_release,
> > > + .fb_destroy = drm_fbdev_fb_destroy,
> > > + .fb_mmap= drm_fbdev_fb_mmap,
> > > + .fb_read= drm_fb_helper_sys_read,
> > > + .fb_write = drm_fb_helper_sys_write,
> > > + .fb_fillrect= drm_fb_helper_sys_fillrect,
> > > + .fb_copyarea= drm_fb_helper_sys_copyarea,
> > > + .fb_imageblit = drm_fb_helper_sys_imageblit,
> > Hm, some drivers require the cfb versions of these. In practice I guess
> > there's not much of a difference really,
Re: [PATCH 4/9] drm: Begin an API for in-kernel clients
On Mon, May 28, 2018 at 03:26:48PM +0200, Noralf Trønnes wrote:
>
> Den 24.05.2018 10.42, skrev Daniel Vetter:
> > On Wed, May 23, 2018 at 04:34:06PM +0200, Noralf Trønnes wrote:
> > > This the beginning of an API for in-kernel clients.
> > > First out is a way to get a framebuffer backed by a dumb buffer.
> > >
> > > Only GEM drivers are supported.
> > > The original idea of using an exported dma-buf was dropped because it
> > > also creates an anonomous file descriptor which doesn't work when the
> > > buffer is created from a kernel thread. The easy way out is to use
> > > drm_driver.gem_prime_vmap to get the virtual address, which requires a
> > > GEM object. This excludes the vmwgfx driver which is the only non-GEM
> > > driver apart from the legacy ones. A solution for vmwgfx will have to be
> > > worked out later if it wants to support the client API which it probably
> > > will when we have a bootsplash client.
> > >
> > > Signed-off-by: Noralf Trønnes
> > A few small nits below, with those addressed:
> >
> > Reviewed-by: Daniel Vetter
> > > ---
>
> [...]
>
> > > +/**
> > > + * drm_client_new - Create a DRM client
> > > + * @dev: DRM device
> > > + *
> > > + * Returns:
> > > + * Pointer to a client or an error pointer on failure.
> > > + */
> > > +struct drm_client_dev *drm_client_new(struct drm_device *dev)
> > Api nitpick:
> >
> > int drm_client_init(struct drm_device *dev,
> > struct drm_client_dev *client)
> >
> > and dropping the kzalloc from this structure here. This allows users of
> > this to embed the client struct into their own thing, which means the
> > ->private backpointer isn't necessary. Allowing embedding is the preferred
> > interface in the kernel (since it's strictly more powerful, you can always
> > just kzalloc + _init to get the _new behaviour).
> >
> > > +{
> > > + struct drm_client_dev *client;
> > > + int ret;
> > > +
> > > + if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
> > > + !dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
> > > + return ERR_PTR(-ENOTSUPP);
> > > +
> > > + client = kzalloc(sizeof(*client), GFP_KERNEL);
> > > + if (!client)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + client->dev = dev;
> > > +
> > > + ret = drm_client_alloc_file(client);
> > > + if (ret) {
> > > + kfree(client);
> > > + return ERR_PTR(ret);
> > > + }
> > > +
> > > + return client;
> > > +}
> > > +EXPORT_SYMBOL(drm_client_new);
> > > +
>
> [...]
>
> > > +static struct drm_client_buffer *
> > > +drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32
> > > height, u32 format)
> > > +{
> > > + struct drm_mode_create_dumb dumb_args = { };
> > > + struct drm_device *dev = client->dev;
> > > + struct drm_client_buffer *buffer;
> > > + struct drm_gem_object *obj;
> > > + void *vaddr;
> > > + int ret;
> > > +
> > > + buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
> > > + if (!buffer)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + buffer->client = client;
> > > +
> > > + dumb_args.width = width;
> > > + dumb_args.height = height;
> > > + dumb_args.bpp = drm_format_plane_cpp(format, 0) * 8;
> > > + ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
> > > + if (ret)
> > > + goto err_free;
> > > +
> > > + buffer->handle = dumb_args.handle;
> > > + buffer->pitch = dumb_args.pitch;
> > > +
> > > + obj = drm_gem_object_lookup(client->file, dumb_args.handle);
> > > + if (!obj) {
> > > + ret = -ENOENT;
> > > + goto err_delete;
> > > + }
> > > +
> > > + buffer->gem = obj;
> > > +
> > I'm paranoid, I think an
> >
> > if (WARN_ON(!gem_prime_vmap))
> > return -EINVAL;
> >
> > would be cool here.
>
> This is already checked in drm_client_init().
Yeah I noticed later on. I think rechecking for safety here can't hurt,
but up to you.
-Daniel
>
> Noralf.
>
> > Also perhaps the following comment:
> >
> > /*
> > * FIXME: The dependency on GEM here isn't required, we could
> > * convert the driver handle to a dma-buf instead and use the
> > * backend-agnostic dma-buf vmap support instead. This would
> > * require that the handle2fd prime ioctl is reworked to pull the
> > * fd_install step out of the driver backend hooks, to make that
> > * final step optional for internal users.
> > */
> >
> >
> > > + vaddr = dev->driver->gem_prime_vmap(obj);
> > > + if (!vaddr) {
> > > + ret = -ENOMEM;
> > > + goto err_delete;
> > > + }
> > > +
> > > + buffer->vaddr = vaddr;
> > > +
> > > + return buffer;
> > > +
> > > +err_delete:
> > > + drm_client_buffer_delete(buffer);
> > > +err_free:
> > > + kfree(buffer);
> > > +
> > > + return ERR_PTR(ret);
> > > +}
>
>
--
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 v4 00/41] drm/i915: Implement HDCP2.2
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter > Sent: Tuesday, May 29, 2018 12:27 PM > To: C, Ramalingam > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; > seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk; > jani.nik...@linux.intel.com; Winkler, Tomas ; > Usyskin, Alexander ; Shankar, Uma > ; Sharma, Shashank > Subject: Re: [PATCH v4 00/41] drm/i915: Implement HDCP2.2 > > On Mon, May 21, 2018 at 06:23:19PM +0530, Ramalingam C wrote: > > The sequence for HDCP2.2 authentication and encryption is implemented > > in I915. Encoder specific implementations are moved into hdcp_shim. > > > > Intel HWs supports HDCP2.2 through ME FW. Hence this series introduces > > a client driver for mei bus, so that for HDCP2.2 authentication, > > HDCP2.2 stack in I915 can avail the services from ME FW. > > > > DRM_I915 selects INTEL_MEI_HDCP, which selects INTEL_MEI_ME and > > INTEL_MEI. If we are interested in disabling the MEI_HDCP and MEI Bus > > then we need an option to disable the HDCP2.2 in I915 (like > > DRM_I915_HDCP2.2!?). Till then they are binded. > > > > Userspace interface remains unchanged as version agnostic. When > > userspace request for HDCP enable, Kernel will detect the HDCP source > > and sink's HDCP version(1.4/2.2)capability and enable the best capable > > version for that combination. > > > > This series enables the HDCP2.2 for Type0 content streams. > > > > Thanks a lot for Usyskin, Alexander and Uma shankar for the review of v3. > > Thanks Daniel vetter for guiding me to test and confirm that there is > > no locking issue with respect to notifier usage between I915 and MEI_HDCP. > > > > Major Changes in v4: > > - GMBus Changes to implement the burst read as generic > > [Jani, Ville and Daniel] > > - Polling is added for extra Notifier notification when I915 and > > MEI_HDCP are modules. > > - Comment and style issues and typos are fixed [Uma and Alexander] > > - INTEL_MEI_HDCP, INTEL_MEI_ME and INTEL_MEI are selected by I915. > > - Fixed the #if in include/linux/mei_hdcp.h for build issues. > > > > GMBus changes are added here for completeness of the series. They are > > in review at https://patchwork.freedesktop.org/series/41632/ also. > > Please reply with a link to your github here (and include it in your next > cover > letter too). I can't ever find it when I need it :-/ You can find a github repo for HDCP2.2 v4 series at https://github.com/ramalingampc2008/drm-tip Thanks, Ram > > Thanks, Daniel > > > > > Ramalingam C (40): > > drm: hdcp2.2 authentication msg definitions > > drm: HDMI and DP specific HDCP2.2 defines > > misc/mei/hdcp: Client driver for HDCP application > > misc/mei/hdcp: Notifier chain for mei cldev state change > > misc/mei/hdcp: Define ME FW interface for HDCP2.2 > > linux/mei: Header for mei_hdcp driver interface > > misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session > > misc/mei/hdcp: Verify Receiver Cert and prepare km > > misc/mei/hdcp: Verify H_prime > > misc/mei/hdcp: Store the HDCP Pairing info > > misc/mei/hdcp: Initiate Locality check > > misc/mei/hdcp: Verify L_prime > > misc/mei/hdcp: Prepare Session Key > > misc/mei/hdcp: Repeater topology verification and ack > > misc/mei/hdcp: Verify M_prime > > misc/mei/hdcp: Enabling the HDCP authentication > > misc/mei/hdcp: Closing wired HDCP2.2 Tx Session > > drm/i915: wrapping all hdcp var into intel_hdcp > > drm/i915: Define HDCP2.2 related variables > > drm/i915: Define Intel HDCP2.2 registers > > drm/i915: Wrappers for mei HDCP2.2 services > > drm/i915: Implement HDCP2.2 receiver authentication > > drm/i915: Implement HDCP2.2 repeater authentication > > drm/i915: Enable and Disable HDCP2.2 port encryption > > drm/i915: Implement HDCP2.2 En/Dis-able > > drm/i915: Implement HDCP2.2 link integrity check > > drm/i915: Handle HDCP2.2 downstream topology change > > drm/i915: Pullout the bksv read and validation > > drm/i915: Initialize HDCP2.2 and its MEI interface > > drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable > > drm/i915: Enable superior HDCP ver that is capable > > drm/i915: Enable HDCP1.4 incase of HDCP2.2 failure > > drm/i915: hdcp_check_link only on CP_IRQ > > drm/i915: Check HDCP 1.4 and 2.2 link on CP_IRQ > > drm/i915/gmbus: Increase the Bytes per Rd/Wr Op > > drm/i915/gmbus: Enable burst read > > drm/i915: Implement the HDCP2.2 support for DP > > drm/i915: Implement the HDCP2.2 support for HDMI > > drm/i915: Add HDCP2.2 support for DP connectors > > drm/i915: Add HDCP2.2 support for HDMI connectors > > > > Tomas Winkler (1): > > mei: bus: whitelist hdcp client > > > > drivers/gpu/drm/i915/Kconfig |1 + > > drivers/gpu/drm/i915/i915_drv.h |3 + > > drivers/gpu/drm/i915/i915_reg.h | 34 ++ > > drivers/gpu/drm/i915/intel_display.c |7 +- > > drivers/gpu/drm/i915/int
Re: [PATCH] drm: Fix possible race conditions while unplugging DRM device
On Tue, May 29, 2018 at 10:09:57AM +0300, Oleksandr Andrushchenko wrote:
> On 05/29/2018 10:02 AM, Daniel Vetter wrote:
> > On Tue, May 22, 2018 at 05:13:04PM +0300, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko
> > >
> > > When unplugging a hotpluggable DRM device we first unregister it
> > > with drm_dev_unregister and then set drm_device.unplugged flag which
> > > is used to mark device critical sections with drm_dev_enter()/
> > > drm_dev_exit() preventing access to device resources that are not
> > > available after the device is gone.
> > > But drm_dev_unregister may lead to hotplug uevent(s) fired to
> > > user-space on card and/or connector removal, thus making it possible
> > > for user-space to try accessing a disconnected device.
> > >
> > > Fix this by first making sure device is properly marked as
> > > disconnected and only then unregister it.
> > >
> > > Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged")
> > >
> > > Signed-off-by: Oleksandr Andrushchenko
> > > Reported-by: Andrii Chepurnyi
> > > Cc: "Noralf Trønnes"
> > Nice catch.
> >
> > Reviewed-by: Daniel Vetter
> >
> > I think you need to push this to drm-misc-next-fixes to make sure it's on
> > the 4.17 train.
> Sure, after I have r-b from Noralf
Noralf's occasionally occupied with other things and doesn't have time to
look at patches. I think it's ok to just push after a few more days, even
if he doesn't respond. Same holds for other people really.
-Daniel
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 14 +++---
> > > 1 file changed, 7 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index b553a6f2ff0e..7af748ed1c58 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -369,13 +369,6 @@ EXPORT_SYMBOL(drm_dev_exit);
> > >*/
> > > void drm_dev_unplug(struct drm_device *dev)
> > > {
> > > - drm_dev_unregister(dev);
> > > -
> > > - mutex_lock(&drm_global_mutex);
> > > - if (dev->open_count == 0)
> > > - drm_dev_put(dev);
> > > - mutex_unlock(&drm_global_mutex);
> > > -
> > > /*
> > >* After synchronizing any critical read section is guaranteed
> > > to see
> > >* the new value of ->unplugged, and any critical section which
> > > might
> > > @@ -384,6 +377,13 @@ void drm_dev_unplug(struct drm_device *dev)
> > >*/
> > > dev->unplugged = true;
> > > synchronize_srcu(&drm_unplug_srcu);
> > > +
> > > + drm_dev_unregister(dev);
> > > +
> > > + mutex_lock(&drm_global_mutex);
> > > + if (dev->open_count == 0)
> > > + drm_dev_put(dev);
> > > + mutex_unlock(&drm_global_mutex);
> > > }
> > > EXPORT_SYMBOL(drm_dev_unplug);
> > > --
> > > 2.17.0
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] drm/omap: Module parameter for display order configuration
On Tue, May 29, 2018 at 10:16:20AM +0300, Tomi Valkeinen wrote: > On 29/05/18 09:42, Daniel Vetter wrote: > > > Thus far the rules has been that we try to put the integrated panel first, > > and that's it. See drm_helper_move_panel_connectors_to_head(). If there's > > Ok. But we may also have multiple integrated panels. > > > any standard, then imo that's it. Not a more generic "the first display is > > the preferred one" because frankly we don't know that - or how do you > > guess that I want to use my laptop just as a work-station, and never use > > the integrated panel when the hdmi thing is connected? You need > > configurability in userspace and fbdev for that. > > I can't guess, which is why we added this parameter. I agree that (ignoring > fbdev for now) the userspace should handle this. But as described in > drm_helper_move_panel_connectors_to_head(), this isn't the case at the > moment. > > > And yes, for fbdev some fbdev option would probably be best. We already > > have options/parsing to disable/force certain connectors, we could also > > have another flag to designate it the preferred primary. > > It's true that the only important thing here is the "primary", i.e. we don't > care how the second or third displays are ordered. > > We wanted to use the connector names here in the parameter, but connector > names are not available before the connectors are created, so we ended up > with the list of numbers... > > > Also, the only thing where primary/secondary matters for fbdev emulation > > is for the vblank handling. Afaiui that was added for the gpu blob drivers > > being stupid and refusing to use kms. Definitely don't want to add huge > > driver-specific hacks for that :-) > > For us it was about the fbdev size, which was setup at probe time to the > size of the first display (Or smallest of the connected ones? I can't > remember). We wanted the fbdev size to be the size of the "primary" display. It's smallest of all connected ones. Atm you do not get fbdev size == size of primary. It's only >= size of primary. And no way to modeset :-/ > > Imo the fbdev one makes some sense, but if the only reason for it is the > > userspace gpu blob maybe not so much. For everything else, you need some > > form of configuration in userspace anyway. KMS doesn't have a concept of > > "primary" display, and I have no idea how we'd even make that happen > > everywhere. > > We were not aiming at a "primary" display in the sense that it'd be > something that the userspace should care about. More like a > fallback-primary-display, in case the userspace only uses the first > connector. > > But I do agree that this feels hacky. So we can carry this in the TI kernel > for now as a temporary measure. One even more impressive hack would be to have this generic in the drm core. I.e. at drm_dev_register time we'd move the primary connector to the front. Only issue is that this might upset the driver, so we might need to do that only for the getresources ioctl (and not for anything else). The problem with that is that drm connectors have no unique/stable names, so I'm not sure how we could make this work correctly -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 PATCH v2 1/2] drm: Add generic colorkey properties
On Sat, May 26, 2018 at 06:56:22PM +0300, Dmitry Osipenko wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transparent or gain adjustment
> of the pixels component values.
>
> Color keying is found in a large number of devices whose capabilities
> often differ, but they still have enough common features in range to
> standardize color key properties. This commit adds nine generic DRM plane
> properties related to the color keying to cover various HW capabilities.
>
> This patch is based on the initial work done by Laurent Pinchart, most of
> credits for this patch goes to him.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_atomic.c | 36 ++
> drivers/gpu/drm/drm_blend.c | 229 +++
> include/drm/drm_blend.h | 3 +
> include/drm/drm_plane.h | 77
> 4 files changed, 345 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 895741e9cd7d..5b808cb68654 100644
> @@ -124,6 +175,19 @@ struct drm_plane_state {
> unsigned int zpos;
> unsigned int normalized_zpos;
>
> + /* Plane colorkey */
> + struct {
> + enum drm_plane_colorkey_mode mode;
> + u64 min;
> + u64 max;
> + u64 mask;
> + u32 format;
> + bool inverted_match;
> + u64 replacement_mask;
> + u64 replacement_value;
> + u32 replacement_format;
> + } colorkey;
After a quick stab at implementing this for i915 I came to the
conclusion that I'd like this struct to have a name so that I can pass
it around/consult it easily without having to mess about with the entire
plane state.
One extra question that came up is how are we going to define the
destination color key? Is it to be a) enabled on the plane that has the
colorkey painted on it, or is it to be b) enabled on a plane that sits
above the plane that is going to be covering up the colorkey? Modern
Intel hardware defines it the a) way, whereas older hw used the b)
method. Thinking about it I do think the a) method seems nicer because
it removes the ambiguity as to which plane's pixels are going to be
compared again the colorkey. So kinda matches the src colorkey case
better.
Oh and this also brings up the question as to which other plane(s) are
taking part in the colorkey process. Looks like on modern Intel hw it's
supposed to be just the plane immediately above the plane with
dst keying enabled. On some really old hw there were some more
complicated rules as to which pair of planes are involved. On middle
aged hw the situation is simpler a there are only ever two
(non-cursor) planes on the same crtc. The cursor doesn't seem to
participate in the colorkeing ever. Not sure there's a sane way to
fully abstract this all.
I should probably poke at the hardware a bit more to figure out how
this really works when there are more than two active planes on the
crtc. I did poke at one particular class of hw which is
a bit of a mix of old and middle aged hw, and there it seems I can
also do dst colorkeying the a) way. And in this case there are three
planes taking part in the dst colorkey match (the primary that
has the colorkey painted on it, and two overlay planes that cover
up the matched pixels). So for that case definitely the a) approach
in the uapi would make more sense as trying to specify conflicting
dst colorkey settings for each of the overlay planes wouldn't make
any sense. I'll need to poke at the modern hw a bit more still...
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/6] drm/omap: Module parameter for display order configuration
On 29/05/18 09:42, Daniel Vetter wrote: Thus far the rules has been that we try to put the integrated panel first, and that's it. See drm_helper_move_panel_connectors_to_head(). If there's Ok. But we may also have multiple integrated panels. any standard, then imo that's it. Not a more generic "the first display is the preferred one" because frankly we don't know that - or how do you guess that I want to use my laptop just as a work-station, and never use the integrated panel when the hdmi thing is connected? You need configurability in userspace and fbdev for that. I can't guess, which is why we added this parameter. I agree that (ignoring fbdev for now) the userspace should handle this. But as described in drm_helper_move_panel_connectors_to_head(), this isn't the case at the moment. And yes, for fbdev some fbdev option would probably be best. We already have options/parsing to disable/force certain connectors, we could also have another flag to designate it the preferred primary. It's true that the only important thing here is the "primary", i.e. we don't care how the second or third displays are ordered. We wanted to use the connector names here in the parameter, but connector names are not available before the connectors are created, so we ended up with the list of numbers... Also, the only thing where primary/secondary matters for fbdev emulation is for the vblank handling. Afaiui that was added for the gpu blob drivers being stupid and refusing to use kms. Definitely don't want to add huge driver-specific hacks for that :-) For us it was about the fbdev size, which was setup at probe time to the size of the first display (Or smallest of the connected ones? I can't remember). We wanted the fbdev size to be the size of the "primary" display. Imo the fbdev one makes some sense, but if the only reason for it is the userspace gpu blob maybe not so much. For everything else, you need some form of configuration in userspace anyway. KMS doesn't have a concept of "primary" display, and I have no idea how we'd even make that happen everywhere. We were not aiming at a "primary" display in the sense that it'd be something that the userspace should care about. More like a fallback-primary-display, in case the userspace only uses the first connector. But I do agree that this feels hacky. So we can carry this in the TI kernel for now as a temporary measure. 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 v2] drm: udl: Destroy framebuffer only if it was initialized
This fixes a NULL pointer dereference that can happen if the UDL
driver is unloaded before the framebuffer is initialized. This can
happen e.g. if the USB device is unplugged right after it was plugged
in.
As explained by Stéphane Marchesin:
It happens when fbdev is disabled (which is the case for Chrome OS).
Even though intialization of the fbdev part is optional (it's done in
udlfb_create which is the callback for fb_probe()), the teardown isn't
optional (udl_driver_unload -> udl_fbdev_cleanup ->
udl_fbdev_destroy).
Note that udl_fbdev_cleanup *tries* to be conditional (you can see it
does if (!udl->fbdev)) but that doesn't work, because udl->fbdev is
always set during udl_fbdev_init.
Suggested-by: Sean Paul
Signed-off-by: Emil Lundmark
---
Changes in v2:
- Updated commit message with explanation from Stéphane Marchesin
drivers/gpu/drm/udl/udl_fb.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 2ebdc6d5a76e..5754e37f741b 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -426,9 +426,11 @@ static void udl_fbdev_destroy(struct drm_device *dev,
{
drm_fb_helper_unregister_fbi(&ufbdev->helper);
drm_fb_helper_fini(&ufbdev->helper);
- drm_framebuffer_unregister_private(&ufbdev->ufb.base);
- drm_framebuffer_cleanup(&ufbdev->ufb.base);
- drm_gem_object_put_unlocked(&ufbdev->ufb.obj->base);
+ if (ufbdev->ufb.obj) {
+ drm_framebuffer_unregister_private(&ufbdev->ufb.base);
+ drm_framebuffer_cleanup(&ufbdev->ufb.base);
+ drm_gem_object_put_unlocked(&ufbdev->ufb.obj->base);
+ }
}
int udl_fbdev_init(struct drm_device *dev)
--
2.17.0.921.gf22659ad46-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On 29.05.2018 02:48, Dmitry Osipenko wrote: > inversion=true" if mask has form of 0x11000111, though this could be not For clarity: I meant s/0x11000111/0xFF000FFF/. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video/hdmi: prefer strlcpy to strncpy
Fixes a stringop-truncation warning from gcc-8. Signed-off-by: Nick Desaulniers --- drivers/video/hdmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index 111a0ab..46c184c 100644 --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -168,8 +168,8 @@ int hdmi_spd_infoframe_init(struct hdmi_spd_infoframe *frame, frame->version = 1; frame->length = HDMI_SPD_INFOFRAME_SIZE; - strncpy(frame->vendor, vendor, sizeof(frame->vendor)); - strncpy(frame->product, product, sizeof(frame->product)); + strlcpy(frame->vendor, vendor, sizeof(frame->vendor)); + strlcpy(frame->product, product, sizeof(frame->product)); return 0; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On 28.05.2018 16:15, Ville Syrjälä wrote:
> On Sat, May 26, 2018 at 06:56:22PM +0300, Dmitry Osipenko wrote:
>> Color keying is the action of replacing pixels matching a given color
>> (or range of colors) with transparent pixels in an overlay when
>> performing blitting. Depending on the hardware capabilities, the
>> matching pixel can either become fully transparent or gain adjustment
>> of the pixels component values.
>>
>> Color keying is found in a large number of devices whose capabilities
>> often differ, but they still have enough common features in range to
>> standardize color key properties. This commit adds nine generic DRM plane
>> properties related to the color keying to cover various HW capabilities.
>>
>> This patch is based on the initial work done by Laurent Pinchart, most of
>> credits for this patch goes to him.
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/gpu/drm/drm_atomic.c | 36 ++
>> drivers/gpu/drm/drm_blend.c | 229 +++
>> include/drm/drm_blend.h | 3 +
>> include/drm/drm_plane.h | 77
>> 4 files changed, 345 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 895741e9cd7d..5b808cb68654 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -799,6 +799,24 @@ 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 == plane->colorkey.mode_property) {
>> +state->colorkey.mode = val;
>> +} else if (property == plane->colorkey.min_property) {
>> +state->colorkey.min = val;
>> +} else if (property == plane->colorkey.max_property) {
>> +state->colorkey.max = val;
>> +} else if (property == plane->colorkey.format_property) {
>> +state->colorkey.format = val;
>> +} else if (property == plane->colorkey.mask_property) {
>> +state->colorkey.mask = val;
>> +} else if (property == plane->colorkey.inverted_match_property) {
>> +state->colorkey.inverted_match = val;
>> +} else if (property == plane->colorkey.replacement_mask_property) {
>> +state->colorkey.replacement_mask = val;
>> +} else if (property == plane->colorkey.replacement_value_property) {
>> +state->colorkey.replacement_value = val;
>> +} else if (property == plane->colorkey.replacement_format_property) {
>> +state->colorkey.replacement_format = val;
>> } else if (property == plane->color_encoding_property) {
>> state->color_encoding = val;
>> } else if (property == plane->color_range_property) {
>> @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>> *val = state->rotation;
>> } else if (property == plane->zpos_property) {
>> *val = state->zpos;
>> +} else if (property == plane->colorkey.mode_property) {
>> +*val = state->colorkey.mode;
>> +} else if (property == plane->colorkey.min_property) {
>> +*val = state->colorkey.min;
>> +} else if (property == plane->colorkey.max_property) {
>> +*val = state->colorkey.max;
>> +} else if (property == plane->colorkey.format_property) {
>> +*val = state->colorkey.format;
>> +} else if (property == plane->colorkey.mask_property) {
>> +*val = state->colorkey.mask;
>> +} else if (property == plane->colorkey.inverted_match_property) {
>> +*val = state->colorkey.inverted_match;
>> +} else if (property == plane->colorkey.replacement_mask_property) {
>> +*val = state->colorkey.replacement_mask;
>> +} else if (property == plane->colorkey.replacement_value_property) {
>> +*val = state->colorkey.replacement_value;
>> +} else if (property == plane->colorkey.replacement_format_property) {
>> +*val = state->colorkey.replacement_format;
>> } else if (property == plane->color_encoding_property) {
>> *val = state->color_encoding;
>> } else if (property == plane->color_range_property) {
>> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
>> index a16a74d7e15e..05e5632ce375 100644
>> --- a/drivers/gpu/drm/drm_blend.c
>> +++ b/drivers/gpu/drm/drm_blend.c
>> @@ -107,6 +107,11 @@
>> * planes. Without this property the primary plane is always below the
>> cursor
>> * plane, and ordering between all other planes is undefined.
>> *
>> + * colorkey:
>> + * Color keying is set up with drm_plane_create_colorkey_properties().
>> + * It adds support for replacing a range of colors with a transparent
>> + * color in the plane.
>> + *
>> * Note that all the property extensions described here apply either to the
>> * plane or the CRTC (e.g. for the background color, which currently
Re: [PATCH] gpu: drm: etnaviv: Change return type to vm_fault_t
On Mon, May 28, 2018 at 6:20 PM, Lucas Stach wrote:
> Hi Souptick,
>
> Am Montag, den 21.05.2018, 22:42 +0530 schrieb Souptick Joarder:
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
>> are converted, vm_fault_t will become a distinct type.
>>
>> Ref- commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>>
>> Previously vm_insert_page() returns err which driver
>> mapped into VM_FAULT_* type. The new function
>> vmf_insert_page() will replace this inefficiency by
>> returning VM_FAULT_* type.
>>
>> A non-fatal signal being delivered to a task which is
>> in the middle of a page fault may well end up in an
>> infinite loop, attempting to handle the page fault and
>> failing forever.
>>
>> On seeing NOPAGE, the fault handler believes the PTE
>> is in the page table, so does nothing before it returns
>> to arch code. It will end up returning to userspace if
>> the signal is non-fatal, at which point it'll go right
>> back into the page fault handler, and mutex_lock_interruptible()
>> will immediately fail. So we've converted a sleeping lock
>> into the most expensive spinlock.
>>
>> I don't think the graphics drivers really want to be
>> interrupted by any signal. I think they want to be
>> interruptible by fatal signals and should use the
>> mutex_lock_killable / fatal_signal_pending family of
>> functions. So mutex_lock_interruptible() is replaced
>> by mutex_lock_killable()
>
> I don't think the other thread discussing this issue has reached a
> proper conclusion and I would rather not pull in a patch based on thin
> reasoning. If we want to change this behavior I would really like to
> see the issue it is solving and it should be a separate patch, not
> intermixed with some return value change.
>
> Regards,
> Lucas
>
Ok, I will separate the vm_fault_t type return value patch
and send v2 for it. We would like to get this patch in queue
for 4.18.
The patch consists, mutex_lock_interruptible/killable() can be keep
on hold until we reached to a proper conclusion.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/12] drm/bridge: tc358764: Add DSI to LVDS bridge driver
On 05/28/2018 02:47 AM, Maciej Purski wrote: > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index fa2c799..58e19af 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -110,6 +110,13 @@ config DRM_THINE_THC63LVD1024 > ---help--- > Thine THC63LVD1024 LVDS/parallel converter driver. > > +config DRM_TOSHIBA_TC358764 > + tristate "TC358764 DSI/LVDS bridge" > + depends on DRM && DRM_PANEL > + depends on OF > + select DRM_MIPI_DSI > + select VIDEOMODE_HELPERS > + Kconfig symbols with "prompt strings" should also have help text. I expected checkpatch to catch that, but I tested it and there was no warning from checkpatch about help text. OTOH, there was a warning that there are 2 lines in this patch that end with whitespace, so that should be fixed. Did you use checkpatch (scripts/checkpatch.pl)? > config DRM_TOSHIBA_TC358767 > tristate "Toshiba TC358767 eDP bridge" > depends on OF thanks, -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
Hi Geert
> > +&hdmi0_con {
> > + remote-endpoint = <&rcar_dw_hdmi0_out>;
> > +};
>
> I think the hdmi0 and hdmi0_con parts can be moved to salvator-common.dtsi.
> Can we do that now (with stubs?), or does this have to wait until r8a77965 has
> received HDMI sound support?
HDMI sound doesn't use hdmi0_con.
You can do it now, thanks
Best regards
---
Kuninori Morimoto
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 1/2] drm/msm: call drm_atomic_helper_suspend() and drm_atomic_helper_resume()
To make suspend and resume work on msm8916 platforms, call into the generic
helpers and preserve the state across suspends.
Signed-off-by: Daniel Mack
---
drivers/gpu/drm/msm/msm_drv.c | 9 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 0a3ea3034e39..cdbe9249bff2 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -907,16 +907,25 @@ static struct drm_driver msm_driver = {
static int msm_pm_suspend(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev->dev_private;
drm_kms_helper_poll_disable(ddev);
+ priv->pm_state = drm_atomic_helper_suspend(ddev);
+ if (IS_ERR(priv->pm_state)) {
+ drm_kms_helper_poll_enable(ddev);
+ return PTR_ERR(priv->pm_state);
+ }
+
return 0;
}
static int msm_pm_resume(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
+ struct msm_drm_private *priv = ddev->dev_private;
+ drm_atomic_helper_resume(ddev, priv->pm_state);
drm_kms_helper_poll_enable(ddev);
return 0;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 0a653dd2e618..459d06a1ab9f 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -155,6 +155,7 @@ struct msm_drm_private {
struct shrinker shrinker;
struct msm_vblank_ctrl vblank_ctrl;
+ struct drm_atomic_state *pm_state;
};
struct msm_format {
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 2/2] drm/msm/adreno: Add power management functions for system sleep
When a msm8016 based system is woken up from suspend, the firmware in
the adreno device hangs.
[ 83.903416] qcom-iommu-ctx 1f09000.iommu-ctx: Unhandled context fault:
fsr=0x202, iova=0x, fsynr=0x2, cb=1
[ 85.853633] msm 1a0.mdss: A306: hangcheck detected gpu lockup rb 0!
[ 85.853661] msm 1a0.mdss: A306: completed fence: 370
[ 85.859073] msm 1a0.mdss: A306: submitted fence: 372
[ 85.865113] msm 1a0.mdss: A306: hangcheck recover!
Fix this by adding pm_runtime_force_suspend/pm_runtime_force_resume
as sleep ops.
Signed-off-by: Daniel Mack
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 05022ea2a007..12d87ccdec53 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -357,6 +357,7 @@ static int adreno_suspend(struct device *dev)
#endif
static const struct dev_pm_ops adreno_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(adreno_suspend, adreno_resume, NULL)
};
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On Tue, May 29, 2018 at 02:48:22AM +0300, Dmitry Osipenko wrote:
> On 28.05.2018 16:15, Ville Syrjälä wrote:
> > On Sat, May 26, 2018 at 06:56:22PM +0300, Dmitry Osipenko wrote:
> >> Color keying is the action of replacing pixels matching a given color
> >> (or range of colors) with transparent pixels in an overlay when
> >> performing blitting. Depending on the hardware capabilities, the
> >> matching pixel can either become fully transparent or gain adjustment
> >> of the pixels component values.
> >>
> >> Color keying is found in a large number of devices whose capabilities
> >> often differ, but they still have enough common features in range to
> >> standardize color key properties. This commit adds nine generic DRM plane
> >> properties related to the color keying to cover various HW capabilities.
> >>
> >> This patch is based on the initial work done by Laurent Pinchart, most of
> >> credits for this patch goes to him.
> >>
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> >> drivers/gpu/drm/drm_atomic.c | 36 ++
> >> drivers/gpu/drm/drm_blend.c | 229 +++
> >> include/drm/drm_blend.h | 3 +
> >> include/drm/drm_plane.h | 77
> >> 4 files changed, 345 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index 895741e9cd7d..5b808cb68654 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -799,6 +799,24 @@ 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 == plane->colorkey.mode_property) {
> >> + state->colorkey.mode = val;
> >> + } else if (property == plane->colorkey.min_property) {
> >> + state->colorkey.min = val;
> >> + } else if (property == plane->colorkey.max_property) {
> >> + state->colorkey.max = val;
> >> + } else if (property == plane->colorkey.format_property) {
> >> + state->colorkey.format = val;
> >> + } else if (property == plane->colorkey.mask_property) {
> >> + state->colorkey.mask = val;
> >> + } else if (property == plane->colorkey.inverted_match_property) {
> >> + state->colorkey.inverted_match = val;
> >> + } else if (property == plane->colorkey.replacement_mask_property) {
> >> + state->colorkey.replacement_mask = val;
> >> + } else if (property == plane->colorkey.replacement_value_property) {
> >> + state->colorkey.replacement_value = val;
> >> + } else if (property == plane->colorkey.replacement_format_property) {
> >> + state->colorkey.replacement_format = val;
> >>} else if (property == plane->color_encoding_property) {
> >>state->color_encoding = val;
> >>} else if (property == plane->color_range_property) {
> >> @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> >>*val = state->rotation;
> >>} else if (property == plane->zpos_property) {
> >>*val = state->zpos;
> >> + } else if (property == plane->colorkey.mode_property) {
> >> + *val = state->colorkey.mode;
> >> + } else if (property == plane->colorkey.min_property) {
> >> + *val = state->colorkey.min;
> >> + } else if (property == plane->colorkey.max_property) {
> >> + *val = state->colorkey.max;
> >> + } else if (property == plane->colorkey.format_property) {
> >> + *val = state->colorkey.format;
> >> + } else if (property == plane->colorkey.mask_property) {
> >> + *val = state->colorkey.mask;
> >> + } else if (property == plane->colorkey.inverted_match_property) {
> >> + *val = state->colorkey.inverted_match;
> >> + } else if (property == plane->colorkey.replacement_mask_property) {
> >> + *val = state->colorkey.replacement_mask;
> >> + } else if (property == plane->colorkey.replacement_value_property) {
> >> + *val = state->colorkey.replacement_value;
> >> + } else if (property == plane->colorkey.replacement_format_property) {
> >> + *val = state->colorkey.replacement_format;
> >>} else if (property == plane->color_encoding_property) {
> >>*val = state->color_encoding;
> >>} else if (property == plane->color_range_property) {
> >> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> >> index a16a74d7e15e..05e5632ce375 100644
> >> --- a/drivers/gpu/drm/drm_blend.c
> >> +++ b/drivers/gpu/drm/drm_blend.c
> >> @@ -107,6 +107,11 @@
> >> *planes. Without this property the primary plane is always below
> >> the cursor
> >> *plane, and ordering between all other planes is undefined.
> >> *
> >> + * colorkey:
> >> + *Color keying is set up with
> >> drm_plane_create_colorkey_properties().
> >> + *It adds support for replacing a range of colors with a
> >> transparent
Re: [PATCH] drm: Fix possible race conditions while unplugging DRM device
On 05/29/2018 10:02 AM, Daniel Vetter wrote:
On Tue, May 22, 2018 at 05:13:04PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
When unplugging a hotpluggable DRM device we first unregister it
with drm_dev_unregister and then set drm_device.unplugged flag which
is used to mark device critical sections with drm_dev_enter()/
drm_dev_exit() preventing access to device resources that are not
available after the device is gone.
But drm_dev_unregister may lead to hotplug uevent(s) fired to
user-space on card and/or connector removal, thus making it possible
for user-space to try accessing a disconnected device.
Fix this by first making sure device is properly marked as
disconnected and only then unregister it.
Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged")
Signed-off-by: Oleksandr Andrushchenko
Reported-by: Andrii Chepurnyi
Cc: "Noralf Trønnes"
Nice catch.
Reviewed-by: Daniel Vetter
I think you need to push this to drm-misc-next-fixes to make sure it's on
the 4.17 train.
Sure, after I have r-b from Noralf
-Daniel
---
drivers/gpu/drm/drm_drv.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b553a6f2ff0e..7af748ed1c58 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -369,13 +369,6 @@ EXPORT_SYMBOL(drm_dev_exit);
*/
void drm_dev_unplug(struct drm_device *dev)
{
- drm_dev_unregister(dev);
-
- mutex_lock(&drm_global_mutex);
- if (dev->open_count == 0)
- drm_dev_put(dev);
- mutex_unlock(&drm_global_mutex);
-
/*
* After synchronizing any critical read section is guaranteed to see
* the new value of ->unplugged, and any critical section which might
@@ -384,6 +377,13 @@ void drm_dev_unplug(struct drm_device *dev)
*/
dev->unplugged = true;
synchronize_srcu(&drm_unplug_srcu);
+
+ drm_dev_unregister(dev);
+
+ mutex_lock(&drm_global_mutex);
+ if (dev->open_count == 0)
+ drm_dev_put(dev);
+ mutex_unlock(&drm_global_mutex);
}
EXPORT_SYMBOL(drm_dev_unplug);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix possible race conditions while unplugging DRM device
On Tue, May 22, 2018 at 05:13:04PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> When unplugging a hotpluggable DRM device we first unregister it
> with drm_dev_unregister and then set drm_device.unplugged flag which
> is used to mark device critical sections with drm_dev_enter()/
> drm_dev_exit() preventing access to device resources that are not
> available after the device is gone.
> But drm_dev_unregister may lead to hotplug uevent(s) fired to
> user-space on card and/or connector removal, thus making it possible
> for user-space to try accessing a disconnected device.
>
> Fix this by first making sure device is properly marked as
> disconnected and only then unregister it.
>
> Fixes: bee330f3d672 ("drm: Use srcu to protect drm_device.unplugged")
>
> Signed-off-by: Oleksandr Andrushchenko
> Reported-by: Andrii Chepurnyi
> Cc: "Noralf Trønnes"
Nice catch.
Reviewed-by: Daniel Vetter
I think you need to push this to drm-misc-next-fixes to make sure it's on
the 4.17 train.
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index b553a6f2ff0e..7af748ed1c58 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -369,13 +369,6 @@ EXPORT_SYMBOL(drm_dev_exit);
> */
> void drm_dev_unplug(struct drm_device *dev)
> {
> - drm_dev_unregister(dev);
> -
> - mutex_lock(&drm_global_mutex);
> - if (dev->open_count == 0)
> - drm_dev_put(dev);
> - mutex_unlock(&drm_global_mutex);
> -
> /*
>* After synchronizing any critical read section is guaranteed to see
>* the new value of ->unplugged, and any critical section which might
> @@ -384,6 +377,13 @@ void drm_dev_unplug(struct drm_device *dev)
>*/
> dev->unplugged = true;
> synchronize_srcu(&drm_unplug_srcu);
> +
> + drm_dev_unregister(dev);
> +
> + mutex_lock(&drm_global_mutex);
> + if (dev->open_count == 0)
> + drm_dev_put(dev);
> + mutex_unlock(&drm_global_mutex);
> }
> EXPORT_SYMBOL(drm_dev_unplug);
>
> --
> 2.17.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
