Re: [PATCH] drm/virtio: fix mmap page attributes

[Gerd Hoffmann]

  Hi,

> There's similar code in udl, [1] which still uses writecombine for
> imported buffers. Virtio does not need this?

virtio doesn't support dma-buf imports (yet).
So no worries for now.

Why pick writecombine for the imported buffer btw?
It'll probably be correct for the majority of imports, but it still
looks like a educated guess to me.  What if you import from vgem?

I guess we should either ...
  (1) Ask the exporting driver to handle things, simliar to how it is
  done for vmaps already, probably by calling dma_buf_mmap(), or
  (2) Refuse to mmap imported objects via drm api.

> Aside from this, do you think we could handle all special cases within
> shmem?

Probably makes sense to teach shmem helpers about caching.

cheers,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/2] drm/virtio: fix mmap page attributes

[Gerd Hoffmann]

v2: make shmem helper caching configurable.

Gerd Hoffmann (2):
  drm/shmem: add support for per object caching attributes
  drm/virtio: fix mmap page attributes

 include/drm/drm_gem_shmem_helper.h  | 12 
 drivers/gpu/drm/drm_gem_shmem_helper.c  | 24 +---
 drivers/gpu/drm/virtio/virtgpu_object.c |  1 +
 3 files changed, 34 insertions(+), 3 deletions(-)

-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] drm/virtio: fix mmap page attributes

[Gerd Hoffmann]

virtio-gpu uses cached mappings, set shmem->caching accordingly.

Reported-by: Gurchetan Singh 
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_object.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 017a9e0fc3bb..a0b5e5195816 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -118,6 +118,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
*vgdev,
shmem_obj = drm_gem_shmem_create(vgdev->ddev, params->size);
if (IS_ERR(shmem_obj))
return PTR_ERR(shmem_obj);
+   shmem_obj->caching = DRM_GEM_SHMEM_CACHED;
bo = gem_to_virtio_gpu_obj(&shmem_obj->base);
 
ret = virtio_gpu_resource_id_get(vgdev, &bo->hw_res_handle);
-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] drm/shmem: add support for per object caching attributes

[Gerd Hoffmann]

Add caching field to drm_gem_shmem_object to specify the cachine
attributes for mappings.  Add helper function to tweak pgprot
accordingly.  Switch vmap and mmap functions to the new helper.

Set caching to write-combine when creating the object so behavior
doesn't change by default.  Drivers can override that later if
needed.

Signed-off-by: Gerd Hoffmann 
---
 include/drm/drm_gem_shmem_helper.h | 12 
 drivers/gpu/drm/drm_gem_shmem_helper.c | 24 +---
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/include/drm/drm_gem_shmem_helper.h 
b/include/drm/drm_gem_shmem_helper.h
index 6748379a0b44..9d6e02c6205f 100644
--- a/include/drm/drm_gem_shmem_helper.h
+++ b/include/drm/drm_gem_shmem_helper.h
@@ -17,6 +17,11 @@ struct drm_mode_create_dumb;
 struct drm_printer;
 struct sg_table;
 
+enum drm_gem_shmem_caching {
+   DRM_GEM_SHMEM_CACHED = 1,
+   DRM_GEM_SHMEM_WC,
+};
+
 /**
  * struct drm_gem_shmem_object - GEM object backed by shmem
  */
@@ -83,6 +88,11 @@ struct drm_gem_shmem_object {
 * The address are un-mapped when the count reaches zero.
 */
unsigned int vmap_use_count;
+
+   /**
+* @caching: caching attributes for mappings.
+*/
+   enum drm_gem_shmem_caching caching;
 };
 
 #define to_drm_gem_shmem_obj(obj) \
@@ -130,6 +140,8 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device *dev,
 
 struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_object *obj);
 
+pgprot_t drm_gem_shmem_caching(struct drm_gem_shmem_object *shmem, pgprot_t 
prot);
+
 /**
  * DRM_GEM_SHMEM_DRIVER_OPS - Default shmem GEM operations
  *
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index a421a2eed48a..5bb94e130a50 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -76,6 +76,7 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct 
drm_device *dev, size_t
mutex_init(&shmem->pages_lock);
mutex_init(&shmem->vmap_lock);
INIT_LIST_HEAD(&shmem->madv_list);
+   shmem->caching = DRM_GEM_SHMEM_WC;
 
/*
 * Our buffers are kept pinned, so allocating them
@@ -256,9 +257,11 @@ static void *drm_gem_shmem_vmap_locked(struct 
drm_gem_shmem_object *shmem)
 
if (obj->import_attach)
shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
-   else
+   else {
+   pgprot_t prot = drm_gem_shmem_caching(shmem, PAGE_KERNEL);
shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
-   VM_MAP, pgprot_writecombine(PAGE_KERNEL));
+   VM_MAP, prot);
+   }
 
if (!shmem->vaddr) {
DRM_DEBUG_KMS("Failed to vmap pages\n");
@@ -540,7 +543,8 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct 
vm_area_struct *vma)
}
 
vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
-   vma->vm_page_prot = 
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+   vma->vm_page_prot = drm_gem_shmem_caching(shmem, vma->vm_page_prot);
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
vma->vm_ops = &drm_gem_shmem_vm_ops;
 
@@ -683,3 +687,17 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
+
+pgprot_t drm_gem_shmem_caching(struct drm_gem_shmem_object *shmem, pgprot_t 
prot)
+{
+   switch (shmem->caching) {
+   case DRM_GEM_SHMEM_CACHED:
+   return prot;
+   case DRM_GEM_SHMEM_WC:
+   return pgprot_writecombine(prot);
+   default:
+   WARN_ON_ONCE(1);
+   return prot;
+   }
+}
+EXPORT_SYMBOL_GPL(drm_gem_shmem_caching);
-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/virtio: skip set_scanout if framebuffer didn't change

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ++
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index bc4bc4475a8c..a0f91658c2bc 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -151,20 +151,23 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
if (bo->dumb)
virtio_gpu_update_dumb_bo(vgdev, bo, plane->state);
 
-   DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
- bo->hw_res_handle,
- plane->state->crtc_w, plane->state->crtc_h,
- plane->state->crtc_x, plane->state->crtc_y,
- plane->state->src_w >> 16,
- plane->state->src_h >> 16,
- plane->state->src_x >> 16,
- plane->state->src_y >> 16);
-   virtio_gpu_cmd_set_scanout(vgdev, output->index,
-  bo->hw_res_handle,
-  plane->state->src_w >> 16,
-  plane->state->src_h >> 16,
-  plane->state->src_x >> 16,
-  plane->state->src_y >> 16);
+   if (plane->state->fb != old_state->fb) {
+   DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
+ bo->hw_res_handle,
+ plane->state->crtc_w, plane->state->crtc_h,
+ plane->state->crtc_x, plane->state->crtc_y,
+ plane->state->src_w >> 16,
+ plane->state->src_h >> 16,
+ plane->state->src_x >> 16,
+ plane->state->src_y >> 16);
+   virtio_gpu_cmd_set_scanout(vgdev, output->index,
+  bo->hw_res_handle,
+  plane->state->src_w >> 16,
+  plane->state->src_h >> 16,
+  plane->state->src_x >> 16,
+  plane->state->src_y >> 16);
+   }
+
virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle,
  plane->state->src_x >> 16,
  plane->state->src_y >> 16,
-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] drm/virtio: some optimitations.

[Gerd Hoffmann]

Gerd Hoffmann (3):
  drm/virtio: skip set_scanout if framebuffer didn't change
  virtio-gpu: batch display update commands.
  virtio-gpu: use damage info for display updates.

 drivers/gpu/drm/virtio/virtgpu_drv.h   |  6 ++
 drivers/gpu/drm/virtio/virtgpu_plane.c | 76 +++---
 drivers/gpu/drm/virtio/virtgpu_vq.c| 23 +++-
 3 files changed, 72 insertions(+), 33 deletions(-)

-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] virtio-gpu: use damage info for display updates.

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 41 +++---
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 2e0d14e005db..1a0fbbb91ec7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -24,6 +24,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -103,22 +104,26 @@ static int virtio_gpu_plane_atomic_check(struct drm_plane 
*plane,
 }
 
 static void virtio_gpu_update_dumb_bo(struct virtio_gpu_device *vgdev,
- struct virtio_gpu_object *bo,
- struct drm_plane_state *state)
+ struct drm_plane_state *state,
+ struct drm_rect *rect)
 {
+   struct virtio_gpu_object *bo =
+   gem_to_virtio_gpu_obj(state->fb->obj[0]);
struct virtio_gpu_object_array *objs;
+   uint32_t w = rect->x2 - rect->x1;
+   uint32_t h = rect->y2 - rect->y1;
+   uint32_t x = rect->x1 + (state->src_x >> 16);
+   uint32_t y = rect->y1 + (state->src_y >> 16);
+   uint32_t off = x * state->fb->format->cpp[0] +
+   y * state->fb->pitches[0];
 
objs = virtio_gpu_array_alloc(1);
if (!objs)
return;
virtio_gpu_array_add_obj(objs, &bo->base.base);
-   virtio_gpu_cmd_transfer_to_host_2d
-   (vgdev, 0,
-state->src_w >> 16,
-state->src_h >> 16,
-state->src_x >> 16,
-state->src_y >> 16,
-objs, NULL);
+
+   virtio_gpu_cmd_transfer_to_host_2d(vgdev, off, w, h, x, y,
+  objs, NULL);
 }
 
 static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
@@ -127,8 +132,8 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
struct drm_device *dev = plane->dev;
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_output *output = NULL;
-   struct virtio_gpu_framebuffer *vgfb;
struct virtio_gpu_object *bo;
+   struct drm_rect rect;
 
if (plane->state->crtc)
output = drm_crtc_to_virtio_gpu_output(plane->state->crtc);
@@ -146,12 +151,14 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
return;
}
 
+   if (!drm_atomic_helper_damage_merged(old_state, plane->state, &rect))
+   return;
+
virtio_gpu_disable_notify(vgdev);
 
-   vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
-   bo = gem_to_virtio_gpu_obj(vgfb->base.obj[0]);
+   bo = gem_to_virtio_gpu_obj(plane->state->fb->obj[0]);
if (bo->dumb)
-   virtio_gpu_update_dumb_bo(vgdev, bo, plane->state);
+   virtio_gpu_update_dumb_bo(vgdev, plane->state, &rect);
 
if (plane->state->fb != old_state->fb) {
DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
@@ -171,10 +178,10 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
}
 
virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle,
- plane->state->src_x >> 16,
- plane->state->src_y >> 16,
- plane->state->src_w >> 16,
- plane->state->src_h >> 16);
+ (plane->state->src_x >> 16) + rect.x1,
+ (plane->state->src_y >> 16) + rect.y1,
+ rect.x2 - rect.x1,
+ rect.y2 - rect.y1);
 
virtio_gpu_enable_notify(vgdev);
 }
-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] virtio-gpu: batch display update commands.

[Gerd Hoffmann]

When the driver submits multiple commands in a row it makes sense to
notify the host only after submitting the last one, so the host can
process them all at once, with a single vmexit.

Add functions to enable/disable notifications to allow that.  Use the
new functions for primary plane updates.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h   |  6 ++
 drivers/gpu/drm/virtio/virtgpu_plane.c |  4 
 drivers/gpu/drm/virtio/virtgpu_vq.c| 23 +--
 3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index eedae2a7b532..29cf005ed6b9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -183,6 +183,9 @@ struct virtio_gpu_device {
struct kmem_cache *vbufs;
bool vqs_ready;
 
+   bool disable_notify;
+   bool pending_notify;
+
struct ida  resource_ida;
 
wait_queue_head_t resp_wq;
@@ -335,6 +338,9 @@ void virtio_gpu_dequeue_ctrl_func(struct work_struct *work);
 void virtio_gpu_dequeue_cursor_func(struct work_struct *work);
 void virtio_gpu_dequeue_fence_func(struct work_struct *work);
 
+void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev);
+void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev);
+
 /* virtio_gpu_display.c */
 int virtio_gpu_framebuffer_init(struct drm_device *dev,
struct virtio_gpu_framebuffer *vgfb,
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index a0f91658c2bc..2e0d14e005db 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -146,6 +146,8 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
return;
}
 
+   virtio_gpu_disable_notify(vgdev);
+
vgfb = to_virtio_gpu_framebuffer(plane->state->fb);
bo = gem_to_virtio_gpu_obj(vgfb->base.obj[0]);
if (bo->dumb)
@@ -173,6 +175,8 @@ static void virtio_gpu_primary_plane_update(struct 
drm_plane *plane,
  plane->state->src_y >> 16,
  plane->state->src_w >> 16,
  plane->state->src_h >> 16);
+
+   virtio_gpu_enable_notify(vgdev);
 }
 
 static int virtio_gpu_cursor_prepare_fb(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9274c4063c70..5914e79d3429 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -404,8 +404,12 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct 
virtio_gpu_device *vgdev,
}
notify = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf, vout);
spin_unlock(&vgdev->ctrlq.qlock);
-   if (notify)
-   virtqueue_notify(vgdev->ctrlq.vq);
+   if (notify) {
+   if (vgdev->disable_notify)
+   vgdev->pending_notify = true;
+   else
+   virtqueue_notify(vgdev->ctrlq.vq);
+   }
 
if (sgt) {
sg_free_table(sgt);
@@ -413,6 +417,21 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct 
virtio_gpu_device *vgdev,
}
 }
 
+void virtio_gpu_disable_notify(struct virtio_gpu_device *vgdev)
+{
+   vgdev->disable_notify = true;
+}
+
+void virtio_gpu_enable_notify(struct virtio_gpu_device *vgdev)
+{
+   vgdev->disable_notify = false;
+
+   if (!vgdev->pending_notify)
+   return;
+   vgdev->pending_notify = false;
+   virtqueue_notify(vgdev->ctrlq.vq);
+}
+
 static void virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev,
 struct virtio_gpu_vbuffer *vbuf)
 {
-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] drm/sprd: add Unisoc's drm kms master

[tang pengchuan]

Daniel Vetter  于2019年12月10日周二 下午6:41写道：

> On Tue, Dec 10, 2019 at 04:36:29PM +0800, Kevin Tang wrote:
> > From: Kevin Tang 
> >
> > Adds drm support for the Unisoc's display subsystem.
> >
> > This is drm device and gem driver. This driver provides support for the
> > Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> >
> > Cc: Orson Zhai 
> > Cc: Baolin Wang 
> > Cc: Chunyan Zhang 
> > Signed-off-by: Kevin Tang 
> > ---
> >  drivers/gpu/drm/Kconfig |   2 +
> >  drivers/gpu/drm/Makefile|   1 +
> >  drivers/gpu/drm/sprd/Kconfig|  14 ++
> >  drivers/gpu/drm/sprd/Makefile   |   8 ++
> >  drivers/gpu/drm/sprd/sprd_drm.c | 287
> 
> >  drivers/gpu/drm/sprd/sprd_drm.h |  19 +++
> >  drivers/gpu/drm/sprd/sprd_gem.c | 178 +
> >  drivers/gpu/drm/sprd/sprd_gem.h |  30 +
> >  8 files changed, 539 insertions(+)
> >  create mode 100644 drivers/gpu/drm/sprd/Kconfig
> >  create mode 100644 drivers/gpu/drm/sprd/Makefile
> >  create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
> >  create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
> >  create mode 100644 drivers/gpu/drm/sprd/sprd_gem.c
> >  create mode 100644 drivers/gpu/drm/sprd/sprd_gem.h
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index bfdadc3..cead12c 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -387,6 +387,8 @@ source "drivers/gpu/drm/aspeed/Kconfig"
> >
> >  source "drivers/gpu/drm/mcde/Kconfig"
> >
> > +source "drivers/gpu/drm/sprd/Kconfig"
> > +
> >  # Keep legacy drivers last
> >
> >  menuconfig DRM_LEGACY
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 9f1c7c4..85ca211 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -122,3 +122,4 @@ obj-$(CONFIG_DRM_LIMA)  += lima/
> >  obj-$(CONFIG_DRM_PANFROST) += panfrost/
> >  obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
> >  obj-$(CONFIG_DRM_MCDE) += mcde/
> > +obj-$(CONFIG_DRM_SPRD) += sprd/
> > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> > new file mode 100644
> > index 000..79f286b
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/Kconfig
> > @@ -0,0 +1,14 @@
> > +config DRM_SPRD
> > + tristate "DRM Support for Unisoc SoCs Platform"
> > + depends on ARCH_SPRD
> > + depends on DRM && OF
> > + select DRM_KMS_HELPER
> > + select DRM_GEM_CMA_HELPER
> > + select DRM_KMS_CMA_HELPER
> > + select DRM_MIPI_DSI
> > + select DRM_PANEL
> > + select VIDEOMODE_HELPERS
> > + select BACKLIGHT_CLASS_DEVICE
> > + help
> > +   Choose this option if you have a Unisoc chipsets.
> > +   If M is selected the module will be called sprd-drm.
> > \ No newline at end of file
> > diff --git a/drivers/gpu/drm/sprd/Makefile
> b/drivers/gpu/drm/sprd/Makefile
> > new file mode 100644
> > index 000..df0b316
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/Makefile
> > @@ -0,0 +1,8 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +ccflags-y += -Iinclude/drm
> > +
> > +subdir-ccflags-y += -I$(src)
> > +
> > +obj-y := sprd_drm.o \
> > + sprd_gem.o
> > \ No newline at end of file
> > diff --git a/drivers/gpu/drm/sprd/sprd_drm.c
> b/drivers/gpu/drm/sprd/sprd_drm.c
> > new file mode 100644
> > index 000..ec16fee
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/sprd_drm.c
> > @@ -0,0 +1,287 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Unisoc Inc.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "sprd_drm.h"
> > +#include "sprd_gem.h"
> > +
> > +#define DRIVER_NAME  "sprd"
> > +#define DRIVER_DESC  "Spreadtrum SoCs' DRM Driver"
> > +#define DRIVER_DATE  "20180501"
> > +#define DRIVER_MAJOR 1
> > +#define DRIVER_MINOR 0
> > +
> > +static const struct drm_mode_config_helper_funcs
> sprd_drm_mode_config_helper = {
> > + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> > +};
> > +
> > +static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
> > + .fb_create = drm_gem_fb_create,
> > + .atomic_check = drm_atomic_helper_check,
> > + .atomic_commit = drm_atomic_helper_commit,
> > +};
> > +
> > +static void sprd_drm_mode_config_init(struct drm_device *drm)
> > +{
> > + drm_mode_config_init(drm);
> > +
> > + drm->mode_config.min_width = 0;
> > + drm->mode_config.min_height = 0;
> > + drm->mode_config.max_width = 8192;
> > + drm->mode_config.max_height = 8192;
> > + drm->mode_config.allow_fb_modifiers = true;
> > +
> > + drm->mode_config.funcs = &sprd_drm_mode_config_funcs;
> > + drm->mode_config.helper_private = &sprd_drm_mode_config_helper;
> > +}
> > +
> > +static const struct file_operations sprd_drm_fops = {
> > + .owner  = THIS_MODU

Re: [PATCH] drm/nouveau: Fix memory leak in nouveau_bo_alloc

[Navid Emamdoost]

ping ...

On Tue, Nov 26, 2019 at 11:50 AM Navid Emamdoost
 wrote:
>
> ping...
>
> On Thu, Nov 21, 2019 at 12:09 PM Navid Emamdoost
>  wrote:
> >
> > On Mon, Oct 21, 2019 at 4:14 PM Navid Emamdoost
> >  wrote:
> > >
> > > In the implementation of nouveau_bo_alloc() if it fails to determine the
> > > target page size via pi, then the allocated memory for nvbo should be
> > > released.
> > >
> > > Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM 
> > > object")
> > > Signed-off-by: Navid Emamdoost 
> >
> > Would you please review this patch?
> >
> >
> > Thanks,
> > Navid.
> >
> > > ---
> > >  drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> > > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > index f8015e0318d7..18857cf44068 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > > @@ -276,8 +276,10 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, 
> > > int *align, u32 flags,
> > > break;
> > > }
> > >
> > > -   if (WARN_ON(pi < 0))
> > > +   if (WARN_ON(pi < 0)) {
> > > +   kfree(nvbo);
> > > return ERR_PTR(-EINVAL);
> > > +   }
> > >
> > > /* Disable compression if suitable settings couldn't be found. */
> > > if (nvbo->comp && !vmm->page[pi].comp) {
> > > --
> > > 2.17.1
> > >
> >
> >
> > --
> > Navid.
>
>
>
> --
> Navid.



-- 
Navid.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding

[Hsin-Yi Wang]

On Mon, Dec 9, 2019 at 10:53 PM Laurent Pinchart
 wrote:
Hi Laurent,

> How about converting this to yaml bindings already ? It's fairly simple
> and gives you DT validation.
>
Added in 
https://lore.kernel.org/lkml/20191211061911.238393-1-hsi...@chromium.org/T/#m183b3822bf60101666436b0244b27275c6765d20

Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RESEND 3/4] dt-bindings: drm/bridge: analogix-anx78xx: support bypass GPIO

[Hsin-Yi Wang]

On Mon, Dec 9, 2019 at 11:32 PM Laurent Pinchart
 wrote:
>
Hi Laurent,
> You may have used a proportional font when writing this, the | doesn't
> align with anything using a fixed font. Do I assume correctly that the
> hardware multiplexer is actually a demultiplexer with one input and two
> outputs ?
>  +---+
> +-+ +--+/--> | HDMI  |
> | MT8173  |  HDMI   |   -->| --/ | Connector |
> |  HDMI   | --> |--/   | +---+
> | Encoder | |->| --\ +---+  +---+
> +-+ +--+\--> | ANX7688   | ---> | USB-C |
>  | Bridge|  | Connector |
>  +---+  +---+
>
Sorry for not noticing the font issue, this graph is correct.

> > There's a hardware mux that takes mt8173 hdmi as input and has 2
> > output port: native hdmi and anx7688 bridge.
> > If gpio is active, we would like it to go to HDMI.
> >
> > Previous approach is to make hardware mux a generic gpio mux bridge,
> > but this is probably a very rare use case that is only for
> > mt8173.(https://lore.kernel.org/lkml/57723ad2.8020...@codeaurora.org/)
> > We merge the mux and anx7688 to a single bridge and leave this as an
> > optional feature in this time.
>
> I think that's a better approach, at least at the DT level. The HDMI
> demultiplexer should be represented as a DT node with 3 ports (one input
> and two outputs) with a control GPIO.
>
I've resend the original gpio mux driver. So for anx7688 there's 1
input and 1 output.

Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v3,2/4] drm/edid: Add CTA-861-G modes with VIC >= 193

[Tom Anderson]

Reviewed-by: Thomas Anderson 

On Wed, Sep 25, 2019 at 04:55:00PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Add a second table to the cea modes with VIC >= 193.
> 
> Cc: Hans Verkuil 
> Cc: Shashank Sharma 
> Signed-off-by: Ville Syrjälä 
> Reviewed-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_edid.c | 151 -
>  1 file changed, 149 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index b700fc075257..9f6996323efa 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1376,6 +1376,149 @@ static const struct drm_display_mode 
> edid_cea_modes_0[] = {
> .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
>  };
>  
> +/*
> + * From CEA/CTA-861 spec.
> + *
> + * Index with VIC-193.
> + */
> +static const struct drm_display_mode edid_cea_modes_193[] = {
> + /* 193 - 5120x2160@120Hz 64:27 */
> + { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 1485000, 5120, 5284,
> +5372, 5500, 0, 2160, 2168, 2178, 2250, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 194 - 7680x4320@24Hz 16:9 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10232,
> +10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 195 - 7680x4320@25Hz 16:9 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10032,
> +10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 196 - 7680x4320@30Hz 16:9 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 8232,
> +8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 197 - 7680x4320@48Hz 16:9 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10232,
> +10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 198 - 7680x4320@50Hz 16:9 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10032,
> +10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 199 - 7680x4320@60Hz 16:9 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 8232,
> +8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 200 - 7680x4320@100Hz 16:9 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 4752000, 7680, 9792,
> +9968, 10560, 0, 4320, 4336, 4356, 4500, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 201 - 7680x4320@120Hz 16:9 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 4752000, 7680, 8032,
> +8208, 8800, 0, 4320, 4336, 4356, 4500, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 202 - 7680x4320@24Hz 64:27 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10232,
> +10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 203 - 7680x4320@25Hz 64:27 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10032,
> +10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 204 - 7680x4320@30Hz 64:27 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 8232,
> +8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 205 - 7680x4320@48Hz 64:27 */
> + { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10232,
> +10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
> +DRM_MO

Re: [PATCH v8 2/2] drm/bridge: Add NWL MIPI DSI host controller support

[Martin Kepplinger]

On 02.12.19 20:35, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found on
> i.MX8 SoCs.
> 
> It adds support for the i.MX8MQ but the same IP can be found on
> e.g. the i.MX8QXP.
> 
> It has been tested on the Librem 5 devkit using mxsfb.
> 
> Signed-off-by: Guido Günther 
> Co-developed-by: Robert Chiras 
> Signed-off-by: Robert Chiras 
> Tested-by: Robert Chiras 
> ---

Running on the librem5-devkit with some of these msxfb fixes on top:
https://lore.kernel.org/linux-arm-kernel/1567078215-31601-1-git-send-email-robert.chi...@nxp.com/

the tree I'm running, starting with this patch:
https://source.puri.sm/martin.kepplinger/linux-next/commits/next-20191210/librem5_nwl_mipi_dsi_testing
so:

Tested-by: Martin Kepplinger 

thanks,
 martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 12/12] auxdisplay: constify fb ops

[robin]

Hello Jani,

On 2019-12-09 15:03, Jani Nikula wrote:

On Tue, 03 Dec 2019, Jani Nikula  wrote:

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

Cc: Miguel Ojeda Sandonis 
Cc: Robin van der Gracht 
Reviewed-by: Daniel Vetter 
Reviewed-by: Miguel Ojeda 
Acked-by: Robin van der Gracht 
Signed-off-by: Jani Nikula 


Miguel, Robin, just to err on the safe side, were you both okay with me
merging this through drm-misc? Not very likely to conflict badly.


ht16k33 driver hasn't seen much change lately, should be fine.

Robin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 6/6] gpu/drm: ingenic: Add support for the JZ4770

[Paul Cercueil]

The LCD controller in the JZ4770 supports up to 720p. While there has
been many new features added since the old JZ4740, which are not yet
handled here, this driver still works fine.

v2: No change

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index da681214d0b6..daa3dbeb736b 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -830,9 +830,16 @@ static const struct jz_soc_info jz4725b_soc_info = {
.max_height = 600,
 };
 
+static const struct jz_soc_info jz4770_soc_info = {
+   .needs_dev_clk = false,
+   .max_width = 1280,
+   .max_height = 720,
+};
+
 static const struct of_device_id ingenic_drm_of_match[] = {
{ .compatible = "ingenic,jz4740-lcd", .data = &jz4740_soc_info },
{ .compatible = "ingenic,jz4725b-lcd", .data = &jz4725b_soc_info },
+   { .compatible = "ingenic,jz4770-lcd", .data = &jz4770_soc_info },
{ /* sentinel */ },
 };
 
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RESEND 3/4] dt-bindings: drm/bridge: Add GPIO display mux binding

[Hsin-Yi Wang]

From: Nicolas Boichat 

Add bindings for Generic GPIO mux driver.

Signed-off-by: Nicolas Boichat 
Signed-off-by: Hsin-Yi Wang 
---
Change from RFC to v1:
- txt to yaml
---
 .../bindings/display/bridge/gpio-mux.yaml | 89 +++
 1 file changed, 89 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml 
b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
new file mode 100644
index ..cef098749066
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/gpio-mux.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic display mux (1 input, 2 outputs)
+
+maintainers:
+  - Nicolas Boichat 
+
+description: |
+  This bindings describes a simple display (e.g. HDMI) mux, that has 1
+  input, and 2 outputs. The mux status is controlled by hardware, and
+  its status is read back using a GPIO.
+
+properties:
+  compatible:
+const: gpio-display-mux
+
+  detect-gpios:
+maxItems: 1
+description: GPIO that indicates the active output
+
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: |
+  Video port for input.
+
+  port@1:
+type: object
+description: |
+  2 video ports for output.
+  The reg value in the endpoints matches the GPIO status: when
+  GPIO is asserted, endpoint with reg value <1> is selected.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - detect-gpios
+  - ports
+
+examples:
+  - |
+hdmi_mux: hdmi_mux {
+  compatible = "gpio-display-mux";
+  status = "okay";
+  detect-gpios = <&pio 36 GPIO_ACTIVE_HIGH>;
+  pinctrl-names = "default";
+  pinctrl-0 = <&hdmi_mux_pins>;
+  ddc-i2c-bus = <&hdmiddc0>;
+
+  ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 { /* input */
+  reg = <0>;
+
+  hdmi_mux_in: endpoint {
+remote-endpoint = <&hdmi0_out>;
+  };
+};
+
+port@1 { /* output */
+  reg = <1>;
+
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  hdmi_mux_out_anx: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&anx7688_in>;
+  };
+
+  hdmi_mux_out_hdmi: endpoint@1 {
+reg = <1>;
+remote-endpoint = <&hdmi_connector_in>;
+  };
+};
+  };
+};
-- 
2.24.0.525.g8f36a354ae-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

KASAN: vmalloc-out-of-bounds Write in sys_imageblit

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:6794862a Merge tag 'for-5.5-rc1-kconfig-tag' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17f407f2e0
kernel config:  https://syzkaller.appspot.com/x/.config?x=79f79de2a27d3e3d
dashboard link: https://syzkaller.appspot.com/bug?extid=26dc38a00dc05118a4e6
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+26dc38a00dc05118a...@syzkaller.appspotmail.com

==
BUG: KASAN: vmalloc-out-of-bounds in fast_imageblit  
drivers/video/fbdev/core/sysimgblt.c:229 [inline]
BUG: KASAN: vmalloc-out-of-bounds in sys_imageblit+0x117f/0x1240  
drivers/video/fbdev/core/sysimgblt.c:275

Write of size 4 at addr c90008de1000 by task syz-executor.3/19698

CPU: 0 PID: 19698 Comm: syz-executor.3 Not tainted 5.5.0-rc1-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS  
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x197/0x210 lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0x5/0x30b mm/kasan/report.c:374
 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506
 kasan_report+0x12/0x20 mm/kasan/common.c:639
 __asan_report_store4_noabort+0x17/0x20 mm/kasan/generic_report.c:139
 fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline]
 sys_imageblit+0x117f/0x1240 drivers/video/fbdev/core/sysimgblt.c:275
 drm_fb_helper_sys_imageblit+0x21/0x180 drivers/gpu/drm/drm_fb_helper.c:768
 bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:139 [inline]
 bit_putcs+0x9a3/0xf10 drivers/video/fbdev/core/bitblit.c:188
 fbcon_putcs+0x33c/0x3e0 drivers/video/fbdev/core/fbcon.c:1353
 do_update_region+0x42b/0x6f0 drivers/tty/vt/vt.c:677
 invert_screen+0x2da/0x650 drivers/tty/vt/vt.c:794
 highlight drivers/tty/vt/selection.c:53 [inline]
 clear_selection drivers/tty/vt/selection.c:81 [inline]
 clear_selection+0x59/0x70 drivers/tty/vt/selection.c:77
 vc_do_resize+0x1163/0x1460 drivers/tty/vt/vt.c:1200
 vc_resize+0x4d/0x60 drivers/tty/vt/vt.c:1304
 fbcon_do_set_font+0x4a6/0x960 drivers/video/fbdev/core/fbcon.c:2599
 fbcon_set_font+0x72e/0x860 drivers/video/fbdev/core/fbcon.c:2696
 con_font_set drivers/tty/vt/vt.c:4538 [inline]
 con_font_op+0xe30/0x1270 drivers/tty/vt/vt.c:4603
 vt_ioctl+0xd2e/0x26d0 drivers/tty/vt/vt_ioctl.c:913
 tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660
 vfs_ioctl fs/ioctl.c:47 [inline]
 file_ioctl fs/ioctl.c:545 [inline]
 do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732
 ksys_ioctl+0xab/0xd0 fs/ioctl.c:749
 __do_sys_ioctl fs/ioctl.c:756 [inline]
 __se_sys_ioctl fs/ioctl.c:754 [inline]
 __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45a7c9
Code: bd b1 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 8b b1 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7fcfa0ba6c88 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 0072bf00 RCX: 0045a7c9
RDX: 2140 RSI: 4b61 RDI: 0003
RBP: 0003 R08:  R09: 
R10:  R11: 0246 R12: 7fcfa0ba76d4
R13: 004ab60f R14: 006ede60 R15: 


Memory state around the buggy address:
 c90008de0f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c90008de0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

c90008de1000: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9

   ^
 c90008de1080: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
 c90008de1100: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
==


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/6] gpu/drm: ingenic: Set max FB height to 4095

[Paul Cercueil]

While the LCD controller can effectively only support a maximum
resolution of 800x600, the framebuffer's height can be much higher,
since we can change the Y start offset.

v2: No change

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 8713f09df448..cef2f29a9d7a 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -636,7 +636,7 @@ static int ingenic_drm_probe(struct platform_device *pdev)
drm->mode_config.min_width = 0;
drm->mode_config.min_height = 0;
drm->mode_config.max_width = 800;
-   drm->mode_config.max_height = 600;
+   drm->mode_config.max_height = 4095;
drm->mode_config.funcs = &ingenic_drm_mode_config_funcs;
 
base = devm_platform_ioremap_resource(pdev, 0);
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Add modes from CTA-861-G

[Tom Anderson]

On Tue, Dec 03, 2019 at 02:53:12PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 02, 2019 at 03:32:46PM -0800, Tom Anderson wrote:
> > On Mon, Nov 25, 2019 at 01:42:00PM -0500, Bhawanpreet Lakha wrote:
> > > Reviewed-by: Bhawanpreet Lakha 
> > 
> > Thank you for the review. +Ville has brought to my attention 978f6b0693c7 
> > which
> > added modes up to 128 which was part of a recent merge, so I didn't seen the
> > changes until now.
> > 
> > Ville also pointed out [1] which achieves the same thing, but has been in 
> > limbo.
> > At any rate, I'll be sending out a rebased v2 patch. I don't mind which 
> > patch
> > lands, all I want is for my 8K display to work :)
> 
> I'd just need someone to slap on a reviwed-by for the few patches
> that are missing it. I'd rather not waste ~13 KiB of memory for
> those 128-192 dummy modes, which is why I prefer my apporach.

Like I said, I'm fine with either patch landing. But in your patch, please merge
the drm_connector.h changes from here, otherwise there's a buffer overflow.

> 
> > 
> > [1] https://patchwork.freedesktop.org/series/63555/
> > 
> > > 
> > > On 2019-11-25 1:14 p.m., Harry Wentland wrote:
> > > > +Bhawan who has been looking at this from our side.
> > > > 
> > > > Harry
> > > > 
> > > > On 2019-11-23 12:50 a.m., Thomas Anderson wrote:
> > > > > The new modes are needed for exotic displays such as 8K. Verified that
> > > > > modes like 8K60 and 4K120 are properly obtained from a Samsung Q900R.
> > > > > 
> > > > > Signed-off-by: Thomas Anderson 
> > > > > ---
> > > > >   drivers/gpu/drm/drm_edid.c  | 388 
> > > > > +++-
> > > > >   include/drm/drm_connector.h |  16 +-
> > > > >   2 files changed, 391 insertions(+), 13 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > > index 6b0177112e18..ff5c928516fb 100644
> > > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > > @@ -1278,6 +1278,374 @@ static const struct drm_display_mode 
> > > > > edid_cea_modes[] = {
> > > > >  4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
> > > > >  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > .vrefresh = 60, .picture_aspect_ratio = 
> > > > > HDMI_PICTURE_ASPECT_64_27, },
> > > > > + /* 108 - 1280x720@48Hz 16:9 */
> > > > > + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 9, 1280, 2240,
> > > > > +2280, 2500, 0, 720, 725, 730, 750, 0,
> > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > HDMI_PICTURE_ASPECT_16_9, },
> > > > > + /* 109 - 1280x720@48Hz 64:27 */
> > > > > + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 9, 1280, 2240,
> > > > > +2280, 2500, 0, 720, 725, 730, 750, 0,
> > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > HDMI_PICTURE_ASPECT_64_27, },
> > > > > + /* 110 - 1680x720@48Hz 64:27 */
> > > > > + { DRM_MODE("1680x720", DRM_MODE_TYPE_DRIVER, 99000, 1680, 2490,
> > > > > +2530, 2750, 0, 720, 725, 730, 750, 0,
> > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > HDMI_PICTURE_ASPECT_64_27, },
> > > > > + /* 111 - 1920x1080@48Hz 16:9 */
> > > > > + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 
> > > > > 2558,
> > > > > +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > HDMI_PICTURE_ASPECT_16_9, },
> > > > > + /* 112 - 1920x1080@48Hz 64:27 */
> > > > > + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 
> > > > > 2558,
> > > > > +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > HDMI_PICTURE_ASPECT_64_27, },
> > > > > + /* 113 - 2560x1080@48Hz 64:27 */
> > > > > + { DRM_MODE("2560x1080", DRM_MODE_TYPE_DRIVER, 198000, 2560, 
> > > > > 3558,
> > > > > +3602, 3750, 0, 1080, 1084, 1089, 1100, 0,
> > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > HDMI_PICTURE_ASPECT_64_27, },
> > > > > + /* 114 - 3840x2160@48Hz 16:9 */
> > > > > + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 594000, 3840, 
> > > > > 5116,
> > > > > +5204, 5500, 0, 2160, 2168, 2178, 2250, 0,
> > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > HDMI_PICTURE_ASPECT_16_9, },
> > > > > + /* 115 - 4096x2160@48Hz 256:135 */
> > > > > +   

Re: [PATCH] drm/edid: Add modes from CTA-861-G

[Tom Anderson]

On Tue, Dec 10, 2019 at 10:05:55PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 10, 2019 at 11:13:35AM -0800, Tom Anderson wrote:
> > On Tue, Dec 03, 2019 at 02:53:12PM +0200, Ville Syrjälä wrote:
> > > On Mon, Dec 02, 2019 at 03:32:46PM -0800, Tom Anderson wrote:
> > > > On Mon, Nov 25, 2019 at 01:42:00PM -0500, Bhawanpreet Lakha wrote:
> > > > > Reviewed-by: Bhawanpreet Lakha 
> > > > 
> > > > Thank you for the review. +Ville has brought to my attention 
> > > > 978f6b0693c7 which
> > > > added modes up to 128 which was part of a recent merge, so I didn't 
> > > > seen the
> > > > changes until now.
> > > > 
> > > > Ville also pointed out [1] which achieves the same thing, but has been 
> > > > in limbo.
> > > > At any rate, I'll be sending out a rebased v2 patch. I don't mind which 
> > > > patch
> > > > lands, all I want is for my 8K display to work :)
> > > 
> > > I'd just need someone to slap on a reviwed-by for the few patches
> > > that are missing it. I'd rather not waste ~13 KiB of memory for
> > > those 128-192 dummy modes, which is why I prefer my apporach.
> > 
> > Like I said, I'm fine with either patch landing. But in your patch, please 
> > merge
> > the drm_connector.h changes from here, otherwise there's a buffer overflow.
> 
> Ouch. Good catch. Didn't even notice that one. Can you send that
> hunk as a separate patch and review the remaining patches in my
> series so I could just push it all?

Will do!

> 
> > 
> > > 
> > > > 
> > > > [1] https://patchwork.freedesktop.org/series/63555/
> > > > 
> > > > > 
> > > > > On 2019-11-25 1:14 p.m., Harry Wentland wrote:
> > > > > > +Bhawan who has been looking at this from our side.
> > > > > > 
> > > > > > Harry
> > > > > > 
> > > > > > On 2019-11-23 12:50 a.m., Thomas Anderson wrote:
> > > > > > > The new modes are needed for exotic displays such as 8K. Verified 
> > > > > > > that
> > > > > > > modes like 8K60 and 4K120 are properly obtained from a Samsung 
> > > > > > > Q900R.
> > > > > > > 
> > > > > > > Signed-off-by: Thomas Anderson 
> > > > > > > ---
> > > > > > >   drivers/gpu/drm/drm_edid.c  | 388 
> > > > > > > +++-
> > > > > > >   include/drm/drm_connector.h |  16 +-
> > > > > > >   2 files changed, 391 insertions(+), 13 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/drm_edid.c 
> > > > > > > b/drivers/gpu/drm/drm_edid.c
> > > > > > > index 6b0177112e18..ff5c928516fb 100644
> > > > > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > > > > @@ -1278,6 +1278,374 @@ static const struct drm_display_mode 
> > > > > > > edid_cea_modes[] = {
> > > > > > >  4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
> > > > > > >  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > > > .vrefresh = 60, .picture_aspect_ratio = 
> > > > > > > HDMI_PICTURE_ASPECT_64_27, },
> > > > > > > + /* 108 - 1280x720@48Hz 16:9 */
> > > > > > > + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 9, 1280, 2240,
> > > > > > > +2280, 2500, 0, 720, 725, 730, 750, 0,
> > > > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > > > HDMI_PICTURE_ASPECT_16_9, },
> > > > > > > + /* 109 - 1280x720@48Hz 64:27 */
> > > > > > > + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 9, 1280, 2240,
> > > > > > > +2280, 2500, 0, 720, 725, 730, 750, 0,
> > > > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > > > HDMI_PICTURE_ASPECT_64_27, },
> > > > > > > + /* 110 - 1680x720@48Hz 64:27 */
> > > > > > > + { DRM_MODE("1680x720", DRM_MODE_TYPE_DRIVER, 99000, 1680, 2490,
> > > > > > > +2530, 2750, 0, 720, 725, 730, 750, 0,
> > > > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > > > HDMI_PICTURE_ASPECT_64_27, },
> > > > > > > + /* 111 - 1920x1080@48Hz 16:9 */
> > > > > > > + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 
> > > > > > > 2558,
> > > > > > > +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> > > > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > > > HDMI_PICTURE_ASPECT_16_9, },
> > > > > > > + /* 112 - 1920x1080@48Hz 64:27 */
> > > > > > > + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 
> > > > > > > 2558,
> > > > > > > +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> > > > > > > +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> > > > > > > +   .vrefresh = 48, .picture_aspect_ratio = 
> > > > > > > HDMI_PICTURE_ASPECT_64_27, },
> > > > > > > + /* 113 - 2560x1080@48Hz 64:27 */
> > > > > > > + { DRM_MODE("2560x1080", DRM_MODE_TYPE_DRIVER, 198000, 2560, 
> > > > > > > 3558,
> > > > > > > +3602, 3750, 0, 1080, 1084,

[PATCH 1/5] drm: atmel-hlcdc: use double rate for pixel clock only if supported

[Claudiu Beznea]

Doubled system clock should be used as pixel cock source only if this
is supported. This is emphasized by the value of
atmel_hlcdc_crtc::dc::desc::fixed_clksrc.

Fixes: a6eca2abdd42 ("drm: atmel-hlcdc: add config option for clock selection")
Signed-off-by: Claudiu Beznea 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index f2e73e6d46b8..5040ed8d0871 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -95,14 +95,14 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
 (adj->crtc_hdisplay - 1) |
 ((adj->crtc_vdisplay - 1) << 16));
 
+   prate = clk_get_rate(crtc->dc->hlcdc->sys_clk);
+   mode_rate = adj->crtc_clock * 1000;
if (!crtc->dc->desc->fixed_clksrc) {
+   prate *= 2;
cfg |= ATMEL_HLCDC_CLKSEL;
mask |= ATMEL_HLCDC_CLKSEL;
}
 
-   prate = 2 * clk_get_rate(crtc->dc->hlcdc->sys_clk);
-   mode_rate = adj->crtc_clock * 1000;
-
div = DIV_ROUND_UP(prate, mode_rate);
if (div < 2) {
div = 2;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RESEND 4/4] drm: bridge: Generic GPIO mux driver

[Hsin-Yi Wang]

From: Nicolas Boichat 

This driver supports single input, 2 output display mux (e.g.
HDMI mux), that provide its status via a GPIO.

Signed-off-by: Nicolas Boichat 
Signed-off-by: Hsin-Yi Wang 
---
 drivers/gpu/drm/bridge/Kconfig|  10 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++
 3 files changed, 317 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 1f3fc6bec842..4734f6993858 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -54,6 +54,16 @@ config DRM_DUMB_VGA_DAC
  Support for non-programmable RGB to VGA DAC bridges, such as ADI
  ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
 
+config DRM_GENERIC_GPIO_MUX
+   tristate "Generic GPIO-controlled mux"
+   depends on OF
+   select DRM_KMS_HELPER
+   ---help---
+ This bridge driver models a GPIO-controlled display mux with one
+ input, 2 outputs (e.g. an HDMI mux). The hardware decides which output
+ is active, reports it as a GPIO, and the driver redirects calls to the
+ appropriate downstream bridge (if any).
+
 config DRM_LVDS_ENCODER
tristate "Transparent parallel to LVDS encoder support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 7a1e0ec032e6..1c0c92667ac4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
+obj-$(CONFIG_DRM_GENERIC_GPIO_MUX) += generic-gpio-mux.o
 obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/generic-gpio-mux.c 
b/drivers/gpu/drm/bridge/generic-gpio-mux.c
new file mode 100644
index ..ba08321dcc17
--- /dev/null
+++ b/drivers/gpu/drm/bridge/generic-gpio-mux.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generic gpio mux bridge driver
+ *
+ * Copyright 2016 Google LLC
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct gpio_display_mux {
+   struct device *dev;
+
+   struct gpio_desc *gpiod_detect;
+   int detect_irq;
+
+   struct drm_bridge bridge;
+
+   struct drm_bridge *next[2];
+};
+
+static inline struct gpio_display_mux *bridge_to_gpio_display_mux(
+   struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct gpio_display_mux, bridge);
+}
+
+static irqreturn_t gpio_display_mux_det_threaded_handler(int unused, void 
*data)
+{
+   struct gpio_display_mux *gpio_display_mux = data;
+   int active = gpiod_get_value(gpio_display_mux->gpiod_detect);
+
+   dev_dbg(gpio_display_mux->dev, "Interrupt %d!\n", active);
+
+   if (gpio_display_mux->bridge.dev)
+   drm_kms_helper_hotplug_event(gpio_display_mux->bridge.dev);
+
+   return IRQ_HANDLED;
+}
+
+static int gpio_display_mux_attach(struct drm_bridge *bridge)
+{
+   struct gpio_display_mux *gpio_display_mux =
+   bridge_to_gpio_display_mux(bridge);
+   struct drm_bridge *next;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(gpio_display_mux->next); i++) {
+   next = gpio_display_mux->next[i];
+   if (next)
+   next->encoder = bridge->encoder;
+   }
+
+   return 0;
+}
+
+static bool gpio_display_mux_mode_fixup(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   struct gpio_display_mux *gpio_display_mux =
+   bridge_to_gpio_display_mux(bridge);
+   int active;
+   struct drm_bridge *next;
+
+   active = gpiod_get_value(gpio_display_mux->gpiod_detect);
+   next = gpio_display_mux->next[active];
+
+   if (next && next->funcs->mode_fixup)
+   return next->funcs->mode_fixup(next, mode, adjusted_mode);
+   else
+   return true;
+}
+
+static void gpio_display_mux_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   struct gpio_display_mux *gpio_display_mux =
+   bridge_to_gpio_display_mux(bridge);
+   int active;
+   struct drm_bridge *next;
+
+   active = gpiod_get_value(gpio_display_mux->gpiod_detect);
+   next = gpio_display_mux->next[active];
+
+   if (next && next->funcs->mode_s

[PATCH 3/5] mfd: atmel-hlcdc: return in case of error

[Claudiu Beznea]

For HLCDC timing engine configurations bit ATMEL_HLCDC_SIP of
ATMEL_HLCDC_SR needs to checked if it is equal with zero before applying
new configuration to timing engine. In case of timeout there is no
indicator about this, so, return with error in case of timeout in
regmap_atmel_hlcdc_reg_write() and also print a message about this.

Signed-off-by: Claudiu Beznea 
---
 drivers/mfd/atmel-hlcdc.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/atmel-hlcdc.c b/drivers/mfd/atmel-hlcdc.c
index 64013c57a920..19f1dbeb8bcd 100644
--- a/drivers/mfd/atmel-hlcdc.c
+++ b/drivers/mfd/atmel-hlcdc.c
@@ -39,10 +39,16 @@ static int regmap_atmel_hlcdc_reg_write(void *context, 
unsigned int reg,
 
if (reg <= ATMEL_HLCDC_DIS) {
u32 status;
-
-   readl_poll_timeout_atomic(hregmap->regs + ATMEL_HLCDC_SR,
- status, !(status & ATMEL_HLCDC_SIP),
- 1, 100);
+   int ret;
+
+   ret = readl_poll_timeout_atomic(hregmap->regs + ATMEL_HLCDC_SR,
+   status,
+   !(status & ATMEL_HLCDC_SIP),
+   1, 100);
+   if (ret) {
+   pr_err("Timeout waiting for ATMEL_HLCDC_SIP\n");
+   return ret;
+   }
}
 
writel(val, hregmap->regs + reg);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/5] fixes for atmel-hlcdc

[Claudiu Beznea]

Hi,

I have few fixes for atmel-hlcdc driver in this series as well
as two reverts.
Revert "drm: atmel-hlcdc: enable sys_clk during initalization." is
due to the fix in in patch 2/5.

Thank you,
Claudiu Beznea

Claudiu Beznea (5):
  drm: atmel-hlcdc: use double rate for pixel clock only if supported
  drm: atmel-hlcdc: enable clock before configuring timing engine
  mfd: atmel-hlcdc: return in case of error
  Revert "drm/atmel-hlcdc: allow selecting a higher pixel-clock than
requested"
  Revert "drm: atmel-hlcdc: enable sys_clk during initalization."

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 26 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 19 +--
 drivers/mfd/atmel-hlcdc.c  | 14 ++
 3 files changed, 21 insertions(+), 38 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] Revert "drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested"

[Peter Rosin]

On 2019-12-10 14:24, Claudiu Beznea wrote:
> This reverts commit f6f7ad3234613f6f7f27c25036aaf078de07e9b0.
> ("drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested")
> because allowing selecting a higher pixel clock may overclock
> LCD devices, not all of them being capable of this.

Without this patch, there are panels that are *severly* underclocked (on the
magnitude of 40MHz instead of 65MHz or something like that, I don't remember
the exact figures). And they are of course not capable of that. All panels
have *some* slack as to what frequencies are supported, and the patch was
written under the assumption that the preferred frequency of the panel was
requested, which should leave at least a *little* headroom.

So, I'm curious as to what panel regressed. Or rather, what pixel-clock it needs
and what it gets with/without the patch?

Or is the revert based on some theory of a perceived risk of toasting a panel?

In short, this revert regresses my use case and I would like at least a hook to
re-enable the removed logic.

Cheers,
Peter

> Cc: Peter Rosin 
> Signed-off-by: Claudiu Beznea 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 12 
>  1 file changed, 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 721fa88bf71d..1a70dff1a417 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -117,18 +117,6 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct 
> drm_crtc *c)
>   div = DIV_ROUND_UP(prate, mode_rate);
>   if (ATMEL_HLCDC_CLKDIV(div) & ~ATMEL_HLCDC_CLKDIV_MASK)
>   div = ATMEL_HLCDC_CLKDIV_MASK;
> - } else {
> - int div_low = prate / mode_rate;
> -
> - if (div_low >= 2 &&
> - ((prate / div_low - mode_rate) <
> -  10 * (mode_rate - prate / div)))
> - /*
> -  * At least 10 times better when using a higher
> -  * frequency than requested, instead of a lower.
> -  * So, go with that.
> -  */
> - div = div_low;
>   }
>  
>   cfg |= ATMEL_HLCDC_CLKDIV(div);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KASAN: slab-out-of-bounds Read in bit_putcs

[syzbot]

syzbot has bisected this bug to:

commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
Author: Russell Currey 
Date:   Mon Feb 8 04:08:20 2016 +

powerpc/powernv: Remove support for p5ioc2

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=16af042ae0
start commit:   9455d25f Merge tag 'ntb-5.5' of git://github.com/jonmason/..
git tree:   upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=15af042ae0
console output: https://syzkaller.appspot.com/x/log.txt?x=11af042ae0
kernel config:  https://syzkaller.appspot.com/x/.config?x=7a3b8f5088d4043a
dashboard link: https://syzkaller.appspot.com/bug?extid=998dec6452146bd7a90c
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=12fa5c2ee0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12e327f2e0

Reported-by: syzbot+998dec6452146bd7a...@syzkaller.appspotmail.com
Fixes: 2de50e9674fc ("powerpc/powernv: Remove support for p5ioc2")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] Revert "drm: atmel-hlcdc: enable sys_clk during initalization."

[Claudiu Beznea]

This reverts commit d2c755e66617620b729041c625a6396c81d1231c.
("drm: atmel-hlcdc: enable sys_clk during initalization."). With
commit "drm: atmel-hlcdc: enable clock before configuring timing engine"
there is no need for this patch. Code is also simpler.

Cc: Sandeep Sheriker Mallikarjun 
Signed-off-by: Claudiu Beznea 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 8dc917a1270b..112aa5066cee 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -721,18 +721,10 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
 
-   if (dc->desc->fixed_clksrc) {
-   ret = clk_prepare_enable(dc->hlcdc->sys_clk);
-   if (ret) {
-   dev_err(dev->dev, "failed to enable sys_clk\n");
-   goto err_destroy_wq;
-   }
-   }
-
ret = clk_prepare_enable(dc->hlcdc->periph_clk);
if (ret) {
dev_err(dev->dev, "failed to enable periph_clk\n");
-   goto err_sys_clk_disable;
+   goto err_destroy_wq;
}
 
pm_runtime_enable(dev->dev);
@@ -768,9 +760,6 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
 err_periph_clk_disable:
pm_runtime_disable(dev->dev);
clk_disable_unprepare(dc->hlcdc->periph_clk);
-err_sys_clk_disable:
-   if (dc->desc->fixed_clksrc)
-   clk_disable_unprepare(dc->hlcdc->sys_clk);
 
 err_destroy_wq:
destroy_workqueue(dc->wq);
@@ -795,8 +784,6 @@ static void atmel_hlcdc_dc_unload(struct drm_device *dev)
 
pm_runtime_disable(dev->dev);
clk_disable_unprepare(dc->hlcdc->periph_clk);
-   if (dc->desc->fixed_clksrc)
-   clk_disable_unprepare(dc->hlcdc->sys_clk);
destroy_workqueue(dc->wq);
 }
 
@@ -910,8 +897,6 @@ static int atmel_hlcdc_dc_drm_suspend(struct device *dev)
regmap_read(regmap, ATMEL_HLCDC_IMR, &dc->suspend.imr);
regmap_write(regmap, ATMEL_HLCDC_IDR, dc->suspend.imr);
clk_disable_unprepare(dc->hlcdc->periph_clk);
-   if (dc->desc->fixed_clksrc)
-   clk_disable_unprepare(dc->hlcdc->sys_clk);
 
return 0;
 }
@@ -921,8 +906,6 @@ static int atmel_hlcdc_dc_drm_resume(struct device *dev)
struct drm_device *drm_dev = dev_get_drvdata(dev);
struct atmel_hlcdc_dc *dc = drm_dev->dev_private;
 
-   if (dc->desc->fixed_clksrc)
-   clk_prepare_enable(dc->hlcdc->sys_clk);
clk_prepare_enable(dc->hlcdc->periph_clk);
regmap_write(dc->hlcdc->regmap, ATMEL_HLCDC_IER, dc->suspend.imr);
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic

[allen.chen]

Hi Jani

Thanks for your help and I will follow your suggestion to modify the patch.

-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com] 
Sent: Tuesday, December 10, 2019 7:10 PM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); Maxime Ripard; Allen Chen (陳柏宇); open list; open 
list:DRM DRIVERS; David Airlie; Pi-Hsun Shih; Sean Paul
Subject: Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking 
timings logic

On Tue, 26 Nov 2019, allen  wrote:
> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
> (Defines EDID Structure Version 1, Revision 4) page: 39
> How to determine whether the monitor support RB timing or not?
> EDID 1.4
> First:  read detailed timing descriptor and make sure byte 0 = 0x00,
>   byte 1 = 0x00, byte 2 = 0x00 and byte 3 = 0xFD
> Second: read EDID bit 0 in feature support byte at address 18h = 1
>   and detailed timing descriptor byte 10 = 0x04
> Third:  if EDID bit 0 in feature support byte = 1 &&
>   detailed timing descriptor byte 10 = 0x04
>   then we can check byte 15, if bit 4 in byte 15 = 1 is support RB
> if EDID bit 0 in feature support byte != 1 ||
>   detailed timing descriptor byte 10 != 0x04,
>   then byte 15 can not be used
>
> The linux code is_rb function not follow the VESA's rule
>
> Signed-off-by: Allen Chen 
> Reported-by: kbuild test robot 
> ---
>  drivers/gpu/drm/drm_edid.c | 36 ++--
>  1 file changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index f5926bf..e11e585 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -93,6 +93,12 @@ struct detailed_mode_closure {
>   int modes;
>  };
>  
> +struct edid_support_rb_closure {
> + struct edid *edid;
> + bool valid_support_rb;
> + bool support_rb;
> +};
> +
>  #define LEVEL_DMT0
>  #define LEVEL_GTF1
>  #define LEVEL_GTF2   2
> @@ -2017,23 +2023,41 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
> drm_device *dev,
>   }
>  }
>  
> +static bool
> +is_display_descriptor(const u8 *r, u8 tag)
> +{
> + return (!r[0] && !r[1] && !r[2] && r[3] == tag) ? true : false;
> +}
> +
>  static void
>  is_rb(struct detailed_timing *t, void *data)
>  {
>   u8 *r = (u8 *)t;
> - if (r[3] == EDID_DETAIL_MONITOR_RANGE)
> - if (r[15] & 0x10)
> - *(bool *)data = true;
> + struct edid_support_rb_closure *closure = data;
> + struct edid *edid = closure->edid;
> +
> + if (is_display_descriptor(r, EDID_DETAIL_MONITOR_RANGE)) {
> + if (edid->features & BIT(0) && r[10] == BIT(2)) {

I'll try to explain my original comment again.

Consider edid->features & BIT(0). It remains unchanged across the
iteration. The code will only change anything if edid->features &
BIT(0).

> + closure->valid_support_rb = true;
> + closure->support_rb = (r[15] & 0x10) ? true : false;

You could combine these to e.g. a single int.

if (r[10] == BIT(2)) {
int *ret = data;
*ret = !!(r[15] & 0x10);
}

> + }
> + }
>  }
>  
>  /* EDID 1.4 defines this explicitly.  For EDID 1.3, we guess, badly. */
>  static bool
>  drm_monitor_supports_rb(struct edid *edid)
>  {
> + struct edid_support_rb_closure closure = {
> + .edid = edid,
> + .valid_support_rb = false,
> + .support_rb = false,
> + };
> +
>   if (edid->revision >= 4) {
> - bool ret = false;
> - drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
> - return ret;
> + drm_for_each_detailed_block((u8 *)edid, is_rb, &closure);
> + if (closure.valid_support_rb)
> + return closure.support_rb;

Here, you'd do:

if (edid->features & BIT(0)) {
int ret = -1;
drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
if (ret != -1)
return ret;
}


>   }
>  
>   return ((edid->input & DRM_EDID_INPUT_DIGITAL) != 0);

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/4] Revert "drm/tegra: Move drm_dp_link helpers to Tegra DRM"

[Dmitry Osipenko]

10.12.2019 08:53, allen пишет:
> This reverts commit 9a42c7c647a9ad0f7ebb147a52eda3dcb7c84292.

Commit messsage must explain reason of the changes made in the patch.

> Signed-off-by: Allen Chen 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 128 ++
>  drivers/gpu/drm/tegra/Makefile  |   1 -
>  drivers/gpu/drm/tegra/dp.c  | 876 
> 
>  drivers/gpu/drm/tegra/dp.h  | 177 
>  drivers/gpu/drm/tegra/dpaux.c   |   1 -
>  drivers/gpu/drm/tegra/sor.c |   1 -
>  include/drm/drm_dp_helper.h |  16 +
>  7 files changed, 144 insertions(+), 1056 deletions(-)
>  delete mode 100644 drivers/gpu/drm/tegra/dp.c
>  delete mode 100644 drivers/gpu/drm/tegra/dp.h
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 2c7870a..f567141 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -352,6 +352,134 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
>  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>  
>  /**
> + * drm_dp_link_probe() - probe a DisplayPort link for capabilities
> + * @aux: DisplayPort AUX channel
> + * @link: pointer to structure in which to return link capabilities
> + *
> + * The structure filled in by this function can usually be passed directly
> + * into drm_dp_link_power_up() and drm_dp_link_configure() to power up and
> + * configure the link based on the link's capabilities.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link)
> +{
> + u8 values[3];
> + int err;
> +
> + memset(link, 0, sizeof(*link));
> +
> + err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
> + if (err < 0)
> + return err;
> +
> + link->revision = values[0];
> + link->rate = drm_dp_bw_code_to_link_rate(values[1]);
> + link->num_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
> +
> + if (values[2] & DP_ENHANCED_FRAME_CAP)
> + link->capabilities |= DP_LINK_CAP_ENHANCED_FRAMING;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_link_probe);
> +
> +/**
> + * drm_dp_link_power_up() - power up a DisplayPort link
> + * @aux: DisplayPort AUX channel
> + * @link: pointer to a structure containing the link configuration
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link)
> +{
> + u8 value;
> + int err;
> +
> + /* DP_SET_POWER register is only available on DPCD v1.1 and later */
> + if (link->revision < 0x11)
> + return 0;
> +
> + err = drm_dp_dpcd_readb(aux, DP_SET_POWER, &value);
> + if (err < 0)
> + return err;
> +
> + value &= ~DP_SET_POWER_MASK;
> + value |= DP_SET_POWER_D0;
> +
> + err = drm_dp_dpcd_writeb(aux, DP_SET_POWER, value);
> + if (err < 0)
> + return err;
> +
> + /*
> +  * According to the DP 1.1 specification, a "Sink Device must exit the
> +  * power saving state within 1 ms" (Section 2.5.3.1, Table 5-52, "Sink
> +  * Control Field" (register 0x600).
> +  */
> + usleep_range(1000, 2000);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_link_power_up);
> +
> +/**
> + * drm_dp_link_power_down() - power down a DisplayPort link
> + * @aux: DisplayPort AUX channel
> + * @link: pointer to a structure containing the link configuration
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link)
> +{
> + u8 value;
> + int err;
> +
> + /* DP_SET_POWER register is only available on DPCD v1.1 and later */
> + if (link->revision < 0x11)
> + return 0;
> +
> + err = drm_dp_dpcd_readb(aux, DP_SET_POWER, &value);
> + if (err < 0)
> + return err;
> +
> + value &= ~DP_SET_POWER_MASK;
> + value |= DP_SET_POWER_D3;
> +
> + err = drm_dp_dpcd_writeb(aux, DP_SET_POWER, value);
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_link_power_down);
> +
> +/**
> + * drm_dp_link_configure() - configure a DisplayPort link
> + * @aux: DisplayPort AUX channel
> + * @link: pointer to a structure containing the link configuration
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link)
> +{
> + u8 values[2];
> + int err;
> +
> + values[0] = drm_dp_link_rate_to_bw_code(link->rate);
> + values[1] = link->num_lanes;
> +
> + if (link->capabilities & DP_LINK_CAP_ENHANCED_FRAMING)
> + values[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> +
> + err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, values, sizeof(values));
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_link_configure);

BUG: unable to handle kernel paging request in sys_imageblit

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:6794862a Merge tag 'for-5.5-rc1-kconfig-tag' of git://git...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1574aaeae0
kernel config:  https://syzkaller.appspot.com/x/.config?x=79f79de2a27d3e3d
dashboard link: https://syzkaller.appspot.com/bug?extid=33f89a9a6b6acd893b11
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+33f89a9a6b6acd893...@syzkaller.appspotmail.com

BUG: unable to handle page fault for address: f5200124c3fc
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 7ffcd067 P4D 7ffcd067 PUD 2cd1c067 PMD 299b2067 PTE 0
Oops:  [#1] PREEMPT SMP KASAN
CPU: 2 PID: 9109 Comm: syz-executor.2 Not tainted 5.5.0-rc1-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS  
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014

RIP: 0010:fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline]
RIP: 0010:sys_imageblit+0x61c/0x1240  
drivers/video/fbdev/core/sysimgblt.c:275
Code: 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 57 0b 00 00 48 b9 00 00 00 00 00  
fc ff df 4c 89 fa 8b 45 b0 23 07 4d 8d 77 04 48 c1 ea 03 <0f> b6 0c 0a 4c  
89 fa 83 e2 07 33 45 c4 83 c2 03 38 ca 7c 08 84 c9

RSP: 0018:c900042c7168 EFLAGS: 00010a06
RAX:  RBX: 888076970800 RCX: dc00
RDX: 19200124c3fc RSI: 83b4fada RDI: 887498e0
RBP: c900042c7230 R08: 88805d278e40 R09: 007f
R10: fbfff14f3347 R11: 8a799a3b R12: 0007
R13: 0007 R14: c90009261fe4 R15: c90009261fe0
FS:  7f0af02fc700() GS:88802d20() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: f5200124c3fc CR3: 278c2000 CR4: 00340ee0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 drm_fb_helper_sys_imageblit+0x21/0x180 drivers/gpu/drm/drm_fb_helper.c:768
 bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:139 [inline]
 bit_putcs+0x9a3/0xf10 drivers/video/fbdev/core/bitblit.c:188
 fbcon_putcs+0x33c/0x3e0 drivers/video/fbdev/core/fbcon.c:1353
 do_update_region+0x42b/0x6f0 drivers/tty/vt/vt.c:677
 invert_screen+0x2da/0x650 drivers/tty/vt/vt.c:794
 highlight drivers/tty/vt/selection.c:53 [inline]
 clear_selection drivers/tty/vt/selection.c:81 [inline]
 clear_selection+0x59/0x70 drivers/tty/vt/selection.c:77
 vc_do_resize+0x1163/0x1460 drivers/tty/vt/vt.c:1200
 vc_resize+0x4d/0x60 drivers/tty/vt/vt.c:1304
 fbcon_do_set_font+0x4a6/0x960 drivers/video/fbdev/core/fbcon.c:2599
 fbcon_set_font+0x72e/0x860 drivers/video/fbdev/core/fbcon.c:2696
 con_font_set drivers/tty/vt/vt.c:4538 [inline]
 con_font_op+0xe30/0x1270 drivers/tty/vt/vt.c:4603
 vt_ioctl+0xd2e/0x26d0 drivers/tty/vt/vt_ioctl.c:913
 tty_ioctl+0xa37/0x14f0 drivers/tty/tty_io.c:2660
 vfs_ioctl fs/ioctl.c:47 [inline]
 file_ioctl fs/ioctl.c:545 [inline]
 do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732
 ksys_ioctl+0xab/0xd0 fs/ioctl.c:749
 __do_sys_ioctl fs/ioctl.c:756 [inline]
 __se_sys_ioctl fs/ioctl.c:754 [inline]
 __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754
 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45a7c9
Code: bd b1 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 8b b1 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7f0af02fbc88 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 0072bf00 RCX: 0045a7c9
RDX: 2000 RSI: 4b61 RDI: 0003
RBP: 0003 R08:  R09: 
R10:  R11: 0246 R12: 7f0af02fc6d4
R13: 004ab60f R14: 006ede60 R15: 
Modules linked in:
CR2: f5200124c3fc
---[ end trace 7698227ca2d5f789 ]---
RIP: 0010:fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline]
RIP: 0010:sys_imageblit+0x61c/0x1240  
drivers/video/fbdev/core/sysimgblt.c:275
Code: 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 57 0b 00 00 48 b9 00 00 00 00 00  
fc ff df 4c 89 fa 8b 45 b0 23 07 4d 8d 77 04 48 c1 ea 03 <0f> b6 0c 0a 4c  
89 fa 83 e2 07 33 45 c4 83 c2 03 38 ca 7c 08 84 c9

RSP: 0018:c900042c7168 EFLAGS: 00010a06
RAX:  RBX: 888076970800 RCX: dc00
RDX: 19200124c3fc RSI: 83b4fada RDI: 887498e0
RBP: c900042c7230 R08: 88805d278e40 R09: 007f
R10: fbfff14f3347 R11: 8a799a3b R12: 0007
R13: 0007 R14: c90009261fe4 R15: c90009261fe0
FS:  7f0af02fc700() GS:88802d20() knlGS:
CS: 

Re: [v3,4/4] drm/edid: Make sure the CEA mode arrays have the correct amount of modes

[Tom Anderson]

Reviewed-by: Thomas Anderson 

On Wed, Sep 25, 2019 at 04:55:02PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We depend on a specific relationship between the VIC number and the
> index in the CEA mode arrays. Assert that the arrays have the excpected
> size to make sure we've not accidentally left holes in them.
> 
> v2: Pimp the BUILD_BUG_ON()s
> 
> Cc: Hans Verkuil 
> Cc: Shashank Sharma 
> Signed-off-by: Ville Syrjälä 
> Reviewed-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_edid.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0007004d3221..06cac8e2afc2 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3209,6 +3209,9 @@ static u8 *drm_find_cea_extension(const struct edid 
> *edid)
>  
>  static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
>  {
> + BUILD_BUG_ON(1 + ARRAY_SIZE(edid_cea_modes_1) - 1 != 127);
> + BUILD_BUG_ON(193 + ARRAY_SIZE(edid_cea_modes_193) - 1 != 219);
> +
>   if (vic >= 1 && vic < 1 + ARRAY_SIZE(edid_cea_modes_1))
>   return &edid_cea_modes_1[vic - 1];
>   if (vic >= 193 && vic < 193 + ARRAY_SIZE(edid_cea_modes_193))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/modes: tag unused variables to avoid warnings

[Benjamin Gaignard]

Some variables are set but never used. To avoid warning when compiling
with W=1 and keep the algorithm like it is tag theses variables
with _maybe_unused macro.

Signed-off-by: Benjamin Gaignard 
---
changes in this version:
- do not modify the code to remove the unused variables
  just prefix them with __maybe_unused macro.
  
 drivers/gpu/drm/drm_modes.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 88232698d7a0..70aed4e2990d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -233,7 +233,7 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device 
*dev, int hdisplay,
/* 3) Nominal HSync width (% of line period) - default 8 */
 #define CVT_HSYNC_PERCENTAGE   8
unsigned int hblank_percentage;
-   int vsyncandback_porch, vback_porch, hblank;
+   int vsyncandback_porch, __maybe_unused vback_porch, hblank;
 
/* estimated the horizontal period */
tmp1 = HV_FACTOR * 100  -
@@ -386,9 +386,10 @@ drm_gtf_mode_complex(struct drm_device *dev, int hdisplay, 
int vdisplay,
int top_margin, bottom_margin;
int interlace;
unsigned int hfreq_est;
-   int vsync_plus_bp, vback_porch;
-   unsigned int vtotal_lines, vfieldrate_est, hperiod;
-   unsigned int vfield_rate, vframe_rate;
+   int vsync_plus_bp, __maybe_unused vback_porch;
+   unsigned int vtotal_lines, __maybe_unused vfieldrate_est;
+   unsigned int __maybe_unused hperiod;
+   unsigned int vfield_rate, __maybe_unused vframe_rate;
int left_margin, right_margin;
unsigned int total_active_pixels, ideal_duty_cycle;
unsigned int hblank, total_pixels, pixel_freq;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] drm/sprd: add Unisoc's drm kms master

[tang pengchuan]

Hi

Thomas Zimmermann  于2019年12月10日周二 下午8:47写道：

> Hi
>
> Am 10.12.19 um 13:38 schrieb tang pengchuan:
> > Hi
> >
> > Thomas Zimmermann mailto:tzimmerm...@suse.de>> 于
> > 2019年12月10日周二 下午6:33写道：
> >
> > Hi
> >
> > Am 10.12.19 um 09:36 schrieb Kevin Tang:
> > > From: Kevin Tang  > >
> > >
> > > Adds drm support for the Unisoc's display subsystem.
> > >
> > > This is drm device and gem driver. This driver provides support
> > for the
> > > Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> > >
> > > Cc: Orson Zhai mailto:orsonz...@gmail.com>>
> > > Cc: Baolin Wang  > >
> > > Cc: Chunyan Zhang  zhang.l...@gmail.com>>
> > > Signed-off-by: Kevin Tang  > >
> > > ---
> > >  drivers/gpu/drm/Kconfig |   2 +
> > >  drivers/gpu/drm/Makefile|   1 +
> > >  drivers/gpu/drm/sprd/Kconfig|  14 ++
> > >  drivers/gpu/drm/sprd/Makefile   |   8 ++
> > >  drivers/gpu/drm/sprd/sprd_drm.c | 287
> > 
> > >  drivers/gpu/drm/sprd/sprd_drm.h |  19 +++
> > >  drivers/gpu/drm/sprd/sprd_gem.c | 178 +
> > >  drivers/gpu/drm/sprd/sprd_gem.h |  30 +
> >
> > The GEM implementation looks like DRM's CMA helpers. Can you not use
> CMA
> > helpers instead?
> >
> > Ok, i will remove cma keywords from the GEM implementatio.
>
> I'm not quite sure what you mean. Why can you not use the existing CMA
> helpers instead of writing your own?
>
CMA helper only support contiguous memory, but our display controller also
need to support scatter buffers via
ion iommu.

>
> Best regards
> Thomas
>
> >
> >
> > >  8 files changed, 539 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/sprd/Kconfig
> > >  create mode 100644 drivers/gpu/drm/sprd/Makefile
> > >  create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
> > >  create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
> > >  create mode 100644 drivers/gpu/drm/sprd/sprd_gem.c
> > >  create mode 100644 drivers/gpu/drm/sprd/sprd_gem.h
> > >
> > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > index bfdadc3..cead12c 100644
> > > --- a/drivers/gpu/drm/Kconfig
> > > +++ b/drivers/gpu/drm/Kconfig
> > > @@ -387,6 +387,8 @@ source "drivers/gpu/drm/aspeed/Kconfig"
> > >
> > >  source "drivers/gpu/drm/mcde/Kconfig"
> > >
> > > +source "drivers/gpu/drm/sprd/Kconfig"
> > > +
> > >  # Keep legacy drivers last
> > >
> > >  menuconfig DRM_LEGACY
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 9f1c7c4..85ca211 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -122,3 +122,4 @@ obj-$(CONFIG_DRM_LIMA)  += lima/
> > >  obj-$(CONFIG_DRM_PANFROST) += panfrost/
> > >  obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
> > >  obj-$(CONFIG_DRM_MCDE) += mcde/
> > > +obj-$(CONFIG_DRM_SPRD) += sprd/
> > > diff --git a/drivers/gpu/drm/sprd/Kconfig
> > b/drivers/gpu/drm/sprd/Kconfig
> > > new file mode 100644
> > > index 000..79f286b
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/sprd/Kconfig
> > > @@ -0,0 +1,14 @@
> > > +config DRM_SPRD
> > > + tristate "DRM Support for Unisoc SoCs Platform"
> > > + depends on ARCH_SPRD
> > > + depends on DRM && OF
> > > + select DRM_KMS_HELPER
> > > + select DRM_GEM_CMA_HELPER
> > > + select DRM_KMS_CMA_HELPER
> > > + select DRM_MIPI_DSI
> > > + select DRM_PANEL
> > > + select VIDEOMODE_HELPERS
> > > + select BACKLIGHT_CLASS_DEVICE
> > > + help
> > > +   Choose this option if you have a Unisoc chipsets.
> > > +   If M is selected the module will be called sprd-drm.
> > > \ No newline at end of file
> > > diff --git a/drivers/gpu/drm/sprd/Makefile
> > b/drivers/gpu/drm/sprd/Makefile
> > > new file mode 100644
> > > index 000..df0b316
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/sprd/Makefile
> > > @@ -0,0 +1,8 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +
> > > +ccflags-y += -Iinclude/drm
> > > +
> > > +subdir-ccflags-y += -I$(src)
> > > +
> > > +obj-y := sprd_drm.o \
> > > + sprd_gem.o
> > > \ No newline at end of file
> > > diff --git a/drivers/gpu/drm/sprd/sprd_drm.c
> > b/drivers/gpu/drm/sprd/sprd_drm.c
> > > new file mode 100644
> > > index 000..ec16fee
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/sprd/sprd_drm.c
> > > @@ -0,0 +1,287 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright (C) 2019 Unisoc Inc.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> >

[PATCH 2/5] drm: atmel-hlcdc: enable clock before configuring timing engine

[Claudiu Beznea]

Changing pixel clock source without having this clock source enabled
will block the timing engine and the next operations after (in this case
setting ATMEL_HLCDC_CFG(5) settings in atmel_hlcdc_crtc_mode_set_nofb()
will fail). It is recomended (although in datasheet this is not present)
to actually enabled pixel clock source before doing any changes on timing
enginge (only SAM9X60 datasheet specifies that the peripheral clock and
pixel clock must be enabled before using LCD controller).

Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support")
Signed-off-by: Claudiu Beznea 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 5040ed8d0871..721fa88bf71d 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -73,7 +73,11 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
unsigned long prate;
unsigned int mask = ATMEL_HLCDC_CLKDIV_MASK | ATMEL_HLCDC_CLKPOL;
unsigned int cfg = 0;
-   int div;
+   int div, ret;
+
+   ret = clk_prepare_enable(crtc->dc->hlcdc->sys_clk);
+   if (ret)
+   return;
 
vm.vfront_porch = adj->crtc_vsync_start - adj->crtc_vdisplay;
vm.vback_porch = adj->crtc_vtotal - adj->crtc_vsync_end;
@@ -147,6 +151,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
   ATMEL_HLCDC_VSPSU | ATMEL_HLCDC_VSPHO |
   ATMEL_HLCDC_GUARDTIME_MASK | ATMEL_HLCDC_MODE_MASK,
   cfg);
+
+   clk_disable_unprepare(crtc->dc->hlcdc->sys_clk);
 }
 
 static enum drm_mode_status
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] Revert "drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested"

[Claudiu.Beznea]

On 10.12.2019 16:11, Peter Rosin wrote:
> On 2019-12-10 14:24, Claudiu Beznea wrote:
>> This reverts commit f6f7ad3234613f6f7f27c25036aaf078de07e9b0.
>> ("drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested")
>> because allowing selecting a higher pixel clock may overclock
>> LCD devices, not all of them being capable of this.
> 
> Without this patch, there are panels that are *severly* underclocked (on the
> magnitude of 40MHz instead of 65MHz or something like that, I don't remember
> the exact figures). 

With patch that switches by default to 2xsystem clock for pixel clock, if
using 133MHz system clock (as you specified in the patch I proposed for
revert here) that would go, without this patch at 53MHz if 65MHz is
requested. Correct me if I'm wrong.

> And they are of course not capable of that. All panels
> have *some* slack as to what frequencies are supported, and the patch was
> written under the assumption that the preferred frequency of the panel was
> requested, which should leave at least a *little* headroom.

I see, but from my point of view, the upper layers should decide what
frequency settings should be done on the LCD controller and not let this at
 the driver's latitude.

> 
> So, I'm curious as to what panel regressed. Or rather, what pixel-clock it 
> needs
> and what it gets with/without the patch?

I have 2 use cases:
1/ system clock = 200MHz and requested pixel clock (mode_rate) ~71MHz. With
the reverted patch the resulted computed pixel clock would be 80MHz.
Previously it was at 66MHz
2/ system clock = 133MHz and the requested pixel clock (mode_rate) 60MHz.
With the reverted patch the computed pixel clock would be 66MHz.

I took into account the patch that uses by default 2xsystem clock as pixel
clock (and this was on a system that supported it).

> 
> Or is the revert based on some theory of a perceived risk of toasting a panel?

It's based on the use cases I mentioned above.

> 
> In short, this revert regresses my use case and I would like at least a hook 
> to
> re-enable the removed logic.

I see, but, FMPOV, you have to take into account that some of the devices
don't support it.

Thank you,
Claudiu Beznea

> 
> Cheers,
> Peter
> 
>> Cc: Peter Rosin 
>> Signed-off-by: Claudiu Beznea 
>> ---
>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 12 
>>  1 file changed, 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
>> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> index 721fa88bf71d..1a70dff1a417 100644
>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> @@ -117,18 +117,6 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct 
>> drm_crtc *c)
>>   div = DIV_ROUND_UP(prate, mode_rate);
>>   if (ATMEL_HLCDC_CLKDIV(div) & ~ATMEL_HLCDC_CLKDIV_MASK)
>>   div = ATMEL_HLCDC_CLKDIV_MASK;
>> - } else {
>> - int div_low = prate / mode_rate;
>> -
>> - if (div_low >= 2 &&
>> - ((prate / div_low - mode_rate) <
>> -  10 * (mode_rate - prate / div)))
>> - /*
>> -  * At least 10 times better when using a higher
>> -  * frequency than requested, instead of a lower.
>> -  * So, go with that.
>> -  */
>> - div = div_low;
>>   }
>>
>>   cfg |= ATMEL_HLCDC_CLKDIV(div);
>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/6] dt-bindings: display/ingenic: Add compatible string for JZ4770

[Paul Cercueil]

Add a compatible string for the LCD controller found in the JZ4770 SoC.

v2: No change

Signed-off-by: Paul Cercueil 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/display/ingenic,lcd.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.txt 
b/Documentation/devicetree/bindings/display/ingenic,lcd.txt
index 7b536c8c6dde..01e3261defb6 100644
--- a/Documentation/devicetree/bindings/display/ingenic,lcd.txt
+++ b/Documentation/devicetree/bindings/display/ingenic,lcd.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible: one of:
   * ingenic,jz4740-lcd
   * ingenic,jz4725b-lcd
+  * ingenic,jz4770-lcd
 - reg: LCD registers location and length
 - clocks: LCD pixclock and device clock specifiers.
   The device clock is only required on the JZ4740.
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v3,3/4] drm/edid: Throw away the dummy VIC 0 cea mode

[Tom Anderson]

On Wed, Sep 25, 2019 at 04:55:01PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Now that the cea mode handling is not 100% tied to the single
> array the dummy VIC 0 mode is pretty much pointles. Throw it
> out.
> 
> Cc: Hans Verkuil 
> Cc: Shashank Sharma 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_edid.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9f6996323efa..0007004d3221 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -709,11 +709,9 @@ static const struct minimode extra_modes[] = {
>  /*
>   * From CEA/CTA-861 spec.
>   *
> - * Index with VIC.
> + * Index with VIC-1.

Since we shouldn't be indexing into this array directly any more, this comment
should instead be changed to say which functions should be used.

>   */
> -static const struct drm_display_mode edid_cea_modes_0[] = {
> - /* 0 - dummy, VICs start at 1 */
> - { },
> +static const struct drm_display_mode edid_cea_modes_1[] = {
>   /* 1 - 640x480@60Hz 4:3 */
>   { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
>  752, 800, 0, 480, 490, 492, 525, 0,
> @@ -3211,10 +3209,8 @@ static u8 *drm_find_cea_extension(const struct edid 
> *edid)
>  
>  static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
>  {
> - if (!vic)
> - return NULL;
> - if (vic < ARRAY_SIZE(edid_cea_modes_0))
> - return &edid_cea_modes_0[vic];
> + if (vic >= 1 && vic < 1 + ARRAY_SIZE(edid_cea_modes_1))
> + return &edid_cea_modes_1[vic - 1];
>   if (vic >= 193 && vic < 193 + ARRAY_SIZE(edid_cea_modes_193))
>   return &edid_cea_modes_193[vic - 193];
>   return NULL;
> @@ -3227,7 +3223,7 @@ static u8 cea_num_vics(void)
>  
>  static u8 cea_next_vic(u8 vic)
>  {
> - if (++vic == ARRAY_SIZE(edid_cea_modes_0))
> + if (++vic == 1 + ARRAY_SIZE(edid_cea_modes_1))
>   vic = 193;
>   return vic;
>  }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v3,1/4] drm/edid: Abstract away cea_edid_modes[]

[Tom Anderson]

+CCs that were accidnetally lost

On Tue, Dec 10, 2019 at 02:34:23PM -0800, Tom Anderson wrote:
> On Wed, Sep 25, 2019 at 04:54:59PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > We're going to need two cea mode tables (on for VICs < 128,
> 
> s/on/one
> 
> > another one for VICs >= 193). To that end replace the direct
> > edid_cea_modes[] lookups with a function call. And we'll rename
> > the array to edid_cea_modes_0[] to indicathe how it's to be
> 
> s/indicathe/indicate
> 
> > indexed.
> > 
> > Cc: Hans Verkuil 
> > Cc: Shashank Sharma 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 80 +++---
> >  1 file changed, 58 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 3c9703b08491..b700fc075257 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -707,12 +707,11 @@ static const struct minimode extra_modes[] = {
> >  };
> >  
> >  /*
> > - * Probably taken from CEA-861 spec.
> > - * This table is converted from xorg's hw/xfree86/modes/xf86EdidModes.c.
> > + * From CEA/CTA-861 spec.
> >   *
> > - * Index using the VIC.
> > + * Index with VIC.
> >   */
> > -static const struct drm_display_mode edid_cea_modes[] = {
> > +static const struct drm_display_mode edid_cea_modes_0[] = {
> 
> Nit: The "_0" suffix is a bit odd. Maybe edid_cea_modes_{lo,hi}, but I'm not
> sure if that's actually better. Up to you.
> 
> > /* 0 - dummy, VICs start at 1 */
> > { },
> > /* 1 - 640x480@60Hz 4:3 */
> > @@ -3067,6 +3066,25 @@ static u8 *drm_find_cea_extension(const struct edid 
> > *edid)
> > return cea;
> >  }
> >  
> > +static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
> > +{
> > +   if (!vic)
> > +   return NULL;
> > +   if (vic < ARRAY_SIZE(edid_cea_modes_0))
> > +   return &edid_cea_modes_0[vic];
> > +   return NULL;
> > +}
> > +
> > +static u8 cea_num_vics(void)
> > +{
> > +   return ARRAY_SIZE(edid_cea_modes_0);
> > +}
> > +
> > +static u8 cea_next_vic(u8 vic)
> > +{
> > +   return vic + 1;
> > +}
> > +
> >  /*
> >   * Calculate the alternate clock for the CEA mode
> >   * (60Hz vs. 59.94Hz etc.)
> > @@ -3104,14 +3122,14 @@ cea_mode_alternate_timings(u8 vic, struct 
> > drm_display_mode *mode)
> >  * get the other variants by simply increasing the
> >  * vertical front porch length.
> >  */
> > -   BUILD_BUG_ON(edid_cea_modes[8].vtotal != 262 ||
> > -edid_cea_modes[9].vtotal != 262 ||
> > -edid_cea_modes[12].vtotal != 262 ||
> > -edid_cea_modes[13].vtotal != 262 ||
> > -edid_cea_modes[23].vtotal != 312 ||
> > -edid_cea_modes[24].vtotal != 312 ||
> > -edid_cea_modes[27].vtotal != 312 ||
> > -edid_cea_modes[28].vtotal != 312);
> > +   BUILD_BUG_ON(cea_mode_for_vic(8)->vtotal != 262 ||
> > +cea_mode_for_vic(9)->vtotal != 262 ||
> > +cea_mode_for_vic(12)->vtotal != 262 ||
> > +cea_mode_for_vic(13)->vtotal != 262 ||
> > +cea_mode_for_vic(23)->vtotal != 312 ||
> > +cea_mode_for_vic(24)->vtotal != 312 ||
> > +cea_mode_for_vic(27)->vtotal != 312 ||
> > +cea_mode_for_vic(28)->vtotal != 312);
> >  
> > if (((vic == 8 || vic == 9 ||
> >   vic == 12 || vic == 13) && mode->vtotal < 263) ||
> > @@ -3139,10 +3157,16 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
> > struct drm_display_mode *to_m
> > if (to_match->picture_aspect_ratio)
> > match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> >  
> > -   for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
> > -   struct drm_display_mode cea_mode = edid_cea_modes[vic];
> > +   for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {
> > +   const struct drm_display_mode *mode = cea_mode_for_vic(vic);
> > +   struct drm_display_mode cea_mode;
> > unsigned int clock1, clock2;
> >  
> > +   if (!mode)
> > +   continue;
> 
> Isn't this check is a no-op now that we have cea_next_vic()?
> 
> > +
> > +   cea_mode = *mode;
> > +
> 
> Get rid of |cea_mode| and use *mode. There's only 1 place where cea_mode.*
> was used, and 3 places where &cea_mode was used, so using a pointer seems
> better.
> 
> > /* Check both 60Hz and 59.94Hz */
> > clock1 = cea_mode.clock;
> > clock2 = cea_mode_alternate_clock(&cea_mode);
> > @@ -3178,10 +3202,16 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> > *to_match)
> > if (to_match->picture_aspect_ratio)
> > match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> >  
> > -   for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
> > -   struct drm_display_mode cea_mode = edid_cea_modes[vic];
> > +   for (vic = 1; vic < cea_num_vics(); vic = cea_ne

[PATCH v2 2/6] gpu/drm: ingenic: Avoid null pointer deference in plane atomic update

[Paul Cercueil]

It is possible that there is no drm_framebuffer associated with a given
plane state.

v2: Handle drm_plane->state which can be NULL too

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 2e2ed653e9c6..f156f245fdec 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -371,14 +371,18 @@ static void ingenic_drm_plane_atomic_update(struct 
drm_plane *plane,
struct ingenic_drm *priv = drm_plane_get_priv(plane);
struct drm_plane_state *state = plane->state;
unsigned int width, height, cpp;
+   dma_addr_t addr;
 
-   width = state->crtc->state->adjusted_mode.hdisplay;
-   height = state->crtc->state->adjusted_mode.vdisplay;
-   cpp = state->fb->format->cpp[plane->index];
+   if (state && state->fb) {
+   addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
+   width = state->crtc->state->adjusted_mode.hdisplay;
+   height = state->crtc->state->adjusted_mode.vdisplay;
+   cpp = state->fb->format->cpp[plane->index];
 
-   priv->dma_hwdesc->addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
-   priv->dma_hwdesc->cmd = width * height * cpp / 4;
-   priv->dma_hwdesc->cmd |= JZ_LCD_CMD_EOF_IRQ;
+   priv->dma_hwdesc->addr = addr;
+   priv->dma_hwdesc->cmd = width * height * cpp / 4;
+   priv->dma_hwdesc->cmd |= JZ_LCD_CMD_EOF_IRQ;
+   }
 }
 
 static void ingenic_drm_encoder_atomic_mode_set(struct drm_encoder *encoder,
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/6] gpu/drm: ingenic: Use the plane's src_[x, y] to configure DMA length

[Paul Cercueil]

Instead of obtaining the width/height of the framebuffer from the CRTC
state, obtain it from the current plane state.

v2: No change

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index f156f245fdec..8713f09df448 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -375,8 +375,8 @@ static void ingenic_drm_plane_atomic_update(struct 
drm_plane *plane,
 
if (state && state->fb) {
addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
-   width = state->crtc->state->adjusted_mode.hdisplay;
-   height = state->crtc->state->adjusted_mode.vdisplay;
+   width = state->src_w >> 16;
+   height = state->src_h >> 16;
cpp = state->fb->format->cpp[plane->index];
 
priv->dma_hwdesc->addr = addr;
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] Revert "drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested"

[Claudiu Beznea]

This reverts commit f6f7ad3234613f6f7f27c25036aaf078de07e9b0.
("drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested")
because allowing selecting a higher pixel clock may overclock
LCD devices, not all of them being capable of this.

Cc: Peter Rosin 
Signed-off-by: Claudiu Beznea 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 721fa88bf71d..1a70dff1a417 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -117,18 +117,6 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
div = DIV_ROUND_UP(prate, mode_rate);
if (ATMEL_HLCDC_CLKDIV(div) & ~ATMEL_HLCDC_CLKDIV_MASK)
div = ATMEL_HLCDC_CLKDIV_MASK;
-   } else {
-   int div_low = prate / mode_rate;
-
-   if (div_low >= 2 &&
-   ((prate / div_low - mode_rate) <
-10 * (mode_rate - prate / div)))
-   /*
-* At least 10 times better when using a higher
-* frequency than requested, instead of a lower.
-* So, go with that.
-*/
-   div = div_low;
}
 
cfg |= ATMEL_HLCDC_CLKDIV(div);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RESEND 1/4] dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter binding

[Hsin-Yi Wang]

From: Nicolas Boichat 

Add support for analogix,anx7688

Signed-off-by: Nicolas Boichat 
Signed-off-by: Hsin-Yi Wang 
---
Change from RFC to v1:
- txt to yaml
---
 .../bindings/display/bridge/anx7688.yaml  | 60 +++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/anx7688.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/anx7688.yaml 
b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml
new file mode 100644
index ..cf79f7cf8fdf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx7688.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/anx7688.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analogix ANX7688 SlimPort (Single-Chip Transmitter for DP over USB-C)
+
+maintainers:
+  - Nicolas Boichat 
+
+description: |
+  The ANX7688 is a single-chip mobile transmitter to support 4K 60 frames per
+  second (4096x2160p60) or FHD 120 frames per second (1920x1080p120) video
+  resolution from a smartphone or tablet with full function USB-C.
+
+  This binding only describes the HDMI to DP display bridge.
+
+properties:
+  compatible:
+const: analogix,anx7688
+
+  reg:
+maxItems: 1
+description: I2C address of the device
+
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: |
+  Video port for HDMI input
+
+  port@1:
+type: object
+description: |
+  Video port for eDP output
+
+required:
+  - port@0
+
+required:
+  - compatible
+  - reg
+  - ports
+
+examples:
+  - |
+anx7688: anx7688@2c {
+  compatible = "analogix,anx7688";
+  reg = <0x2c>;
+
+  port {
+anx7688_in: endpoint {
+  remote-endpoint = <&hdmi0_out>;
+};
+  };
+};
-- 
2.24.0.525.g8f36a354ae-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 5/6] gpu/drm: ingenic: Check for display size in CRTC atomic check

[Paul Cercueil]

Check that the requested display size isn't above the limits supported
by the CRTC.

- JZ4750 and older support up to 800x600;
- JZ4755 supports up to 1024x576;
- JZ4760 and JZ4770 support up to 720p;
- JZ4780 supports up to 2k.

v2: No change

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/ingenic/ingenic-drm.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index cef2f29a9d7a..da681214d0b6 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -152,6 +152,7 @@ struct ingenic_dma_hwdesc {
 
 struct jz_soc_info {
bool needs_dev_clk;
+   unsigned int max_width, max_height;
 };
 
 struct ingenic_drm {
@@ -163,6 +164,7 @@ struct ingenic_drm {
struct device *dev;
struct regmap *map;
struct clk *lcd_clk, *pix_clk;
+   const struct jz_soc_info *soc_info;
 
struct ingenic_dma_hwdesc *dma_hwdesc;
dma_addr_t dma_hwdesc_phys;
@@ -325,6 +327,10 @@ static int ingenic_drm_crtc_atomic_check(struct drm_crtc 
*crtc,
if (!drm_atomic_crtc_needs_modeset(state))
return 0;
 
+   if (state->mode.hdisplay > priv->soc_info->max_height ||
+   state->mode.vdisplay > priv->soc_info->max_width)
+   return -EINVAL;
+
rate = clk_round_rate(priv->pix_clk,
  state->adjusted_mode.clock * 1000);
if (rate < 0)
@@ -620,6 +626,7 @@ static int ingenic_drm_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
+   priv->soc_info = soc_info;
priv->dev = dev;
drm = &priv->drm;
drm->dev_private = priv;
@@ -635,7 +642,7 @@ static int ingenic_drm_probe(struct platform_device *pdev)
drm_mode_config_init(drm);
drm->mode_config.min_width = 0;
drm->mode_config.min_height = 0;
-   drm->mode_config.max_width = 800;
+   drm->mode_config.max_width = soc_info->max_width;
drm->mode_config.max_height = 4095;
drm->mode_config.funcs = &ingenic_drm_mode_config_funcs;
 
@@ -813,10 +820,14 @@ static int ingenic_drm_remove(struct platform_device 
*pdev)
 
 static const struct jz_soc_info jz4740_soc_info = {
.needs_dev_clk = true,
+   .max_width = 800,
+   .max_height = 600,
 };
 
 static const struct jz_soc_info jz4725b_soc_info = {
.needs_dev_clk = false,
+   .max_width = 800,
+   .max_height = 600,
 };
 
 static const struct of_device_id ingenic_drm_of_match[] = {
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] drm/sprd: add Unisoc's drm kms master

[tang pengchuan]

Hi Thomas
Thomas Zimmermann  于2019年12月10日周二 下午8:47写道：

> Hi
>
> Am 10.12.19 um 13:38 schrieb tang pengchuan:
> > Hi
> >
> > Thomas Zimmermann mailto:tzimmerm...@suse.de>> 于
> > 2019年12月10日周二 下午6:33写道：
> >
> > Hi
> >
> > Am 10.12.19 um 09:36 schrieb Kevin Tang:
> > > From: Kevin Tang  > >
> > >
> > > Adds drm support for the Unisoc's display subsystem.
> > >
> > > This is drm device and gem driver. This driver provides support
> > for the
> > > Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> > >
> > > Cc: Orson Zhai mailto:orsonz...@gmail.com>>
> > > Cc: Baolin Wang  > >
> > > Cc: Chunyan Zhang  zhang.l...@gmail.com>>
> > > Signed-off-by: Kevin Tang  > >
> > > ---
> > >  drivers/gpu/drm/Kconfig |   2 +
> > >  drivers/gpu/drm/Makefile|   1 +
> > >  drivers/gpu/drm/sprd/Kconfig|  14 ++
> > >  drivers/gpu/drm/sprd/Makefile   |   8 ++
> > >  drivers/gpu/drm/sprd/sprd_drm.c | 287
> > 
> > >  drivers/gpu/drm/sprd/sprd_drm.h |  19 +++
> > >  drivers/gpu/drm/sprd/sprd_gem.c | 178 +
> > >  drivers/gpu/drm/sprd/sprd_gem.h |  30 +
> >
> > The GEM implementation looks like DRM's CMA helpers. Can you not use
> CMA
> > helpers instead?
> >
> > Ok, i will remove cma keywords from the GEM implementatio.
>
> I'm not quite sure what you mean. Why can you not use the existing CMA
> helpers instead of writing your own?
>
My previous understanding was wrong, our Soc not support CMA, We only
support reserved memory or scattered buffers via iommu

>
> Best regards
> Thomas
>
> >
> >
> > >  8 files changed, 539 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/sprd/Kconfig
> > >  create mode 100644 drivers/gpu/drm/sprd/Makefile
> > >  create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
> > >  create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
> > >  create mode 100644 drivers/gpu/drm/sprd/sprd_gem.c
> > >  create mode 100644 drivers/gpu/drm/sprd/sprd_gem.h
> > >
> > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > index bfdadc3..cead12c 100644
> > > --- a/drivers/gpu/drm/Kconfig
> > > +++ b/drivers/gpu/drm/Kconfig
> > > @@ -387,6 +387,8 @@ source "drivers/gpu/drm/aspeed/Kconfig"
> > >
> > >  source "drivers/gpu/drm/mcde/Kconfig"
> > >
> > > +source "drivers/gpu/drm/sprd/Kconfig"
> > > +
> > >  # Keep legacy drivers last
> > >
> > >  menuconfig DRM_LEGACY
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 9f1c7c4..85ca211 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -122,3 +122,4 @@ obj-$(CONFIG_DRM_LIMA)  += lima/
> > >  obj-$(CONFIG_DRM_PANFROST) += panfrost/
> > >  obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
> > >  obj-$(CONFIG_DRM_MCDE) += mcde/
> > > +obj-$(CONFIG_DRM_SPRD) += sprd/
> > > diff --git a/drivers/gpu/drm/sprd/Kconfig
> > b/drivers/gpu/drm/sprd/Kconfig
> > > new file mode 100644
> > > index 000..79f286b
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/sprd/Kconfig
> > > @@ -0,0 +1,14 @@
> > > +config DRM_SPRD
> > > + tristate "DRM Support for Unisoc SoCs Platform"
> > > + depends on ARCH_SPRD
> > > + depends on DRM && OF
> > > + select DRM_KMS_HELPER
> > > + select DRM_GEM_CMA_HELPER
> > > + select DRM_KMS_CMA_HELPER
> > > + select DRM_MIPI_DSI
> > > + select DRM_PANEL
> > > + select VIDEOMODE_HELPERS
> > > + select BACKLIGHT_CLASS_DEVICE
> > > + help
> > > +   Choose this option if you have a Unisoc chipsets.
> > > +   If M is selected the module will be called sprd-drm.
> > > \ No newline at end of file
> > > diff --git a/drivers/gpu/drm/sprd/Makefile
> > b/drivers/gpu/drm/sprd/Makefile
> > > new file mode 100644
> > > index 000..df0b316
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/sprd/Makefile
> > > @@ -0,0 +1,8 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +
> > > +ccflags-y += -Iinclude/drm
> > > +
> > > +subdir-ccflags-y += -I$(src)
> > > +
> > > +obj-y := sprd_drm.o \
> > > + sprd_gem.o
> > > \ No newline at end of file
> > > diff --git a/drivers/gpu/drm/sprd/sprd_drm.c
> > b/drivers/gpu/drm/sprd/sprd_drm.c
> > > new file mode 100644
> > > index 000..ec16fee
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/sprd/sprd_drm.c
> > > @@ -0,0 +1,287 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright (C) 2019 Unisoc Inc.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#inc

Re: [PATCH] drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add

[Navid Emamdoost]

ping ...

On Thu, Nov 21, 2019 at 12:17 PM Navid Emamdoost
 wrote:
>
> On Tue, Sep 24, 2019 at 11:38 PM Navid Emamdoost
>  wrote:
> >
> > In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
> > for cres should be released.
> >
> > Signed-off-by: Navid Emamdoost 
>
> Would you please review this patch?
>
> Thanks,
>
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c 
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> > index 4ac55fc2bf97..44d858ce4ce7 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> > @@ -209,8 +209,10 @@ int vmw_cmdbuf_res_add(struct vmw_cmdbuf_res_manager 
> > *man,
> >
> > cres->hash.key = user_key | (res_type << 24);
> > ret = drm_ht_insert_item(&man->resources, &cres->hash);
> > -   if (unlikely(ret != 0))
> > +   if (unlikely(ret != 0)) {
> > +   kfree(cres);
> > goto out_invalid_key;
> > +   }
> >
> > cres->state = VMW_CMDBUF_RES_ADD;
> > cres->res = vmw_resource_reference(res);
> > --
> > 2.17.1
> >
>
>
> --
> Navid.



-- 
Navid.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 4/8] drm/sprd: add Unisoc's drm display controller driver

[tang pengchuan]

Hi

Emil Velikov  于2019年12月11日周三 上午1:14写道：

> Hi Kevin,
>
> On Tue, 10 Dec 2019 at 08:41, Kevin Tang  wrote:
> >
> > From: Kevin Tang 
> >
> > Adds DPU(Display Processor Unit) support for the Unisoc's display
> subsystem.
> > It's support multi planes, scaler, rotation, PQ(Picture Quality) and
> more.
> >
> > Cc: Orson Zhai 
> > Cc: Baolin Wang 
> > Cc: Chunyan Zhang 
> > Signed-off-by: Kevin Tang 
> > ---
> >  drivers/gpu/drm/sprd/Makefile   |6 +-
> >  drivers/gpu/drm/sprd/disp_lib.c |  290 +++
> >  drivers/gpu/drm/sprd/disp_lib.h |   40 +
> >  drivers/gpu/drm/sprd/dpu/Makefile   |8 +
> >  drivers/gpu/drm/sprd/dpu/dpu_r2p0.c | 1464
> +++
> >  drivers/gpu/drm/sprd/sprd_dpu.c | 1152 +++
> >  drivers/gpu/drm/sprd/sprd_dpu.h |  217 ++
> >  7 files changed, 3176 insertions(+), 1 deletion(-)
>
> As we can see from the diff stat this patch is huge. So it would be fairly
> hard
> to provide meaningful review as-is.
>
> One can combine my earlier suggestion (to keep modeset/atomic out of 2/8),
> with
> the following split:
>  - 4/8 add basic atomic modeset support - one format, one rotation 0, no
> extra
>  attributes
>  - 5/8 add extra formats
>  - 6/8 add extra rotation support
>  - ... add custom attributes
>
Ok, i will split this patch, upstream modeset and atomic at first. clock,
gloabl, enhance, extra
attributes  and so on will be upload later.
>
>
> 
>
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/disp_lib.c
>
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/disp_lib.h
>
> Let's keep this code out, for now. If we really need it we could
> revive/add it
> at a later stage.
>
Ok

>
> 
>
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/dpu/dpu_r2p0.c
> > @@ -0,0 +1,1464 @@
>
>
> > +struct gamma_entry {
> > +   u16 r;
> > +   u16 g;
> > +   u16 b;
> > +};
> > +
> Seem to be unused. Please drop this and double-check for other unused
> structs
>
>
> > +static struct scale_cfg scale_copy;
> > +static struct cm_cfg cm_copy;
> > +static struct slp_cfg slp_copy;
> > +static struct gamma_lut gamma_copy;
> > +static struct hsv_lut hsv_copy;
> > +static struct epf_cfg epf_copy;
> > +static u32 enhance_en;
> > +
> > +static DECLARE_WAIT_QUEUE_HEAD(wait_queue);
> > +static bool panel_ready = true;
> > +static bool need_scale;
> > +static bool mode_changed;
> > +static bool evt_update;
> > +static bool evt_stop;
> > +static u32 prev_y2r_coef;
> > +
> We should really avoid static variables. Some of the above look like
> enhancer
> state. One could create a struct keeping it alongside the rest of the
> display
> pipeline, right?
>
>
> 
>
> > +static void dpu_enhance_backup(u32 id, void *param)
> > +{
> As the enhance code is fairly large, lets keep the portions to a separate
> patch.
>
enhance code is  a big feature, so i will removed it at first commit.

>
>
> 
>
> > +static struct dpu_core_ops dpu_r2p0_ops = {
> Nit: as a general rule ops should be const.
>
>
> > +static int __init dpu_core_register(void)
> > +{
> > +   return dpu_core_ops_register(&entry);
> > +}
> > +
> > +subsys_initcall(dpu_core_register);
> I think that subsys_initcall, __init and MODULE area applicable only
> when we have multiple
> modules. Not 100% sure though ;-)
>
Yes, our display controller have multiple ip version, every version maybe
different

>
>
> > diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c
> b/drivers/gpu/drm/sprd/sprd_dpu.c
> > new file mode 100644
> > index 000..43142b3
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/sprd_dpu.c
>
> > +struct sprd_plane {
> > +   struct drm_plane plane;
> > +   struct drm_property *alpha_property;
> > +   struct drm_property *blend_mode_property;
> Core DRM already has alpha and blend_mode properties. Please reuse the code
>
>
> > +   struct drm_property *fbc_hsize_r_property;
> > +   struct drm_property *fbc_hsize_y_property;
> > +   struct drm_property *fbc_hsize_uv_property;
> > +   struct drm_property *y2r_coef_property;
> > +   struct drm_property *pallete_en_property;
> > +   struct drm_property *pallete_color_property;
> Let's have these properties introduced with separate follow-up patches.
> Please mention, in the commit message, why they are specific to the driver.
>
Ok, i will split it and commit later...

>
>
> 
>
> > +static int sprd_dpu_init(struct sprd_dpu *dpu)
> > +{
> > +   struct dpu_context *ctx = &dpu->ctx;
> > +
> > +   down(&ctx->refresh_lock);
> > +
> > +   if (dpu->ctx.is_inited) {
> > +   up(&ctx->refresh_lock);
> > +   return 0;
> > +   }
> > +
> > +   if (dpu->glb && dpu->glb->power)
> > +   dpu->glb->power(ctx, true);
> > +   if (dpu->glb && dpu->glb->enable)
> > +   dpu->glb->enable(ctx);
> > +
> > +   if (ctx->is_stopped && dpu->glb && dpu->glb->reset)
> > +   dpu->glb->reset(ctx);
> > +
> > +   if (dpu->clk && dpu->clk->init)
> > 

Re: [PATCH v3 12/12] auxdisplay: constify fb ops

[Miguel Ojeda]

On Mon, Dec 9, 2019 at 3:04 PM Jani Nikula  wrote:
>
> On Tue, 03 Dec 2019, Jani Nikula  wrote:
> > Now that the fbops member of struct fb_info is const, we can start
> > making the ops const as well.
> >
> > Cc: Miguel Ojeda Sandonis 
> > Cc: Robin van der Gracht 
> > Reviewed-by: Daniel Vetter 
> > Reviewed-by: Miguel Ojeda 
> > Acked-by: Robin van der Gracht 
> > Signed-off-by: Jani Nikula 
>
> Miguel, Robin, just to err on the safe side, were you both okay with me
> merging this through drm-misc? Not very likely to conflict badly.

I think that is fine, go ahead! :)

Cheers,
Miguel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC 2/8] drm/sprd: add Unisoc's drm kms master

[tang pengchuan]

Hi

Thomas Zimmermann  于2019年12月10日周二 下午6:33写道：

> Hi
>
> Am 10.12.19 um 09:36 schrieb Kevin Tang:
> > From: Kevin Tang 
> >
> > Adds drm support for the Unisoc's display subsystem.
> >
> > This is drm device and gem driver. This driver provides support for the
> > Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> >
> > Cc: Orson Zhai 
> > Cc: Baolin Wang 
> > Cc: Chunyan Zhang 
> > Signed-off-by: Kevin Tang 
> > ---
> >  drivers/gpu/drm/Kconfig |   2 +
> >  drivers/gpu/drm/Makefile|   1 +
> >  drivers/gpu/drm/sprd/Kconfig|  14 ++
> >  drivers/gpu/drm/sprd/Makefile   |   8 ++
> >  drivers/gpu/drm/sprd/sprd_drm.c | 287
> 
> >  drivers/gpu/drm/sprd/sprd_drm.h |  19 +++
> >  drivers/gpu/drm/sprd/sprd_gem.c | 178 +
> >  drivers/gpu/drm/sprd/sprd_gem.h |  30 +
>
> The GEM implementation looks like DRM's CMA helpers. Can you not use CMA
> helpers instead?
>
Ok, i will remove cma keywords from the GEM implementatio.

>
> >  8 files changed, 539 insertions(+)
> >  create mode 100644 drivers/gpu/drm/sprd/Kconfig
> >  create mode 100644 drivers/gpu/drm/sprd/Makefile
> >  create mode 100644 drivers/gpu/drm/sprd/sprd_drm.c
> >  create mode 100644 drivers/gpu/drm/sprd/sprd_drm.h
> >  create mode 100644 drivers/gpu/drm/sprd/sprd_gem.c
> >  create mode 100644 drivers/gpu/drm/sprd/sprd_gem.h
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index bfdadc3..cead12c 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -387,6 +387,8 @@ source "drivers/gpu/drm/aspeed/Kconfig"
> >
> >  source "drivers/gpu/drm/mcde/Kconfig"
> >
> > +source "drivers/gpu/drm/sprd/Kconfig"
> > +
> >  # Keep legacy drivers last
> >
> >  menuconfig DRM_LEGACY
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 9f1c7c4..85ca211 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -122,3 +122,4 @@ obj-$(CONFIG_DRM_LIMA)  += lima/
> >  obj-$(CONFIG_DRM_PANFROST) += panfrost/
> >  obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
> >  obj-$(CONFIG_DRM_MCDE) += mcde/
> > +obj-$(CONFIG_DRM_SPRD) += sprd/
> > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> > new file mode 100644
> > index 000..79f286b
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/Kconfig
> > @@ -0,0 +1,14 @@
> > +config DRM_SPRD
> > + tristate "DRM Support for Unisoc SoCs Platform"
> > + depends on ARCH_SPRD
> > + depends on DRM && OF
> > + select DRM_KMS_HELPER
> > + select DRM_GEM_CMA_HELPER
> > + select DRM_KMS_CMA_HELPER
> > + select DRM_MIPI_DSI
> > + select DRM_PANEL
> > + select VIDEOMODE_HELPERS
> > + select BACKLIGHT_CLASS_DEVICE
> > + help
> > +   Choose this option if you have a Unisoc chipsets.
> > +   If M is selected the module will be called sprd-drm.
> > \ No newline at end of file
> > diff --git a/drivers/gpu/drm/sprd/Makefile
> b/drivers/gpu/drm/sprd/Makefile
> > new file mode 100644
> > index 000..df0b316
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/Makefile
> > @@ -0,0 +1,8 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +ccflags-y += -Iinclude/drm
> > +
> > +subdir-ccflags-y += -I$(src)
> > +
> > +obj-y := sprd_drm.o \
> > + sprd_gem.o
> > \ No newline at end of file
> > diff --git a/drivers/gpu/drm/sprd/sprd_drm.c
> b/drivers/gpu/drm/sprd/sprd_drm.c
> > new file mode 100644
> > index 000..ec16fee
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/sprd_drm.c
> > @@ -0,0 +1,287 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Unisoc Inc.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "sprd_drm.h"
> > +#include "sprd_gem.h"
> > +
> > +#define DRIVER_NAME  "sprd"
> > +#define DRIVER_DESC  "Spreadtrum SoCs' DRM Driver"
> > +#define DRIVER_DATE  "20180501"
> > +#define DRIVER_MAJOR 1
> > +#define DRIVER_MINOR 0
> > +
> > +static const struct drm_mode_config_helper_funcs
> sprd_drm_mode_config_helper = {
> > + .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> > +};
> > +
> > +static const struct drm_mode_config_funcs sprd_drm_mode_config_funcs = {
> > + .fb_create = drm_gem_fb_create,
> > + .atomic_check = drm_atomic_helper_check,
> > + .atomic_commit = drm_atomic_helper_commit,
> > +};
> > +
> > +static void sprd_drm_mode_config_init(struct drm_device *drm)
> > +{
> > + drm_mode_config_init(drm);
> > +
> > + drm->mode_config.min_width = 0;
> > + drm->mode_config.min_height = 0;
> > + drm->mode_config.max_width = 8192;
> > + drm->mode_config.max_height = 8192;
> > + drm->mode_config.allow_fb_modifiers = true;
> > +
> > + drm->mode_config.funcs = &sprd_drm_mode_config_funcs;
> > + drm->mode_config.

[PATCH RESEND 0/4] drm: bridge: anx7688 and mux drivers

[Hsin-Yi Wang]

This is a resend of [1] with a few modification due to drm core function
changes and use regmap abstraction.

The gpio mux driver is required for MT8173 board layout:

  /-- anx7688
-- MT8173 HDMI bridge -- GPIO mux
  \-- native HDMI

[1] 
https://lore.kernel.org/lkml/1467013727-11482-1-git-send-email-drink...@chromium.org/

Nicolas Boichat (4):
  dt-bindings: drm/bridge: analogix-anx7688: Add ANX7688 transmitter
binding
  drm: bridge: anx7688: Add anx7688 bridge driver support.
  dt-bindings: drm/bridge: Add GPIO display mux binding
  drm: bridge: Generic GPIO mux driver

 .../bindings/display/bridge/anx7688.yaml  |  60 
 .../bindings/display/bridge/gpio-mux.yaml |  89 +
 drivers/gpu/drm/bridge/Kconfig|  19 ++
 drivers/gpu/drm/bridge/Makefile   |   2 +
 drivers/gpu/drm/bridge/analogix-anx7688.c | 202 
 drivers/gpu/drm/bridge/generic-gpio-mux.c | 306 ++
 6 files changed, 678 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/anx7688.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/gpio-mux.yaml
 create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c
 create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c

-- 
2.24.0.525.g8f36a354ae-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] Revert "drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested"

[Peter Rosin]

On 2019-12-10 15:59, claudiu.bez...@microchip.com wrote:
> 
> 
> On 10.12.2019 16:11, Peter Rosin wrote:
>> On 2019-12-10 14:24, Claudiu Beznea wrote:
>>> This reverts commit f6f7ad3234613f6f7f27c25036aaf078de07e9b0.
>>> ("drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested")
>>> because allowing selecting a higher pixel clock may overclock
>>> LCD devices, not all of them being capable of this.
>>
>> Without this patch, there are panels that are *severly* underclocked (on the
>> magnitude of 40MHz instead of 65MHz or something like that, I don't remember
>> the exact figures). 
> 
> With patch that switches by default to 2xsystem clock for pixel clock, if
> using 133MHz system clock (as you specified in the patch I proposed for
> revert here) that would go, without this patch at 53MHz if 65MHz is
> requested. Correct me if I'm wrong.

It might have been 53MHz, whatever it was it was too low for things to work.

>> And they are of course not capable of that. All panels
>> have *some* slack as to what frequencies are supported, and the patch was
>> written under the assumption that the preferred frequency of the panel was
>> requested, which should leave at least a *little* headroom.
> 
> I see, but from my point of view, the upper layers should decide what
> frequency settings should be done on the LCD controller and not let this at
>  the driver's latitude.

Right, but the upper layers do not support negotiating a frequency from
ranges. At least the didn't when the patch was written, and implementing
*that* seemed like a huge undertaking.

>>
>> So, I'm curious as to what panel regressed. Or rather, what pixel-clock it 
>> needs
>> and what it gets with/without the patch?
> 
> I have 2 use cases:
> 1/ system clock = 200MHz and requested pixel clock (mode_rate) ~71MHz. With
> the reverted patch the resulted computed pixel clock would be 80MHz.
> Previously it was at 66MHz

I don't see how that's possible.

[doing some calculation by hand]

Arrgh. *blush*

The code does not do what I intended for it to do.
Can you please try this instead of reverting?

Cheers,
Peter

>From b3e86d55b8d107a5c07e98f879c67f67120c87a6 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Tue, 10 Dec 2019 18:11:28 +0100
Subject: [PATCH] drm/atmel-hlcdc: prefer a lower pixel-clock than requested

The intention was to only select a higher pixel-clock rate than the
requested, if a slight overclocking would result in a rate significantly
closer to the requested rate than if the conservative lower pixel-clock
rate is selected. The fixed patch has the logic the other way around and
actually prefers the higher frequency. Fix that.

Fixes: f6f7ad323461 ("drm/atmel-hlcdc: allow selecting a higher pixel-clock 
than requested")
Reported-by: Claudiu Beznea 
Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 9e34bce089d0..03691845d37a 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -120,8 +120,8 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc 
*c)
int div_low = prate / mode_rate;
 
if (div_low >= 2 &&
-   ((prate / div_low - mode_rate) <
-10 * (mode_rate - prate / div)))
+   (10 * (prate / div_low - mode_rate) <
+(mode_rate - prate / div)))
/*
 * At least 10 times better when using a higher
 * frequency than requested, instead of a lower.
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RESEND 2/4] drm: bridge: anx7688: Add anx7688 bridge driver support.

[Hsin-Yi Wang]

From: Nicolas Boichat 

ANX7688 is a HDMI to DP converter (as well as USB-C port controller),
that has an internal microcontroller.

The only reason a Linux kernel driver is necessary is to reject
resolutions that require more bandwidth than what is available on
the DP side. DP bandwidth and lane count are reported by the bridge
via 2 registers on I2C.

Signed-off-by: Nicolas Boichat 
Signed-off-by: Hsin-Yi Wang 
---
 drivers/gpu/drm/bridge/Kconfig|   9 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/analogix-anx7688.c | 202 ++
 3 files changed, 212 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 34362976cd6f..1f3fc6bec842 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -16,6 +16,15 @@ config DRM_PANEL_BRIDGE
 menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
 
+config DRM_ANALOGIX_ANX7688
+   tristate "Analogix ANX7688 bridge"
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   ---help---
+ ANX7688 is a transmitter to support DisplayPort over USB-C for
+ smartphone and tablets.
+ This driver only supports the HDMI to DP component of the chip.
+
 config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..7a1e0ec032e6 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
diff --git a/drivers/gpu/drm/bridge/analogix-anx7688.c 
b/drivers/gpu/drm/bridge/analogix-anx7688.c
new file mode 100644
index ..baaed48d6201
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix-anx7688.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright 2016 Google LLC
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* Register addresses */
+#define VENDOR_ID_REG 0x00
+#define DEVICE_ID_REG 0x02
+
+#define FW_VERSION_REG 0x80
+
+#define DP_BANDWIDTH_REG 0x85
+#define DP_LANE_COUNT_REG 0x86
+
+#define VENDOR_ID 0x1f29
+#define DEVICE_ID 0x7688
+
+/* First supported firmware version (0.85) */
+#define MINIMUM_FW_VERSION 0x0085
+
+struct anx7688 {
+   struct drm_bridge bridge;
+   struct i2c_client *client;
+   struct regmap *regmap;
+
+   bool filter;
+};
+
+static inline struct anx7688 *bridge_to_anx7688(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct anx7688, bridge);
+}
+
+static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+   struct anx7688 *anx7688 = bridge_to_anx7688(bridge);
+   u8 regs[2];
+   u8 dpbw, lanecount;
+   int totalbw, requiredbw;
+   int ret;
+
+   if (!anx7688->filter)
+   return true;
+
+   /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
+   ret = regmap_bulk_read(anx7688->regmap, DP_BANDWIDTH_REG, regs, 2);
+   if (ret < 0) {
+   dev_err(&anx7688->client->dev,
+   "Failed to read bandwidth/lane count\n");
+   return false;
+   }
+   dpbw = regs[0];
+   lanecount = regs[1];
+
+   /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
+   if (dpbw > 0x19 || lanecount > 2) {
+   dev_err(&anx7688->client->dev,
+   "Invalid bandwidth/lane count (%02x/%d)\n",
+   dpbw, lanecount);
+   return false;
+   }
+
+   /* Compute available bandwidth (kHz) */
+   totalbw = dpbw * lanecount * 27 * 8 / 10;
+
+   /* Required bandwidth (8 bpc, kHz) */
+   requiredbw = mode->clock * 8 * 3;
+
+   dev_dbg(&anx7688->client->dev,
+   "DP bandwidth: %d kHz (%02x/%d); mode requires %d Khz\n",
+   totalbw, dpbw, lanecount, requiredbw);
+
+   if (totalbw == 0) {
+   dev_warn(&anx7688->client->dev,
+"Bandwidth/lane count are 0, not rejecting modes\n");
+   return true;
+   }
+
+   return totalbw >= requiredbw;
+}
+
+static const struct drm_bridge_funcs anx7688_bridge_funcs = {
+   .mode_fixup = anx7688_bridge_mode_fixup,
+};
+
+static const struct regmap_config anx7688_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+};
+
+static int anx7688_i2c_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+   

Re: linux-next: build failure after merge of the drm-intel tree

[Jani Nikula]

On Tue, 10 Dec 2019, Stephen Rothwell  wrote:
> Hi all,
>
> [Just adding Dave Airlie to the cc list]
>
> On Tue, 10 Dec 2019 09:39:57 +1100 Stephen Rothwell  
> wrote:
>>
>> After merging the drm-intel tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:

FYI, I've now backmerged drm-next and thus v5.5-rc1 to
drm-intel-next-queued, resolving the conflict.

BR,
Jani.


>> 
>> In file included from include/linux/spinlock_types.h:18,
>>  from include/linux/mutex.h:16,
>>  from include/linux/kernfs.h:12,
>>  from include/linux/sysfs.h:16,
>>  from include/linux/kobject.h:20,
>>  from include/linux/of.h:17,
>>  from include/linux/irqdomain.h:35,
>>  from include/linux/acpi.h:13,
>>  from drivers/gpu/drm/i915/i915_drv.c:30:
>> drivers/gpu/drm/i915/gem/i915_gem_object.h: In function 
>> 'i915_gem_object_pin_pages':
>> include/linux/lockdep.h:635:2: error: too many arguments to function 
>> 'lock_release'
>>   635 |  lock_release(&(lock)->dep_map, 0, _THIS_IP_);  \
>>   |  ^~~~
>> drivers/gpu/drm/i915/gem/i915_gem_object.h:294:2: note: in expansion of 
>> macro 'might_lock_nested'
>>   294 |  might_lock_nested(&obj->mm.lock, I915_MM_GET_PAGES);
>>   |  ^
>> include/linux/lockdep.h:352:13: note: declared here
>>   352 | extern void lock_release(struct lockdep_map *lock, unsigned long ip);
>>   | ^~~~
>> In file included from include/linux/spinlock_types.h:18,
>>  from include/linux/spinlock.h:83,
>>  from include/linux/mmzone.h:8,
>>  from include/linux/gfp.h:6,
>>  from include/linux/slab.h:15,
>>  from drivers/gpu/drm/i915/i915_irq.c:32:
>> drivers/gpu/drm/i915/gem/i915_gem_object.h: In function 
>> 'i915_gem_object_pin_pages':
>> include/linux/lockdep.h:635:2: error: too many arguments to function 
>> 'lock_release'
>>   635 |  lock_release(&(lock)->dep_map, 0, _THIS_IP_);  \
>>   |  ^~~~
>> drivers/gpu/drm/i915/gem/i915_gem_object.h:294:2: note: in expansion of 
>> macro 'might_lock_nested'
>>   294 |  might_lock_nested(&obj->mm.lock, I915_MM_GET_PAGES);
>>   |  ^
>> include/linux/lockdep.h:352:13: note: declared here
>>   352 | extern void lock_release(struct lockdep_map *lock, unsigned long ip);
>>   | ^~~~
>> 
>> Caused by commit
>> 
>>   e692b4021a2e ("lockdep: add might_lock_nested()")
>> 
>> interacting with commit
>> 
>>   5facae4f3549 ("locking/lockdep: Remove unused @nested argument from 
>> lock_release()")
>> 
>> from Linus' tree.
>> 
>> I have applied the following merge fix patch for today:
>> 
>> From: Stephen Rothwell 
>> Date: Tue, 10 Dec 2019 09:37:07 +1100
>> Subject: [PATCH] lockdep: fix up for lock_release API change
>> 
>> ---
>>  include/linux/lockdep.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
>> index 5bbfd5866081..664f52c6dd4c 100644
>> --- a/include/linux/lockdep.h
>> +++ b/include/linux/lockdep.h
>> @@ -632,7 +632,7 @@ do { 
>> \
>>  typecheck(struct lockdep_map *, &(lock)->dep_map);  \
>>  lock_acquire(&(lock)->dep_map, subclass, 0, 1, 1, NULL, \
>>   _THIS_IP_);\
>> -lock_release(&(lock)->dep_map, 0, _THIS_IP_);   \
>> +lock_release(&(lock)->dep_map, _THIS_IP_);  \
>>  } while (0)
>>  
>>  #define lockdep_assert_irqs_enabled()   do {
>> \

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] video: hdmi: indicate applicability in avi infoframe log

[Johan Korsnes]

When logging the AVI InfoFrame, clearly indicate whether or not
attributes are active/"in effect". The specification is given in
CTA-861-G Section 6.4: Format of Version 2, 3 & 4 AVI InfoFrames.

Attribute BytesRequirement
Ext. Colorimetry  EC0..EC2 Colorimetry (C0,C1) set to Extended.
IT Contents Type  CN0,CN1  IT Content (ITC) set to True.
RGB Quant. Range  Q0,Q1Color Space (Y0..Y2) set to RGB.
YCC Quant. Range  YQ0,YQ1  Color space (Y0..Y2) set to YCbCr.

Example log output with patch applied:
HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13
colorspace: RGB
scan mode: No Data
colorimetry: ITU709
picture aspect: 16:9
active aspect: Same as Picture
itc: IT Content
extended colorimetry: N/A (0x0)
quantization range: Full
nups: Unknown Non-uniform Scaling
video code: 16
ycc quantization range: N/A (0x0)
hdmi content type: Graphics
pixel repeat: 0
bar top 0, bottom 0, left 0, right 0

Signed-off-by: Johan Korsnes 
Cc: Hans Verkuil 
Cc: Martin Bugge 

---
v1 -> v2:
 * Indicate applicability not only for ext. colorimetry
---
 drivers/video/hdmi.c | 40 
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 9c82e2a0a411..491a77b28a9b 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1209,16 +1209,40 @@ static void hdmi_avi_infoframe_log(const char *level,
hdmi_log("active aspect: %s\n",
hdmi_active_aspect_get_name(frame->active_aspect));
hdmi_log("itc: %s\n", frame->itc ? "IT Content" : "No Data");
-   hdmi_log("extended colorimetry: %s\n",
-   
hdmi_extended_colorimetry_get_name(frame->extended_colorimetry));
-   hdmi_log("quantization range: %s\n",
-   
hdmi_quantization_range_get_name(frame->quantization_range));
+
+   if (frame->colorimetry == HDMI_COLORIMETRY_EXTENDED)
+   hdmi_log("extended colorimetry: %s\n",
+
hdmi_extended_colorimetry_get_name(frame->extended_colorimetry));
+   else
+   hdmi_log("extended colorimetry: N/A (0x%x)\n",
+frame->extended_colorimetry);
+
+   if (frame->colorspace == HDMI_COLORSPACE_RGB)
+   hdmi_log("quantization range: %s\n",
+
hdmi_quantization_range_get_name(frame->quantization_range));
+   else
+   hdmi_log("quantization range: N/A (0x%x)\n",
+frame->quantization_range);
+
hdmi_log("nups: %s\n", hdmi_nups_get_name(frame->nups));
hdmi_log("video code: %u\n", frame->video_code);
-   hdmi_log("ycc quantization range: %s\n",
-   
hdmi_ycc_quantization_range_get_name(frame->ycc_quantization_range));
-   hdmi_log("hdmi content type: %s\n",
-   hdmi_content_type_get_name(frame->content_type));
+
+   if (frame->colorspace == HDMI_COLORSPACE_YUV422 ||
+   frame->colorspace == HDMI_COLORSPACE_YUV444 ||
+   frame->colorspace == HDMI_COLORSPACE_YUV420)
+   hdmi_log("ycc quantization range: %s\n",
+
hdmi_ycc_quantization_range_get_name(frame->ycc_quantization_range));
+   else
+   hdmi_log("ycc quantization range: N/A (0x%x)\n",
+frame->ycc_quantization_range);
+
+   if (frame->itc)
+   hdmi_log("hdmi content type: %s\n",
+hdmi_content_type_get_name(frame->content_type));
+   else
+   hdmi_log("hdmi content type: N/A (0x%x)\n",
+frame->content_type);
+
hdmi_log("pixel repeat: %u\n", frame->pixel_repeat);
hdmi_log("bar top %u, bottom %u, left %u, right %u\n",
frame->top_bar, frame->bottom_bar,
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/shmem: add support for per object caching attributes

[Thomas Zimmermann]

Hi Gerd

Am 11.12.19 um 09:18 schrieb Gerd Hoffmann:
> Add caching field to drm_gem_shmem_object to specify the cachine
> attributes for mappings.  Add helper function to tweak pgprot
> accordingly.  Switch vmap and mmap functions to the new helper.
> 
> Set caching to write-combine when creating the object so behavior
> doesn't change by default.  Drivers can override that later if
> needed.
> 
> Signed-off-by: Gerd Hoffmann 

If you want to merge this patch, you have my

Reviewed-by: Thomas Zimmermann 

Please see my comment below.

> ---
>  include/drm/drm_gem_shmem_helper.h | 12 
>  drivers/gpu/drm/drm_gem_shmem_helper.c | 24 +---
>  2 files changed, 33 insertions(+), 3 deletions(-)
> 
> diff --git a/include/drm/drm_gem_shmem_helper.h 
> b/include/drm/drm_gem_shmem_helper.h
> index 6748379a0b44..9d6e02c6205f 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -17,6 +17,11 @@ struct drm_mode_create_dumb;
>  struct drm_printer;
>  struct sg_table;
>  
> +enum drm_gem_shmem_caching {
> + DRM_GEM_SHMEM_CACHED = 1,
> + DRM_GEM_SHMEM_WC,
> +};
> +
>  /**
>   * struct drm_gem_shmem_object - GEM object backed by shmem
>   */
> @@ -83,6 +88,11 @@ struct drm_gem_shmem_object {
>* The address are un-mapped when the count reaches zero.
>*/
>   unsigned int vmap_use_count;
> +
> + /**
> +  * @caching: caching attributes for mappings.
> +  */
> + enum drm_gem_shmem_caching caching;
>  };
>  
>  #define to_drm_gem_shmem_obj(obj) \
> @@ -130,6 +140,8 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device 
> *dev,
>  
>  struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_object *obj);
>  
> +pgprot_t drm_gem_shmem_caching(struct drm_gem_shmem_object *shmem, pgprot_t 
> prot);
> +
>  /**
>   * DRM_GEM_SHMEM_DRIVER_OPS - Default shmem GEM operations
>   *
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index a421a2eed48a..5bb94e130a50 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -76,6 +76,7 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct 
> drm_device *dev, size_t
>   mutex_init(&shmem->pages_lock);
>   mutex_init(&shmem->vmap_lock);
>   INIT_LIST_HEAD(&shmem->madv_list);
> + shmem->caching = DRM_GEM_SHMEM_WC;
>  
>   /*
>* Our buffers are kept pinned, so allocating them
> @@ -256,9 +257,11 @@ static void *drm_gem_shmem_vmap_locked(struct 
> drm_gem_shmem_object *shmem)
>  
>   if (obj->import_attach)
>   shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
> - else
> + else {
> + pgprot_t prot = drm_gem_shmem_caching(shmem, PAGE_KERNEL);
>   shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
> - VM_MAP, pgprot_writecombine(PAGE_KERNEL));
> + VM_MAP, prot);
> + }
>  
>   if (!shmem->vaddr) {
>   DRM_DEBUG_KMS("Failed to vmap pages\n");
> @@ -540,7 +543,8 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct 
> vm_area_struct *vma)
>   }
>  
>   vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
> - vma->vm_page_prot = 
> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> + vma->vm_page_prot = drm_gem_shmem_caching(shmem, vma->vm_page_prot);
>   vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>   vma->vm_ops = &drm_gem_shmem_vm_ops;
>  
> @@ -683,3 +687,17 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device 
> *dev,
>   return ERR_PTR(ret);
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
> +
> +pgprot_t drm_gem_shmem_caching(struct drm_gem_shmem_object *shmem, pgprot_t 
> prot)
> +{
> + switch (shmem->caching) {
> + case DRM_GEM_SHMEM_CACHED:
> + return prot;
> + case DRM_GEM_SHMEM_WC:
> + return pgprot_writecombine(prot);
> + default:
> + WARN_ON_ONCE(1);
> + return prot;
> + }
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_caching);

Two reason why I'd reconsider this design.

I don't like switch statements new the bottom of the call graph. The
code ends up with default warnings, such as this one.

Udl has different caching flags for imported and 'native' buffers. This
would require a new constant and additional code here.

What do you think about turning this function into a callback in struct
shmem_funcs? The default implementation would be for WC, virtio would
use CACHED. The individual implementations could still be located in the
shmem code. Udl would later provide its own code.

Best regards
Thomas

> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Desc

Re: [PATCH v2 1/2] drm/shmem: add support for per object caching attributes

[Thomas Zimmermann]

Am 11.12.19 um 10:58 schrieb Thomas Zimmermann:
> 
> What do you think about turning this function into a callback in struct
> shmem_funcs? The default implementation would be for WC, virtio would

s/shmem_funcs/drm_gem_object_funcs

> use CACHED. The individual implementations could still be located in the
> shmem code. Udl would later provide its own code.
> 
> Best regards
> Thomas
> 
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/shmem: add support for per object caching attributes

[Thomas Zimmermann]

Am 11.12.19 um 10:58 schrieb Thomas Zimmermann:
> Hi Gerd
> 
> Am 11.12.19 um 09:18 schrieb Gerd Hoffmann:
>> Add caching field to drm_gem_shmem_object to specify the cachine
>> attributes for mappings.  Add helper function to tweak pgprot
>> accordingly.  Switch vmap and mmap functions to the new helper.
>>
>> Set caching to write-combine when creating the object so behavior
>> doesn't change by default.  Drivers can override that later if
>> needed.
>>
>> Signed-off-by: Gerd Hoffmann 
> 
> If you want to merge this patch, you have my
> 
> Reviewed-by: Thomas Zimmermann 
> 
> Please see my comment below.
> 
>> ---
>>  include/drm/drm_gem_shmem_helper.h | 12 
>>  drivers/gpu/drm/drm_gem_shmem_helper.c | 24 +---
>>  2 files changed, 33 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/drm/drm_gem_shmem_helper.h 
>> b/include/drm/drm_gem_shmem_helper.h
>> index 6748379a0b44..9d6e02c6205f 100644
>> --- a/include/drm/drm_gem_shmem_helper.h
>> +++ b/include/drm/drm_gem_shmem_helper.h
>> @@ -17,6 +17,11 @@ struct drm_mode_create_dumb;
>>  struct drm_printer;
>>  struct sg_table;
>>  
>> +enum drm_gem_shmem_caching {
>> +DRM_GEM_SHMEM_CACHED = 1,
>> +DRM_GEM_SHMEM_WC,
>> +};
>> +
>>  /**
>>   * struct drm_gem_shmem_object - GEM object backed by shmem
>>   */
>> @@ -83,6 +88,11 @@ struct drm_gem_shmem_object {
>>   * The address are un-mapped when the count reaches zero.
>>   */
>>  unsigned int vmap_use_count;
>> +
>> +/**
>> + * @caching: caching attributes for mappings.
>> + */
>> +enum drm_gem_shmem_caching caching;
>>  };
>>  
>>  #define to_drm_gem_shmem_obj(obj) \
>> @@ -130,6 +140,8 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device 
>> *dev,
>>  
>>  struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_object *obj);
>>  
>> +pgprot_t drm_gem_shmem_caching(struct drm_gem_shmem_object *shmem, pgprot_t 
>> prot);
>> +
>>  /**
>>   * DRM_GEM_SHMEM_DRIVER_OPS - Default shmem GEM operations
>>   *
>> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
>> b/drivers/gpu/drm/drm_gem_shmem_helper.c
>> index a421a2eed48a..5bb94e130a50 100644
>> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
>> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
>> @@ -76,6 +76,7 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct 
>> drm_device *dev, size_t
>>  mutex_init(&shmem->pages_lock);
>>  mutex_init(&shmem->vmap_lock);
>>  INIT_LIST_HEAD(&shmem->madv_list);
>> +shmem->caching = DRM_GEM_SHMEM_WC;
>>  
>>  /*
>>   * Our buffers are kept pinned, so allocating them
>> @@ -256,9 +257,11 @@ static void *drm_gem_shmem_vmap_locked(struct 
>> drm_gem_shmem_object *shmem)
>>  
>>  if (obj->import_attach)
>>  shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
>> -else
>> +else {
>> +pgprot_t prot = drm_gem_shmem_caching(shmem, PAGE_KERNEL);
>>  shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
>> -VM_MAP, pgprot_writecombine(PAGE_KERNEL));
>> +VM_MAP, prot);
>> +}
>>  
>>  if (!shmem->vaddr) {
>>  DRM_DEBUG_KMS("Failed to vmap pages\n");
>> @@ -540,7 +543,8 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, 
>> struct vm_area_struct *vma)
>>  }
>>  
>>  vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
>> -vma->vm_page_prot = 
>> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
>> +vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>> +vma->vm_page_prot = drm_gem_shmem_caching(shmem, vma->vm_page_prot);
>>  vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>>  vma->vm_ops = &drm_gem_shmem_vm_ops;
>>  
>> @@ -683,3 +687,17 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device 
>> *dev,
>>  return ERR_PTR(ret);
>>  }
>>  EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
>> +
>> +pgprot_t drm_gem_shmem_caching(struct drm_gem_shmem_object *shmem, pgprot_t 
>> prot)
>> +{
>> +switch (shmem->caching) {
>> +case DRM_GEM_SHMEM_CACHED:
>> +return prot;
>> +case DRM_GEM_SHMEM_WC:
>> +return pgprot_writecombine(prot);
>> +default:
>> +WARN_ON_ONCE(1);
>> +return prot;
>> +}
>> +}
>> +EXPORT_SYMBOL_GPL(drm_gem_shmem_caching);
> 
> Two reason why I'd reconsider this design.
> 
> I don't like switch statements new the bottom of the call graph. The
> code ends up with default warnings, such as this one.
> 
> Udl has different caching flags for imported and 'native' buffers. This
> would require a new constant and additional code here.
> 
> What do you think about turning this function into a callback in struct
> shmem_funcs? The default implementation would be for WC, virtio would
> use CACHED. The individual implementations could still be located in the
> shmem code. Udl would later provide its own code.

On a second thought, all this might be over-engineered and v1 of 

Re: [PATCH] drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add

[Thomas Hellstrom]

On 9/25/19 6:38 AM, Navid Emamdoost wrote:
> In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
> for cres should be released.
>
> Signed-off-by: Navid Emamdoost 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> index 4ac55fc2bf97..44d858ce4ce7 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> @@ -209,8 +209,10 @@ int vmw_cmdbuf_res_add(struct vmw_cmdbuf_res_manager 
> *man,
>  
>   cres->hash.key = user_key | (res_type << 24);
>   ret = drm_ht_insert_item(&man->resources, &cres->hash);
> - if (unlikely(ret != 0))
> + if (unlikely(ret != 0)) {
> + kfree(cres);
>   goto out_invalid_key;
> + }
>  
>   cres->state = VMW_CMDBUF_RES_ADD;
>   cres->res = vmw_resource_reference(res);

Reviewed-by: Thomas Hellstrom 

Will be part of next vmwgfx-next pull.

Thanks,

Thomas


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vmwgfx: prevent memory leak in vmw_context_define

[Thomas Hellstrom]

On 9/25/19 6:46 AM, Navid Emamdoost wrote:
> In vmw_context_define if vmw_context_init fails the allocated resource
> should be unreferenced. The goto label was fixed.
>
> Signed-off-by: Navid Emamdoost 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> index a56c9d802382..ac42f8a6acf0 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
> @@ -773,7 +773,7 @@ static int vmw_context_define(struct drm_device *dev, 
> void *data,
>  
>   ret = vmw_context_init(dev_priv, res, vmw_user_context_free, dx);
>   if (unlikely(ret != 0))
> - goto out_unlock;
> + goto out_err;
>  
>   tmp = vmw_resource_reference(&ctx->res);
>   ret = ttm_base_object_init(tfile, &ctx->base, false, VMW_RES_CONTEXT,

This patch doesn't look correct. vmw_context_init should free up all
resources if failing.

Thanks,

Thomas


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v9 20/25] powerpc: book3s64: convert to pin_user_pages() and put_user_page()

[Jan Kara]

On Tue 10-12-19 18:53:13, John Hubbard wrote:
> 1. Convert from get_user_pages() to pin_user_pages().
> 
> 2. As required by pin_user_pages(), release these pages via
> put_user_page().
> 
> Cc: Jan Kara 
> Signed-off-by: John Hubbard 

The patch looks good to me. You can add:

Reviewed-by: Jan Kara 

I'd just note that mm_iommu_do_alloc() has a pre-existing bug that the last
jump to 'free_exit' (at line 157) happens already after converting page
pointers to physical addresses so put_page() calls there will just crash.
But that's completely unrelated to your change. I'll send a fix separately.

Honza

> ---
>  arch/powerpc/mm/book3s64/iommu_api.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/powerpc/mm/book3s64/iommu_api.c 
> b/arch/powerpc/mm/book3s64/iommu_api.c
> index 56cc84520577..a86547822034 100644
> --- a/arch/powerpc/mm/book3s64/iommu_api.c
> +++ b/arch/powerpc/mm/book3s64/iommu_api.c
> @@ -103,7 +103,7 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, 
> unsigned long ua,
>   for (entry = 0; entry < entries; entry += chunk) {
>   unsigned long n = min(entries - entry, chunk);
>  
> - ret = get_user_pages(ua + (entry << PAGE_SHIFT), n,
> + ret = pin_user_pages(ua + (entry << PAGE_SHIFT), n,
>   FOLL_WRITE | FOLL_LONGTERM,
>   mem->hpages + entry, NULL);
>   if (ret == n) {
> @@ -167,9 +167,8 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, 
> unsigned long ua,
>   return 0;
>  
>  free_exit:
> - /* free the reference taken */
> - for (i = 0; i < pinned; i++)
> - put_page(mem->hpages[i]);
> + /* free the references taken */
> + put_user_pages(mem->hpages, pinned);
>  
>   vfree(mem->hpas);
>   kfree(mem);
> @@ -215,7 +214,8 @@ static void mm_iommu_unpin(struct 
> mm_iommu_table_group_mem_t *mem)
>   if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
>   SetPageDirty(page);
>  
> - put_page(page);
> + put_user_page(page);
> +
>   mem->hpas[i] = 0;
>   }
>  }
> -- 
> 2.24.0
> 
-- 
Jan Kara 
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 04/50] drm/bridge: Add connector-related bridge operations and data

[Mihail Atanassov]

Hi Laurent,

On Tuesday, 10 December 2019 22:57:04 GMT Laurent Pinchart wrote:
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
> 
> - Output detection, hot-plug notification, mode retrieval and EDID
>   retrieval operations
> - Bitmask of supported operations
> - Bridge output type
> - I2C adapter for DDC access
> 
> Add and document these.
> 
> Three new bridge helper functions are also added to handle hot plug
> notification in a way that is as transparent as possible for the
> bridges.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Boris Brezillon 
> ---
> Changes since v2:
> 
> - Add wrappers around the .detect(), .get_modes() and .get_edid()
>   operations
> - Warn bridge drivers about valid usage of the connector argument to
>   .get_modes() and .get_edid()
> 
> Changes since v1:
> 
> - Make .hpd_enable() and .hpd_disable() optional
> - Rename .lost_hotplug() to .hpd_notify()
> - Add ddc field to drm_bridge
> ---
>  drivers/gpu/drm/drm_bridge.c | 162 +
>  include/drm/drm_bridge.h | 193 ++-
>  2 files changed, 354 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index c2cf0c90fa26..473353bd762f 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>   */
>  void drm_bridge_add(struct drm_bridge *bridge)
>  {
> + mutex_init(&bridge->hpd_mutex);
> +
>   mutex_lock(&bridge_lock);
>   list_add_tail(&bridge->list, &bridge_list);
>   mutex_unlock(&bridge_lock);
> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>   mutex_lock(&bridge_lock);
>   list_del_init(&bridge->list);
>   mutex_unlock(&bridge_lock);
> +
> + mutex_destroy(&bridge->hpd_mutex);
>  }
>  EXPORT_SYMBOL(drm_bridge_remove);
>  
> @@ -516,6 +520,164 @@ void drm_atomic_bridge_chain_enable(struct drm_bridge 
> *bridge,
>  }
>  EXPORT_SYMBOL(drm_atomic_bridge_chain_enable);
>  
> +/**
> + * drm_bridge_detect - check if anything is attached to the bridge output
> + * @bridge: bridge control structure
> + *
> + * If the bridge supports output detection, as reported by the
> + * DRM_BRIDGE_OP_DETECT bridge ops flag, call &drm_bridge_funcs.detect for 
> the
> + * bridge and return the connection status. Otherwise return
> + * connector_status_unknown.
> + *
> + * RETURNS:
> + * The detection status on success, or connector_status_unknown if the bridge
> + * doesn't support output detection.
> + */
> +enum drm_connector_status drm_bridge_detect(struct drm_bridge *bridge)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_DETECT))
> + return connector_status_unknown;
> +
> + return bridge->funcs->detect(bridge);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_detect);
> +
> +/**
> + * drm_bridge_get_modes - fill all modes currently valid for the sink into 
> the
> + * @connector
> + * @bridge: bridge control structure
> + * @connector: the connector to fill with modes
> + *
> + * If the bridge supports output modes retrieval, as reported by the
> + * DRM_BRIDGE_OP_MODES bridge ops flag, call &drm_bridge_funcs.get_modes to
> + * fill the connector with all valid modes and return the number of modes
> + * added. Otherwise return 0.
> + *
> + * RETURNS:
> + * The number of modes added to the connector.
> + */
> +int drm_bridge_get_modes(struct drm_bridge *bridge,
> +  struct drm_connector *connector)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_MODES))
> + return 0;
> +
> + return bridge->funcs->get_modes(bridge, connector);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_get_modes);
> +
> +/**
> + * drm_bridge_get_edid - get the EDID data of the connected display
> + * @bridge: bridge control structure
> + * @connector: the connector to read EDID for
> + *
> + * If the bridge supports output EDID retrieval, as reported by the
> + * DRM_BRIDGE_OP_EDID bridge ops flag, call &drm_bridge_funcs.get_edid to
> + * get the EDID and return it. Otherwise return ERR_PTR(-ENOTSUPP).
> + *
> + * RETURNS:
> + * The retrieved EDID on success, or an error pointer otherwise.
> + */
> +struct edid *drm_bridge_get_edid(struct drm_bridge *bridge,
> +  struct drm_connector *connector)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_EDID))
> + return ERR_PTR(-ENOTSUPP);
> +
> + return bridge->funcs->get_edid(bridge, connector);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_get_edid);
> +
> +/**
> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> + * @bridge: bridge control structure
> + * @cb: hot-plug detection callback
> + * @data: data to be passed to the hot-plug detection callback
> + *
> + * Call &drm_bridge_funcs.hpd_enable if implemented and register the given 
> @cb
> + * and @data as hot plug notification callback. From now on th

Re: [PATCH] drm: remove drm_bridge->dev

[Mihail Atanassov]

Hi,

On Wednesday, 11 December 2019 07:38:29 GMT Thomas Zimmermann wrote:
> Hi
> 
> Am 10.12.19 um 16:11 schrieb Mihail Atanassov:
> > As suggested in [1], the 'dev' field is a bit repetitive, since it 1:1
> > follows the setting and NULLing of the 'encoder' field. Therefore, use
> > drm_bridge->encoder->dev in place of drm_bridge->dev.
> > 
> > [1] https://patchwork.freedesktop.org/patch/343824/
> > 
> > Cc: Daniel Vetter 
> > Suggested-by: Thomas Zimmermann 
> > Signed-off-by: Mihail Atanassov 
> 
> Do you need help with merging the patch?

I've push rights to drm-misc-next, I'll handle it Soon(tm)/today. Thanks for
the offer, though :).

> 
> Best regards
> Thomas
> 
> > ---
> >  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  2 +-
> >  drivers/gpu/drm/bridge/analogix/analogix-anx6345.c |  2 +-
> >  drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c |  2 +-
> >  drivers/gpu/drm/bridge/cdns-dsi.c  |  2 +-
> >  drivers/gpu/drm/bridge/dumb-vga-dac.c  |  2 +-
> >  .../gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c   |  2 +-
> >  drivers/gpu/drm/bridge/nxp-ptn3460.c   |  2 +-
> >  drivers/gpu/drm/bridge/panel.c |  2 +-
> >  drivers/gpu/drm/bridge/parade-ps8622.c |  2 +-
> >  drivers/gpu/drm/bridge/sii902x.c   |  6 +++---
> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  6 +++---
> >  drivers/gpu/drm/bridge/tc358764.c  |  4 ++--
> >  drivers/gpu/drm/bridge/tc358767.c  |  6 +++---
> >  drivers/gpu/drm/bridge/ti-sn65dsi86.c  |  2 +-
> >  drivers/gpu/drm/bridge/ti-tfp410.c |  6 +++---
> >  drivers/gpu/drm/drm_bridge.c   | 10 --
> >  drivers/gpu/drm/i2c/tda998x_drv.c  |  2 +-
> >  drivers/gpu/drm/mcde/mcde_dsi.c|  2 +-
> >  drivers/gpu/drm/msm/edp/edp_bridge.c   |  2 +-
> >  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |  4 ++--
> >  drivers/gpu/drm/rcar-du/rcar_lvds.c|  3 ++-
> >  include/drm/drm_bridge.h   |  2 --
> >  22 files changed, 35 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > index 9e13e466e72c..009cf1fef8d4 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > @@ -863,7 +863,7 @@ static int adv7511_bridge_attach(struct drm_bridge 
> > *bridge)
> > adv->connector.polled = DRM_CONNECTOR_POLL_CONNECT |
> > DRM_CONNECTOR_POLL_DISCONNECT;
> >  
> > -   ret = drm_connector_init(bridge->dev, &adv->connector,
> > +   ret = drm_connector_init(bridge->encoder->dev, &adv->connector,
> >  &adv7511_connector_funcs,
> >  DRM_MODE_CONNECTOR_HDMIA);
> > if (ret) {
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c 
> > b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> > index 9917ce0d86a0..5b806d23fcb3 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> > @@ -541,7 +541,7 @@ static int anx6345_bridge_attach(struct drm_bridge 
> > *bridge)
> > return err;
> > }
> >  
> > -   err = drm_connector_init(bridge->dev, &anx6345->connector,
> > +   err = drm_connector_init(bridge->encoder->dev, &anx6345->connector,
> >  &anx6345_connector_funcs,
> >  DRM_MODE_CONNECTOR_eDP);
> > if (err) {
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c 
> > b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> > index 41867be03751..7463537950cb 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> > @@ -908,7 +908,7 @@ static int anx78xx_bridge_attach(struct drm_bridge 
> > *bridge)
> > return err;
> > }
> >  
> > -   err = drm_connector_init(bridge->dev, &anx78xx->connector,
> > +   err = drm_connector_init(bridge->encoder->dev, &anx78xx->connector,
> >  &anx78xx_connector_funcs,
> >  DRM_MODE_CONNECTOR_DisplayPort);
> > if (err) {
> > diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
> > b/drivers/gpu/drm/bridge/cdns-dsi.c
> > index 3a5bd4e7fd1e..32863e3ad537 100644
> > --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> > +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> > @@ -651,7 +651,7 @@ static int cdns_dsi_bridge_attach(struct drm_bridge 
> > *bridge)
> > struct cdns_dsi *dsi = input_to_dsi(input);
> > struct cdns_dsi_output *output = &dsi->output;
> >  
> > -   if (!drm_core_check_feature(bridge->dev, DRIVER_ATOMIC)) {
> > +   if (!drm_core_check_feature(bridge->enc

Re: [v3,3/4] drm/edid: Throw away the dummy VIC 0 cea mode

[Ville Syrjälä]

On Tue, Dec 10, 2019 at 03:18:54PM -0800, Tom Anderson wrote:
> On Wed, Sep 25, 2019 at 04:55:01PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Now that the cea mode handling is not 100% tied to the single
> > array the dummy VIC 0 mode is pretty much pointles. Throw it
> > out.
> > 
> > Cc: Hans Verkuil 
> > Cc: Shashank Sharma 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 14 +-
> >  1 file changed, 5 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 9f6996323efa..0007004d3221 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -709,11 +709,9 @@ static const struct minimode extra_modes[] = {
> >  /*
> >   * From CEA/CTA-861 spec.
> >   *
> > - * Index with VIC.
> > + * Index with VIC-1.
> 
> Since we shouldn't be indexing into this array directly any more, this comment
> should instead be changed to say which functions should be used.

Seems reasonable.

> 
> >   */
> > -static const struct drm_display_mode edid_cea_modes_0[] = {
> > -   /* 0 - dummy, VICs start at 1 */
> > -   { },
> > +static const struct drm_display_mode edid_cea_modes_1[] = {
> > /* 1 - 640x480@60Hz 4:3 */
> > { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
> >752, 800, 0, 480, 490, 492, 525, 0,
> > @@ -3211,10 +3209,8 @@ static u8 *drm_find_cea_extension(const struct edid 
> > *edid)
> >  
> >  static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
> >  {
> > -   if (!vic)
> > -   return NULL;
> > -   if (vic < ARRAY_SIZE(edid_cea_modes_0))
> > -   return &edid_cea_modes_0[vic];
> > +   if (vic >= 1 && vic < 1 + ARRAY_SIZE(edid_cea_modes_1))
> > +   return &edid_cea_modes_1[vic - 1];
> > if (vic >= 193 && vic < 193 + ARRAY_SIZE(edid_cea_modes_193))
> > return &edid_cea_modes_193[vic - 193];
> > return NULL;
> > @@ -3227,7 +3223,7 @@ static u8 cea_num_vics(void)
> >  
> >  static u8 cea_next_vic(u8 vic)
> >  {
> > -   if (++vic == ARRAY_SIZE(edid_cea_modes_0))
> > +   if (++vic == 1 + ARRAY_SIZE(edid_cea_modes_1))
> > vic = 193;
> > return vic;
> >  }

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 12/12] auxdisplay: constify fb ops

[Jani Nikula]

On Tue, 10 Dec 2019, Miguel Ojeda  wrote:
> On Mon, Dec 9, 2019 at 3:04 PM Jani Nikula  wrote:
>>
>> On Tue, 03 Dec 2019, Jani Nikula  wrote:
>> > Now that the fbops member of struct fb_info is const, we can start
>> > making the ops const as well.
>> >
>> > Cc: Miguel Ojeda Sandonis 
>> > Cc: Robin van der Gracht 
>> > Reviewed-by: Daniel Vetter 
>> > Reviewed-by: Miguel Ojeda 
>> > Acked-by: Robin van der Gracht 
>> > Signed-off-by: Jani Nikula 
>>
>> Miguel, Robin, just to err on the safe side, were you both okay with me
>> merging this through drm-misc? Not very likely to conflict badly.
>
> I think that is fine, go ahead! :)

Thanks, pushed to drm-misc-next!

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v9 23/25] mm/gup: track FOLL_PIN pages

[Jan Kara]

On Tue 10-12-19 18:53:16, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
> 
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via unpin_user_page().
> The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
> for DIO and/or RDMA use".
> 
> Pages that have been pinned via FOLL_PIN are identifiable via a
> new function call:
> 
>bool page_dma_pinned(struct page *page);
> 
> What to do in response to encountering such a page, is left to later
> patchsets. There is discussion about this in [1], [2], and [3].
> 
> This also changes a BUG_ON(), to a WARN_ON(), in follow_page_mask().
> 
> [1] Some slow progress on get_user_pages() (Apr 2, 2019):
> https://lwn.net/Articles/784574/
> [2] DMA and get_user_pages() (LPC: Dec 12, 2018):
> https://lwn.net/Articles/774411/
> [3] The trouble with get_user_pages() (Apr 30, 2018):
> https://lwn.net/Articles/753027/

The patch looks mostly good to me now. Just a few smaller comments below.

> Suggested-by: Jan Kara 
> Suggested-by: Jérôme Glisse 
> Reviewed-by: Jan Kara 
> Reviewed-by: Jérôme Glisse 
> Reviewed-by: Ira Weiny 

I think you inherited here the Reviewed-by tags from the "add flags" patch
you've merged into this one but that's not really fair since this patch
does much more... In particular I didn't give my Reviewed-by tag for this
patch yet.

> +/*
> + * try_grab_compound_head() - attempt to elevate a page's refcount, by a
> + * flags-dependent amount.
> + *
> + * This has a default assumption of "use FOLL_GET behavior, if FOLL_PIN is 
> not
> + * set".
> + *
> + * "grab" names in this file mean, "look at flags to decide whether to use
> + * FOLL_PIN or FOLL_GET behavior, when incrementing the page's refcount.
> + */
> +static __maybe_unused struct page *try_grab_compound_head(struct page *page,
> +   int refs,
> +   unsigned int flags)
> +{
> + if (flags & FOLL_PIN)
> + return try_pin_compound_head(page, refs);
> +
> + return try_get_compound_head(page, refs);
> +}

I somewhat wonder about the asymmetry of try_grab_compound_head() vs
try_grab_page() in the treatment of 'flags'. How costly would it be to make
them symmetric (i.e., either set FOLL_GET for try_grab_compound_head()
callers or make sure one of FOLL_GET, FOLL_PIN is set for try_grab_page())?

Because this difference looks like a subtle catch in the long run...

> +
> +/**
> + * try_grab_page() - elevate a page's refcount by a flag-dependent amount
> + *
> + * This might not do anything at all, depending on the flags argument.
> + *
> + * "grab" names in this file mean, "look at flags to decide whether to use
> + * FOLL_PIN or FOLL_GET behavior, when incrementing the page's refcount.
> + *
> + * @page:pointer to page to be grabbed
> + * @flags:   gup flags: these are the FOLL_* flag values.
> + *
> + * Either FOLL_PIN or FOLL_GET (or neither) may be set, but not both at the 
> same
> + * time. (That's true throughout the get_user_pages*() and pin_user_pages*()
> + * APIs.) Cases:
> + *
> + *   FOLL_GET: page's refcount will be incremented by 1.
> + *  FOLL_PIN: page's refcount will be incremented by 
> GUP_PIN_COUNTING_BIAS.
> + *
> + * Return: true for success, or if no action was required (if neither 
> FOLL_PIN
> + * nor FOLL_GET was set, nothing is done). False for failure: FOLL_GET or
> + * FOLL_PIN was set, but the page could not be grabbed.
> + */
> +bool __must_check try_grab_page(struct page *page, unsigned int flags)
> +{
> + if (flags & FOLL_GET)
> + return try_get_page(page);
> + else if (flags & FOLL_PIN) {
> + page = compound_head(page);
> + WARN_ON_ONCE(flags & FOLL_GET);
> +
> + if (WARN_ON_ONCE(page_ref_zero_or_close_to_bias_overflow(page)))
> + return false;
> +
> + page_ref_add(page, GUP_PIN_COUNTING_BIAS);
> + __update_proc_vmstat(page, NR_FOLL_PIN_REQUESTED, 1);
> + }
> +
> + return true;
> +}

...

> @@ -1522,8 +1536,8 @@ struct page *follow_trans_huge_pmd(struct 
> vm_area_struct *vma,
>  skip_mlock:
>   page += (addr & ~HPAGE_PMD_MASK) >> PAGE_SHIFT;
>   VM_BUG_ON_PAGE(!PageCompound(page) && !is_zone_device_page(page), page);
> - if (flags & FOLL_GET)
> - get_page(page);
> + if (!try_grab_page(page, flags))
> + page = ERR_PTR(-EFAULT);

I think you need to also move the try_grab_page() earlier in the function.
At this point the page may be marked as mlocked and you'd need to undo that
in case try_grab_page() fails.

> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index ac65bb5e38ac..0aab6fe0072f 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4356,7 +4356,13 @@ long follow_hugetlb_page(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>  same_page:
> 

Re: [PATCH RFC 4/8] drm/sprd: add Unisoc's drm display controller driver

[Emil Velikov]

On Wed, 11 Dec 2019 at 09:18, tang pengchuan  wrote:
>
> Hi
>
> Emil Velikov  于2019年12月11日周三 上午1:14写道：
>>
>> Hi Kevin,
>>
>> On Tue, 10 Dec 2019 at 08:41, Kevin Tang  wrote:
>> >
>> > From: Kevin Tang 
>> >
>> > Adds DPU(Display Processor Unit) support for the Unisoc's display 
>> > subsystem.
>> > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
>> >
>> > Cc: Orson Zhai 
>> > Cc: Baolin Wang 
>> > Cc: Chunyan Zhang 
>> > Signed-off-by: Kevin Tang 
>> > ---
>> >  drivers/gpu/drm/sprd/Makefile   |6 +-
>> >  drivers/gpu/drm/sprd/disp_lib.c |  290 +++
>> >  drivers/gpu/drm/sprd/disp_lib.h |   40 +
>> >  drivers/gpu/drm/sprd/dpu/Makefile   |8 +
>> >  drivers/gpu/drm/sprd/dpu/dpu_r2p0.c | 1464 
>> > +++
>> >  drivers/gpu/drm/sprd/sprd_dpu.c | 1152 +++
>> >  drivers/gpu/drm/sprd/sprd_dpu.h |  217 ++
>> >  7 files changed, 3176 insertions(+), 1 deletion(-)
>>
>> As we can see from the diff stat this patch is huge. So it would be fairly 
>> hard
>> to provide meaningful review as-is.
>>
>> One can combine my earlier suggestion (to keep modeset/atomic out of 2/8), 
>> with
>> the following split:
>>  - 4/8 add basic atomic modeset support - one format, one rotation 0, no 
>> extra
>>  attributes
>>  - 5/8 add extra formats
>>  - 6/8 add extra rotation support
>>  - ... add custom attributes
>
> Ok, i will split this patch, upstream modeset and atomic at first. clock, 
> gloabl, enhance, extra
> attributes  and so on will be upload later.

Amazing thank you. Please apply the similar logic and split patch 6/8
- that patch is twice larger than this one.

Some small general requests - please use plain text emails (see [1])
and trim unrelated fragments when replying.
Otherwise it is very easy to miss the comment that you and others have made.

HTH
Emil

[1] 
https://www.lifewire.com/how-to-send-a-message-in-plain-text-from-gmail-1171963
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/gma500: globle no more!

[Daniel Vetter]

globle, goblin, moblin?

It's dead code, we lucked out.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/gma500/mdfld_intel_display.c | 23 
 1 file changed, 23 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_intel_display.c 
b/drivers/gpu/drm/gma500/mdfld_intel_display.c
index b8bfb96008b8..4fff110c4921 100644
--- a/drivers/gpu/drm/gma500/mdfld_intel_display.c
+++ b/drivers/gpu/drm/gma500/mdfld_intel_display.c
@@ -113,27 +113,6 @@ static int psb_intel_panel_fitter_pipe(struct drm_device 
*dev)
return (pfit_control >> 29) & 0x3;
 }
 
-static struct drm_device globle_dev;
-
-void mdfld__intel_plane_set_alpha(int enable)
-{
-   struct drm_device *dev = &globle_dev;
-   int dspcntr_reg = DSPACNTR;
-   u32 dspcntr;
-
-   dspcntr = REG_READ(dspcntr_reg);
-
-   if (enable) {
-   dspcntr &= ~DISPPLANE_32BPP_NO_ALPHA;
-   dspcntr |= DISPPLANE_32BPP;
-   } else {
-   dspcntr &= ~DISPPLANE_32BPP;
-   dspcntr |= DISPPLANE_32BPP_NO_ALPHA;
-   }
-
-   REG_WRITE(dspcntr_reg, dspcntr);
-}
-
 static int check_fb(struct drm_framebuffer *fb)
 {
if (!fb)
@@ -164,8 +143,6 @@ static int mdfld__intel_pipe_set_base(struct drm_crtc 
*crtc, int x, int y,
u32 dspcntr;
int ret;
 
-   memcpy(&globle_dev, dev, sizeof(struct drm_device));
-
dev_dbg(dev->dev, "pipe = 0x%x.\n", pipe);
 
/* no fb bound */
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: Remove drm_bridge->dev

[Mihail Atanassov]

As suggested in [1], the 'dev' field is a bit repetitive, since it 1:1
follows the setting and NULLing of the 'encoder' field. Therefore, use
drm_bridge->encoder->dev in place of drm_bridge->dev.

[1] https://patchwork.freedesktop.org/patch/343824/

v2:
 - fix checkpatch complaint about unnecessary parentheses in
 drm_bridge.c. I've left the other two in since they're in the patch
 context rather than in a touched line.

Cc: Daniel Vetter 
Suggested-by: Thomas Zimmermann 
Acked-by: Thomas Zimmermann 
Signed-off-by: Mihail Atanassov 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  2 +-
 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c |  2 +-
 drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c |  2 +-
 drivers/gpu/drm/bridge/cdns-dsi.c  |  2 +-
 drivers/gpu/drm/bridge/dumb-vga-dac.c  |  2 +-
 .../gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c   |  2 +-
 drivers/gpu/drm/bridge/nxp-ptn3460.c   |  2 +-
 drivers/gpu/drm/bridge/panel.c |  2 +-
 drivers/gpu/drm/bridge/parade-ps8622.c |  2 +-
 drivers/gpu/drm/bridge/sii902x.c   |  6 +++---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  6 +++---
 drivers/gpu/drm/bridge/tc358764.c  |  4 ++--
 drivers/gpu/drm/bridge/tc358767.c  |  6 +++---
 drivers/gpu/drm/bridge/ti-sn65dsi86.c  |  2 +-
 drivers/gpu/drm/bridge/ti-tfp410.c |  6 +++---
 drivers/gpu/drm/drm_bridge.c   | 10 --
 drivers/gpu/drm/i2c/tda998x_drv.c  |  2 +-
 drivers/gpu/drm/mcde/mcde_dsi.c|  2 +-
 drivers/gpu/drm/msm/edp/edp_bridge.c   |  2 +-
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |  4 ++--
 drivers/gpu/drm/rcar-du/rcar_lvds.c|  3 ++-
 include/drm/drm_bridge.h   |  2 --
 22 files changed, 35 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 9e13e466e72c..009cf1fef8d4 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -863,7 +863,7 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge)
adv->connector.polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
 
-   ret = drm_connector_init(bridge->dev, &adv->connector,
+   ret = drm_connector_init(bridge->encoder->dev, &adv->connector,
 &adv7511_connector_funcs,
 DRM_MODE_CONNECTOR_HDMIA);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 9917ce0d86a0..5b806d23fcb3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -541,7 +541,7 @@ static int anx6345_bridge_attach(struct drm_bridge *bridge)
return err;
}
 
-   err = drm_connector_init(bridge->dev, &anx6345->connector,
+   err = drm_connector_init(bridge->encoder->dev, &anx6345->connector,
 &anx6345_connector_funcs,
 DRM_MODE_CONNECTOR_eDP);
if (err) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index 41867be03751..7463537950cb 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -908,7 +908,7 @@ static int anx78xx_bridge_attach(struct drm_bridge *bridge)
return err;
}
 
-   err = drm_connector_init(bridge->dev, &anx78xx->connector,
+   err = drm_connector_init(bridge->encoder->dev, &anx78xx->connector,
 &anx78xx_connector_funcs,
 DRM_MODE_CONNECTOR_DisplayPort);
if (err) {
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
index 3a5bd4e7fd1e..32863e3ad537 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -651,7 +651,7 @@ static int cdns_dsi_bridge_attach(struct drm_bridge *bridge)
struct cdns_dsi *dsi = input_to_dsi(input);
struct cdns_dsi_output *output = &dsi->output;
 
-   if (!drm_core_check_feature(bridge->dev, DRIVER_ATOMIC)) {
+   if (!drm_core_check_feature(bridge->encoder->dev, DRIVER_ATOMIC)) {
dev_err(dsi->base.dev,
"cdns-dsi driver is only compatible with DRM devices 
supporting atomic updates");
return -ENOTSUPP;
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index cc33dc411b9e..67ad6cecf68d 100644
--- a/drivers/gpu/drm/bridge/du

[PATCH v3 4/4] drm/udl: simplify gem object mapping.

[Gerd Hoffmann]

With shmem helpers allowing to update pgprot caching flags via
drm_gem_object_funcs.pgprot we can just use that and ditch our own
implementations of mmap() and vmap().

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/udl/udl_gem.c | 62 ---
 1 file changed, 7 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index b6e26f98aa0a..b82a4a921f1b 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -17,61 +17,12 @@
  * GEM object funcs
  */
 
-static int udl_gem_object_mmap(struct drm_gem_object *obj,
-  struct vm_area_struct *vma)
+static pgprot_t udl_gem_object_pgprot(struct drm_gem_object *obj,
+ pgprot_t pgprot)
 {
-   int ret;
-
-   ret = drm_gem_shmem_mmap(obj, vma);
-   if (ret)
-   return ret;
-
-   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
if (obj->import_attach)
-   vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
-   vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
-
-   return 0;
-}
-
-static void *udl_gem_object_vmap(struct drm_gem_object *obj)
-{
-   struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
-   int ret;
-
-   ret = mutex_lock_interruptible(&shmem->vmap_lock);
-   if (ret)
-   return ERR_PTR(ret);
-
-   if (shmem->vmap_use_count++ > 0)
-   goto out;
-
-   ret = drm_gem_shmem_get_pages(shmem);
-   if (ret)
-   goto err_zero_use;
-
-   if (obj->import_attach)
-   shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
-   else
-   shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
-   VM_MAP, PAGE_KERNEL);
-
-   if (!shmem->vaddr) {
-   DRM_DEBUG_KMS("Failed to vmap pages\n");
-   ret = -ENOMEM;
-   goto err_put_pages;
-   }
-
-out:
-   mutex_unlock(&shmem->vmap_lock);
-   return shmem->vaddr;
-
-err_put_pages:
-   drm_gem_shmem_put_pages(shmem);
-err_zero_use:
-   shmem->vmap_use_count = 0;
-   mutex_unlock(&shmem->vmap_lock);
-   return ERR_PTR(ret);
+   pgprot = pgprot_writecombine(pgprot);
+   return pgprot;
 }
 
 static const struct drm_gem_object_funcs udl_gem_object_funcs = {
@@ -80,9 +31,10 @@ static const struct drm_gem_object_funcs 
udl_gem_object_funcs = {
.pin = drm_gem_shmem_pin,
.unpin = drm_gem_shmem_unpin,
.get_sg_table = drm_gem_shmem_get_sg_table,
-   .vmap = udl_gem_object_vmap,
+   .vmap = drm_gem_shmem_vmap,
.vunmap = drm_gem_shmem_vunmap,
-   .mmap = udl_gem_object_mmap,
+   .mmap = drm_gem_shmem_mmap,
+   .pgprot = udl_gem_object_pgprot,
 };
 
 /*
-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/4] drm/shmem: add support for per object caching flags.

[Gerd Hoffmann]

Use drm_gem_pgprot_wc() as pgprot callback in drm_gem_shmem_funcs.
Use drm_gem_pgprot() to update pgprot caching flags.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index a421a2eed48a..2a662ed77115 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -33,6 +33,7 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs 
= {
.vmap = drm_gem_shmem_vmap,
.vunmap = drm_gem_shmem_vunmap,
.mmap = drm_gem_shmem_mmap,
+   .pgprot = drm_gem_pgprot_wc,
 };
 
 /**
@@ -258,7 +259,7 @@ static void *drm_gem_shmem_vmap_locked(struct 
drm_gem_shmem_object *shmem)
shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
else
shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
-   VM_MAP, pgprot_writecombine(PAGE_KERNEL));
+   VM_MAP, drm_gem_pgprot(obj, PAGE_KERNEL));
 
if (!shmem->vaddr) {
DRM_DEBUG_KMS("Failed to vmap pages\n");
@@ -540,7 +541,8 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct 
vm_area_struct *vma)
}
 
vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
-   vma->vm_page_prot = 
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+   vma->vm_page_prot = drm_gem_pgprot(obj, vma->vm_page_prot);
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
vma->vm_ops = &drm_gem_shmem_vm_ops;
 
-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/4] drm/virtio: fix mmap page attributes

[Gerd Hoffmann]

virtio-gpu uses cached mappings, set virtio_gpu_gem_funcs.pgprot
accordingly.

Reported-by: Gurchetan Singh 
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_object.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 017a9e0fc3bb..0b754c5bbcce 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -87,6 +87,7 @@ static const struct drm_gem_object_funcs virtio_gpu_gem_funcs 
= {
.vmap = drm_gem_shmem_vmap,
.vunmap = drm_gem_shmem_vunmap,
.mmap = &drm_gem_shmem_mmap,
+   .pgprot = &drm_gem_pgprot_cached,
 };
 
 struct drm_gem_object *virtio_gpu_create_object(struct drm_device *dev,
-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/4] drm/virtio: fix mmap page attributes

[Gerd Hoffmann]

v3: switch to drm_gem_object_funcs callback.
v2: make shmem helper caching configurable.

Gerd Hoffmann (4):
  drm: add pgprot callback to drm_gem_object_funcs
  drm/shmem: add support for per object caching flags.
  drm/virtio: fix mmap page attributes
  drm/udl: simplify gem object mapping.

 include/drm/drm_gem.h   | 15 ++
 drivers/gpu/drm/drm_gem.c   | 46 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c  |  6 ++-
 drivers/gpu/drm/udl/udl_gem.c   | 62 +++--
 drivers/gpu/drm/virtio/virtgpu_object.c |  1 +
 5 files changed, 72 insertions(+), 58 deletions(-)

-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/4] drm: add pgprot callback to drm_gem_object_funcs

[Gerd Hoffmann]

The callback allows drivers and helpers to tweak pgprot for mappings.
This is especially helpful when using shmem helpers.  It allows drivers
to switch mappings from writecombine (default) to something else (cached
for example) on a per-object base without having to supply their own
mmap() and vmap() functions.

The patch also adds two implementations for the callback, for cached and
writecombine mappings, and the drm_gem_pgprot() function to update
pgprot for a given object, using the new &drm_gem_object_funcs.pgprot
callback if available.

Signed-off-by: Gerd Hoffmann 
---
 include/drm/drm_gem.h | 15 +
 drivers/gpu/drm/drm_gem.c | 46 ++-
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 0b375069cd48..5beef7226e69 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -163,6 +163,17 @@ struct drm_gem_object_funcs {
 */
int (*mmap)(struct drm_gem_object *obj, struct vm_area_struct *vma);
 
+   /**
+* @pgprot:
+*
+* Tweak pgprot as needed, typically used to set cache bits.
+*
+* This callback is optional.
+*
+* If unset drm_gem_pgprot_wc() will be used.
+*/
+   pgprot_t (*pgprot)(struct drm_gem_object *obj, pgprot_t prot);
+
/**
 * @vm_ops:
 *
@@ -350,6 +361,10 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned 
long obj_size,
 struct vm_area_struct *vma);
 int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
 
+pgprot_t drm_gem_pgprot_cached(struct drm_gem_object *obj, pgprot_t prot);
+pgprot_t drm_gem_pgprot_wc(struct drm_gem_object *obj, pgprot_t prot);
+pgprot_t drm_gem_pgprot(struct drm_gem_object *obj, pgprot_t prot);
+
 /**
  * drm_gem_object_get - acquire a GEM buffer object reference
  * @obj: GEM buffer object
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 56f42e0f2584..1c468fe8e342 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1119,7 +1119,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned 
long obj_size,
return -EINVAL;
 
vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | 
VM_DONTDUMP;
-   vma->vm_page_prot = 
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+   vma->vm_page_prot = drm_gem_pgprot(obj, vma->vm_page_prot);
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
}
 
@@ -1210,6 +1211,49 @@ int drm_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
 }
 EXPORT_SYMBOL(drm_gem_mmap);
 
+/**
+ * drm_gem_mmap - update pgprot for objects needing a cachable mapping.
+ * @obj: the GEM object.
+ * @prot: page attributes.
+ *
+ * This function can be used as &drm_gem_object_funcs.pgprot callback.
+ */
+pgprot_t drm_gem_pgprot_cached(struct drm_gem_object *obj, pgprot_t prot)
+{
+   return prot;
+}
+EXPORT_SYMBOL(drm_gem_pgprot_cached);
+
+/**
+ * drm_gem_mmap - update pgprot for objects needing a wc mapping.
+ * @obj: the GEM object.
+ * @prot: page attributes.
+ *
+ * This function can be used as &drm_gem_object_funcs.pgprot callback.
+ */
+pgprot_t drm_gem_pgprot_wc(struct drm_gem_object *obj, pgprot_t prot)
+{
+   return pgprot_writecombine(prot);
+}
+EXPORT_SYMBOL(drm_gem_pgprot_wc);
+
+/**
+ * drm_gem_mmap - update pgprot for a given gem object.
+ * @obj: the GEM object.
+ * @prot: page attributes.
+ *
+ * This function updates pgprot according to the needs of the given
+ * object.  If present &drm_gem_object_funcs.pgprot callback will be
+ * used, otherwise drm_gem_pgprot_wc() is called.
+ */
+pgprot_t drm_gem_pgprot(struct drm_gem_object *obj, pgprot_t prot)
+{
+   if (obj->funcs->pgprot)
+   return obj->funcs->pgprot(obj, prot);
+   return drm_gem_pgprot_wc(obj, prot);
+}
+EXPORT_SYMBOL(drm_gem_pgprot);
+
 void drm_gem_print_info(struct drm_printer *p, unsigned int indent,
const struct drm_gem_object *obj)
 {
-- 
2.18.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/shmem: add support for per object caching attributes

[Daniel Vetter]

On Wed, Dec 11, 2019 at 11:07:25AM +0100, Thomas Zimmermann wrote:
> 
> 
> Am 11.12.19 um 10:58 schrieb Thomas Zimmermann:
> > Hi Gerd
> > 
> > Am 11.12.19 um 09:18 schrieb Gerd Hoffmann:
> >> Add caching field to drm_gem_shmem_object to specify the cachine
> >> attributes for mappings.  Add helper function to tweak pgprot
> >> accordingly.  Switch vmap and mmap functions to the new helper.
> >>
> >> Set caching to write-combine when creating the object so behavior
> >> doesn't change by default.  Drivers can override that later if
> >> needed.
> >>
> >> Signed-off-by: Gerd Hoffmann 
> > 
> > If you want to merge this patch, you have my
> > 
> > Reviewed-by: Thomas Zimmermann 
> > 
> > Please see my comment below.
> > 
> >> ---
> >>  include/drm/drm_gem_shmem_helper.h | 12 
> >>  drivers/gpu/drm/drm_gem_shmem_helper.c | 24 +---
> >>  2 files changed, 33 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/include/drm/drm_gem_shmem_helper.h 
> >> b/include/drm/drm_gem_shmem_helper.h
> >> index 6748379a0b44..9d6e02c6205f 100644
> >> --- a/include/drm/drm_gem_shmem_helper.h
> >> +++ b/include/drm/drm_gem_shmem_helper.h
> >> @@ -17,6 +17,11 @@ struct drm_mode_create_dumb;
> >>  struct drm_printer;
> >>  struct sg_table;
> >>  
> >> +enum drm_gem_shmem_caching {
> >> +  DRM_GEM_SHMEM_CACHED = 1,
> >> +  DRM_GEM_SHMEM_WC,
> >> +};
> >> +
> >>  /**
> >>   * struct drm_gem_shmem_object - GEM object backed by shmem
> >>   */
> >> @@ -83,6 +88,11 @@ struct drm_gem_shmem_object {
> >> * The address are un-mapped when the count reaches zero.
> >> */
> >>unsigned int vmap_use_count;
> >> +
> >> +  /**
> >> +   * @caching: caching attributes for mappings.
> >> +   */
> >> +  enum drm_gem_shmem_caching caching;
> >>  };
> >>  
> >>  #define to_drm_gem_shmem_obj(obj) \
> >> @@ -130,6 +140,8 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device 
> >> *dev,
> >>  
> >>  struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_object *obj);
> >>  
> >> +pgprot_t drm_gem_shmem_caching(struct drm_gem_shmem_object *shmem, 
> >> pgprot_t prot);
> >> +
> >>  /**
> >>   * DRM_GEM_SHMEM_DRIVER_OPS - Default shmem GEM operations
> >>   *
> >> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
> >> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> >> index a421a2eed48a..5bb94e130a50 100644
> >> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> >> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> >> @@ -76,6 +76,7 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct 
> >> drm_device *dev, size_t
> >>mutex_init(&shmem->pages_lock);
> >>mutex_init(&shmem->vmap_lock);
> >>INIT_LIST_HEAD(&shmem->madv_list);
> >> +  shmem->caching = DRM_GEM_SHMEM_WC;
> >>  
> >>/*
> >> * Our buffers are kept pinned, so allocating them
> >> @@ -256,9 +257,11 @@ static void *drm_gem_shmem_vmap_locked(struct 
> >> drm_gem_shmem_object *shmem)
> >>  
> >>if (obj->import_attach)
> >>shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
> >> -  else
> >> +  else {
> >> +  pgprot_t prot = drm_gem_shmem_caching(shmem, PAGE_KERNEL);
> >>shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
> >> -  VM_MAP, pgprot_writecombine(PAGE_KERNEL));
> >> +  VM_MAP, prot);
> >> +  }
> >>  
> >>if (!shmem->vaddr) {
> >>DRM_DEBUG_KMS("Failed to vmap pages\n");
> >> @@ -540,7 +543,8 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, 
> >> struct vm_area_struct *vma)
> >>}
> >>  
> >>vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
> >> -  vma->vm_page_prot = 
> >> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> >> +  vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> >> +  vma->vm_page_prot = drm_gem_shmem_caching(shmem, vma->vm_page_prot);
> >>vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
> >>vma->vm_ops = &drm_gem_shmem_vm_ops;
> >>  
> >> @@ -683,3 +687,17 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device 
> >> *dev,
> >>return ERR_PTR(ret);
> >>  }
> >>  EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
> >> +
> >> +pgprot_t drm_gem_shmem_caching(struct drm_gem_shmem_object *shmem, 
> >> pgprot_t prot)
> >> +{
> >> +  switch (shmem->caching) {
> >> +  case DRM_GEM_SHMEM_CACHED:
> >> +  return prot;
> >> +  case DRM_GEM_SHMEM_WC:
> >> +  return pgprot_writecombine(prot);
> >> +  default:
> >> +  WARN_ON_ONCE(1);
> >> +  return prot;
> >> +  }
> >> +}
> >> +EXPORT_SYMBOL_GPL(drm_gem_shmem_caching);
> > 
> > Two reason why I'd reconsider this design.
> > 
> > I don't like switch statements new the bottom of the call graph. The
> > code ends up with default warnings, such as this one.
> > 
> > Udl has different caching flags for imported and 'native' buffers. This
> > would require a new constant and additional code here.
> > 
> > What do you think about turning this function into a callback in struct
> > shme

Re: [PATCH v3 1/4] drm: add pgprot callback to drm_gem_object_funcs

[Daniel Vetter]

On Wed, Dec 11, 2019 at 01:19:53PM +0100, Gerd Hoffmann wrote:
> The callback allows drivers and helpers to tweak pgprot for mappings.
> This is especially helpful when using shmem helpers.  It allows drivers
> to switch mappings from writecombine (default) to something else (cached
> for example) on a per-object base without having to supply their own
> mmap() and vmap() functions.
> 
> The patch also adds two implementations for the callback, for cached and
> writecombine mappings, and the drm_gem_pgprot() function to update
> pgprot for a given object, using the new &drm_gem_object_funcs.pgprot
> callback if available.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/drm/drm_gem.h | 15 +
>  drivers/gpu/drm/drm_gem.c | 46 ++-
>  2 files changed, 60 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 0b375069cd48..5beef7226e69 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -163,6 +163,17 @@ struct drm_gem_object_funcs {
>*/
>   int (*mmap)(struct drm_gem_object *obj, struct vm_area_struct *vma);
>  
> + /**
> +  * @pgprot:
> +  *
> +  * Tweak pgprot as needed, typically used to set cache bits.
> +  *
> +  * This callback is optional.
> +  *
> +  * If unset drm_gem_pgprot_wc() will be used.
> +  */
> + pgprot_t (*pgprot)(struct drm_gem_object *obj, pgprot_t prot);

I kinda prefer v1, mostly because this is a huge can of worms, and solving
this properly is going to be real hard (and will necessarily involve
dma-buf and dma-api and probably more). Charging ahead here just risks
that we dig ourselves into a corner. You're v1 is maybe not the most
clean, but just a few code bits here&there should be more flexible and
easier to hack on and experiment around with.
-Daniel

> +
>   /**
>* @vm_ops:
>*
> @@ -350,6 +361,10 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, 
> unsigned long obj_size,
>struct vm_area_struct *vma);
>  int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
>  
> +pgprot_t drm_gem_pgprot_cached(struct drm_gem_object *obj, pgprot_t prot);
> +pgprot_t drm_gem_pgprot_wc(struct drm_gem_object *obj, pgprot_t prot);
> +pgprot_t drm_gem_pgprot(struct drm_gem_object *obj, pgprot_t prot);
> +
>  /**
>   * drm_gem_object_get - acquire a GEM buffer object reference
>   * @obj: GEM buffer object
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 56f42e0f2584..1c468fe8e342 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1119,7 +1119,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, 
> unsigned long obj_size,
>   return -EINVAL;
>  
>   vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | 
> VM_DONTDUMP;
> - vma->vm_page_prot = 
> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> + vma->vm_page_prot = drm_gem_pgprot(obj, vma->vm_page_prot);
>   vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>   }
>  
> @@ -1210,6 +1211,49 @@ int drm_gem_mmap(struct file *filp, struct 
> vm_area_struct *vma)
>  }
>  EXPORT_SYMBOL(drm_gem_mmap);
>  
> +/**
> + * drm_gem_mmap - update pgprot for objects needing a cachable mapping.
> + * @obj: the GEM object.
> + * @prot: page attributes.
> + *
> + * This function can be used as &drm_gem_object_funcs.pgprot callback.
> + */
> +pgprot_t drm_gem_pgprot_cached(struct drm_gem_object *obj, pgprot_t prot)
> +{
> + return prot;
> +}
> +EXPORT_SYMBOL(drm_gem_pgprot_cached);
> +
> +/**
> + * drm_gem_mmap - update pgprot for objects needing a wc mapping.
> + * @obj: the GEM object.
> + * @prot: page attributes.
> + *
> + * This function can be used as &drm_gem_object_funcs.pgprot callback.
> + */
> +pgprot_t drm_gem_pgprot_wc(struct drm_gem_object *obj, pgprot_t prot)
> +{
> + return pgprot_writecombine(prot);
> +}
> +EXPORT_SYMBOL(drm_gem_pgprot_wc);
> +
> +/**
> + * drm_gem_mmap - update pgprot for a given gem object.
> + * @obj: the GEM object.
> + * @prot: page attributes.
> + *
> + * This function updates pgprot according to the needs of the given
> + * object.  If present &drm_gem_object_funcs.pgprot callback will be
> + * used, otherwise drm_gem_pgprot_wc() is called.
> + */
> +pgprot_t drm_gem_pgprot(struct drm_gem_object *obj, pgprot_t prot)
> +{
> + if (obj->funcs->pgprot)
> + return obj->funcs->pgprot(obj, prot);
> + return drm_gem_pgprot_wc(obj, prot);
> +}
> +EXPORT_SYMBOL(drm_gem_pgprot);
> +
>  void drm_gem_print_info(struct drm_printer *p, unsigned int indent,
>   const struct drm_gem_object *obj)
>  {
> -- 
> 2.18.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@

Re: [PATCH v2] drm/panfrost: Add the panfrost_gem_mapping concept

[Steven Price]

On 10/12/2019 23:08, Rob Herring wrote:
> From: Boris Brezillon 
> 
> With the introduction of per-FD address space, the same BO can be mapped
> in different address space if the BO is globally visible (GEM_FLINK)
> and opened in different context or if the dmabuf is self-imported. The
> current implementation does not take that case into account, and 
> attaches the mapping directly to the panfrost_gem_object.
> 
> Let's create a panfrost_gem_mapping struct and allow multiple mappings
> per BO.
> 
> The mappings are refcounted which helps solve another problem where
> mappings were torn down (GEM handle closed by userspace) while GPU
> jobs accessing those BOs were still in-flight. Jobs now keep a
> reference on the mappings they use.
> 
> v2 (robh):
> - Minor review comment clean-ups from Steven
> - Use list_is_singular helper
> - Just WARN if we add a mapping when madvise state is not WILLNEED.
>   With that, drop the use of object_name_lock.
> 
> Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> Cc: 
> Signed-off-by: Boris Brezillon 
> Signed-off-by: Rob Herring 
> ---
> I've hacked up IGT prime_self_import test to run on panfrost other than 
> the 2 test which depend on i915 debugfs files (export-vs-gem_close-race, 
> reimport-vs-gem_close-race). With this patch, they now pass.
> 
> I'm not adding the test to IGT which is just a copy-n-paste of the 
> original except for different wrappers for BO alloc and mmap. That 
> should be fixed first IMO.
> 
> Rob
> 
>  drivers/gpu/drm/panfrost/panfrost_drv.c   |  91 +++--
>  drivers/gpu/drm/panfrost/panfrost_gem.c   | 123 +++---
>  drivers/gpu/drm/panfrost/panfrost_gem.h   |  41 +-
>  .../gpu/drm/panfrost/panfrost_gem_shrinker.c  |   3 +-
>  drivers/gpu/drm/panfrost/panfrost_job.c   |  13 +-
>  drivers/gpu/drm/panfrost/panfrost_job.h   |   1 +
>  drivers/gpu/drm/panfrost/panfrost_mmu.c   |  61 +
>  drivers/gpu/drm/panfrost/panfrost_mmu.h   |   6 +-
>  drivers/gpu/drm/panfrost/panfrost_perfcnt.c   |  34 +++--
>  9 files changed, 299 insertions(+), 74 deletions(-)
> 



> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c 
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index fd766b1395fb..3a7862e3e775 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -29,6 +29,12 @@ static void panfrost_gem_free_object(struct drm_gem_object 
> *obj)
>   list_del_init(&bo->base.madv_list);
>   mutex_unlock(&pfdev->shrinker_lock);
>  
> + /*
> +  * If we still have mappings attached to the BO, there's a problem in
> +  * our refcounting.
> +  */
> + WARN_ON_ONCE(!list_empty(&bo->mappings.list));
> +
>   if (bo->sgts) {
>   int i;
>   int n_sgt = bo->base.base.size / SZ_2M;
> @@ -46,6 +52,68 @@ static void panfrost_gem_free_object(struct drm_gem_object 
> *obj)
>   drm_gem_shmem_free_object(obj);
>  }
>  
> +struct panfrost_gem_mapping *
> +panfrost_gem_mapping_get(struct panfrost_gem_object *bo,
> +  struct panfrost_file_priv *priv)
> +{
> + struct panfrost_gem_mapping *iter;
> +
> + mutex_lock(&bo->mappings.lock);
> + list_for_each_entry(iter, &bo->mappings.list, node) {
> + if (iter->mmu == &priv->mmu) {
> + kref_get(&iter->refcount);
> + break;
> + }
> + }
> + mutex_unlock(&bo->mappings.lock);
> +
> + return iter;

If the entry isn't found then iter will equal
container_of(&bo->mappings.list, struct panfrost_gem_mapping, node) -
but you actually want a NULL return in this case.

I also think the previous version with a "member" variable being
returned was clearer.

Thanks,

Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/shmem: add support for per object caching attributes

[Thomas Zimmermann]

Hi

Am 11.12.19 um 13:36 schrieb Daniel Vetter:
> 
> The udl use-case should be covered already, simply set the flag correctly
> at create/import time? It's per-object ...

The original udl gem code did this. It was additional state for
something that was detectable from the value of import_attach. So udl
now overrides vmap and mmap.


> btw on why udl does this: Imported bo are usually rendered by real hw, and
> reading it uncached/wc is the more defensive setting. It would be kinda
> nice if dma-buf would expose this, but I fear dma-api maintainers would
> murder us if we even just propose that ... so it's a mess right now.

Yeah, in some way it's a variation of the discussion around fbdev memory
access that we had before.

Best regards
Thomas

> 
> btw the issue extends to dma access by devices too, e.g. both i915 and
> amdgpu can select the coherency mode at runtime (using e.g. the pcie
> no-snoop transaction mode), and we have similar uncoordinated hacks in
> there too, like in udl.
> -Daniel
> 
>>
>> Acked-by: Thomas Zimmermann 
>>
>> if you prefer to merge v1.
>>
>>>
>>> Best regards
>>> Thomas
>>>

>>>
>>
>> -- 
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>> (HRB 36809, AG Nürnberg)
>> Geschäftsführer: Felix Imendörffer
>>
> 
> 
> 
> 
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/4] drm: add pgprot callback to drm_gem_object_funcs

[Gerd Hoffmann]

> > +   /**
> > +* @pgprot:
> > +*
> > +* Tweak pgprot as needed, typically used to set cache bits.
> > +*
> > +* This callback is optional.
> > +*
> > +* If unset drm_gem_pgprot_wc() will be used.
> > +*/
> > +   pgprot_t (*pgprot)(struct drm_gem_object *obj, pgprot_t prot);
> 
> I kinda prefer v1, mostly because this is a huge can of worms, and solving
> this properly is going to be real hard (and will necessarily involve
> dma-buf and dma-api and probably more). Charging ahead here just risks
> that we dig ourselves into a corner. You're v1 is maybe not the most
> clean, but just a few code bits here&there should be more flexible and
> easier to hack on and experiment around with.

Hmm.  Second vote for v1.

Problem with v1 is that it covers mmap() only, not vmap() ...

cheers,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/shmem: add support for per object caching attributes

[Gerd Hoffmann]

  Hi,

> btw on why udl does this: Imported bo are usually rendered by real hw, and
> reading it uncached/wc is the more defensive setting. It would be kinda
> nice if dma-buf would expose this, but I fear dma-api maintainers would
> murder us if we even just propose that ... so it's a mess right now.

I suspect for imported dma-bufs we should leave the mmap() to the
exporter instead of pulling the pages out of the sgt and map them
ourself.

> btw the issue extends to dma access by devices too, e.g. both i915 and
> amdgpu can select the coherency mode at runtime (using e.g. the pcie
> no-snoop transaction mode), and we have similar uncoordinated hacks in
> there too, like in udl.

Hmm.  Ok.  I guess I'm not going to try solve all that properly just for
the little virtio fix.

Just curious:  How do you tell your hardware?  Are there bits for that
in the gtt, simliar to the caching bits in the x86 page tables?

cheers,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/4] drm: add pgprot callback to drm_gem_object_funcs

[Thomas Zimmermann]

Hi

Am 11.12.19 um 13:38 schrieb Daniel Vetter:
> On Wed, Dec 11, 2019 at 01:19:53PM +0100, Gerd Hoffmann wrote:
>> The callback allows drivers and helpers to tweak pgprot for mappings.
>> This is especially helpful when using shmem helpers.  It allows drivers
>> to switch mappings from writecombine (default) to something else (cached
>> for example) on a per-object base without having to supply their own
>> mmap() and vmap() functions.
>>
>> The patch also adds two implementations for the callback, for cached and
>> writecombine mappings, and the drm_gem_pgprot() function to update
>> pgprot for a given object, using the new &drm_gem_object_funcs.pgprot
>> callback if available.
>>
>> Signed-off-by: Gerd Hoffmann 
>> ---
>>  include/drm/drm_gem.h | 15 +
>>  drivers/gpu/drm/drm_gem.c | 46 ++-
>>  2 files changed, 60 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>> index 0b375069cd48..5beef7226e69 100644
>> --- a/include/drm/drm_gem.h
>> +++ b/include/drm/drm_gem.h
>> @@ -163,6 +163,17 @@ struct drm_gem_object_funcs {
>>   */
>>  int (*mmap)(struct drm_gem_object *obj, struct vm_area_struct *vma);
>>  
>> +/**
>> + * @pgprot:
>> + *
>> + * Tweak pgprot as needed, typically used to set cache bits.
>> + *
>> + * This callback is optional.
>> + *
>> + * If unset drm_gem_pgprot_wc() will be used.
>> + */
>> +pgprot_t (*pgprot)(struct drm_gem_object *obj, pgprot_t prot);
> 
> I kinda prefer v1, mostly because this is a huge can of worms, and solving
> this properly is going to be real hard (and will necessarily involve
> dma-buf and dma-api and probably more). Charging ahead here just risks
> that we dig ourselves into a corner. You're v1 is maybe not the most
> clean, but just a few code bits here&there should be more flexible and
> easier to hack on and experiment around with.
> -Daniel

I agree; at least patch v1 is known to be a sound approach. The others
might fall on our feet at some point. Sorry, Gerd, if my proposals added
lots of work for you.

Best regards
Thomas

> 
>> +
>>  /**
>>   * @vm_ops:
>>   *
>> @@ -350,6 +361,10 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, 
>> unsigned long obj_size,
>>   struct vm_area_struct *vma);
>>  int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
>>  
>> +pgprot_t drm_gem_pgprot_cached(struct drm_gem_object *obj, pgprot_t prot);
>> +pgprot_t drm_gem_pgprot_wc(struct drm_gem_object *obj, pgprot_t prot);
>> +pgprot_t drm_gem_pgprot(struct drm_gem_object *obj, pgprot_t prot);
>> +
>>  /**
>>   * drm_gem_object_get - acquire a GEM buffer object reference
>>   * @obj: GEM buffer object
>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>> index 56f42e0f2584..1c468fe8e342 100644
>> --- a/drivers/gpu/drm/drm_gem.c
>> +++ b/drivers/gpu/drm/drm_gem.c
>> @@ -1119,7 +1119,8 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, 
>> unsigned long obj_size,
>>  return -EINVAL;
>>  
>>  vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | 
>> VM_DONTDUMP;
>> -vma->vm_page_prot = 
>> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
>> +vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>> +vma->vm_page_prot = drm_gem_pgprot(obj, vma->vm_page_prot);
>>  vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>>  }
>>  
>> @@ -1210,6 +1211,49 @@ int drm_gem_mmap(struct file *filp, struct 
>> vm_area_struct *vma)
>>  }
>>  EXPORT_SYMBOL(drm_gem_mmap);
>>  
>> +/**
>> + * drm_gem_mmap - update pgprot for objects needing a cachable mapping.
>> + * @obj: the GEM object.
>> + * @prot: page attributes.
>> + *
>> + * This function can be used as &drm_gem_object_funcs.pgprot callback.
>> + */
>> +pgprot_t drm_gem_pgprot_cached(struct drm_gem_object *obj, pgprot_t prot)
>> +{
>> +return prot;
>> +}
>> +EXPORT_SYMBOL(drm_gem_pgprot_cached);
>> +
>> +/**
>> + * drm_gem_mmap - update pgprot for objects needing a wc mapping.
>> + * @obj: the GEM object.
>> + * @prot: page attributes.
>> + *
>> + * This function can be used as &drm_gem_object_funcs.pgprot callback.
>> + */
>> +pgprot_t drm_gem_pgprot_wc(struct drm_gem_object *obj, pgprot_t prot)
>> +{
>> +return pgprot_writecombine(prot);
>> +}
>> +EXPORT_SYMBOL(drm_gem_pgprot_wc);
>> +
>> +/**
>> + * drm_gem_mmap - update pgprot for a given gem object.
>> + * @obj: the GEM object.
>> + * @prot: page attributes.
>> + *
>> + * This function updates pgprot according to the needs of the given
>> + * object.  If present &drm_gem_object_funcs.pgprot callback will be
>> + * used, otherwise drm_gem_pgprot_wc() is called.
>> + */
>> +pgprot_t drm_gem_pgprot(struct drm_gem_object *obj, pgprot_t prot)
>> +{
>> +if (obj->funcs->pgprot)
>> +return obj->funcs->pgprot(obj, prot);
>> +return drm_gem_pgprot_wc(obj, prot);
>> +}
>> +EXPO

Re: [PATCH v2] drm/panfrost: Add the panfrost_gem_mapping concept

[Rob Herring]

On Wed, Dec 11, 2019 at 6:38 AM Steven Price  wrote:
>
> On 10/12/2019 23:08, Rob Herring wrote:
> > From: Boris Brezillon 
> >
> > With the introduction of per-FD address space, the same BO can be mapped
> > in different address space if the BO is globally visible (GEM_FLINK)
> > and opened in different context or if the dmabuf is self-imported. The
> > current implementation does not take that case into account, and
> > attaches the mapping directly to the panfrost_gem_object.
> >
> > Let's create a panfrost_gem_mapping struct and allow multiple mappings
> > per BO.
> >
> > The mappings are refcounted which helps solve another problem where
> > mappings were torn down (GEM handle closed by userspace) while GPU
> > jobs accessing those BOs were still in-flight. Jobs now keep a
> > reference on the mappings they use.
> >
> > v2 (robh):
> > - Minor review comment clean-ups from Steven
> > - Use list_is_singular helper
> > - Just WARN if we add a mapping when madvise state is not WILLNEED.
> >   With that, drop the use of object_name_lock.
> >
> > Fixes: a5efb4c9a562 ("drm/panfrost: Restructure the GEM object creation")
> > Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> > Cc: 
> > Signed-off-by: Boris Brezillon 
> > Signed-off-by: Rob Herring 
> > ---
> > I've hacked up IGT prime_self_import test to run on panfrost other than
> > the 2 test which depend on i915 debugfs files (export-vs-gem_close-race,
> > reimport-vs-gem_close-race). With this patch, they now pass.
> >
> > I'm not adding the test to IGT which is just a copy-n-paste of the
> > original except for different wrappers for BO alloc and mmap. That
> > should be fixed first IMO.
> >
> > Rob
> >
> >  drivers/gpu/drm/panfrost/panfrost_drv.c   |  91 +++--
> >  drivers/gpu/drm/panfrost/panfrost_gem.c   | 123 +++---
> >  drivers/gpu/drm/panfrost/panfrost_gem.h   |  41 +-
> >  .../gpu/drm/panfrost/panfrost_gem_shrinker.c  |   3 +-
> >  drivers/gpu/drm/panfrost/panfrost_job.c   |  13 +-
> >  drivers/gpu/drm/panfrost/panfrost_job.h   |   1 +
> >  drivers/gpu/drm/panfrost/panfrost_mmu.c   |  61 +
> >  drivers/gpu/drm/panfrost/panfrost_mmu.h   |   6 +-
> >  drivers/gpu/drm/panfrost/panfrost_perfcnt.c   |  34 +++--
> >  9 files changed, 299 insertions(+), 74 deletions(-)
> >
>
> 
>
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c 
> > b/drivers/gpu/drm/panfrost/panfrost_gem.c
> > index fd766b1395fb..3a7862e3e775 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> > @@ -29,6 +29,12 @@ static void panfrost_gem_free_object(struct 
> > drm_gem_object *obj)
> >   list_del_init(&bo->base.madv_list);
> >   mutex_unlock(&pfdev->shrinker_lock);
> >
> > + /*
> > +  * If we still have mappings attached to the BO, there's a problem in
> > +  * our refcounting.
> > +  */
> > + WARN_ON_ONCE(!list_empty(&bo->mappings.list));
> > +
> >   if (bo->sgts) {
> >   int i;
> >   int n_sgt = bo->base.base.size / SZ_2M;
> > @@ -46,6 +52,68 @@ static void panfrost_gem_free_object(struct 
> > drm_gem_object *obj)
> >   drm_gem_shmem_free_object(obj);
> >  }
> >
> > +struct panfrost_gem_mapping *
> > +panfrost_gem_mapping_get(struct panfrost_gem_object *bo,
> > +  struct panfrost_file_priv *priv)
> > +{
> > + struct panfrost_gem_mapping *iter;
> > +
> > + mutex_lock(&bo->mappings.lock);
> > + list_for_each_entry(iter, &bo->mappings.list, node) {
> > + if (iter->mmu == &priv->mmu) {
> > + kref_get(&iter->refcount);
> > + break;
> > + }
> > + }
> > + mutex_unlock(&bo->mappings.lock);
> > +
> > + return iter;
>
> If the entry isn't found then iter will equal
> container_of(&bo->mappings.list, struct panfrost_gem_mapping, node) -
> but you actually want a NULL return in this case.

Ugg, yes. I knew that...

> I also think the previous version with a "member" variable being
> returned was clearer.

I over interpreted what you were suggesting. Will change it back and
*just* add the break.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gma500: globle no more!

[Jani Nikula]

On Wed, 11 Dec 2019, Daniel Vetter  wrote:
> globle, goblin, moblin?
>
> It's dead code, we lucked out.

Oh, sad to see it go. The oldest reference to globle_dev I could find
was from 2011.

Acked-by: Jani Nikula 

>
> Cc: Ville Syrjälä 
> Cc: Jani Nikula 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/gma500/mdfld_intel_display.c | 23 
>  1 file changed, 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/mdfld_intel_display.c 
> b/drivers/gpu/drm/gma500/mdfld_intel_display.c
> index b8bfb96008b8..4fff110c4921 100644
> --- a/drivers/gpu/drm/gma500/mdfld_intel_display.c
> +++ b/drivers/gpu/drm/gma500/mdfld_intel_display.c
> @@ -113,27 +113,6 @@ static int psb_intel_panel_fitter_pipe(struct drm_device 
> *dev)
>   return (pfit_control >> 29) & 0x3;
>  }
>  
> -static struct drm_device globle_dev;
> -
> -void mdfld__intel_plane_set_alpha(int enable)
> -{
> - struct drm_device *dev = &globle_dev;
> - int dspcntr_reg = DSPACNTR;
> - u32 dspcntr;
> -
> - dspcntr = REG_READ(dspcntr_reg);
> -
> - if (enable) {
> - dspcntr &= ~DISPPLANE_32BPP_NO_ALPHA;
> - dspcntr |= DISPPLANE_32BPP;
> - } else {
> - dspcntr &= ~DISPPLANE_32BPP;
> - dspcntr |= DISPPLANE_32BPP_NO_ALPHA;
> - }
> -
> - REG_WRITE(dspcntr_reg, dspcntr);
> -}
> -
>  static int check_fb(struct drm_framebuffer *fb)
>  {
>   if (!fb)
> @@ -164,8 +143,6 @@ static int mdfld__intel_pipe_set_base(struct drm_crtc 
> *crtc, int x, int y,
>   u32 dspcntr;
>   int ret;
>  
> - memcpy(&globle_dev, dev, sizeof(struct drm_device));
> -
>   dev_dbg(dev->dev, "pipe = 0x%x.\n", pipe);
>  
>   /* no fb bound */

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5.4 55/92] drm: damage_helper: Fix race checking plane->state->fb

[Greg Kroah-Hartman]

From: Sean Paul 

commit 354c2d310082d1c384213ba76c3757dd3cd8755d upstream.

Since the dirtyfb ioctl doesn't give us any hints as to which plane is
scanning out the fb it's marking as damaged, we need to loop through
planes to find it.

Currently we just reach into plane state and check, but that can race
with another commit changing the fb out from under us. This patch locks
the plane before checking the fb and will release the lock if the plane
is not displaying the dirty fb.

Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb")
Cc: Rob Clark 
Cc: Deepak Rawat 
Cc: Daniel Vetter 
Cc: Thomas Hellstrom 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.0+
Reported-by: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190904202938.110207-1-s...@poorly.run
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/drm_damage_helper.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -212,8 +212,14 @@ retry:
drm_for_each_plane(plane, fb->dev) {
struct drm_plane_state *plane_state;
 
-   if (plane->state->fb != fb)
+   ret = drm_modeset_lock(&plane->mutex, state->acquire_ctx);
+   if (ret)
+   goto out;
+
+   if (plane->state->fb != fb) {
+   drm_modeset_unlock(&plane->mutex);
continue;
+   }
 
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH AUTOSEL 5.4 109/134] drm/amdgpu: Call find_vma under mmap_sem

[Sasha Levin]

From: Jason Gunthorpe 

[ Upstream commit a9ae8731e6e52829a935d81a65d7f925cb95dbac ]

find_vma() must be called under the mmap_sem, reorganize this code to
do the vma check after entering the lock.

Further, fix the unlocked use of struct task_struct's mm, instead use
the mm from hmm_mirror which has an active mm_grab. Also the mm_grab
must be converted to a mm_get before acquiring mmap_sem or calling
find_vma().

Fixes: 66c45500bfdc ("drm/amdgpu: use new HMM APIs and helpers")
Fixes: 0919195f2b0d ("drm/amdgpu: Enable amdgpu_ttm_tt_get_user_pages in worker 
threads")
Link: https://lore.kernel.org/r/20191112202231.3856-11-...@ziepe.ca
Acked-by: Christian König 
Reviewed-by: Felix Kuehling 
Reviewed-by: Philip Yang 
Tested-by: Philip Yang 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 37 ++---
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dff41d0a85fe9..c0e41f1f0c236 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -788,7 +789,7 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, 
struct page **pages)
struct hmm_mirror *mirror = bo->mn ? &bo->mn->mirror : NULL;
struct ttm_tt *ttm = bo->tbo.ttm;
struct amdgpu_ttm_tt *gtt = (void *)ttm;
-   struct mm_struct *mm = gtt->usertask->mm;
+   struct mm_struct *mm;
unsigned long start = gtt->userptr;
struct vm_area_struct *vma;
struct hmm_range *range;
@@ -796,25 +797,14 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, 
struct page **pages)
uint64_t *pfns;
int r = 0;
 
-   if (!mm) /* Happens during process shutdown */
-   return -ESRCH;
-
if (unlikely(!mirror)) {
DRM_DEBUG_DRIVER("Failed to get hmm_mirror\n");
-   r = -EFAULT;
-   goto out;
+   return -EFAULT;
}
 
-   vma = find_vma(mm, start);
-   if (unlikely(!vma || start < vma->vm_start)) {
-   r = -EFAULT;
-   goto out;
-   }
-   if (unlikely((gtt->userflags & AMDGPU_GEM_USERPTR_ANONONLY) &&
-   vma->vm_file)) {
-   r = -EPERM;
-   goto out;
-   }
+   mm = mirror->hmm->mmu_notifier.mm;
+   if (!mmget_not_zero(mm)) /* Happens during process shutdown */
+   return -ESRCH;
 
range = kzalloc(sizeof(*range), GFP_KERNEL);
if (unlikely(!range)) {
@@ -847,6 +837,17 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, 
struct page **pages)
hmm_range_wait_until_valid(range, HMM_RANGE_DEFAULT_TIMEOUT);
 
down_read(&mm->mmap_sem);
+   vma = find_vma(mm, start);
+   if (unlikely(!vma || start < vma->vm_start)) {
+   r = -EFAULT;
+   goto out_unlock;
+   }
+   if (unlikely((gtt->userflags & AMDGPU_GEM_USERPTR_ANONONLY) &&
+   vma->vm_file)) {
+   r = -EPERM;
+   goto out_unlock;
+   }
+
r = hmm_range_fault(range, 0);
up_read(&mm->mmap_sem);
 
@@ -865,15 +866,19 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, 
struct page **pages)
}
 
gtt->range = range;
+   mmput(mm);
 
return 0;
 
+out_unlock:
+   up_read(&mm->mmap_sem);
 out_free_pfns:
hmm_range_unregister(range);
kvfree(pfns);
 out_free_ranges:
kfree(range);
 out:
+   mmput(mm);
return r;
 }
 
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5.3 073/105] drm: damage_helper: Fix race checking plane->state->fb

[Greg Kroah-Hartman]

From: Sean Paul 

commit 354c2d310082d1c384213ba76c3757dd3cd8755d upstream.

Since the dirtyfb ioctl doesn't give us any hints as to which plane is
scanning out the fb it's marking as damaged, we need to loop through
planes to find it.

Currently we just reach into plane state and check, but that can race
with another commit changing the fb out from under us. This patch locks
the plane before checking the fb and will release the lock if the plane
is not displaying the dirty fb.

Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb")
Cc: Rob Clark 
Cc: Deepak Rawat 
Cc: Daniel Vetter 
Cc: Thomas Hellstrom 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.0+
Reported-by: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190904202938.110207-1-s...@poorly.run
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/drm_damage_helper.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -212,8 +212,14 @@ retry:
drm_for_each_plane(plane, fb->dev) {
struct drm_plane_state *plane_state;
 
-   if (plane->state->fb != fb)
+   ret = drm_modeset_lock(&plane->mutex, state->acquire_ctx);
+   if (ret)
+   goto out;
+
+   if (plane->state->fb != fb) {
+   drm_modeset_unlock(&plane->mutex);
continue;
+   }
 
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Increase size of VDB and CMDB bitmaps to 256 bits

[Ville Syrjälä]

On Tue, Dec 10, 2019 at 02:10:48PM -0800, Thomas Anderson wrote:
> CEA-861-G adds modes up to 219, so increase the size of the
> maps in preparation for adding the new modes to drm_edid.c.
> 
> Signed-off-by: Thomas Anderson 

Thanks. lgtm. Pushed to drm-misc-next.

PS. I do wonder a bit if we should consider a more economical way to
track this stuff. Not really sure how many bits we can realistically
expect to be set in these bitmasks...

> ---
>  include/drm/drm_connector.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 5f8c3389d46f..17b728d9c73d 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -188,19 +188,19 @@ struct drm_hdmi_info {
>  
>   /**
>* @y420_vdb_modes: bitmap of modes which can support ycbcr420
> -  * output only (not normal RGB/YCBCR444/422 outputs). There are total
> -  * 107 VICs defined by CEA-861-F spec, so the size is 128 bits to map
> -  * upto 128 VICs;
> +  * output only (not normal RGB/YCBCR444/422 outputs). The max VIC
> +  * defined by the CEA-861-G spec is 219, so the size is 256 bits to map
> +  * up to 256 VICs.
>*/
> - unsigned long y420_vdb_modes[BITS_TO_LONGS(128)];
> + unsigned long y420_vdb_modes[BITS_TO_LONGS(256)];
>  
>   /**
>* @y420_cmdb_modes: bitmap of modes which can support ycbcr420
> -  * output also, along with normal HDMI outputs. There are total 107
> -  * VICs defined by CEA-861-F spec, so the size is 128 bits to map upto
> -  * 128 VICs;
> +  * output also, along with normal HDMI outputs. The max VIC defined by
> +  * the CEA-861-G spec is 219, so the size is 256 bits to map up to 256
> +  * VICs.
>*/
> - unsigned long y420_cmdb_modes[BITS_TO_LONGS(128)];
> + unsigned long y420_cmdb_modes[BITS_TO_LONGS(256)];
>  
>   /** @y420_cmdb_map: bitmap of SVD index, to extraxt vcb modes */
>   u64 y420_cmdb_map;
> -- 
> 2.24.0.525.g8f36a354ae-goog

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm v4] modetest: Use floating vrefresh while dumping mode

[Ville Syrjälä]

On Tue, Dec 03, 2019 at 06:37:36AM -0800, Devarsh Thakkar wrote:
> Add function to derive floating value of vertical
> refresh rate from drm mode using pixel clock,
> horizontal total size and vertical total size.
> 
> Use this function to find suitable mode having vrefresh
> value which is matching with user provided vrefresh value.
> 
> If user doesn't provide any vrefresh value in args then
> update vertical refresh rate value in pipe args using this
> function.
> 
> Also use this function for printing floating vrefresh while
> dumping all available modes.
> 
> This will give more accurate picture to user for available modes
> differentiated by floating vertical refresh rate and help user
> select more appropriate mode using suitable refresh rate value.
> 
> V4:
> 1) While setting mode, print mode name and vrefresh using struct
>drmModeModeInfo instead of struct pipe_args.
> 2) Revert back to using a float value instead of float *
>for vrefresh arg in connector_find_mode().
> 
> V3:
> 1) Change name of function used to derive refresh rate.
> 
> V2:
> 1) Don't use inline function for deriving refresh rate from mode.
> 2) If requested mode not found, print refresh rate only
>if user had provided it in args.
> 
> Signed-off-by: Devarsh Thakkar 
> Reviewed-by: Neil Armstrong 

Thanks. lgtm -> pushed to master.

> ---
>  tests/modetest/modetest.c | 35 +++
>  1 file changed, 23 insertions(+), 12 deletions(-)
> 
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index b4edfcb..e998e8e 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -133,6 +133,12 @@ static inline int64_t U642I64(uint64_t val)
>   return (int64_t)*((int64_t *)&val);
>  }
>  
> +static float mode_vrefresh(drmModeModeInfo *mode)
> +{
> + return  mode->clock * 1000.00
> + / (mode->htotal * mode->vtotal);
> +}
> +
>  #define bit_name_fn(res) \
>  const char * res##_str(int type) {   \
>   unsigned int i; \
> @@ -210,9 +216,9 @@ static void dump_encoders(struct device *dev)
>  
>  static void dump_mode(drmModeModeInfo *mode)
>  {
> - printf("  %s %d %d %d %d %d %d %d %d %d %d",
> + printf("  %s %.2f %d %d %d %d %d %d %d %d %d",
>  mode->name,
> -mode->vrefresh,
> +mode_vrefresh(mode),
>  mode->hdisplay,
>  mode->hsync_start,
>  mode->hsync_end,
> @@ -828,7 +834,6 @@ connector_find_mode(struct device *dev, uint32_t con_id, 
> const char *mode_str,
>   drmModeConnector *connector;
>   drmModeModeInfo *mode;
>   int i;
> - float mode_vrefresh;
>  
>   connector = get_connector_by_id(dev, con_id);
>   if (!connector || !connector->count_modes)
> @@ -837,15 +842,14 @@ connector_find_mode(struct device *dev, uint32_t 
> con_id, const char *mode_str,
>   for (i = 0; i < connector->count_modes; i++) {
>   mode = &connector->modes[i];
>   if (!strcmp(mode->name, mode_str)) {
> - /* If the vertical refresh frequency is not specified 
> then return the
> -  * first mode that match with the name. Else, return 
> the mode that match
> -  * the name and the specified vertical refresh 
> frequency.
> + /* If the vertical refresh frequency is not specified
> +  * then return the first mode that match with the name.
> +  * Else, return the mode that match the name and
> +  * the specified vertical refresh frequency.
>*/
> - mode_vrefresh = mode->clock * 1000.00
> - / (mode->htotal * mode->vtotal);
>   if (vrefresh == 0)
>   return mode;
> - else if (fabs(mode_vrefresh - vrefresh) < 0.005)
> + else if (fabs(mode_vrefresh(mode) - vrefresh) < 0.005)
>   return mode;
>   }
>   }
> @@ -911,7 +915,13 @@ static int pipe_find_crtc_and_mode(struct device *dev, 
> struct pipe_arg *pipe)
>   mode = connector_find_mode(dev, pipe->con_ids[i],
>  pipe->mode_str, pipe->vrefresh);
>   if (mode == NULL) {
> - fprintf(stderr,
> + if (pipe->vrefresh)
> + fprintf(stderr,
> + "failed to find mode "
> + "\"%s-%.2fHz\" for connector %s\n",
> + pipe->mode_str, pipe->vrefresh, pipe->cons[i]);
> + else
> + fprintf(stderr,
>   "failed to find mode \"%s\" for connector %s\n",
>   p

Re: [PATCH v2] video: hdmi: indicate applicability in avi infoframe log

[Ville Syrjälä]

On Wed, Dec 11, 2019 at 10:48:42AM +0100, Johan Korsnes wrote:
> When logging the AVI InfoFrame, clearly indicate whether or not
> attributes are active/"in effect". The specification is given in
> CTA-861-G Section 6.4: Format of Version 2, 3 & 4 AVI InfoFrames.
> 
> Attribute BytesRequirement
> Ext. Colorimetry  EC0..EC2 Colorimetry (C0,C1) set to Extended.
> IT Contents Type  CN0,CN1  IT Content (ITC) set to True.
> RGB Quant. Range  Q0,Q1Color Space (Y0..Y2) set to RGB.
> YCC Quant. Range  YQ0,YQ1  Color space (Y0..Y2) set to YCbCr.
> 
> Example log output with patch applied:
> HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13
> colorspace: RGB
> scan mode: No Data
> colorimetry: ITU709
> picture aspect: 16:9
> active aspect: Same as Picture
> itc: IT Content
> extended colorimetry: N/A (0x0)
> quantization range: Full
> nups: Unknown Non-uniform Scaling
> video code: 16
> ycc quantization range: N/A (0x0)
> hdmi content type: Graphics
> pixel repeat: 0
> bar top 0, bottom 0, left 0, right 0
> 
> Signed-off-by: Johan Korsnes 
> Cc: Hans Verkuil 
> Cc: Martin Bugge 
> 
> ---
> v1 -> v2:
>  * Indicate applicability not only for ext. colorimetry
> ---
>  drivers/video/hdmi.c | 40 
>  1 file changed, 32 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 9c82e2a0a411..491a77b28a9b 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -1209,16 +1209,40 @@ static void hdmi_avi_infoframe_log(const char *level,
>   hdmi_log("active aspect: %s\n",
>   hdmi_active_aspect_get_name(frame->active_aspect));
>   hdmi_log("itc: %s\n", frame->itc ? "IT Content" : "No Data");
> - hdmi_log("extended colorimetry: %s\n",
> - 
> hdmi_extended_colorimetry_get_name(frame->extended_colorimetry));
> - hdmi_log("quantization range: %s\n",
> - 
> hdmi_quantization_range_get_name(frame->quantization_range));
> +
> + if (frame->colorimetry == HDMI_COLORIMETRY_EXTENDED)
> + hdmi_log("extended colorimetry: %s\n",
> +  
> hdmi_extended_colorimetry_get_name(frame->extended_colorimetry));
> + else
> + hdmi_log("extended colorimetry: N/A (0x%x)\n",
> +  frame->extended_colorimetry);
> +
> + if (frame->colorspace == HDMI_COLORSPACE_RGB)
> + hdmi_log("quantization range: %s\n",
> +  
> hdmi_quantization_range_get_name(frame->quantization_range));
> + else
> + hdmi_log("quantization range: N/A (0x%x)\n",
> +  frame->quantization_range);
> +
>   hdmi_log("nups: %s\n", hdmi_nups_get_name(frame->nups));
>   hdmi_log("video code: %u\n", frame->video_code);
> - hdmi_log("ycc quantization range: %s\n",
> - 
> hdmi_ycc_quantization_range_get_name(frame->ycc_quantization_range));
> - hdmi_log("hdmi content type: %s\n",
> - hdmi_content_type_get_name(frame->content_type));
> +
> + if (frame->colorspace == HDMI_COLORSPACE_YUV422 ||
> + frame->colorspace == HDMI_COLORSPACE_YUV444 ||
> + frame->colorspace == HDMI_COLORSPACE_YUV420)

ocd nit: order 444||422||420 or 420||422||444

> + hdmi_log("ycc quantization range: %s\n",
> +  
> hdmi_ycc_quantization_range_get_name(frame->ycc_quantization_range));
> + else
> + hdmi_log("ycc quantization range: N/A (0x%x)\n",
> +  frame->ycc_quantization_range);

CTA-861-G does recommend that we set YQ to match Q when trasmitting
RGB. So not sure "N/A" is entirely accurate here. However we also
found out that following that recommendation did break some crappy
sinks which get confused when they see RGB + YQ!=0. So now we follow
that recommendation only for HDMI 2.0+ sinks. Anyways, as long as the
raw value is present I guess we can stil spot such cases from the logs.

Reviewed-by: Ville Syrjälä 

> +
> + if (frame->itc)
> + hdmi_log("hdmi content type: %s\n",
> +  hdmi_content_type_get_name(frame->content_type));
> + else
> + hdmi_log("hdmi content type: N/A (0x%x)\n",
> +  frame->content_type);
> +
>   hdmi_log("pixel repeat: %u\n", frame->pixel_repeat);
>   hdmi_log("bar top %u, bottom %u, left %u, right %u\n",
>   frame->top_bar, frame->bottom_bar,
> -- 
> 2.23.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/l

Re: [PATCH][next] drm/i915: remove redundant checks for a null fb pointer

[Ville Syrjälä]

On Tue, Dec 10, 2019 at 02:23:49PM +, Colin King wrote:
> From: Colin Ian King 
> 
> A prior check and return when pointer fb is null makes
> subsequent null checks on fb redundant.  Remove the redundant
> null checks.
> 
> Addresses-Coverity: ("Logically dead code")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 062e5bef637a..a48478be6e8f 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2600,8 +2600,8 @@ static void intel_plane_hw_info(struct seq_file *m, 
> struct intel_plane *plane)
>  plane_state->hw.rotation);
>  
>   seq_printf(m, "\t\thw: fb=%d,%s,%dx%d, visible=%s, src=" 
> DRM_RECT_FP_FMT ", dst=" DRM_RECT_FMT ", rotation=%s\n",
> -fb ? fb->base.id : 0, fb ? format_name.str : "n/a",
> -fb ? fb->width : 0, fb ? fb->height : 0,
> +fb->base.id, format_name.str,
> +fb->width, fb->height,

Thanks.

Pushed to drm-intel-next-queued.

>  yesno(plane_state->uapi.visible),
>  DRM_RECT_FP_ARG(&plane_state->uapi.src),
>  DRM_RECT_ARG(&plane_state->uapi.dst),
> -- 
> 2.24.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] drm/i915/display: remove duplicated assignment to pointer crtc_state

[Ville Syrjälä]

On Tue, Dec 10, 2019 at 02:45:35PM +, Colin King wrote:
> From: Colin Ian King 
> 
> Pointer crtc_state is being assigned twice, one of these is redundant
> and can be removed.
> 
> Addresses-Coverity: ("Evaluation order violation")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5c50b7d2db25..f3389d315b19 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -17751,7 +17751,7 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
>  
>   for_each_intel_crtc(&dev_priv->drm, crtc) {
>   struct intel_crtc_state *crtc_state =
> - crtc_state = to_intel_crtc_state(crtc->base.state);
> + to_intel_crtc_state(crtc->base.state);

Thanks.

Pushed to drm-intel-next-queued.

>  
>   intel_sanitize_crtc(crtc, ctx);
>   intel_dump_pipe_config(crtc_state, NULL, "[setup_hw_state]");
> -- 
> 2.24.0

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp_mst: clear time slots for ports invalid

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v5.4.2, v5.3.15, v4.19.88, v4.14.158, 
v4.9.206, v4.4.206.

v5.4.2: Failed to apply! Possible dependencies:
14692a3637d4 ("drm/dp_mst: Add probe_lock")
37dfdc55ffeb ("drm/dp_mst: Cleanup drm_dp_send_link_address() a bit")
3f9b3f02dda5 ("drm/dp_mst: Protect drm_dp_mst_port members with locking")
50094b5dcd32 ("drm/dp_mst: Destroy topology_mgr mutexes")
5950f0b797fc ("drm/dp_mst: Move link address dumping into a function")
60f9ae9d0d3d ("drm/dp_mst: Remove huge conditional in 
drm_dp_mst_handle_up_req()")
7cb12d48314e ("drm/dp_mst: Destroy MSTBs asynchronously")
9408cc94eb04 ("drm/dp_mst: Handle UP requests asynchronously")
a29d881875fc ("drm/dp_mst: Refactor drm_dp_mst_handle_up_req()")
c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
caf81ec6cd72 ("drm: Destroy the correct mutex name in 
drm_dp_mst_topology_mgr_destroy")
dad7d84f8835 ("drm/dp_mst: Don't forget to update port->input in 
drm_dp_mst_handle_conn_stat()")
e2839ff692c6 ("drm/dp_mst: Rename drm_dp_add_port and drm_dp_update_port")

v5.3.15: Failed to apply! Possible dependencies:
14692a3637d4 ("drm/dp_mst: Add probe_lock")
37dfdc55ffeb ("drm/dp_mst: Cleanup drm_dp_send_link_address() a bit")
3f9b3f02dda5 ("drm/dp_mst: Protect drm_dp_mst_port members with locking")
50094b5dcd32 ("drm/dp_mst: Destroy topology_mgr mutexes")
562836a269e3 ("drm/dp_mst: Enable registration of AUX devices for MST 
ports")
5950f0b797fc ("drm/dp_mst: Move link address dumping into a function")
60f9ae9d0d3d ("drm/dp_mst: Remove huge conditional in 
drm_dp_mst_handle_up_req()")
7cb12d48314e ("drm/dp_mst: Destroy MSTBs asynchronously")
9408cc94eb04 ("drm/dp_mst: Handle UP requests asynchronously")
a29d881875fc ("drm/dp_mst: Refactor drm_dp_mst_handle_up_req()")
c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
caf81ec6cd72 ("drm: Destroy the correct mutex name in 
drm_dp_mst_topology_mgr_destroy")
dad7d84f8835 ("drm/dp_mst: Don't forget to update port->input in 
drm_dp_mst_handle_conn_stat()")
e2839ff692c6 ("drm/dp_mst: Rename drm_dp_add_port and drm_dp_update_port")

v4.19.88: Failed to apply! Possible dependencies:
1e55a53a28d3 ("drm: Trivial comment grammar cleanups")
706246c761dd ("drm/dp_mst: Refactor drm_dp_update_payload_part1()")
72fdb40c1a4b ("drm: extract drm_atomic_uapi.c")
7f4de521001f ("drm/atomic: Add __drm_atomic_helper_plane_reset")
a5ec8332d428 ("drm: Add per-plane pixel blend mode property")
c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
d0757afd00d7 ("drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref 
and friends")
d86552efe10a ("drm/atomic: trim driver interface/docs")
dad7d84f8835 ("drm/dp_mst: Don't forget to update port->input in 
drm_dp_mst_handle_conn_stat()")
de9f8eea5a44 ("drm/atomic_helper: Stop modesets on unregistered connectors 
harder")
ebcc0e6b5091 ("drm/dp_mst: Introduce new refcounting scheme for mstbs and 
ports")
fc63668656bd ("drm/dp_mst: Remove bogus conditional in 
drm_dp_update_payload_part1()")

v4.14.158: Failed to apply! Possible dependencies:
0bb9c2b27f5e ("drm/dp/mst: Sideband message transaction to power up/down 
nodes")
163bcc2c74a2 ("drm/atomic: Move drm_crtc_commit to drm_crtc_state, v4.")
179c02fe90a4 ("drm/tve200: Add new driver for TVE200")
1e55a53a28d3 ("drm: Trivial comment grammar cleanups")
21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by 
tracking commits, v3.")
22a07038c0ea ("drm: NULL pointer dereference [null-pointer-deref] (CWE 476) 
problem")
24557865c8b1 ("drm: Add Content Protection property")
2ed077e467ee ("drm: Add drm_object lease infrastructure [v5]")
34ca26a98ad6 ("drm/atomic_helper: Allow DPMS On<->Off changes for 
unregistered connectors")
0d4cf21b ("drm: add connector info/property for non-desktop displays 
[v2]")
6d544fd6f4e1 ("drm/doc: Put all driver docs into a separate chapter")
706246c761dd ("drm/dp_mst: Refactor drm_dp_update_payload_part1()")
72fdb40c1a4b ("drm: extract drm_atomic_uapi.c")
8d70f395e6cb ("drm: Add support for a panel-orientation connector property, 
v6")
935774cd71fe ("drm: Add writeback connector type")
c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
c76f0f7cb546 ("drm: Begin an API for in-kernel clients")
d0757afd00d7 ("drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref 
and friends")
dad7d84f8835 ("drm/dp_mst: Don't forget to update port->input in 
drm_dp_mst_handle_conn_stat()")
de9f8eea5a44 ("drm/atomic_helper: Stop modesets on unregistered connectors 
harder")
e96550956fbc ("dr

Re: [PATCH] drm/komeda: Correct d71 register block counting

[Mihail Atanassov]

On Tuesday, 10 December 2019 06:10:34 GMT james qian wang (Arm Technology 
China) wrote:
> Per HW, d71->num_blocks includes reserved blocks but no PERIPH block,
> correct the block counting accordingly.
> D71 happens to only have one reserved block and periph block, which
> hides this counting error.
> 
> Signed-off-by: james qian wang (Arm Technology China) 
> 
> ---
>  drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c 
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> index 822b23a1ce75..d53f95dea0a1 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> @@ -414,8 +414,11 @@ static int d71_enum_resources(struct komeda_dev *mdev)
>   d71->pipes[i] = to_d71_pipeline(pipe);
>   }
>  
> - /* loop the register blks and probe */
> - i = 2; /* exclude GCU and PERIPH */
> + /* loop the register blks and probe.
> +  * NOTE: d71->num_blocks includes reserved blocks.
> +  * d71->num_blocks = GCU + valid blocks + reserved blocks
> +  */
> + i = 1; /* exclude GCU */
>   offset = D71_BLOCK_SIZE; /* skip GCU */
>   while (i < d71->num_blocks) {
>   blk_base = mdev->reg_base + (offset >> 2);
> @@ -425,9 +428,9 @@ static int d71_enum_resources(struct komeda_dev *mdev)
>   err = d71_probe_block(d71, &blk, blk_base);
>   if (err)
>   goto err_cleanup;
> - i++;
>   }
>  
> + i++;
>   offset += D71_BLOCK_SIZE;
>   }
>  
> 

Reviewed-by: Mihail Atanassov 

-- 
Mihail



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/komeda: Add basic support for D77

[Mihail Atanassov]

Hi Tiannan,

Thanks for the patch.

On Wednesday, 11 December 2019 10:30:09 GMT Tiannan Zhu (Arm Technology China) 
wrote:
> Make komeda driver can recongise D77, D77 is arm latest display
> product, compare with D71, D77 support some new features:
> 1. Crossbar: adjust every plane's zorder
> 2. ATU: Asynchronous Timewarp Unit, which is used to support VR/AR

I don't think the new features listing is relevant for this patch. I'd just
put a simple wording along the lines of:

Add D77 support via a new DT compatible string. The existing code is
sufficient for basic bring-up.

> 
> Signed-off-by: Tiannan Zhu (Arm Technology China) 
> ---
>  .../gpu/drm/arm/display/include/malidp_product.h  |  1 +
>  .../drm/arm/display/komeda/d71/d71_component.c| 15 +++
>  drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c  |  1 +
>  drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h |  4 
>  drivers/gpu/drm/arm/display/komeda/komeda_drv.c   |  1 +
>  5 files changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h 
> b/drivers/gpu/drm/arm/display/include/malidp_product.h
> index dbd3d4765065..cbde47f06c9f 100644
> --- a/drivers/gpu/drm/arm/display/include/malidp_product.h
> +++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
> @@ -19,6 +19,7 @@
>  
>  /* Mali-display product IDs */
>  #define MALIDP_D71_PRODUCT_ID0x0071
> +#define MALIDP_D77_PRODUCT_ID0x0072
>  #define MALIDP_D32_PRODUCT_ID0x0032
>  
>  union komeda_config_id {
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index c7f7e9c545c7..ec96b69a5ade 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -1347,6 +1347,21 @@ int d71_probe_block(struct d71_dev *d71,
>   d71->glb_scl_coeff_addr[blk_id] = reg;
>   break;
>  
> + case D71_BLK_TYPE_GLB_SC_COEFF:
> + break;
> +
> + case D77_BLK_TYPE_CBU:
> + break;
> +
> + case D77_BLK_TYPE_ATU:
> + break;
> +
> + case D77_BLK_TYPE_ATU_VP:
> + break;
> +
> + case D77_BLK_TYPE_LPU_PERF:
> + break;
> +

I'd omit this from the basic enablement patch since it's effectively dead
code. Add it when you need it.

>   default:
>   DRM_ERROR("Unknown block (block_info: 0x%x) is found\n",
> blk->block_info);
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c 
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> index 2d429e310e5b..7598e4856e0c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> @@ -614,6 +614,7 @@ d71_identify(u32 __iomem *reg_base, struct 
> komeda_chip_info *chip)
>   switch (product_id) {
>   case MALIDP_D71_PRODUCT_ID:
>   case MALIDP_D32_PRODUCT_ID:
> + case MALIDP_D77_PRODUCT_ID:
>   funcs = &d71_chip_funcs;
>   break;
>   default:
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h 
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
> index 81de6a23e7f3..01ea53918cf1 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
> @@ -477,8 +477,11 @@ enum d71_blk_type {
>   D71_BLK_TYPE_PERIPH = 0x08,
>   D71_BLK_TYPE_LPU_TRUSTED= 0x09,
>   D71_BLK_TYPE_AEU_TRUSTED= 0x0A,
> + D77_BLK_TYPE_CBU= 0x0B,
> + D77_BLK_TYPE_ATU= 0x0C,
>   D71_BLK_TYPE_LPU_LAYER  = 0x10,
>   D71_BLK_TYPE_LPU_WB_LAYER   = 0x11,
> + D77_BLK_TYPE_LPU_PERF   = 0x12,
>   D71_BLK_TYPE_CU_SPLITTER= 0x20,
>   D71_BLK_TYPE_CU_SCALER  = 0x21,
>   D71_BLK_TYPE_CU_MERGER  = 0x22,
> @@ -487,6 +490,7 @@ enum d71_blk_type {
>   D71_BLK_TYPE_DOU_FT_COEFF   = 0x32,
>   D71_BLK_TYPE_AEU_DS = 0x40,
>   D71_BLK_TYPE_AEU_AES= 0x41,
> + D77_BLK_TYPE_ATU_VP = 0xC0,

Same for all these block types.

>   D71_BLK_TYPE_RESERVED   = 0xFF
>  };
>  
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index ad38bbc7431e..3ac6b43beb2c 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -126,6 +126,7 @@ static int komeda_platform_remove(struct platform_device 
> *pdev)
>  static const struct of_device_id komeda_of_match[] = {
>   { .compatible = "arm,mali-d71", .data = d71_identify, },
>   { .compatible = "arm,mali-d32", .data = d71_identify, },
> + { .compatible = "arm,mali-d77", .data = d71_identify, },
>   {},
>  };
>  
> 


-- 
Mihail



___
dri-devel mailing list
d

Re: [PATCH v3 2/2] drm/komeda: Enable new product D32 support

[Mihail Atanassov]

On Tuesday, 10 December 2019 08:48:51 GMT james qian wang (Arm Technology 
China) wrote:
> D32 is simple version of D71, the difference is:
> - Only has one pipeline
> - Drop the periph block and merge it to GCU
> 
> v2: Rebase.
> v3: Isolate the block counting fix to a new patch

I would've expected the fix to be a part of this series as 2/3 and this
patch as 3/3.

Otherwise, this patch is
Reviewed-by: Mihail Atanassov 

> 
> Signed-off-by: James Qian Wang (Arm Technology China) 
> 
> ---
>  .../drm/arm/display/include/malidp_product.h  |  3 +-
>  .../arm/display/komeda/d71/d71_component.c|  2 +-
>  .../gpu/drm/arm/display/komeda/d71/d71_dev.c  | 39 ---
>  .../gpu/drm/arm/display/komeda/d71/d71_regs.h | 13 +++
>  .../gpu/drm/arm/display/komeda/komeda_drv.c   |  1 +
>  5 files changed, 42 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h 
> b/drivers/gpu/drm/arm/display/include/malidp_product.h
> index 1053b11352eb..16a8a2c22c42 100644
> --- a/drivers/gpu/drm/arm/display/include/malidp_product.h
> +++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
> @@ -18,7 +18,8 @@
>  #define MALIDP_CORE_ID_STATUS(__core_id) (((__u32)(__core_id)) & 0xFF)
>  
>  /* Mali-display product IDs */
> -#define MALIDP_D71_PRODUCT_ID   0x0071
> +#define MALIDP_D71_PRODUCT_ID0x0071
> +#define MALIDP_D32_PRODUCT_ID0x0032
>  
>  union komeda_config_id {
>   struct {
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> index b6517c46e670..8a02ade369db 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> @@ -1270,7 +1270,7 @@ static int d71_timing_ctrlr_init(struct d71_dev *d71,
>  
>   ctrlr = to_ctrlr(c);
>  
> - ctrlr->supports_dual_link = true;
> + ctrlr->supports_dual_link = d71->supports_dual_link;
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c 
> b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> index 7e79c2e88421..dd1ecf4276d3 100644
> --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> @@ -371,23 +371,33 @@ static int d71_enum_resources(struct komeda_dev *mdev)
>   goto err_cleanup;
>   }
>  
> - /* probe PERIPH */
> + /* Only the legacy HW has the periph block, the newer merges the periph
> +  * into GCU
> +  */
>   value = malidp_read32(d71->periph_addr, BLK_BLOCK_INFO);
> - if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH) {
> - DRM_ERROR("access blk periph but got blk: %d.\n",
> -   BLOCK_INFO_BLK_TYPE(value));
> - err = -EINVAL;
> - goto err_cleanup;
> + if (BLOCK_INFO_BLK_TYPE(value) != D71_BLK_TYPE_PERIPH)
> + d71->periph_addr = NULL;
> +
> + if (d71->periph_addr) {
> + /* probe PERIPHERAL in legacy HW */
> + value = malidp_read32(d71->periph_addr, 
> PERIPH_CONFIGURATION_ID);
> +
> + d71->max_line_size  = value & PERIPH_MAX_LINE_SIZE ? 4096 : 
> 2048;
> + d71->max_vsize  = 4096;
> + d71->num_rich_layers= value & PERIPH_NUM_RICH_LAYERS ? 2 : 
> 1;
> + d71->supports_dual_link = !!(value & PERIPH_SPLIT_EN);
> + d71->integrates_tbu = !!(value & PERIPH_TBU_EN);
> + } else {
> + value = malidp_read32(d71->gcu_addr, GCU_CONFIGURATION_ID0);
> + d71->max_line_size  = GCU_MAX_LINE_SIZE(value);
> + d71->max_vsize  = GCU_MAX_NUM_LINES(value);
> +
> + value = malidp_read32(d71->gcu_addr, GCU_CONFIGURATION_ID1);
> + d71->num_rich_layers= GCU_NUM_RICH_LAYERS(value);
> + d71->supports_dual_link = GCU_DISPLAY_SPLIT_EN(value);
> + d71->integrates_tbu = GCU_DISPLAY_TBU_EN(value);
>   }
>  
> - value = malidp_read32(d71->periph_addr, PERIPH_CONFIGURATION_ID);
> -
> - d71->max_line_size  = value & PERIPH_MAX_LINE_SIZE ? 4096 : 2048;
> - d71->max_vsize  = 4096;
> - d71->num_rich_layers= value & PERIPH_NUM_RICH_LAYERS ? 2 : 1;
> - d71->supports_dual_link = value & PERIPH_SPLIT_EN ? true : false;
> - d71->integrates_tbu = value & PERIPH_TBU_EN ? true : false;
> -
>   for (i = 0; i < d71->num_pipelines; i++) {
>   pipe = komeda_pipeline_add(mdev, sizeof(struct d71_pipeline),
>  &d71_pipeline_funcs);
> @@ -606,6 +616,7 @@ d71_identify(u32 __iomem *reg_base, struct 
> komeda_chip_info *chip)
>  
>   switch (product_id) {
>   case MALIDP_D71_PRODUCT_ID:
> + case MALIDP_D32_PRODUCT_ID:
>   funcs = &d71_chip_funcs;
>   break;
>   default:
> diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_re

Re: [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight

[Hans de Goede]

Hi Lee,

On 10-12-2019 09:51, Lee Jones wrote:

On Tue, 19 Nov 2019, Hans de Goede wrote:


At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.

Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).

So far in the LPSS code on BYT we have skipped registering the LPSS PWM
controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is
present, assuming that in this case the PMIC PWM controller will be used.

On CHT we have been relying on only 1 of the 2 PWM controllers being
enabled in the DSDT at the same time; and always registered the lookup.

So far this has been working, but the correct way to determine which PWM
controller needs to be used is by checking a bit in the VBT table and
recently I've learned about 2 different BYT devices:
Point of View MOBII TAB-P800W
Acer Switch 10 SW5-012

Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS
PWM controller (and the VBT correctly indicates this), so here our old
heuristics fail.

Since only the i915 driver has access to the VBT, this commit renames
the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM
controller to "pwm_pmic_backlight" so that the i915 driver can do a
pwm_get() for the right controller depending on the VBT bit, instead of
the i915 driver relying on a "pwm_backlight" lookup getting registered
which magically points to the right controller.

Signed-off-by: Hans de Goede 
---
  drivers/mfd/intel_soc_pmic_core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


For my own reference:
   Acked-for-MFD-by: Lee Jones 


As mentioned in the cover-letter, to avoid breaking bi-sectability
as well as to avoid breaking the intel-gfx CI we need to merge this series
in one go through one tree. Specifically through the drm-intel tree.
Is that ok with you ?

If this is ok with you, then you do not have to do anything, I will just push
the entire series to drm-intel. drivers/mfd/intel_soc_pmic_core.c
does not see much changes so I do not expect this to lead to any conflicts.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 12/13] drm/connector: Split out orientation quirk detection (v2)

[Hans de Goede]

Hi All,

Can I get a review or Acked-by from someone for this patch please?

The other patches in this series all have acks and it would be nice if
I can push this to drm-misc-next...

Regards,

Hans

On 18-11-2019 16:51, Hans de Goede wrote:

From: Derek Basehore 

Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.

Hans de Goede (changes in v2):

Rename the function from drm_connector_init_panel_orientation_property
to drm_connector_set_panel_orientation[_with_quirk] and pass in the
panel-orientation to set.

Beside the rename, also make the function set the passed in value
only once, if the value was set before (to a value other then
DRM_MODE_PANEL_ORIENTATION_UNKNOWN) make any further set calls a no-op.

This change is preparation for allowing the user to override the
panel-orientation for any connector from the kernel commandline.
When the panel-orientation is overridden this way, then we must ignore
the panel-orientation detection done by the driver.

Signed-off-by: Derek Basehore 
Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/drm_connector.c | 74 ++---
  drivers/gpu/drm/i915/display/icl_dsi.c  |  5 +-
  drivers/gpu/drm/i915/display/intel_dp.c |  9 ++-
  drivers/gpu/drm/i915/display/vlv_dsi.c  |  5 +-
  include/drm/drm_connector.h |  9 ++-
  5 files changed, 71 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..40a985c411a6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1114,7 +1114,8 @@ static const struct drm_prop_enum_list hdmi_colorspaces[] 
= {
   *coordinates, so if userspace rotates the picture to adjust for
   *the orientation it must also apply the same transformation to the
   *touchscreen input coordinates. This property is initialized by calling
- * drm_connector_init_panel_orientation_property().
+ * drm_connector_set_panel_orientation() or
+ * drm_connector_set_panel_orientation_with_quirk()
   *
   * scaling mode:
   *This property defines how a non-native mode is upscaled to the native
@@ -1986,38 +1987,41 @@ void drm_connector_set_vrr_capable_property(
  EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
  
  /**

- * drm_connector_init_panel_orientation_property -
- * initialize the connecters panel_orientation property
- * @connector: connector for which to init the panel-orientation property.
- * @width: width in pixels of the panel, used for panel quirk detection
- * @height: height in pixels of the panel, used for panel quirk detection
+ * drm_connector_set_panel_orientation - sets the connecter's panel_orientation
+ * @connector: connector for which to set the panel-orientation property.
+ * @panel_orientation: drm_panel_orientation value to set
+ *
+ * This function sets the connector's panel_orientation and attaches
+ * a "panel orientation" property to the connector.
   *
- * This function should only be called for built-in panels, after setting
- * connector->display_info.panel_orientation first (if known).
+ * Calling this function on a connector where the panel_orientation has
+ * already been set is a no-op (e.g. the orientation has been overridden with
+ * a kernel commandline option).
   *
- * This function will check for platform specific (e.g. DMI based) quirks
- * overriding display_info.panel_orientation first, then if panel_orientation
- * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
- * "panel orientation" property to the connector.
+ * It is allowed to call this function with a panel_orientation of
+ * DRM_MODE_PANEL_ORIENTATION_UNKNOWN, in which case it is a no-op.
   *
   * Returns:
   * Zero on success, negative errno on failure.
   */
-int drm_connector_init_panel_orientation_property(
-   struct drm_connector *connector, int width, int height)
+int drm_connector_set_panel_orientation(
+   struct drm_connector *connector,
+   enum drm_panel_orientation panel_orientation)
  {
struct drm_device *dev = connector->dev;
struct drm_display_info *info = &connector->display_info;
struct drm_property *prop;
-   int orientation_quirk;
  
-	orientation_quirk = drm_get_panel_orientation_quirk(width, height);

-   if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
-   info->panel_orientation = orientation_quirk;
+   /* Already set? */
+   if (info->panel_orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
+   return 0;
  
-	if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)

+   /* Don't attach the property if the orientation is unknown */
+   if (panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
return 0;
  
+	info->panel_orientation = panel_or

Re: [PATCH] drm: panel-orientation-quirks: Add quirk for Teclast X89 tablet

[Hans de Goede]

Hi,

I know these kinda patches are sorta trivial, still I prefer to get an
Acked-by before pushing this to drm-misc-next. Can someone review this please?

Alternative I guess we could agree that pushing patches which just add a dmi
quirk to drm_panel_orientation_quirks.c is ok when the patch has sat on the
list without any response for a week ?

Regards,

Hans



On 02-12-2019 11:50, Hans de Goede wrote:

The Teclast X89 uses an upside-down mounted eDP panel, add a
panel-orientation quirk for this.

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index ffd95bfeaa94..9f2d12f28a73 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -108,6 +108,13 @@ static const struct drm_dmi_panel_orientation_data 
lcd1200x1920_rightside_up = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
  };
  
+static const struct drm_dmi_panel_orientation_data teclast_x89 = {

+   .width = 1536,
+   .height = 2048,
+   .bios_dates = (const char * const []){ "12/19/2014", NULL },
+   .orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP,
+};
+
  static const struct dmi_system_id orientation_data[] = {
{   /* Acer One 10 (S1003) */
.matches = {
@@ -205,6 +212,12 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad 
D330-10IGM"),
},
.driver_data = (void *)&lcd1200x1920_rightside_up,
+   }, {/* Teclast X89 (tPAD is too generic, also match on bios date) */
+   .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "TECLAST"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "tPAD"),
+   },
+   .driver_data = (void *)&teclast_x89,
}, {/* VIOS LTH17 */
.matches = {
  DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/i915/vlv_dsi: Control panel and backlight enable GPIOs on BYT

[Hans de Goede]

Hi,

On 11-12-2019 01:24, Linus Walleij wrote:

On Mon, Dec 2, 2019 at 4:49 PM Hans de Goede  wrote:


There is only one problem, currently is is not possible to
unregister a mapping added with pinctrl_register_mappings
and the i915 driver is typically a module which can be unloaded
and I believe actually is unloaded as part of the i915 CI.

pinctrl_register_mappings copies the passed in mapping, but
it is a shallow copy, so it contains pointers to the modules
const segment and we do not want to re-add another copy of
the mapping when the module loads a second time.

Fixing this is easy though, there already is a pinctrl_unregister_map()
function, we just need to export it so that the i915 driver can
remove the mapping when it is unbound.

Linus would exporting this function be ok with you?


Yep!


Linus, question what is the purpose of the "dupping" / shallow
copying of the argument passed to pinctrl_register_map ?


The initial commit contained this comment later removed:

+   /*
+* Make a copy of the map array - string pointers will end up in the
+* kernel const section anyway so these do not need to be deep copied.
+*/

The use was to free up memory for platforms using boardfiles
with a gazillion variants and huge pin control tables, so these
could be marked  __initdata and discarded after boot.
As the strings would anyway stay around we didn't need to
deep copy.

See for example in arch/arm/mach-u300/core.c
static struct pinctrl_map __initdata u300_pinmux_map[]


Since
it is shallow the mem for any pointers contained within there need
to be kept around by the caller, so why not let the caller keep
the pinctrl_map struct itself around too?


So the strings will be kept around because the kernel can't get
rid of strings. (Yeah it is silly, should haven been fixed ages
ago, but not by me, haha :)


If we are going to export pinctrl_unregister_map() we need to make it
do the right thing for dupped maps too, we can just store the dup flag
in struct pinctrl_maps. So this is easy, but I wonder if we cannot
get rid of the dupping all together ?


Maybe ... I don't know. What do you think? I suppose you could
make u300 crash if you do that.


I've prepared a patch which makes pinctrl_register_mappings remember
if the mapping is dupped or not (store the dup value in struct pinctrl_maps);
and which modifies pinctrl_unregister_map() to do the right thing
depending on the stored dup value.

I still need to test the new series and then I will post it.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about MSM Driver

[Rob Clark]

On Wed, Dec 11, 2019 at 6:22 AM ggermanres  wrote:
>
> Hello.
>
> I have question about MSM Driver.
>
> I using Dragonboard 410 with ili9881 display. This is hobby project. This 
> display from xiaomi redmi 3x/4x. I made PCB board for connect them. I changed 
> dts, created panel driver (this all on buildroot with my config). All ok. Run 
> platform. I saw linux console. Freedreno (opengl test app) is working fine. 
> But I saw flickering like on old monitor I saw from phone. I tried changing 
> timings, but this helped a little bit (I used it from dtsi from xiaomi 
> repository).
>
> I think this is with vsync problem. Your driver support DSI_VSYNC input? In 
> panel driver I sent command for vblank, on oscilloscope I saw pulse on this 
> pin 60Hz. I tried find path in your driver code, added some debug output in 
> code with sync. I saw MDSS_DSI_0_TRIG_CTRL configured with support TE. But 
> Its not helped for me.
>
> If you know something, tell me. Or how change driver to support DSI_VSYNC 
> input.
>

I guess this is a command mode panel?  So you'd be caring about the TE
signal?  As far as I understand (from, iirc, jhugo) this was handled
by the hardware and not exposed to the driver on older devices.

If it is a video mode panel, the problem could be different (userspace
not waiting for pageflip event?)

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/vram-helper: Support struct drm_driver.gem_create_object

[Thomas Zimmermann]

Drivers that what to allocate VRAM GEM objects with additional fields
can now do this by implementing struct drm_driver.gem_create_object.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index b760fd27f3c0..d475d94e2e3e 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -142,13 +143,19 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct 
drm_device *dev,
size_t size,
unsigned long pg_align)
 {
+   struct drm_gem_object *gem;
struct drm_gem_vram_object *gbo;
int ret;
 
-   gbo = kzalloc(sizeof(*gbo), GFP_KERNEL);
-   if (!gbo)
+   if (dev->driver->gem_create_object)
+   gem = dev->driver->gem_create_object(dev, size);
+   else
+   gem = kzalloc(sizeof(*gbo), GFP_KERNEL);
+   if (!gem)
return ERR_PTR(-ENOMEM);
 
+   gbo = drm_gem_vram_of_gem(gem);
+
ret = drm_gem_vram_init(dev, gbo, size, pg_align);
if (ret < 0)
goto err_kfree;
-- 
2.24.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel