Re: [PATCH 19/51] drm: Cleanups after drmm_add_final_kfree rollout

[Daniel Vetter]

On Thu, Apr 2, 2020 at 2:50 AM Laurent Pinchart
 wrote:
>
> Hi Daniel,
>
> (On a side note, git-format-patch accepts a -v argument to specify the
> version, I didn't realize you were not aware of it :-))
>
> On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> > A few things:
> > - Update the example driver in the documentation.
> > - We can drop the old kfree in drm_dev_release.
> > - Add a WARN_ON check in drm_dev_register to make sure everyone calls
> >   drmm_add_final_kfree and there's no leaks.
> >
> > v2: Restore the full cleanup, I accidentally left some moved code
> > behind when fixing the bisectability of the series.
> >
> > Acked-by: Sam Ravnborg 
> > Acked-by: Thomas Zimmermann 
> > Cc: Sam Ravnborg 
> > Cc: Dan Carpenter 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_drv.c | 12 +---
> >  1 file changed, 5 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 877ded348b6e..7f9d7ea543a0 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -297,8 +297,6 @@ void drm_minor_release(struct drm_minor *minor)
> >   *
> >   *   drm_mode_config_cleanup(drm);
> >   *   drm_dev_fini(drm);
> > - *   kfree(priv->userspace_facing);
> > - *   kfree(priv);
> >   *   }
> >   *
> >   *   static struct drm_driver driver_drm_driver = {
> > @@ -326,10 +324,11 @@ void drm_minor_release(struct drm_minor *minor)
> >   *   kfree(drm);
> >   *   return ret;
> >   *   }
> > + *   drmm_add_final_kfree(drm, priv);
> >   *
> >   *   drm_mode_config_init(drm);
> >   *
> > - *   priv->userspace_facing = kzalloc(..., GFP_KERNEL);
> > + *   priv->userspace_facing = drmm_kzalloc(..., GFP_KERNEL);
> >   *   if (!priv->userspace_facing)
> >   *   return -ENOMEM;
> >   *
> > @@ -837,10 +836,7 @@ static void drm_dev_release(struct kref *ref)
> >
> >   drm_managed_release(dev);
> >
> > - if (!dev->driver->release && !dev->managed.final_kfree) {
> > - WARN_ON(!list_empty(>managed.resources));
> > - kfree(dev);
> > - } else if (dev->managed.final_kfree)
> > + if (dev->managed.final_kfree)
> >   kfree(dev->managed.final_kfree);
> >  }
> >
> > @@ -961,6 +957,8 @@ int drm_dev_register(struct drm_device *dev, unsigned 
> > long flags)
> >   if (!driver->load)
> >   drm_mode_config_validate(dev);
> >
> > + WARN_ON(!dev->managed.final_kfree);
>
> That's too aggressive. Driver freeing their private object in .release()
> isn't wrong. I'd even go as far as saying that it should be the norm,
> until we manage to find a better way to handle that (which this series
> doesn't achieve). Many drivers need to allocate resources at probe time
> before they get a chance to init the drm device. Those resources must be
> released in the error handling paths of probe. By requiring
> drmm_add_final_kfree(), you're making that much more complex. I can't
> release those resources in the error path anymore after calling
> drmm_add_final_kfree(), or they will be released twice. And I can't rely
> on drmm_* to release them in all cases, as the error path may be hit
> before touching anything drm-related.
>
> Until we figure out a good way forward and test it on a significant
> number of drivers, let's not add WARN_ON() that will be hit with the
> majority of drivers, forcing them to be converted to something that is
> clearly half-baked.

Hm, is this conjecture, or did you actually hit this WARN_ON with a
driver? Because I did audit them all, none should hit this, all are
fixed up.

Also, I'm now actually going through all the places where I've added
the drmm_add_final_kfree and remove it again, they are _all_ about 5
lines after the kzalloc that allocates the driver structure which has
drm_device embedded.

So I'd like to understand where you get your seemingly rather sure
convinction from that this is a horrible mistake here ...

/me confused
-Daniel

>
> > +
> >   if (drm_dev_needs_global_mutex(dev))
> >   mutex_lock(_global_mutex);
> >
>
> --
> Regards,
>
> Laurent Pinchart



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v11 1/5] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings

[Laurent Pinchart]

Hi Hyun,

On Wed, Mar 18, 2020 at 06:08:57PM -0700, Hyun Kwon wrote:
> On Wed, 2020-03-18 at 12:26:51 -0700, Sam Ravnborg wrote:
> > On Wed, Mar 18, 2020 at 05:37:24PM +0200, Laurent Pinchart wrote:
> >> From: Hyun Kwon 
> >> 
> >> The bindings describe the ZynqMP DP subsystem. They don't support the
> >> interface with the programmable logic (FPGA) or audio yet.
> >> 
> >> Signed-off-by: Hyun Kwon 
> >> Signed-off-by: Laurent Pinchart 
> >> Reviewed-by: Rob Herring 
> > 
> > Bikeshedding - examples with indent on 4 spaces to make them easier to
> > read.
> > 
> > Would it be possible to make this binding: (GPL-2.0-only OR BSD-2-Clause)
> > This is preferred for new bindings.
> > In this case asking Hyun Kwon should be enough?
> 
> It should be possible. But to be safer and if needed, I need to check with
> corperate policy before I can confirm.
> 
> Michal, have you already checked about adding 'OR BSD-2-Clause'? or should I
> take it up to Xilinx legal?

Have you been able to get an answer on this ? I though the
double-license was encouraged for new bindings, but it now seems to be a
hard requirement to get them merged.

> > With or without the suggestions above:
> > Acked-by: Sam Ravnborg 
> > 
> > Sam
> > 
> >> ---
> >> Changes since v10:
> >> 
> >> - Update example to new PHY DT bindings without subnodes
> >> - Add resets property
> >> 
> >> Changes since v9:
> >> 
> >> - Fix constraints on clock-names
> >> - Document dp_apb_clk as the APB clock, not the AXI clock
> >> 
> >> Changes since v8:
> >> 
> >> - Convert to yaml
> >> - Rename aclk to dp_apb_clk
> >> ---
> >>  .../display/xlnx/xlnx,zynqmp-dpsub.yaml   | 174 ++
> >>  1 file changed, 174 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
> >> 
> >> diff --git 
> >> a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml 
> >> b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
> >> new file mode 100644
> >> index ..05e6a14de75c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
> >> @@ -0,0 +1,174 @@
> >> +# SPDX-License-Identifier: GPL-2.0
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/display/xlnx/xlnx,zynqmp-dpsub.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Xilinx ZynqMP DisplayPort Subsystem
> >> +
> >> +description: |
> >> +  The DisplayPort subsystem of Xilinx ZynqMP (Zynq UltraScale+ MPSoC)
> >> +  implements the display and audio pipelines based on the DisplayPort v1.2
> >> +  standard. The subsystem includes multiple functional blocks as below:
> >> +
> >> +   
> >> ++
> >> +  ++   | ++ +---+ 
> >>   |
> >> +  | DPDMA  | --->|| --> |   Video   | Video 
> >> +-+ |
> >> +  | 4x vid |   | || | Rendering | -+--> | 
> >> | |   +--+
> >> +  | 2x aud |   | |  Audio/Video   | --> | Pipeline  |  || DisplayPort 
> >> |---> | PHY0 |
> >> +  ++   | | Buffer Manager | +---+  ||   Source
> >> | |   +--+
> >> +   | |and STC | +---+  || Controller  
> >> | |   +--+
> >> +  Live Video --->|| --> |   Audio   | Audio | 
> >> |---> | PHY1 |
> >> +   | || |   Mixer   | --+-> | 
> >> | |   +--+
> >> +  Live Audio --->|| --> |   |  ||   
> >> +-+ |
> >> +   | ++ +---+  || 
> >>   |
> >> +   
> >> +---||---+
> >> +   vv
> >> + Blended Video and
> >> + Mixed Audio to PL
> >> +
> >> +  The Buffer Manager interacts with external interface such as DMA 
> >> engines or
> >> +  live audio/video streams from the programmable logic. The Video 
> >> Rendering
> >> +  Pipeline blends the video and graphics layers and performs colorspace
> >> +  conversion. The Audio Mixer mixes the incoming audio streams. The 
> >> DisplayPort
> >> +  Source Controller handles the DisplayPort protocol and connects to 
> >> external
> >> +  PHYs.
> >> +
> >> +  The subsystem supports 2 video and 2 audio streams, and various pixel 
> >> formats
> >> +  and depths up to 4K@30 resolution.
> >> +
> >> +  Please refer to "Zynq UltraScale+ Device Technical Reference Manual"
> >> +  
> >> (https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf)
> >> +  for more details.
> >> +
> >> +maintainers:
> >> +  - Laurent Pinchart 
> >> +
> >> +properties:
> >> +  compatible:
> >> +

Re: [Outreachy kernel] [PATCH] staging: android: ion: Fix parenthesis alignment

[Stefano Brivio]

On Wed,  1 Apr 2020 18:25:15 -0700
"John B. Wyatt IV"  wrote:

> Fix 2 parenthesis alignment issues.
> 
> Reported by checkpatch.
> 
> Signed-off-by: John B. Wyatt IV 

Reviewed-by: Stefano Brivio 

-- 
Stefano

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

Re: [PATCH 19/51] drm: Cleanups after drmm_add_final_kfree rollout

[Laurent Pinchart]

Hi Daniel,

(On a side note, git-format-patch accepts a -v argument to specify the
version, I didn't realize you were not aware of it :-))

On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> A few things:
> - Update the example driver in the documentation.
> - We can drop the old kfree in drm_dev_release.
> - Add a WARN_ON check in drm_dev_register to make sure everyone calls
>   drmm_add_final_kfree and there's no leaks.
> 
> v2: Restore the full cleanup, I accidentally left some moved code
> behind when fixing the bisectability of the series.
> 
> Acked-by: Sam Ravnborg 
> Acked-by: Thomas Zimmermann 
> Cc: Sam Ravnborg 
> Cc: Dan Carpenter 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_drv.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 877ded348b6e..7f9d7ea543a0 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -297,8 +297,6 @@ void drm_minor_release(struct drm_minor *minor)
>   *
>   *   drm_mode_config_cleanup(drm);
>   *   drm_dev_fini(drm);
> - *   kfree(priv->userspace_facing);
> - *   kfree(priv);
>   *   }
>   *
>   *   static struct drm_driver driver_drm_driver = {
> @@ -326,10 +324,11 @@ void drm_minor_release(struct drm_minor *minor)
>   *   kfree(drm);
>   *   return ret;
>   *   }
> + *   drmm_add_final_kfree(drm, priv);
>   *
>   *   drm_mode_config_init(drm);
>   *
> - *   priv->userspace_facing = kzalloc(..., GFP_KERNEL);
> + *   priv->userspace_facing = drmm_kzalloc(..., GFP_KERNEL);
>   *   if (!priv->userspace_facing)
>   *   return -ENOMEM;
>   *
> @@ -837,10 +836,7 @@ static void drm_dev_release(struct kref *ref)
>  
>   drm_managed_release(dev);
>  
> - if (!dev->driver->release && !dev->managed.final_kfree) {
> - WARN_ON(!list_empty(>managed.resources));
> - kfree(dev);
> - } else if (dev->managed.final_kfree)
> + if (dev->managed.final_kfree)
>   kfree(dev->managed.final_kfree);
>  }
>  
> @@ -961,6 +957,8 @@ int drm_dev_register(struct drm_device *dev, unsigned 
> long flags)
>   if (!driver->load)
>   drm_mode_config_validate(dev);
>  
> + WARN_ON(!dev->managed.final_kfree);

That's too aggressive. Driver freeing their private object in .release()
isn't wrong. I'd even go as far as saying that it should be the norm,
until we manage to find a better way to handle that (which this series
doesn't achieve). Many drivers need to allocate resources at probe time
before they get a chance to init the drm device. Those resources must be
released in the error handling paths of probe. By requiring
drmm_add_final_kfree(), you're making that much more complex. I can't
release those resources in the error path anymore after calling
drmm_add_final_kfree(), or they will be released twice. And I can't rely
on drmm_* to release them in all cases, as the error path may be hit
before touching anything drm-related.

Until we figure out a good way forward and test it on a significant
number of drivers, let's not add WARN_ON() that will be hit with the
majority of drivers, forcing them to be converted to something that is
clearly half-baked.

> +
>   if (drm_dev_needs_global_mutex(dev))
>   mutex_lock(_global_mutex);
>  

-- 
Regards,

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

Re: [git pull] drm for 5.7-rc1

[pr-tracker-bot]

The pull request you sent on Wed, 1 Apr 2020 15:50:42 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-04-01

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f365ab31efacb70bed1e821f7435626e0b2528a6

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm/virtio: only call virtio_gpu_cmd_create_resource for dumb resources

[Gurchetan Singh]

We want to avoid this path for upcoming blob resources.

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

diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 6ccbd01cd888c..82df066ac0552 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -224,7 +224,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
*vgdev,
if (params->virgl) {
virtio_gpu_cmd_resource_create_3d(vgdev, bo, params,
  objs, fence);
-   } else {
+   } else if (params->dumb) {
virtio_gpu_cmd_create_resource(vgdev, bo, params,
   objs, fence);
}
-- 
2.24.1

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

[PATCH 1/5] drm/virtio: random virtgpu_drv.h cleanups

[Gurchetan Singh]

- Static-ify virtio_gpu_gem_create
- Delete unused prototypes
- Point to current implementation files

Signed-off-by: Gurchetan Singh 
Reviewed-by: Chia-I Wu 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h | 26 +-
 drivers/gpu/drm/virtio/virtgpu_gem.c | 10 +-
 2 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 824f9f15926cf..79ad176aca5a8 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -218,26 +218,18 @@ struct virtio_gpu_fpriv {
struct mutex context_lock;
 };
 
-/* virtio_ioctl.c */
+/* virtgpu_ioctl.c */
 #define DRM_VIRTIO_NUM_IOCTLS 10
 extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
 
-/* virtio_kms.c */
+/* virtgpu_kms.c */
 int virtio_gpu_init(struct drm_device *dev);
 void virtio_gpu_deinit(struct drm_device *dev);
 void virtio_gpu_release(struct drm_device *dev);
 int virtio_gpu_driver_open(struct drm_device *dev, struct drm_file *file);
 void virtio_gpu_driver_postclose(struct drm_device *dev, struct drm_file 
*file);
 
-/* virtio_gem.c */
-void virtio_gpu_gem_free_object(struct drm_gem_object *gem_obj);
-int virtio_gpu_gem_init(struct virtio_gpu_device *vgdev);
-void virtio_gpu_gem_fini(struct virtio_gpu_device *vgdev);
-int virtio_gpu_gem_create(struct drm_file *file,
- struct drm_device *dev,
- struct virtio_gpu_object_params *params,
- struct drm_gem_object **obj_p,
- uint32_t *handle_p);
+/* virtgpu_gem.c */
 int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
   struct drm_file *file);
 void virtio_gpu_gem_object_close(struct drm_gem_object *obj,
@@ -263,7 +255,7 @@ void virtio_gpu_array_put_free_delayed(struct 
virtio_gpu_device *vgdev,
   struct virtio_gpu_object_array *objs);
 void virtio_gpu_array_put_free_work(struct work_struct *work);
 
-/* virtio vg */
+/* virtgpu_vq.c */
 int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev);
 void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev);
 void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
@@ -343,17 +335,17 @@ void virtio_gpu_dequeue_fence_func(struct work_struct 
*work);
 
 void virtio_gpu_notify(struct virtio_gpu_device *vgdev);
 
-/* virtio_gpu_display.c */
+/* virtgpu_display.c */
 void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
 void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
 
-/* virtio_gpu_plane.c */
+/* virtgpu_plane.c */
 uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc);
 struct drm_plane *virtio_gpu_plane_init(struct virtio_gpu_device *vgdev,
enum drm_plane_type type,
int index);
 
-/* virtio_gpu_fence.c */
+/* virtgpu_fence.c */
 struct virtio_gpu_fence *virtio_gpu_fence_alloc(
struct virtio_gpu_device *vgdev);
 void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
@@ -362,7 +354,7 @@ void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
 void virtio_gpu_fence_event_process(struct virtio_gpu_device *vdev,
u64 last_seq);
 
-/* virtio_gpu_object */
+/* virtgpu_object.c */
 void virtio_gpu_cleanup_object(struct virtio_gpu_object *bo);
 struct drm_gem_object *virtio_gpu_create_object(struct drm_device *dev,
size_t size);
@@ -378,7 +370,7 @@ struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
struct drm_device *dev, struct dma_buf_attachment *attach,
struct sg_table *sgt);
 
-/* virgl debugfs */
+/* virtgpu_debugfs.c */
 void virtio_gpu_debugfs_init(struct drm_minor *minor);
 
 #endif
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c 
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 0d6152c99a271..90c0a8ea1708c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -28,11 +28,11 @@
 
 #include "virtgpu_drv.h"
 
-int virtio_gpu_gem_create(struct drm_file *file,
- struct drm_device *dev,
- struct virtio_gpu_object_params *params,
- struct drm_gem_object **obj_p,
- uint32_t *handle_p)
+static int virtio_gpu_gem_create(struct drm_file *file,
+struct drm_device *dev,
+struct virtio_gpu_object_params *params,
+struct drm_gem_object **obj_p,
+uint32_t *handle_p)
 {
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_object *obj;
-- 
2.24.1

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

[PATCH 2/5] drm/virtio: delete notify after virtio_gpu_cmd_context_create

[Gurchetan Singh]

The first 3D ioctl will take care of notification.

Signed-off-by: Gurchetan Singh 
Reviewed-by: Chia-I Wu 
---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 336cc9143205d..867c5e239d553 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -47,7 +47,6 @@ static void virtio_gpu_create_context(struct drm_device *dev,
get_task_comm(dbgname, current);
virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id,
  strlen(dbgname), dbgname);
-   virtio_gpu_notify(vgdev);
vfpriv->context_created = true;
 
 out_unlock:
-- 
2.24.1

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

[PATCH 4/5] drm/virtio: make virtio_gpu_object_attach void

[Gurchetan Singh]

It always returns zero.

Signed-off-by: Gurchetan Singh 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h| 8 
 drivers/gpu/drm/virtio/virtgpu_object.c | 6 +-
 drivers/gpu/drm/virtio/virtgpu_vq.c | 9 -
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 79ad176aca5a8..49bebdee6d91e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -279,10 +279,10 @@ void virtio_gpu_cmd_set_scanout(struct virtio_gpu_device 
*vgdev,
uint32_t scanout_id, uint32_t resource_id,
uint32_t width, uint32_t height,
uint32_t x, uint32_t y);
-int virtio_gpu_object_attach(struct virtio_gpu_device *vgdev,
-struct virtio_gpu_object *obj,
-struct virtio_gpu_mem_entry *ents,
-unsigned int nents);
+void virtio_gpu_object_attach(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *obj,
+ struct virtio_gpu_mem_entry *ents,
+ unsigned int nents);
 int virtio_gpu_attach_status_page(struct virtio_gpu_device *vgdev);
 int virtio_gpu_detach_status_page(struct virtio_gpu_device *vgdev);
 void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev,
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 51a8da7d5ef3b..6ccbd01cd888c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -235,11 +235,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
*vgdev,
return ret;
}
 
-   ret = virtio_gpu_object_attach(vgdev, bo, ents, nents);
-   if (ret != 0) {
-   virtio_gpu_free_object(_obj->base);
-   return ret;
-   }
+   virtio_gpu_object_attach(vgdev, bo, ents, nents);
 
*bo_ptr = bo;
return 0;
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 73854915ec349..9e663a5d99526 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -1087,14 +1087,13 @@ void virtio_gpu_cmd_submit(struct virtio_gpu_device 
*vgdev,
virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, fence);
 }
 
-int virtio_gpu_object_attach(struct virtio_gpu_device *vgdev,
-struct virtio_gpu_object *obj,
-struct virtio_gpu_mem_entry *ents,
-unsigned int nents)
+void virtio_gpu_object_attach(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *obj,
+ struct virtio_gpu_mem_entry *ents,
+ unsigned int nents)
 {
virtio_gpu_cmd_resource_attach_backing(vgdev, obj->hw_res_handle,
   ents, nents, NULL);
-   return 0;
 }
 
 void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev,
-- 
2.24.1

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

[PATCH 3/5] drm/virtio: delete notify in virtio_gpu_object_create

[Gurchetan Singh]

For 3D buffers, virtio_gpu_gem_object_open notifies.
We can have the same behavior for dumb buffer.

v2: virtio_gpu_gem_object_open always notifies
v3: avoid boolean variable

Signed-off-by: Gurchetan Singh 
Reviewed-by: Chia-I Wu 
---
 drivers/gpu/drm/virtio/virtgpu_gem.c| 3 ++-
 drivers/gpu/drm/virtio/virtgpu_object.c | 1 -
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c 
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 90c0a8ea1708c..1025658be4df2 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -114,7 +114,7 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
struct virtio_gpu_object_array *objs;
 
if (!vgdev->has_virgl_3d)
-   return 0;
+   goto out_notify;
 
objs = virtio_gpu_array_alloc(1);
if (!objs)
@@ -123,6 +123,7 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
 
virtio_gpu_cmd_context_attach_resource(vgdev, vfpriv->ctx_id,
   objs);
+out_notify:
virtio_gpu_notify(vgdev);
return 0;
 }
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index d9039bb7c5e37..51a8da7d5ef3b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -241,7 +241,6 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
*vgdev,
return ret;
}
 
-   virtio_gpu_notify(vgdev);
*bo_ptr = bo;
return 0;
 
-- 
2.24.1

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

Re: [v1 3/3] arm64: dts: sc7180: define interconnects for sc7180 target

[Matthias Kaehlcke]

On Wed, Apr 01, 2020 at 02:47:45PM +0530, Krishna Manikandan wrote:

> Subject: arm64: dts: sc7180: define interconnects for sc7180 target

Please be more specific about which interconnect entries are added.
Also no need to repeat 'sc7180', it is already clear from the prefix.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Aliases for DRI connectors?

[Matt Hoosier]

On Wed, Apr 1, 2020 at 3:17 PM Simon Ser  wrote:

> On Wednesday, April 1, 2020 9:38 PM, Matt Hoosier 
> wrote:
>
> > I'm searching for some sort of scheme that will let my DRI master query
> the set of available connectors and select the one carrying a prearranged
> designation. The problem I'm trying to solve is to allow deploying one
> standardized userspace component across a fleet of devices that have
> varying numbers of displays, with the use cases not always driven on the
> same connector topologically.
> >
> > I had a look around the properties available on my system's DRI
> connectors, and nothing immediate jumped out at me. Is there a standard
> connector property that (assuming I can find the right place in DeviceTree
> or similar to) that would be a good fit for this?
>
> Maybe information in the EDID would help? You'll find the manufacturer,
> the model number and the serial number.
>

That might be a possibility. The trouble there is that there can be more
than one instance of the same display model connected to the system, so the
EDID blob wouldn't be particularly helpful to distinguish them. The
connectors in question are generally something like LVDS or DSI that don't
typically expose EDID properties, too.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Arnd Bergmann]

On Tue, Mar 31, 2020 at 7:51 PM Segher Boessenkool
 wrote:
>
> On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote:
> > While we are at it, can we also remove the 601 ? This one is also full
> > of workarounds and diverges a bit from other 6xx.
> >
> > I'm unable to find its end of life date, but it was on the market in
> > 1994, so I guess it must be outdated by more than 10-15 yr old now ?
>
> There probably are still some people running Linux on 601 powermacs.

It could be marked as "BROKEN" for a year to find out for sure ;-)

Apparently there were only two or three models that are old enough to
have a 601 and new enough to run Linux with PCI and OF: 7200/8200
and 7500. These were sold for less than 18 months around 1996,
though one can still find them on eBay.

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

Re: Aliases for DRI connectors?

[Simon Ser]

On Wednesday, April 1, 2020 9:38 PM, Matt Hoosier  
wrote:

> I'm searching for some sort of scheme that will let my DRI master query the 
> set of available connectors and select the one carrying a prearranged 
> designation. The problem I'm trying to solve is to allow deploying one 
> standardized userspace component across a fleet of devices that have varying 
> numbers of displays, with the use cases not always driven on the same 
> connector topologically.
>
> I had a look around the properties available on my system's DRI connectors, 
> and nothing immediate jumped out at me. Is there a standard connector 
> property that (assuming I can find the right place in DeviceTree or similar 
> to) that would be a good fit for this?

Maybe information in the EDID would help? You'll find the manufacturer,
the model number and the serial number.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu, amdkfd drm-next-5.7

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 5.7.

The following changes since commit 59e7a8cc2dcf335116d500d684bfb34d1d97a6fe:

  Merge tag 'drm-msm-next-2020-03-22' of https://gitlab.freedesktop.org/drm/msm 
into drm-next (2020-03-31 16:34:55 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.7-2020-04-01

for you to fetch changes up to 3148a6a0ef3cf93570f30a477292768f7eb5d3c3:

  drm/amdkfd: kfree the wrong pointer (2020-04-01 14:44:22 -0400)


amd-drm-next-5.7-2020-04-01:

amdgpu:
- HDCP fixes
- gfx10 fix
- Misc display fixes
- BACO fixes

amdkfd:
- Fix memory leak


Aric Cyr (1):
  drm/amd/display: LFC not working on 2.0x range monitors (v2)

Bhawanpreet Lakha (3):
  drm/amd/display: Don't try hdcp1.4 when content_type is set to type1
  drm/amd/display: Correctly cancel future watchdog and callback events
  drm/amd/display: increase HDCP authentication delay

Dmytro Laktyushkin (1):
  drm/amd/display: Fix dcn21 num_states

Eric Bernstein (1):
  drm/amd/display: Update function to get optimal number of taps

Evan Quan (2):
  drm/amd/powerplay: drop redundant BIF doorbell interrupt operations
  drm/amd/powerplay: move the ASIC specific nbio operation out of 
smu_v11_0.c

Isabel Zhang (1):
  drm/amd/display: Revert change to HDCP display states

Jack Zhang (1):
  drm/amdkfd: kfree the wrong pointer

Kevin Wang (1):
  drm/amdgpu: fix hpd bo size calculation error

Nicholas Kazlauskas (1):
  drm/amd/display: Use double buffered DRR timing update by default

Stylon Wang (3):
  drm/amd/display: Support P010 pixel format
  drm/amd/display: Support plane level CTM
  drm/amd/display: Enable BT2020 in COLOR_ENCODING property

Yongqiang Sun (1):
  drm/amd/display: Not doing optimize bandwidth if flip pending.

 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |  2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_device.c|  4 +--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 12 +--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 14 +---
 drivers/gpu/drm/amd/display/dc/core/dc.c   | 33 +-
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |  1 +
 drivers/gpu/drm/amd/display/dc/dc.h|  3 ++
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  |  6 
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c  | 18 ++
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.h  |  3 ++
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  |  3 +-
 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c  |  5 +--
 .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c  | 40 --
 drivers/gpu/drm/amd/display/dc/dml/dc_features.h   |  2 +-
 .../drm/amd/display/dc/dml/display_mode_structs.h  |  7 ++--
 .../drm/amd/display/modules/freesync/freesync.c| 34 ++
 drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c|  5 ++-
 drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h| 28 +++
 .../drm/amd/display/modules/hdcp/hdcp1_execution.c |  2 +-
 .../drm/amd/display/modules/hdcp/hdcp2_execution.c |  2 +-
 .../gpu/drm/amd/display/modules/hdcp/hdcp_psp.c| 39 -
 drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h |  1 +
 drivers/gpu/drm/amd/powerplay/arcturus_ppt.c   | 15 +++-
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 18 --
 drivers/gpu/drm/amd/powerplay/smu_v11_0.c  | 24 +
 drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 14 +++-
 27 files changed, 223 insertions(+), 114 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Aliases for DRI connectors?

[Matt Hoosier]

I'm searching for some sort of scheme that will let my DRI master query the
set of available connectors and select the one carrying a prearranged
designation. The problem I'm trying to solve is to allow deploying one
standardized userspace component across a fleet of devices that have
varying numbers of displays, with the use cases not always driven on the
same connector topologically.

I had a look around the properties available on my system's DRI connectors,
and nothing immediate jumped out at me. Is there a standard connector
property that (assuming I can find the right place in DeviceTree or similar
to) that would be a good fit for this?

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

gpu: msm: possible circular locking dependency detected on 5.5

[Fabio Estevam]

Hi,

Here is an adreno regression I noticed on imx53 running 5.5.13:

[   21.283902] ==
[   21.290148] WARNING: possible circular locking dependency detected
[   21.296409] 5.5.13 #1 Not tainted
[   21.299785] --
[   21.306030] kworker/u2:1/19 is trying to acquire lock:
[   21.311236] dc888ae8 (reservation_ww_class_mutex){+.+.}, at:
dma_buf_detach+0x78/0x1e0
[   21.319341]
[   21.319341] but task is already holding lock:
[   21.325232] dc88838c (_obj->lock){+.+.}, at:
msm_gem_free_work+0x100/0x188
[   21.332587]
[   21.33258[   32.525073] evbug: Event. Dev: input1, Type: 3, Code:
1, Value: 41
[   32.531942] evbug: Event. Dev: input1, Type: 0, Code: 0, Value: 0
7] which lock already depends on the new lock.
[   21.332587]
[   21.340823]
[   21.340823] the existing dependency chain (in reverse order) is:
[   21.348362]
[   21.348362] -> #1 (_obj->lock){+.+.}:
[   21.353989]mutex_lock_nested+0x1c/0x24
[   21.358514]msm_gem_get_and_pin_iova+0x30/0x158
[   21.363733]msm_ioctl_gem_submit+0xa90/0x1148
[   21.368775]drm_ioctl_kernel+0xa4/0xec
[   21.373203]drm_ioctl+0x1e0/0x3c8
[   21.377215]do_vfs_ioctl+0x9c/0xa68
[   21.381388]ksys_ioctl+0x34/0x60
[   21.385304]ret_fast_syscall+0x0/0x28
[   21.389646]0xbea6f8d8
[   21.392670]
[   21.392670] -> #0 (reservation_ww_class_mutex){+.+.}:
[   21.399333]lock_acquire+0xcc/0x1ec
[   21.403516]__ww_mutex_lock.constprop.8+0x94/0x10a4
[   21.409080]ww_mutex_lock+0x78/0xb0
[   21.413261]dma_buf_detach+0x78/0x1e0
[   21.417637]drm_prime_gem_destroy+0x2c/0x38
[   21.422505]msm_gem_free_work+0x88/0x188
[   21.427133]process_one_work+0x2c4/0x754
[   21.431744]worker_thread+0x2c/0x590
[   21.436015]kthread+0x134/0x148
[   21.439838]ret_from_fork+0x14/0x20
[   21.444000]0x0
[   21.446418]
[   21.446418] other info that might help us debug this:
[   21.446418]
[   21.454483]  Possible unsafe locking scenario:
[   21.454483]
[   21.460460]CPU0CPU1
[   21.465044]
[   21.469627]   lock(_obj->lock);
[   21.473190]lock(reservation_ww_class_mutex);
[   21.480314]lock(_obj->lock);
[   21.486392]   lock(reservation_ww_class_mutex);
[   21.490996]
[   21.490996]  *** DEADLOCK ***
[   21.490996]
[   21.496985] 4 locks held by kworker/u2:1/19:
[   21.501311]  #0: dc43a6a0 ((wq_completion)msm){+.+.}, at:
process_one_work+0x210/0x754
[   21.509358]  #1: dc207f1c
((work_completion)(>free_work)){+.+.}, at:
process_one_work+0x210/0x754
[   21.518876]  #2: dc3a7070 (>struct_mutex){+.+.}, at:
msm_gem_free_work+0x4c/0x188
[   21.526915]  #3: dc88838c (_obj->lock){+.+.}, at:
msm_gem_free_work+0x100/0x188
[   21.534692]
[   21.534692] stack backtrace:
[   21.539136] CPU: 0 PID: 19 Comm: kworker/u2:1 Not tainted 5.5.13 #1
[   21.545470] Hardware name: Freescale i.MX53 (Device Tree Support)
[   21.551667] Workqueue: msm msm_gem_free_work
[   21.556087] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[   21.563950] [] (show_stack) from []
(dump_stack+0xe4/0x11c)
[   21.571372] [] (dump_stack) from []
(check_noncircular+0x130/0x1e4)
[   21.579486] [] (check_noncircular) from []
(__lock_acquire+0xf58/0x2458)
[   21.588030] [] (__lock_acquire) from []
(lock_acquire+0xcc/0x1ec)
[   21.595976] [] (lock_acquire) from []
(__ww_mutex_lock.constprop.8+0x94/0x10a4)
[   21.605134] [] (__ww_mutex_lock.constprop.8) from
[] (ww_mutex_lock+0x78/0xb0)
[   21.614207] [] (ww_mutex_lock) from []
(dma_buf_detach+0x78/0x1e0)
[   21.622239] [] (dma_buf_detach) from []
(drm_prime_gem_destroy+0x2c/0x38)
[   21.630874] [] (drm_prime_gem_destroy) from []
(msm_gem_free_work+0x88/0x188)
[   21.639854] [] (msm_gem_free_work) from []
(process_one_work+0x2c4/0x754)
[   21.648487] [] (process_one_work) from []
(worker_thread+0x2c/0x590)
[   21.656681] [] (worker_thread) from []
(kthread+0x134/0x148)
[   21.664176] [] (kthread) from []
(ret_from_fork+0x14/0x20)
[   21.671470] Exception stack(0xdc207fb0 to 0xdc207ff8)

In order to reproduce it, I just launch kmscube and it starts running normally.

Then I do a "CTRL + C" and the message below appears.

Testing on 5.4.x I don't see this problem.

I haven't started bisecting this yet, but just checking if anyone has
any ideas first.

Thanks,

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

Re: [PATCH 0/4] drm/dp_mst: Remove ->destroy_connector() callback

[Alex Deucher]

On Tue, Mar 31, 2020 at 4:58 PM Lyude Paul  wrote:
>
> This finishes up the work that Pankaj Bharadiya started in:
>
> https://patchwork.freedesktop.org/series/74412/
>
> And allows us to entirely remove ->destroy_connector()
>
> Lyude Paul (4):
>   drm/amd/amdgpu_dm/mst: Remove unneeded edid assignment when destroying
> connectors
>   drm/amd/amdgpu_dm/mst: Remove ->destroy_connector() callback
>   drm/amd/amdgpu_dm/mst: Stop printing extra messages in
> dm_dp_add_mst_connector()
>   drm/dp_mst: Remove drm_dp_mst_topology_cbs.destroy_connector

I noticed this as well when I was sorting out the load and unload
callback removal.  Thanks for finishing this up.  This series looks
good to me, assuming none of the display folks have any concerns:
Reviewed-by: Alex Deucher 


>
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   | 45 +--
>  drivers/gpu/drm/drm_dp_mst_topology.c | 16 ++-
>  include/drm/drm_dp_mst_helper.h   |  2 -
>  3 files changed, 15 insertions(+), 48 deletions(-)
>
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd/dc: Kill dc_conn_log_hex_linux()

[Alex Deucher]

On Wed, Apr 1, 2020 at 9:00 AM Kazlauskas, Nicholas
 wrote:
>
> On 2020-03-31 5:22 p.m., Lyude Paul wrote:
> > DRM already supports tracing DPCD transactions, there's no reason for
> > the existence of this function. Also, it prints one byte per-line which
> > is way too loud. So, just remove it.
> >
> > Signed-off-by: Lyude Paul 
>
> Thanks for helping clean this up!
>
> Series is:
>
> Reviewed-by: Nicholas Kazlauskas 


Applied the series.  Thanks!

Alex

>
> Regards,
> Nicholas Kazlauskas
>
> > ---
> >   .../gpu/drm/amd/display/dc/basics/Makefile|  3 +-
> >   .../drm/amd/display/dc/basics/log_helpers.c   | 39 ---
> >   .../amd/display/include/logger_interface.h|  4 --
> >   3 files changed, 1 insertion(+), 45 deletions(-)
> >   delete mode 100644 drivers/gpu/drm/amd/display/dc/basics/log_helpers.c
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/basics/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/basics/Makefile
> > index 7ad0cad0f4ef..01b99e0d788e 100644
> > --- a/drivers/gpu/drm/amd/display/dc/basics/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/basics/Makefile
> > @@ -24,8 +24,7 @@
> >   # It provides the general basic services required by other DAL
> >   # subcomponents.
> >
> > -BASICS = conversion.o fixpt31_32.o \
> > - log_helpers.o vector.o dc_common.o
> > +BASICS = conversion.o fixpt31_32.o vector.o dc_common.o
> >
> >   AMD_DAL_BASICS = $(addprefix $(AMDDALPATH)/dc/basics/,$(BASICS))
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/basics/log_helpers.c 
> > b/drivers/gpu/drm/amd/display/dc/basics/log_helpers.c
> > deleted file mode 100644
> > index 26583f346c39..
> > --- a/drivers/gpu/drm/amd/display/dc/basics/log_helpers.c
> > +++ /dev/null
> > @@ -1,39 +0,0 @@
> > -/*
> > - * Copyright 2012-16 Advanced Micro Devices, Inc.
> > - *
> > - * Permission is hereby granted, free of charge, to any person obtaining a
> > - * copy of this software and associated documentation files (the 
> > "Software"),
> > - * to deal in the Software without restriction, including without 
> > limitation
> > - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > - * and/or sell copies of the Software, and to permit persons to whom the
> > - * Software is furnished to do so, subject to the following conditions:
> > - *
> > - * The above copyright notice and this permission notice shall be included 
> > in
> > - * all copies or substantial portions of the Software.
> > - *
> > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > - * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > - * OTHER DEALINGS IN THE SOFTWARE.
> > - *
> > - * Authors: AMD
> > - *
> > - */
> > -
> > -#include "core_types.h"
> > -#include "logger.h"
> > -#include "include/logger_interface.h"
> > -#include "dm_helpers.h"
> > -
> > -void dc_conn_log_hex_linux(const uint8_t *hex_data, int hex_data_count)
> > -{
> > - int i;
> > -
> > - if (hex_data)
> > - for (i = 0; i < hex_data_count; i++)
> > - DC_LOG_DEBUG("%2.2X ", hex_data[i]);
> > -}
> > -
> > diff --git a/drivers/gpu/drm/amd/display/include/logger_interface.h 
> > b/drivers/gpu/drm/amd/display/include/logger_interface.h
> > index 6e008de25629..02c23b04d34b 100644
> > --- a/drivers/gpu/drm/amd/display/include/logger_interface.h
> > +++ b/drivers/gpu/drm/amd/display/include/logger_interface.h
> > @@ -40,8 +40,6 @@ struct dc_state;
> >*
> >*/
> >
> > -void dc_conn_log_hex_linux(const uint8_t *hex_data, int hex_data_count);
> > -
> >   void pre_surface_trace(
> >   struct dc *dc,
> >   const struct dc_plane_state *const *plane_states,
> > @@ -102,14 +100,12 @@ void context_clock_trace(
> >   #define CONN_DATA_DETECT(link, hex_data, hex_len, ...) \
> >   do { \
> >   (void)(link); \
> > - dc_conn_log_hex_linux(hex_data, hex_len); \
> >   DC_LOG_EVENT_DETECTION(__VA_ARGS__); \
> >   } while (0)
> >
> >   #define CONN_DATA_LINK_LOSS(link, hex_data, hex_len, ...) \
> >   do { \
> >   (void)(link); \
> > - dc_conn_log_hex_linux(hex_data, hex_len); \
> >   DC_LOG_EVENT_LINK_LOSS(__VA_ARGS__); \
> >   } while (0)
> >
> >
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH][next] drm/amdgpu/vcn: fix spelling mistake "fimware" -> "firmware"

[Alex Deucher]

On Wed, Apr 1, 2020 at 12:35 PM Colin King  wrote:
>
> From: Colin Ian King 
>
> There is a spelling mistake in a dev_err error message. Fix it.
>
> Signed-off-by: Colin Ian King 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> index 328b6ceb80de..d653a18dcbc3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> @@ -187,7 +187,7 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
> PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM, 
> >vcn.inst[i].fw_shared_bo,
> >vcn.inst[i].fw_shared_gpu_addr, 
> >vcn.inst[i].fw_shared_cpu_addr);
> if (r) {
> -   dev_err(adev->dev, "VCN %d (%d) failed to allocate 
> fimware shared bo\n", i, r);
> +   dev_err(adev->dev, "VCN %d (%d) failed to allocate 
> firmware shared bo\n", i, r);
> return r;
> }
> }
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH][next] drm/amdgpu/vcn: fix spelling mistake "fimware" -> "firmware"

[Colin King]

From: Colin Ian King 

There is a spelling mistake in a dev_err error message. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index 328b6ceb80de..d653a18dcbc3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -187,7 +187,7 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM, 
>vcn.inst[i].fw_shared_bo,
>vcn.inst[i].fw_shared_gpu_addr, 
>vcn.inst[i].fw_shared_cpu_addr);
if (r) {
-   dev_err(adev->dev, "VCN %d (%d) failed to allocate 
fimware shared bo\n", i, r);
+   dev_err(adev->dev, "VCN %d (%d) failed to allocate 
firmware shared bo\n", i, r);
return r;
}
}
-- 
2.25.1

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

Re: [PATCH v3 4/4] MAINTAINERS: add files for Mediatek DRM drivers

[Matthias Brugger]

On 31/03/2020 17:57, Chun-Kuang Hu wrote:
> Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to
> drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers'
> information.
> 
> Signed-off-by: Chun-Kuang Hu 

Reviewed-by: Matthias Brugger 

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 38fe2f3f7b6f..129777037538 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5612,6 +5612,7 @@ M:  Philipp Zabel 
>  L:   dri-devel@lists.freedesktop.org
>  S:   Supported
>  F:   drivers/gpu/drm/mediatek/
> +F:   drivers/phy/mediatek/phy-mtk-hdmi*
>  F:   Documentation/devicetree/bindings/display/mediatek/
>  
>  DRM DRIVERS FOR NVIDIA TEGRA
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/4] phy: mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek folder

[Matthias Brugger]

On 31/03/2020 17:57, Chun-Kuang Hu wrote:
> From: CK Hu 
> 
> mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> more suitable to place a phy driver into phy driver folder, so move
> mtk_hdmi_phy driver into phy driver folder.
> 
> Signed-off-by: CK Hu 
> Signed-off-by: Chun-Kuang Hu 
> ---

Reviewed-by: Matthias Brugger 

>  drivers/gpu/drm/mediatek/Kconfig   | 7 ---
>  drivers/gpu/drm/mediatek/Makefile  | 6 --
>  drivers/phy/mediatek/Kconfig   | 7 +++
>  drivers/phy/mediatek/Makefile  | 7 +++
>  .../mediatek/phy-mtk-hdmi-mt2701.c}| 2 +-
>  .../mediatek/phy-mtk-hdmi-mt8173.c}| 2 +-
>  .../mtk_hdmi_phy.c => phy/mediatek/phy-mtk-hdmi.c} | 2 +-
>  .../mtk_hdmi_phy.h => phy/mediatek/phy-mtk-hdmi.h} | 0
>  8 files changed, 17 insertions(+), 16 deletions(-)
>  rename drivers/{gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c => 
> phy/mediatek/phy-mtk-hdmi-mt2701.c} (99%)
>  rename drivers/{gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c => 
> phy/mediatek/phy-mtk-hdmi-mt8173.c} (99%)
>  rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.c => 
> phy/mediatek/phy-mtk-hdmi.c} (99%)
>  rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.h => 
> phy/mediatek/phy-mtk-hdmi.h} (100%)
> 
> diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> b/drivers/gpu/drm/mediatek/Kconfig
> index ff6a1eb4ae83..2427d5bf699d 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -26,10 +26,3 @@ config DRM_MEDIATEK_HDMI
>   select PHY_MTK_HDMI
>   help
> DRM/KMS HDMI driver for Mediatek SoCs
> -
> -config PHY_MTK_HDMI
> -tristate "MediaTek HDMI-PHY Driver"
> -depends on ARCH_MEDIATEK && OF
> -select GENERIC_PHY
> -help
> -  Enable this to support HDMI-PHY
> diff --git a/drivers/gpu/drm/mediatek/Makefile 
> b/drivers/gpu/drm/mediatek/Makefile
> index fcbef23aa6ce..77b0fd86063d 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -22,9 +22,3 @@ mediatek-drm-hdmi-objs := mtk_cec.o \
> mtk_hdmi_ddc.o
>  
>  obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
> -
> -phy-mtk-hdmi-drv-objs := mtk_hdmi_phy.o \
> -  mtk_mt2701_hdmi_phy.o \
> -  mtk_mt8173_hdmi_phy.o
> -
> -obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> index dee757c957f2..10f0ec2d5b54 100644
> --- a/drivers/phy/mediatek/Kconfig
> +++ b/drivers/phy/mediatek/Kconfig
> @@ -35,3 +35,10 @@ config PHY_MTK_XSPHY
> Enable this to support the SuperSpeedPlus XS-PHY transceiver for
> USB3.1 GEN2 controllers on MediaTek chips. The driver supports
> multiple USB2.0, USB3.1 GEN2 ports.
> +
> +config PHY_MTK_HDMI
> +tristate "MediaTek HDMI-PHY Driver"
> +depends on ARCH_MEDIATEK && OF
> +select GENERIC_PHY
> +help
> +  Enable this to support HDMI-PHY
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index 08a8e6a97b1e..cda074c53235 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -6,3 +6,10 @@
>  obj-$(CONFIG_PHY_MTK_TPHY)   += phy-mtk-tphy.o
>  obj-$(CONFIG_PHY_MTK_UFS)+= phy-mtk-ufs.o
>  obj-$(CONFIG_PHY_MTK_XSPHY)  += phy-mtk-xsphy.o
> +
> +phy-mtk-hdmi-drv-objs := phy-mtk-hdmi.o \
> +  phy-mtk-hdmi-mt2701.o \
> +  phy-mtk-hdmi-mt8173.o
> +
> +obj-$(CONFIG_PHY_MTK_HDMI) += phy-mtk-hdmi-drv.o
> +
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
> b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> similarity index 99%
> rename from drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> rename to drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> index 99fe05cd3598..a6cb1dea3d0c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt2701.c
> @@ -4,7 +4,7 @@
>   * Author: Chunhui Dai 
>   */
>  
> -#include "mtk_hdmi_phy.h"
> +#include "phy-mtk-hdmi.h"
>  
>  #define HDMI_CON00x00
>  #define RG_HDMITX_DRV_IBIAS  0
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
> b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
> similarity index 99%
> rename from drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> rename to drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
> index b55f51675205..3521c4893c53 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
> +++ b/drivers/phy/mediatek/phy-mtk-hdmi-mt8173.c
> @@ -4,7 +4,7 @@
>   * Author: Jie Qiu 
>   */
>  
> -#include "mtk_hdmi_phy.h"
> +#include "phy-mtk-hdmi.h"
>  
>  #define HDMI_CON00x00
>  #define RG_HDMITX_PLL_EN BIT(31)
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c 
> b/drivers/phy/mediatek/phy-mtk-hdmi.c
> similarity index 99%
> 

RE: [PATCH 1/6] dma-buf: add peer2peer flag

[Ruhl, Michael J]

>-Original Message-
>From: dri-devel  On Behalf Of
>Daniel Vetter
>Sent: Wednesday, April 1, 2020 7:35 AM
>To: Christian König 
>Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH 1/6] dma-buf: add peer2peer flag
>
>On Mon, Mar 30, 2020 at 03:55:31PM +0200, Christian König wrote:
>> Add a peer2peer flag noting that the importer can deal with device
>> resources which are not backed by pages.
>>
>> Signed-off-by: Christian König 
>> ---
>>  drivers/dma-buf/dma-buf.c |  2 ++
>>  include/linux/dma-buf.h   | 10 ++
>>  2 files changed, 12 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index ccc9eda1bc28..570c923023e6 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -690,6 +690,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf,
>struct device *dev,
>>
>>  attach->dev = dev;
>>  attach->dmabuf = dmabuf;
>> +if (importer_ops)
>> +attach->peer2peer = importer_ops->allow_peer2peer;
>
>So an idea that crossed my mind to validate this, since we need quite some
>bad amounts of bad luck if someone accidentally introduces and access to
>struct_page in sg lists in some slowpath.
>
>On map_sg, if ->peer2peer is set, we could mangle the struct_page
>pointers, e.g. swap high bits for low bits (so that NULL stays NULL). On
>unmap_sg we obviously need to undo that, in case the exporter needs those
>pointers for its own book-keeping for some reason. I was also pondering
>just setting them all to NULL, but that might break some exporters. With
>the pointer mangling trick (especially if we flip high for low bits on 64
>where this should result in invalid addresses in almost all cases) we
>should be able to catch buggy p2p importers quite quickly.

The scatter list usage of the struct page pointer has other information in the
lower bits for keeping track of linking and other stuff.  Swizzling the page
pointers will probably make the scatter list unusable.

Mike

>Thoughts? Maybe add as a follow-up patch for testing?
>-Daniel
>>  attach->importer_ops = importer_ops;
>>  attach->importer_priv = importer_priv;
>>
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index 1ade486fc2bb..82e0a4a64601 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -334,6 +334,14 @@ struct dma_buf {
>>   * Attachment operations implemented by the importer.
>>   */
>>  struct dma_buf_attach_ops {
>> +/**
>> + * @allow_peer2peer:
>> + *
>> + * If this is set to true the importer must be able to handle peer
>> + * resources without struct pages.
>> + */
>> +bool allow_peer2peer;
>> +
>>  /**
>>   * @move_notify
>>   *
>> @@ -362,6 +370,7 @@ struct dma_buf_attach_ops {
>>   * @node: list of dma_buf_attachment, protected by dma_resv lock of the
>dmabuf.
>>   * @sgt: cached mapping.
>>   * @dir: direction of cached mapping.
>> + * @peer2peer: true if the importer can handle peer resources without
>pages.
>>   * @priv: exporter specific attachment data.
>>   * @importer_ops: importer operations for this attachment, if provided
>>   * dma_buf_map/unmap_attachment() must be called with the dma_resv
>lock held.
>> @@ -382,6 +391,7 @@ struct dma_buf_attachment {
>>  struct list_head node;
>>  struct sg_table *sgt;
>>  enum dma_data_direction dir;
>> +bool peer2peer;
>>  const struct dma_buf_attach_ops *importer_ops;
>>  void *importer_priv;
>>  void *priv;
>> --
>> 2.17.1
>>
>
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/4] drm/mediatek: Move tz_disabled from mtk_hdmi_phy to mtk_hdmi driver

[Matthias Brugger]

On 01/04/2020 04:16, Chunfeng Yun wrote:
> On Tue, 2020-03-31 at 23:57 +0800, Chun-Kuang Hu wrote:
>> From: CK Hu 
>>
>> tz_disabled is used to control mtk_hdmi output signal, but this variable
>> is stored in mtk_hdmi_phy and mtk_hdmi_phy does not use it. So move
>> tz_disabled to mtk_hdmi where it's used.
>>
>> Signed-off-by: CK Hu 
>> Signed-off-by: Chun-Kuang Hu 
>> ---
>>  drivers/gpu/drm/mediatek/mtk_hdmi.c   | 22 ---
>>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.h   |  1 -
>>  .../gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c|  1 -
>>  3 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
>> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
>> index 5e4a4dbda443..878433c09c9b 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
>> @@ -144,11 +144,16 @@ struct hdmi_audio_param {
>>  struct hdmi_codec_params codec_params;
>>  };
>>  
>> +struct mtk_hdmi_conf {
>> +bool tz_disabled;
>> +};
>> +
>>  struct mtk_hdmi {
>>  struct drm_bridge bridge;
>>  struct drm_bridge *next_bridge;
>>  struct drm_connector conn;
>>  struct device *dev;
>> +const struct mtk_hdmi_conf *conf;
>>  struct phy *phy;
>>  struct device *cec_dev;
>>  struct i2c_adapter *ddc_adpt;
>> @@ -230,7 +235,6 @@ static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi, 
>> bool black)
>>  static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool 
>> enable)
>>  {
>>  struct arm_smccc_res res;
>> -struct mtk_hdmi_phy *hdmi_phy = phy_get_drvdata(hdmi->phy);
>>  
>>  /*
>>   * MT8173 HDMI hardware has an output control bit to enable/disable HDMI
>> @@ -238,7 +242,7 @@ static void mtk_hdmi_hw_make_reg_writable(struct 
>> mtk_hdmi *hdmi, bool enable)
>>   * The ARM trusted firmware provides an API for the HDMI driver to set
>>   * this control bit to enable HDMI output in supervisor mode.
>>   */
>> -if (hdmi_phy->conf && hdmi_phy->conf->tz_disabled)
>> +if (hdmi->conf->tz_disabled)

Wouldn't we need to check:
if (hdmi->conf && hdmi->conf->tz_disabled)

>>  regmap_update_bits(hdmi->sys_regmap,
>> hdmi->sys_offset + HDMI_SYS_CFG20,
>> 0x80008005, enable ? 0x8005 : 0x8000);
>> @@ -1688,6 +1692,7 @@ static int mtk_drm_hdmi_probe(struct platform_device 
>> *pdev)
>>  return -ENOMEM;
>>  
>>  hdmi->dev = dev;
>> +hdmi->conf = of_device_get_match_data(dev);
>>  
>>  ret = mtk_hdmi_dt_parse_pdata(hdmi, pdev);
>>  if (ret)
>> @@ -1765,8 +1770,19 @@ static int mtk_hdmi_resume(struct device *dev)
>>  static SIMPLE_DEV_PM_OPS(mtk_hdmi_pm_ops,
>>   mtk_hdmi_suspend, mtk_hdmi_resume);
>>  
>> +static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = {
>> +.tz_disabled = true,
>> +};
>> +
>> +static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8173;
>> +
>>  static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
>> -{ .compatible = "mediatek,mt8173-hdmi", },
>> +{ .compatible = "mediatek,mt2701-hdmi",
>> +  .data = _hdmi_conf_mt2701,
>> +},
>> +{ .compatible = "mediatek,mt8173-hdmi",
>> +  .data = _hdmi_conf_mt8173,

We don't have any data? Then we should set data to NULL instead.

Regards,
Matthias

>> +},
>>  {}
>>  };
>>  
>> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h 
>> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
>> index 2d8b3182470d..fc1c2efd1128 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
>> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
>> @@ -20,7 +20,6 @@
>>  struct mtk_hdmi_phy;
>>  
>>  struct mtk_hdmi_phy_conf {
>> -bool tz_disabled;
>>  unsigned long flags;
>>  const struct clk_ops *hdmi_phy_clk_ops;
>>  void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
>> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
>> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
>> index d3cc4022e988..99fe05cd3598 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
>> @@ -237,7 +237,6 @@ static void mtk_hdmi_phy_disable_tmds(struct 
>> mtk_hdmi_phy *hdmi_phy)
>>  }
>>  
>>  struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
>> -.tz_disabled = true,
>>  .flags = CLK_SET_RATE_GATE,
>>  .hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
>>  .hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
> 
> Reviewed-by: Chunfeng Yun 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Sakari Ailus]

Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
the same implementation can be used.

Suggested-by: Mauro Carvalho Chehab 
Signed-off-by: Sakari Ailus 
---
 Documentation/core-api/printk-formats.rst | 11 +
 lib/vsprintf.c| 29 +++
 2 files changed, 40 insertions(+)

diff --git a/Documentation/core-api/printk-formats.rst 
b/Documentation/core-api/printk-formats.rst
index 8ebe46b1af39..b6249f513c09 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -545,6 +545,17 @@ For printing netdev_features_t.
 
 Passed by reference.
 
+V4L2 and DRM fourcc code (pixel format)
+---
+
+::
+
+   %ppf
+
+Print a 4cc code used by V4L2 or DRM.
+
+Passed by reference.
+
 Thanks
 ==
 
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 7c488a1ce318..b39f0ac317c5 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1721,6 +1721,32 @@ char *netdev_bits(char *buf, char *end, const void *addr,
return special_hex_number(buf, end, num, size);
 }
 
+static noinline_for_stack
+char *pixel_format_string(char *buf, char *end, const u32 *fourcc,
+ struct printf_spec spec, const char *fmt)
+{
+   char ch[2] = { 0 };
+   unsigned int i;
+
+   if (check_pointer(, end, fourcc, spec))
+   return buf;
+
+   switch (fmt[1]) {
+   case 'f':
+   for (i = 0; i < sizeof(*fourcc); i++) {
+   ch[0] = *fourcc >> (i << 3);
+   buf = string(buf, end, ch, spec);
+   }
+
+   if (*fourcc & BIT(31))
+   buf = string(buf, end, "-BE", spec);
+
+   return buf;
+   default:
+   return error_string(buf, end, "(%pp?)", spec);
+   }
+}
+
 static noinline_for_stack
 char *address_val(char *buf, char *end, const void *addr,
  struct printf_spec spec, const char *fmt)
@@ -2131,6 +2157,7 @@ char *fwnode_string(char *buf, char *end, struct 
fwnode_handle *fwnode,
  *   correctness of the format string and va_list arguments.
  * - 'K' For a kernel pointer that should be hidden from unprivileged users
  * - 'NF' For a netdev_features_t
+ * - 'pf' V4L2 or DRM pixel format.
  * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
  *a certain separator (' ' by default):
  *  C colon
@@ -2223,6 +2250,8 @@ char *pointer(const char *fmt, char *buf, char *end, void 
*ptr,
return restricted_pointer(buf, end, ptr, spec);
case 'N':
return netdev_bits(buf, end, ptr, spec, fmt);
+   case 'p':
+   return pixel_format_string(buf, end, ptr, spec, fmt);
case 'a':
return address_val(buf, end, ptr, spec, fmt);
case 'd':
-- 
2.20.1

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

Re: [PATCH 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

[Hans Verkuil]

On 4/1/20 4:05 PM, Sakari Ailus wrote:
> Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> the same implementation can be used.
> 
> Suggested-by: Mauro Carvalho Chehab 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/core-api/printk-formats.rst | 11 +
>  lib/vsprintf.c| 29 +++
>  2 files changed, 40 insertions(+)
> 
> diff --git a/Documentation/core-api/printk-formats.rst 
> b/Documentation/core-api/printk-formats.rst
> index 8ebe46b1af39..b6249f513c09 100644
> --- a/Documentation/core-api/printk-formats.rst
> +++ b/Documentation/core-api/printk-formats.rst
> @@ -545,6 +545,17 @@ For printing netdev_features_t.
>  
>  Passed by reference.
>  
> +V4L2 and DRM fourcc code (pixel format)
> +---
> +
> +::
> +
> + %ppf
> +
> +Print a 4cc code used by V4L2 or DRM.

FourCC appears to be the more-or-less official name 
(https://en.wikipedia.org/wiki/FourCC)

I would explain about the -BE suffix for bigendian fourcc variants.

> +
> +Passed by reference.
> +
>  Thanks
>  ==
>  
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 7c488a1ce318..b39f0ac317c5 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1721,6 +1721,32 @@ char *netdev_bits(char *buf, char *end, const void 
> *addr,
>   return special_hex_number(buf, end, num, size);
>  }
>  
> +static noinline_for_stack
> +char *pixel_format_string(char *buf, char *end, const u32 *fourcc,
> +   struct printf_spec spec, const char *fmt)
> +{
> + char ch[2] = { 0 };

This can just be '{ };'

> + unsigned int i;
> +
> + if (check_pointer(, end, fourcc, spec))
> + return buf;
> +
> + switch (fmt[1]) {
> + case 'f':
> + for (i = 0; i < sizeof(*fourcc); i++) {
> + ch[0] = *fourcc >> (i << 3);

You need to AND with 0x7f, otherwise a big endian fourcc (bit 31 is set)
will look wrong. Also, each character is standard 7 bit ascii, bit 7 isn't
used except to indicate a BE variant.

> + buf = string(buf, end, ch, spec);
> + }
> +
> + if (*fourcc & BIT(31))
> + buf = string(buf, end, "-BE", spec);
> +
> + return buf;
> + default:
> + return error_string(buf, end, "(%pp?)", spec);
> + }
> +}
> +
>  static noinline_for_stack
>  char *address_val(char *buf, char *end, const void *addr,
> struct printf_spec spec, const char *fmt)
> @@ -2131,6 +2157,7 @@ char *fwnode_string(char *buf, char *end, struct 
> fwnode_handle *fwnode,
>   *   correctness of the format string and va_list arguments.
>   * - 'K' For a kernel pointer that should be hidden from unprivileged users
>   * - 'NF' For a netdev_features_t
> + * - 'pf' V4L2 or DRM pixel format.

I'd say 'FourCC format' instead of 'pixel format'.

>   * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
>   *a certain separator (' ' by default):
>   *  C colon
> @@ -2223,6 +2250,8 @@ char *pointer(const char *fmt, char *buf, char *end, 
> void *ptr,
>   return restricted_pointer(buf, end, ptr, spec);
>   case 'N':
>   return netdev_bits(buf, end, ptr, spec, fmt);
> + case 'p':
> + return pixel_format_string(buf, end, ptr, spec, fmt);
>   case 'a':
>   return address_val(buf, end, ptr, spec, fmt);
>   case 'd':
> 

Regards,

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

[Bug 207047] Crash after failed to pin userptr on amdgpu

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=207047

--- Comment #2 from bigbeesh...@gmail.com ---
5.5.14 is out and should contain the fixes for the above 


https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.5.y=aeeda19db4ab8b8e5bf653835058728ebe26909f


https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.5.y=834de33d3c387345a4eb7511d039742fa91f87c5


https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.5.y=9f22030d75b2e9ee7d700c5e1837b050282668a1

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd/dc: Kill dc_conn_log_hex_linux()

[Kazlauskas, Nicholas]

On 2020-03-31 5:22 p.m., Lyude Paul wrote:

DRM already supports tracing DPCD transactions, there's no reason for
the existence of this function. Also, it prints one byte per-line which
is way too loud. So, just remove it.

Signed-off-by: Lyude Paul 


Thanks for helping clean this up!

Series is:

Reviewed-by: Nicholas Kazlauskas 

Regards,
Nicholas Kazlauskas


---
  .../gpu/drm/amd/display/dc/basics/Makefile|  3 +-
  .../drm/amd/display/dc/basics/log_helpers.c   | 39 ---
  .../amd/display/include/logger_interface.h|  4 --
  3 files changed, 1 insertion(+), 45 deletions(-)
  delete mode 100644 drivers/gpu/drm/amd/display/dc/basics/log_helpers.c

diff --git a/drivers/gpu/drm/amd/display/dc/basics/Makefile 
b/drivers/gpu/drm/amd/display/dc/basics/Makefile
index 7ad0cad0f4ef..01b99e0d788e 100644
--- a/drivers/gpu/drm/amd/display/dc/basics/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/basics/Makefile
@@ -24,8 +24,7 @@
  # It provides the general basic services required by other DAL
  # subcomponents.
  
-BASICS = conversion.o fixpt31_32.o \

-   log_helpers.o vector.o dc_common.o
+BASICS = conversion.o fixpt31_32.o vector.o dc_common.o
  
  AMD_DAL_BASICS = $(addprefix $(AMDDALPATH)/dc/basics/,$(BASICS))
  
diff --git a/drivers/gpu/drm/amd/display/dc/basics/log_helpers.c b/drivers/gpu/drm/amd/display/dc/basics/log_helpers.c

deleted file mode 100644
index 26583f346c39..
--- a/drivers/gpu/drm/amd/display/dc/basics/log_helpers.c
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * Copyright 2012-16 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors: AMD
- *
- */
-
-#include "core_types.h"
-#include "logger.h"
-#include "include/logger_interface.h"
-#include "dm_helpers.h"
-
-void dc_conn_log_hex_linux(const uint8_t *hex_data, int hex_data_count)
-{
-   int i;
-
-   if (hex_data)
-   for (i = 0; i < hex_data_count; i++)
-   DC_LOG_DEBUG("%2.2X ", hex_data[i]);
-}
-
diff --git a/drivers/gpu/drm/amd/display/include/logger_interface.h 
b/drivers/gpu/drm/amd/display/include/logger_interface.h
index 6e008de25629..02c23b04d34b 100644
--- a/drivers/gpu/drm/amd/display/include/logger_interface.h
+++ b/drivers/gpu/drm/amd/display/include/logger_interface.h
@@ -40,8 +40,6 @@ struct dc_state;
   *
   */
  
-void dc_conn_log_hex_linux(const uint8_t *hex_data, int hex_data_count);

-
  void pre_surface_trace(
struct dc *dc,
const struct dc_plane_state *const *plane_states,
@@ -102,14 +100,12 @@ void context_clock_trace(
  #define CONN_DATA_DETECT(link, hex_data, hex_len, ...) \
do { \
(void)(link); \
-   dc_conn_log_hex_linux(hex_data, hex_len); \
DC_LOG_EVENT_DETECTION(__VA_ARGS__); \
} while (0)
  
  #define CONN_DATA_LINK_LOSS(link, hex_data, hex_len, ...) \

do { \
(void)(link); \
-   dc_conn_log_hex_linux(hex_data, hex_len); \
DC_LOG_EVENT_LINK_LOSS(__VA_ARGS__); \
} while (0)
  



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

Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel

[Tomi Valkeinen]

On 25/03/2020 15:03, Laurent Pinchart wrote:

Hi Tomi,

On Wed, Mar 25, 2020 at 02:47:48PM +0200, Tomi Valkeinen wrote:

On 25/02/2020 01:20, Sebastian Reichel wrote:

This updates the existing omapdrm DSI code, so that it uses
common drm_mipi_dsi API and drm_panel.

The patchset has been tested with Droid 4 using Linux console, X.org and
Weston. The patchset is based on Laurent Pinchartl's patch series [0]
and removes the last custom panel driver, so quite a few cleanups on the
omapdrm codebase were possible.


This is a big series, and I suggest to keep the cleanups to minimum.
Things can be cleaned up afterwards after the functional parts of this
series have been merged.


There are a few cleanups at the bottom of the series that could be
merged without waiting for the rest though :-)


Yep. So, Sebastian, if there are patches that can be applied independently of this series, can you 
send those separately or move them to the beginning of the series.


There was also the change to include/drm/drm_mipi_dsi.h which is outside the OMAP context. Maybe 
send that separately to the relevant maintainers. Or at least cc them, as now it's kind of hidden 
between all the omap changes.


And I need to try to wake up one of my boards with a DSI video mode display for 
testing...

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 41/56] drm/omap: dsi: return proper error code from dsi_update_all()

[Tomi Valkeinen]

On 25/02/2020 01:21, Sebastian Reichel wrote:

Signed-off-by: Sebastian Reichel 
---
  drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index acbfffe83b3e..f629e6b1025b 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -3987,7 +3987,7 @@ static int dsi_update_all(struct omap_dss_device *dssdev)
return r;
}
  
-	return 0;

+   return r;
  }
  
  /* Display funcs */




Shouldn't this be squashed to earlier patch?

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm: msm: scale DDR BW along with GPU frequency

[Sharat Masetty]

On 3/31/2020 10:56 PM, Jordan Crouse wrote:

On Tue, Mar 31, 2020 at 01:25:51PM +0530, Sharat Masetty wrote:

This patch adds support to parse the OPP tables attached the GPU device,
the main opp table and the DDR bandwidth opp table. Additionally, vote
for the GPU->DDR bandwidth when setting the GPU frequency by querying
the linked DDR BW opp to the GPU opp.

Signed-off-by: Sharat Masetty 
---
  drivers/gpu/drm/msm/adreno/a6xx_gmu.c   | 41 ++
  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 44 +
  drivers/gpu/drm/msm/msm_gpu.h   |  9 +++
  3 files changed, 84 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 748cd37..489d9b6 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -100,6 +100,40 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
  }

+void a6xx_gmu_set_icc_vote(struct msm_gpu *gpu, unsigned long gpu_freq)
+{
+   struct dev_pm_opp *gpu_opp, *ddr_opp;
+   struct opp_table **tables = gpu->opp_tables;
+   unsigned long peak_bw;
+
+   if (!gpu->opp_tables[GPU_DDR_OPP_TABLE_INDEX])
+   goto done;
+
+   gpu_opp = dev_pm_opp_find_freq_exact(>pdev->dev, gpu_freq, true);
+   if (IS_ERR_OR_NULL(gpu_opp))
+   goto done;
+
+   ddr_opp = dev_pm_opp_xlate_required_opp(tables[GPU_OPP_TABLE_INDEX],
+   tables[GPU_DDR_OPP_TABLE_INDEX],
+   gpu_opp);
+   dev_pm_opp_put(gpu_opp);
+
+   if (IS_ERR_OR_NULL(ddr_opp))
+   goto done;

I think that the final approach is still up in the air but either way we're
going to pull the bandwidth from an OPP, its just a question of which OPP.


+   peak_bw = dev_pm_opp_get_bw(ddr_opp, NULL);
+   dev_pm_opp_put(ddr_opp);
+
+   icc_set_bw(gpu->icc_path, 0, peak_bw);
+   return;
+done:
+   /*
+* If there is a problem, for now leave it at max so that the
+* performance is nominal.
+*/
+   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+}
+
  static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
  {
struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
@@ -128,11 +162,8 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int 
index)

gmu->freq = gmu->gpu_freqs[index];

-   /*
-* Eventually we will want to scale the path vote with the frequency but
-* for now leave it at max so that the performance is nominal.
-*/
-   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+   if (gpu->icc_path)
+   a6xx_gmu_set_icc_vote(gpu, gmu->freq);

This function is annoying because we call it from two different spots, but it
feels wasteful that devfreq gives us an OPP pointer and we go out of our way to
not use it only to search for it again in the set_icc_vote function. I think
maybe we should pass the OPP through from msm_gpu.c.  We could have a helper
function to pull the initial opp in a6xx_gmu_resume to make it clean.


Yes Jordan, it makes sense. I did think about this too, but may be I 
was  a bit too lazy to change the existing plumbing :)


I will take care of this in the next iteration.




  }

  void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 2d13694..bbbcc7a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -882,7 +882,7 @@ static int adreno_get_pwrlevels(struct device *dev,
  {
unsigned long freq = ULONG_MAX;
struct dev_pm_opp *opp;
-   int ret;
+   int ret, i;

gpu->fast_rate = 0;

@@ -890,9 +890,29 @@ static int adreno_get_pwrlevels(struct device *dev,
if (!of_find_property(dev->of_node, "operating-points-v2", NULL))
ret = adreno_get_legacy_pwrlevels(dev);
else {
-   ret = dev_pm_opp_of_add_table(dev);
-   if (ret)
-   DRM_DEV_ERROR(dev, "Unable to set the OPP table\n");
+   int count = of_count_phandle_with_args(dev->of_node,
+   "operating-points-v2", NULL);
+
+   count = min(count, GPU_DDR_OPP_TABLE_INDEX + 1);
+   count = max(count, 1);
+
+   for (i = 0; i < count; i++) {
+   ret = dev_pm_opp_of_add_table_indexed(dev, i);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "Add OPP table %d: failed 
%d\n",
+   i, ret);
+   goto err;
+   }
+
+   gpu->opp_tables[i] =
+   

Re: [PATCHv2 18/56] drm/omap: panel-dsi-cm: use common MIPI DCS 1.3 defines

[Tomi Valkeinen]

On 25/02/2020 01:20, Sebastian Reichel wrote:

Drop local definition of common MIPI DCS 1.3 defines.

Signed-off-by: Sebastian Reichel 
---
  drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)


Reviewed-by: Tomi Valkeinen 

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 10/56] drm/omap: dsi: drop virtual channel logic

[Tomi Valkeinen]

On 01/04/2020 14:33, Laurent Pinchart wrote:

Hi Tomi,

On Wed, Apr 01, 2020 at 02:30:25PM +0300, Tomi Valkeinen wrote:

On 25/02/2020 17:01, Laurent Pinchart wrote:

On Tue, Feb 25, 2020 at 12:20:40AM +0100, Sebastian Reichel wrote:

This drops the virtual channel logic. Afterwards DSI clients
request their channel number and get the virtual channel with
the same number or -EBUSY if already in use.


I wonder why this level of indirection was used, allocating "virtual
VCs". A single virtual indirection should be enough :-) I may be missing
some context though, I'll defer that to Tomi, but for me,


I haven't reviewed the code yet, and it's been a long time since I wrote this 
code. But maybe this
explains at least some:

(I hope I remember this right)

DSI packets have virtual channel IDs (VCID). That's number 0-3 that needs to be 
in the packets.

DSI IP has virtual channel "blocks" (VC), with associated registers. So 4 VC 
register blocks. These
are not related to DSI virtual channel IDs in any way.

To do DSI transactions, you choose a VC, and program it. A VC can send data via 
video pipeline, or
transmit and receive data messages created with CPU. And in both cases, you 
need to include the VCID
in the transmissions, of course.

So, I think a normal use case could be a single panel, with VCID 0. To send 
video data and control
messages, you would use VC0 and VC1. VC0 would be configured for video data, 
and VC1 would be
configured for control messages.

And if I recall right, currently you first request a free VC from the IP with 
request_vc(). Then you
use set_vc_id(channel, id) to set the VCID, used when doing transactions with 
that VC.

So the virtual channel naming is pretty confusing in the DSI IP, in my opinion.


I wasn't aware of those details, thank you for the explanation. It's
quite confusing indeed, let's try to document the architecture in a
comment block at the beginning of the dsi.c file for later reference.


But also, I think there's much room for cleanups and improvements. I don't think we have ever really 
supported multiple DSI peripherals, even in theory. So just one peripheral, with VCID always 0.


Even if we need two VCs to manage that single peripheral (I think that's often the case, we want one 
VC for video, one for control), we could fully hide that detail into the driver. This won't work 
with more than 2 DSI peripherals, but I think we can just say the driver supports a single 
peripheral, and that's it.


But with a quick browsing of this patch, I don't think it does it right, as it looks to me that the 
patch makes VCID == VC.


 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 10/56] drm/omap: dsi: drop virtual channel logic

[Tomi Valkeinen]

On 25/02/2020 17:01, Laurent Pinchart wrote:

Hi Sebastian,

Thank you for the patch.

On Tue, Feb 25, 2020 at 12:20:40AM +0100, Sebastian Reichel wrote:

This drops the virtual channel logic. Afterwards DSI clients
request their channel number and get the virtual channel with
the same number or -EBUSY if already in use.


I wonder why this level of indirection was used, allocating "virtual
VCs". A single virtual indirection should be enough :-) I may be missing
some context though, I'll defer that to Tomi, but for me,


I haven't reviewed the code yet, and it's been a long time since I wrote this code. But maybe this 
explains at least some:


(I hope I remember this right)

DSI packets have virtual channel IDs (VCID). That's number 0-3 that needs to be 
in the packets.

DSI IP has virtual channel "blocks" (VC), with associated registers. So 4 VC register blocks. These 
are not related to DSI virtual channel IDs in any way.


To do DSI transactions, you choose a VC, and program it. A VC can send data via video pipeline, or 
transmit and receive data messages created with CPU. And in both cases, you need to include the VCID 
in the transmissions, of course.


So, I think a normal use case could be a single panel, with VCID 0. To send video data and control 
messages, you would use VC0 and VC1. VC0 would be configured for video data, and VC1 would be 
configured for control messages.


And if I recall right, currently you first request a free VC from the IP with request_vc(). Then you 
use set_vc_id(channel, id) to set the VCID, used when doing transactions with that VC.


So the virtual channel naming is pretty confusing in the DSI IP, in my opinion.

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] dma-buf: add peer2peer flag

[Daniel Vetter]

On Mon, Mar 30, 2020 at 03:55:31PM +0200, Christian König wrote:
> Add a peer2peer flag noting that the importer can deal with device
> resources which are not backed by pages.
> 
> Signed-off-by: Christian König 
> ---
>  drivers/dma-buf/dma-buf.c |  2 ++
>  include/linux/dma-buf.h   | 10 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index ccc9eda1bc28..570c923023e6 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -690,6 +690,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
> device *dev,
>  
>   attach->dev = dev;
>   attach->dmabuf = dmabuf;
> + if (importer_ops)
> + attach->peer2peer = importer_ops->allow_peer2peer;

So an idea that crossed my mind to validate this, since we need quite some
bad amounts of bad luck if someone accidentally introduces and access to
struct_page in sg lists in some slowpath.

On map_sg, if ->peer2peer is set, we could mangle the struct_page
pointers, e.g. swap high bits for low bits (so that NULL stays NULL). On
unmap_sg we obviously need to undo that, in case the exporter needs those
pointers for its own book-keeping for some reason. I was also pondering
just setting them all to NULL, but that might break some exporters. With
the pointer mangling trick (especially if we flip high for low bits on 64
where this should result in invalid addresses in almost all cases) we
should be able to catch buggy p2p importers quite quickly.

Thoughts? Maybe add as a follow-up patch for testing?
-Daniel
>   attach->importer_ops = importer_ops;
>   attach->importer_priv = importer_priv;
>  
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 1ade486fc2bb..82e0a4a64601 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -334,6 +334,14 @@ struct dma_buf {
>   * Attachment operations implemented by the importer.
>   */
>  struct dma_buf_attach_ops {
> + /**
> +  * @allow_peer2peer:
> +  *
> +  * If this is set to true the importer must be able to handle peer
> +  * resources without struct pages.
> +  */
> + bool allow_peer2peer;
> +
>   /**
>* @move_notify
>*
> @@ -362,6 +370,7 @@ struct dma_buf_attach_ops {
>   * @node: list of dma_buf_attachment, protected by dma_resv lock of the 
> dmabuf.
>   * @sgt: cached mapping.
>   * @dir: direction of cached mapping.
> + * @peer2peer: true if the importer can handle peer resources without pages.
>   * @priv: exporter specific attachment data.
>   * @importer_ops: importer operations for this attachment, if provided
>   * dma_buf_map/unmap_attachment() must be called with the dma_resv lock held.
> @@ -382,6 +391,7 @@ struct dma_buf_attachment {
>   struct list_head node;
>   struct sg_table *sgt;
>   enum dma_data_direction dir;
> + bool peer2peer;
>   const struct dma_buf_attach_ops *importer_ops;
>   void *importer_priv;
>   void *priv;
> -- 
> 2.17.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 10/56] drm/omap: dsi: drop virtual channel logic

[Laurent Pinchart]

Hi Tomi,

On Wed, Apr 01, 2020 at 02:30:25PM +0300, Tomi Valkeinen wrote:
> On 25/02/2020 17:01, Laurent Pinchart wrote:
> > On Tue, Feb 25, 2020 at 12:20:40AM +0100, Sebastian Reichel wrote:
> >> This drops the virtual channel logic. Afterwards DSI clients
> >> request their channel number and get the virtual channel with
> >> the same number or -EBUSY if already in use.
> > 
> > I wonder why this level of indirection was used, allocating "virtual
> > VCs". A single virtual indirection should be enough :-) I may be missing
> > some context though, I'll defer that to Tomi, but for me,
> 
> I haven't reviewed the code yet, and it's been a long time since I wrote this 
> code. But maybe this 
> explains at least some:
> 
> (I hope I remember this right)
> 
> DSI packets have virtual channel IDs (VCID). That's number 0-3 that needs to 
> be in the packets.
> 
> DSI IP has virtual channel "blocks" (VC), with associated registers. So 4 VC 
> register blocks. These 
> are not related to DSI virtual channel IDs in any way.
> 
> To do DSI transactions, you choose a VC, and program it. A VC can send data 
> via video pipeline, or 
> transmit and receive data messages created with CPU. And in both cases, you 
> need to include the VCID 
> in the transmissions, of course.
> 
> So, I think a normal use case could be a single panel, with VCID 0. To send 
> video data and control 
> messages, you would use VC0 and VC1. VC0 would be configured for video data, 
> and VC1 would be 
> configured for control messages.
> 
> And if I recall right, currently you first request a free VC from the IP with 
> request_vc(). Then you 
> use set_vc_id(channel, id) to set the VCID, used when doing transactions with 
> that VC.
> 
> So the virtual channel naming is pretty confusing in the DSI IP, in my 
> opinion.

I wasn't aware of those details, thank you for the explanation. It's
quite confusing indeed, let's try to document the architecture in a
comment block at the beginning of the dsi.c file for later reference.

-- 
Regards,

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

Re: [PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Takashi Iwai]

On Wed, 01 Apr 2020 12:35:16 +0200,
Michael Ellerman wrote:
> 
> Michal Simek  writes:
> > On 01. 04. 20 4:07, Michael Ellerman wrote:
> >> Michal Simek  writes:
> >>> Hi,
> >>>
> >>> recently we wanted to update xilinx intc driver and we found that function
> >>> which we wanted to remove is still wired by ancient Xilinx PowerPC
> >>> platforms. Here is the thread about it.
> >>> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/
> >>>
> >>> I have been talking about it internally and there is no interest in these
> >>> platforms and it is also orphan for quite a long time. None is really
> >>> running/testing these platforms regularly that's why I think it makes 
> >>> sense
> >>> to remove them also with drivers which are specific to this platform.
> >>>
> >>> U-Boot support was removed in 2017 without anybody complain about it
> >>> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed
> >>>
> >>> Based on current ppc/next.
> >>>
> >>> If anyone has any objection about it, please let me know.
> >> 
> >> Thanks for taking the time to find all this code and remove it.
> >> 
> >> I'm not going to take this series for v5.7, it was posted too close to
> >> the merge window, and doing so wouldn't give people much time to object,
> >> especially given people are distracted at the moment.
> >> 
> >> I'm happy to take it for v5.8, assuming there's no major objections.
> >
> > Sure. Just to let you know Christophe Leroy included this patch in his
> > series about ppc405 removal. It should be the same.
> >
> > If you don't want to take that alsa patch I can send it separately and
> > this patch can be taken from his series. I don't really mind but please
> > let me know what way you prefer.
> 
> It's better to keep it all together, so I'm happy take the alsa patch as
> well, it's already been acked.

Sure, please go ahead.


thanks,

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

Re: [git pull] drm for 5.7-rc1

[Jani Nikula]

On Wed, 01 Apr 2020, Dave Airlie  wrote:
> i915 and amdgpu have initial OLED backlight support

I suppose we've had a bunch of "initial support" code for a long time
already, but only now Lyude made it actually work on real world
machines. ;)

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] drm/mm: revert "Break long searches in fragmented address spaces"

[Christian König]

Am 01.04.20 um 10:53 schrieb Chris Wilson:

Quoting Christian König (2020-04-01 08:29:34)

Am 31.03.20 um 15:19 schrieb Chris Wilson:

Quoting Daniel Vetter (2020-03-31 11:38:50)

On Tue, Mar 31, 2020 at 11:20 AM Chris Wilson  wrote:

Quoting Daniel Vetter (2020-03-31 10:16:18)

On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote:
[SNIP]

We allow userspace to poison the drm_mm at roughly 8K intervals, a
search space of 35b with typically O(N^2) behaviour and each node
traversal (rb_next/rb_prev) will itself be costly. Even our simple tests
can generate a search of several minutes before our patience runs out.o
Any drm_mm that allows for userspace to control alignment can be
arbitrarily fragmented, hence a raised eyebrow that this search would be
allowed in atomic context.

Wow, that is indeed quite a lot.

What is the criteria use for ordering the tree? Just the size or is that
size+alignment?

The tree is just size. Alignment is a little used parameter, but there's
a requirement for userspace to be able to control it -- although it is
strictly the older interface, it is still open to abuse.

Converting the tree to [size, ffs(addr)] would help for many, but on top
of that we have zones in the drm_mm, so search-in-range can be abused on
top of search-for-alignment.


The difference is that search in range is not controllable by userspace, 
but at least for amdgpu the alignment is very well controllable.



Never looked into this, but maybe we have a low hanging fruit for an
improvement here?

A bit -- alignment is so rarely used in practice, optimising it was not
a concern, just someone else has now noticed the potential for abuse.


Well we do use alignment rather widely. IIRC we can have everything 
between 4K and 2MB based on the tilling flags, memory channel config etc 
etc...



They ran a test, get bored and complained that it didn't respond to ^C
for a long period of time and from that derive a proof-of-concept test to
show how it can be used by one client to upset another :|


And as far as I can see that is a really valid problem we need to fix. 
Give me a second to write a test case for this.


Thanks for pointing that out,
Christian.

  

I'm not 100% sure, but moving away from atomic context wouldn't be that
easy.

Fair enough. I would not worry unless the layout is controllable by the
user -- but we probably want some other means of bounding the search.
-Chris


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

Re: [PATCH 2/2] drm/core: Calculate bpp in afbc helper

[Daniel Vetter]

On Tue, Mar 31, 2020 at 05:53:08PM +0200, Andrzej Pietrasiewicz wrote:
> Some drivers (komeda, malidp) don't set anything in cpp. If that is the
> case the right value can be inferred from the format. Then the "bpp" member
> can be eliminated from struct drm_afbc_framebuffer.
> 
> Signed-off-by: Andrzej Pietrasiewicz 

Didn't check computations, but yup this matches what I had in mind.

Acked-by: Daniel Vetter 
> ---
>  Documentation/gpu/todo.rst   | 15 
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 39 
>  include/drm/drm_framebuffer.h|  7 
>  3 files changed, 32 insertions(+), 29 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 37a3a023c114..439656f55c5d 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -404,21 +404,6 @@ Contact: Laurent Pinchart, respective driver maintainers
>  
>  Level: Intermediate
>  
> -Encode cpp properly in malidp
> --
> -
> -cpp (chars per pixel) is not encoded properly in malidp, zero is
> -used instead. afbc implementation needs bpp or cpp, but if it is
> -zero it needs to be provided elsewhere, and so the bpp field exists
> -in struct drm_afbc_framebuffer.
> -
> -Properly encode cpp in malidp and remove the bpp field in struct
> -drm_afbc_framebuffer.
> -
> -Contact: malidp maintainers
> -
> -Level: Intermediate
> -
>  Core refactorings
>  =
>  
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index 6fb1841fa71c..cac15294aef6 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -309,11 +309,37 @@ drm_gem_fb_create_with_dirty(struct drm_device *dev, 
> struct drm_file *file,
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
>  
> +static __u32 drm_gem_afbc_get_bpp(struct drm_device *dev,
> +   const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + const struct drm_format_info *info;
> +
> + info = drm_get_format_info(dev, mode_cmd);
> +
> + /* use whatever a driver has set */
> + if (info->cpp[0])
> + return info->cpp[0] * 8;
> +
> + /* guess otherwise */
> + switch (info->format) {
> + case DRM_FORMAT_YUV420_8BIT:
> + return 12;
> + case DRM_FORMAT_YUV420_10BIT:
> + return 15;
> + case DRM_FORMAT_VUY101010:
> + return 30;
> + default:
> + break;
> + }
> +
> + /* all attempts failed */
> + return 0;
> +}
> +
>  static int drm_gem_afbc_min_size(struct drm_device *dev,
>const struct drm_mode_fb_cmd2 *mode_cmd,
>struct drm_afbc_framebuffer *afbc_fb)
>  {
> - const struct drm_format_info *info;
>   __u32 n_blocks, w_alignment, h_alignment, hdr_alignment;
>   /* remove bpp when all users properly encode cpp in drm_format_info */
>   __u32 bpp;
> @@ -351,12 +377,11 @@ static int drm_gem_afbc_min_size(struct drm_device *dev,
>   afbc_fb->aligned_height = ALIGN(mode_cmd->height, h_alignment);
>   afbc_fb->offset = mode_cmd->offsets[0];
>  
> - info = drm_get_format_info(dev, mode_cmd);
> - /*
> -  * Change to always using info->cpp[0]
> -  * when all users properly encode it
> -  */
> - bpp = info->cpp[0] ? info->cpp[0] * 8 : afbc_fb->bpp;
> + bpp = drm_gem_afbc_get_bpp(dev, mode_cmd);
> + if (!bpp) {
> + drm_dbg_kms(dev, "Invalid AFBC bpp value: %d\n", bpp);
> + return -EINVAL;
> + }
>  
>   n_blocks = (afbc_fb->aligned_width * afbc_fb->aligned_height)
>  / AFBC_SUPERBLOCK_PIXELS;
> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> index b53c0332f040..be658ebbec72 100644
> --- a/include/drm/drm_framebuffer.h
> +++ b/include/drm/drm_framebuffer.h
> @@ -331,13 +331,6 @@ struct drm_afbc_framebuffer {
>* @afbc_size: minimum size of afbc buffer
>*/
>   u32 afbc_size;
> - /**
> -  * @bpp: bpp value for this afbc buffer
> -  * To be removed when users such as malidp
> -  * properly store the cpp in drm_format_info.
> -  * New users should not start using this field.
> -  */
> - u32 bpp;
>  };
>  
>  #define fb_to_afbc_fb(x) container_of(x, struct drm_afbc_framebuffer, base)
> -- 
> 2.17.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/core: Use proper debugging macro

[Daniel Vetter]

On Tue, Mar 31, 2020 at 05:53:07PM +0200, Andrzej Pietrasiewicz wrote:
> Use drm_dbg_kms() instead of DRM_DEBUG_KMS.
> 
> Signed-off-by: Andrzej Pietrasiewicz 

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index 7e3982c36baa..6fb1841fa71c 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -331,9 +331,9 @@ static int drm_gem_afbc_min_size(struct drm_device *dev,
>   case AFBC_FORMAT_MOD_BLOCK_SIZE_64x4:
>   case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4:
>   default:
> - DRM_DEBUG_KMS("Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
> -   mode_cmd->modifier[0]
> -   & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
> + drm_dbg_kms(dev, "Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
> + mode_cmd->modifier[0]
> + & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
>   return -EINVAL;
>   }
>  
> -- 
> 2.17.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: INFO: trying to register non-static key in try_to_wake_up

[Daniel Vetter]

On Wed, Apr 1, 2020 at 10:59 AM Daniel Vetter  wrote:
>
> On Wed, Apr 1, 2020 at 10:47 AM Dmitry Vyukov  wrote:
> >
> > On Tue, Mar 31, 2020 at 2:50 PM Daniel Vetter  wrote:
> > >
> > > On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz
> > >  wrote:
> > > >
> > > >
> > > > On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> > > > > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra 
> > > > >  wrote:
> > > > >>
> > > > >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> > > > >>> Hello,
> > > > >>>
> > > > >>> syzbot found the following crash on:
> > > > >>>
> > > > >>> HEAD commit:9420e8ad Merge tag 'for-linus' of 
> > > > >>> git://git.kernel.org/pub..
> > > > >>> git tree:   upstream
> > > > >>> console output: 
> > > > >>> https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be0
> > > > >>> kernel config:  
> > > > >>> https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> > > > >>> dashboard link: 
> > > > >>> https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> > > > >>> 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+e84d7ebd1361da13c...@syzkaller.appspotmail.com
> > > > >>>
> > > > >>> INFO: trying to register non-static key.
> > > > >>> the code is fine but needs lockdep annotation.
> > > > >>> turning off the locking correctness validator.
> > > > >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 
> > > > >>> 5.6.0-rc7-syzkaller #0
> > > > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, 
> > > > >>> BIOS Google 01/01/2011
> > > > >>> Call Trace:
> > > > >>>  
> > > > >>>  __dump_stack lib/dump_stack.c:77 [inline]
> > > > >>>  dump_stack+0x188/0x20d lib/dump_stack.c:118
> > > > >>>  assign_lock_key kernel/locking/lockdep.c:880 [inline]
> > > > >>>  register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> > > > >>>  __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> > > > >>>  lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> > > > >>>  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 
> > > > >>> [inline]
> > > > >>>  _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> > > > >>>  try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
> > > > >>
> > > > >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
> > > > >> copy_process(). This should be impossible. Very odd.
> > > > >
> > > > > The stack mentions fbdev, which is a red flag at the moment. There are
> > > > > a dozen of bad bugs in fbdev and around. Just few days ago Andy
> > > > > pointed to another "impossible" crash "general protection fault in
> > > > > do_syscall_64" which is related to dri:
> > > > > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
> > > > > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ
> > > > >
> > > > > There are probably more random manifestations of these bugs already,
> > > > > and I guess we will be getting more.
> > > > >
> > > > > +fbdev maintainers
> > > >
> > > > Thank you for the report.
> > > >
> > > > fbdev is in the maintenance mode and no new features or drivers are
> > > > being added so syzbot reports are not for a new bugs (regressions) and
> > > > are not a priority (at least to me).
> > >
> > > Yup same here, I've seen a pile of syzbot reports for fbdev (and also
> > > vt, or combinations of them since fbdev is linked to vt through fbcon)
> > > fly by. But I really don't have to deal with these, my recommendation
> > > to anyone who cares about security are:
> > > - Don't enable vt
> > > - Don't enable fbdev
> >
> > 1. How do we deliver this message to relevant people?
> >
> > Because:
> >
> > $ grep FBDEV syzkaller/dashboard/config/upstream-kasan.config
> > CONFIG_DRM_FBDEV_EMULATION=y
> > CONFIG_DRM_FBDEV_OVERALLOC=100
> > # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> > CONFIG_XEN_FBDEV_FRONTEND=y
> >
> > and my current work machine:
> >
> > $ grep FBDEV /boot/config-5.2.17-1-amd64
> > CONFIG_DRM_FBDEV_EMULATION=y
> > CONFIG_DRM_FBDEV_OVERALLOC=100
> > # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> > CONFIG_XEN_FBDEV_FRONTEND=y
>
> Yeah I know it's been like this since forever. In theory you could
> build a fbdev/fbcon less distro since years (the last bit for a proof
> of concept was kmscon/systemd-consoled), but the amount of 

Re: INFO: trying to register non-static key in try_to_wake_up

[Daniel Vetter]

On Wed, Apr 1, 2020 at 10:47 AM Dmitry Vyukov  wrote:
>
> On Tue, Mar 31, 2020 at 2:50 PM Daniel Vetter  wrote:
> >
> > On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz
> >  wrote:
> > >
> > >
> > > On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> > > > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra  
> > > > wrote:
> > > >>
> > > >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> > > >>> Hello,
> > > >>>
> > > >>> syzbot found the following crash on:
> > > >>>
> > > >>> HEAD commit:9420e8ad Merge tag 'for-linus' of 
> > > >>> git://git.kernel.org/pub..
> > > >>> git tree:   upstream
> > > >>> console output: 
> > > >>> https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be0
> > > >>> kernel config:  
> > > >>> https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> > > >>> dashboard link: 
> > > >>> https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> > > >>> 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+e84d7ebd1361da13c...@syzkaller.appspotmail.com
> > > >>>
> > > >>> INFO: trying to register non-static key.
> > > >>> the code is fine but needs lockdep annotation.
> > > >>> turning off the locking correctness validator.
> > > >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller 
> > > >>> #0
> > > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, 
> > > >>> BIOS Google 01/01/2011
> > > >>> Call Trace:
> > > >>>  
> > > >>>  __dump_stack lib/dump_stack.c:77 [inline]
> > > >>>  dump_stack+0x188/0x20d lib/dump_stack.c:118
> > > >>>  assign_lock_key kernel/locking/lockdep.c:880 [inline]
> > > >>>  register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> > > >>>  __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> > > >>>  lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> > > >>>  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> > > >>>  _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> > > >>>  try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
> > > >>
> > > >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
> > > >> copy_process(). This should be impossible. Very odd.
> > > >
> > > > The stack mentions fbdev, which is a red flag at the moment. There are
> > > > a dozen of bad bugs in fbdev and around. Just few days ago Andy
> > > > pointed to another "impossible" crash "general protection fault in
> > > > do_syscall_64" which is related to dri:
> > > > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
> > > > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ
> > > >
> > > > There are probably more random manifestations of these bugs already,
> > > > and I guess we will be getting more.
> > > >
> > > > +fbdev maintainers
> > >
> > > Thank you for the report.
> > >
> > > fbdev is in the maintenance mode and no new features or drivers are
> > > being added so syzbot reports are not for a new bugs (regressions) and
> > > are not a priority (at least to me).
> >
> > Yup same here, I've seen a pile of syzbot reports for fbdev (and also
> > vt, or combinations of them since fbdev is linked to vt through fbcon)
> > fly by. But I really don't have to deal with these, my recommendation
> > to anyone who cares about security are:
> > - Don't enable vt
> > - Don't enable fbdev
>
> 1. How do we deliver this message to relevant people?
>
> Because:
>
> $ grep FBDEV syzkaller/dashboard/config/upstream-kasan.config
> CONFIG_DRM_FBDEV_EMULATION=y
> CONFIG_DRM_FBDEV_OVERALLOC=100
> # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> CONFIG_XEN_FBDEV_FRONTEND=y
>
> and my current work machine:
>
> $ grep FBDEV /boot/config-5.2.17-1-amd64
> CONFIG_DRM_FBDEV_EMULATION=y
> CONFIG_DRM_FBDEV_OVERALLOC=100
> # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> CONFIG_XEN_FBDEV_FRONTEND=y

Yeah I know it's been like this since forever. In theory you could
build a fbdev/fbcon less distro since years (the last bit for a proof
of concept was kmscon/systemd-consoled), but the amount of investment
into classic linux desktop is so little that it's impossible to get
this funded. CrOS fixed this a while ago iirc though.

I think to fix the syzbot issues all we'd need is a competent intern
for a few months, that should take care of the worst stuff. Obviously

Re: [PATCH] drm/mm: revert "Break long searches in fragmented address spaces"

[Chris Wilson]

Quoting Christian König (2020-04-01 08:29:34)
> Am 31.03.20 um 15:19 schrieb Chris Wilson:
> > Quoting Daniel Vetter (2020-03-31 11:38:50)
> >> On Tue, Mar 31, 2020 at 11:20 AM Chris Wilson  
> >> wrote:
> >>> Quoting Daniel Vetter (2020-03-31 10:16:18)
>  On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote:
> > A not so gentle ping, since this pretty much broke all TTM based 
> > drivers.
> >
> > Could we revert this for now?
>  Always ack for revert.
> 
>  Acked-by: Daniel Vetter 
> >>> So you didn't check the earlier patch either?
> >> I did, but wasn't super sold on the idea of more flags to smack an r-b
> >> onto it, so figured I'll throw the default ack-for-revert on this
> >> meanwhile.
> > We allow userspace to poison the drm_mm at roughly 8K intervals, a
> > search space of 35b with typically O(N^2) behaviour and each node
> > traversal (rb_next/rb_prev) will itself be costly. Even our simple tests
> > can generate a search of several minutes before our patience runs out.o
> > Any drm_mm that allows for userspace to control alignment can be
> > arbitrarily fragmented, hence a raised eyebrow that this search would be
> > allowed in atomic context.
> 
> Wow, that is indeed quite a lot.
> 
> What is the criteria use for ordering the tree? Just the size or is that 
> size+alignment?

The tree is just size. Alignment is a little used parameter, but there's
a requirement for userspace to be able to control it -- although it is
strictly the older interface, it is still open to abuse.

Converting the tree to [size, ffs(addr)] would help for many, but on top
of that we have zones in the drm_mm, so search-in-range can be abused on
top of search-for-alignment.
 
> Never looked into this, but maybe we have a low hanging fruit for an 
> improvement here?

A bit -- alignment is so rarely used in practice, optimising it was not
a concern, just someone else has now noticed the potential for abuse.
They ran a test, get bored and complained that it didn't respond to ^C
for a long period of time and from that derive a proof-of-concept test to
show how it can be used by one client to upset another :|
 
> I'm not 100% sure, but moving away from atomic context wouldn't be that 
> easy.

Fair enough. I would not worry unless the layout is controllable by the
user -- but we probably want some other means of bounding the search.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: How to handle disconnection of eDP panels due to dynamic display mux switches

[Jani Nikula]

On Tue, 31 Mar 2020, Daniel Dadap  wrote:
> On 3/30/20 10:11 AM, Jani Nikula wrote:
>> On Fri, 27 Mar 2020, Daniel Dadap  wrote:
>>> A number of hybrid GPU notebook computer designs with dual (integrated
>>> plus discrete) GPUs are equipped with multiplexers (muxes) that allow
>>> display panels to be driven by either the integrated GPU or the discrete
>>> GPU. Typically, this is a selection that can be made at boot time as a
>>> menu option in the system firmware's setup screen, and the mux selection
>>> stays fixed for as long as the system is running and persists across
>>> reboots until it is explicitly changed. However, some muxed hybrid GPU
>>> systems have dynamically switchable muxes which can be switched while
>>> the system is running.
>>>
>>> NVIDIA is exploring the possibility of taking advantage of dynamically
>>> switchable muxes to enhance the experience of using a hybrid GPU system.
>>> For example, on a system configured for PRIME render offloading, it may
>>> be possible to keep the discrete GPU powered down and use the integrated
>>> GPU for rendering and displaying the desktop when no applications are
>>> using the discrete GPU, and dynamically switch the panel to be driven
>>> directly by the discrete GPU when render-offloading a fullscreen
>>> application.
>>>
>>> We have been conducting some experiments on systems with dynamic muxes,
>>> and have found some limitations that would need to be addressed in order
>>> to support use cases like the one suggested above:
>>>
>>> * In at least the i915 DRM-KMS driver, and likely in other DRM-KMS
>>> drivers as well, eDP panels are assumed to be always connected. This
>>> assumption is broken when the panel is muxed away, which can cause
>>> problems. A typical symptom is i915 repeatedly attempting to retrain the
>>> link, severely impacting system performance and printing messages like
>>> the following every five seconds or so:
>>>
>>> [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link
>>> training
>>> [drm] Reducing the compressed framebuffer size. This may lead to less
>>> power savings than a non-reduced-size. Try to increase stolen memory
>>> size if available in BIOS.
>>>
>>> This symptom might occur if something causes the DRM-KMS driver to probe
>>> the display while it's muxed away, for example a modeset or DPMS state
>>> change.
>>>
>>> * When switching the mux back to a GPU that was previously driving a
>>> mode, it is necessary to at the very least retrain DP links to restore
>>> the previously displayed image. In a proof of concept I have been
>>> experimenting with, I am able to accomplish this from userspace by
>>> triggering DPMS off and then back on again; however, it would be good to
>>> have an in-kernel API to request that an output owned by a DRM-KMS
>>> driver be refreshed to resume driving a mode on a disconnected and
>>> reconnected display. This API would need to be accessible from outside
>>> of the DRM-KMS driver handling the output. One reason it would be good
>>> to do this within the kernel, rather than rely on e.g. DPMS operations
>>> in the xf86-video-modesetting driver, is that it would be useful for
>>> restoring the console if X crashes or is forcefully killed while the mux
>>> is switched to a GPU other than the one which drives the console.
>>>
>>> Basically, we'd like to be able to do the following:
>>>
>>> 1) Communicate to a DRM-KMS driver that an output is disconnected and
>>> can't be used. Ideally, DRI clients such as X should still see the
>>> output as being connected, so user applications don't need to keep track
>>> of the change.
>> I think everything will be much easier if you provide a way for
>> userspace to control the muxing using the KMS API, and not lie to the
>> userspace about what's going on.
>>
>> You're not actually saying what component you think should control the
>> muxing.
>>
>> Why should the drivers keep telling the userspace the output is
>> connected when it's not? Obviously the userspace should also switch to
>> using a different output on a different GPU, right? Or are you planning
>> some proprietary behind the scenes hack for discrete?
>
>
> The desire to lie to userspace is driven mainly by trying to avoid 
> interactions from desktop environments / window managers reacting to the 
> display going away. Many desktops will do things like try to migrate 
> windows in response to a change in the current display configuration, 
> and updating all of them to avoid doing so when a display appears to 
> disappear from one GPU and reappear on another GPU seems harder than 
> allowing userspace to believe that nothing has changed. I wouldn't mind 
> if e.g. X drivers were in on the lie, and the lie boundary shifts to 
> RandR, but it would be nice to avoid having to deal with the fallout of 
> desktop environments handling displays apparently vanishing and 
> re-appearing.

If the change from one GPU to another was driven and initiated by
userspace, it would 

Re: How to handle disconnection of eDP panels due to dynamic display mux switches

[Pekka Paalanen]

On Tue, 31 Mar 2020 20:59:39 -0500
Daniel Dadap  wrote:

> On 3/30/20 10:11 AM, Jani Nikula wrote:
> > On Fri, 27 Mar 2020, Daniel Dadap  wrote:  
> >> A number of hybrid GPU notebook computer designs with dual (integrated
> >> plus discrete) GPUs are equipped with multiplexers (muxes) that allow
> >> display panels to be driven by either the integrated GPU or the discrete
> >> GPU. Typically, this is a selection that can be made at boot time as a
> >> menu option in the system firmware's setup screen, and the mux selection
> >> stays fixed for as long as the system is running and persists across
> >> reboots until it is explicitly changed. However, some muxed hybrid GPU
> >> systems have dynamically switchable muxes which can be switched while
> >> the system is running.
> >>
> >> NVIDIA is exploring the possibility of taking advantage of dynamically
> >> switchable muxes to enhance the experience of using a hybrid GPU system.
> >> For example, on a system configured for PRIME render offloading, it may
> >> be possible to keep the discrete GPU powered down and use the integrated
> >> GPU for rendering and displaying the desktop when no applications are
> >> using the discrete GPU, and dynamically switch the panel to be driven
> >> directly by the discrete GPU when render-offloading a fullscreen
> >> application.
> >>
> >> We have been conducting some experiments on systems with dynamic muxes,
> >> and have found some limitations that would need to be addressed in order
> >> to support use cases like the one suggested above:
> >>
> >> * In at least the i915 DRM-KMS driver, and likely in other DRM-KMS
> >> drivers as well, eDP panels are assumed to be always connected. This
> >> assumption is broken when the panel is muxed away, which can cause
> >> problems. A typical symptom is i915 repeatedly attempting to retrain the
> >> link, severely impacting system performance and printing messages like
> >> the following every five seconds or so:
> >>
> >> [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link
> >> training
> >> [drm] Reducing the compressed framebuffer size. This may lead to less
> >> power savings than a non-reduced-size. Try to increase stolen memory
> >> size if available in BIOS.
> >>
> >> This symptom might occur if something causes the DRM-KMS driver to probe
> >> the display while it's muxed away, for example a modeset or DPMS state
> >> change.
> >>
> >> * When switching the mux back to a GPU that was previously driving a
> >> mode, it is necessary to at the very least retrain DP links to restore
> >> the previously displayed image. In a proof of concept I have been
> >> experimenting with, I am able to accomplish this from userspace by
> >> triggering DPMS off and then back on again; however, it would be good to
> >> have an in-kernel API to request that an output owned by a DRM-KMS
> >> driver be refreshed to resume driving a mode on a disconnected and
> >> reconnected display. This API would need to be accessible from outside
> >> of the DRM-KMS driver handling the output. One reason it would be good
> >> to do this within the kernel, rather than rely on e.g. DPMS operations
> >> in the xf86-video-modesetting driver, is that it would be useful for
> >> restoring the console if X crashes or is forcefully killed while the mux
> >> is switched to a GPU other than the one which drives the console.
> >>
> >> Basically, we'd like to be able to do the following:
> >>
> >> 1) Communicate to a DRM-KMS driver that an output is disconnected and
> >> can't be used. Ideally, DRI clients such as X should still see the
> >> output as being connected, so user applications don't need to keep track
> >> of the change.  
> > I think everything will be much easier if you provide a way for
> > userspace to control the muxing using the KMS API, and not lie to the
> > userspace about what's going on.
> >
> > You're not actually saying what component you think should control the
> > muxing.
> >
> > Why should the drivers keep telling the userspace the output is
> > connected when it's not? Obviously the userspace should also switch to
> > using a different output on a different GPU, right? Or are you planning
> > some proprietary behind the scenes hack for discrete?  
> 
> 
> The desire to lie to userspace is driven mainly by trying to avoid 
> interactions from desktop environments / window managers reacting to the 
> display going away. Many desktops will do things like try to migrate 
> windows in response to a change in the current display configuration, 
> and updating all of them to avoid doing so when a display appears to 
> disappear from one GPU and reappear on another GPU seems harder than 
> allowing userspace to believe that nothing has changed. I wouldn't mind 
> if e.g. X drivers were in on the lie, and the lie boundary shifts to 
> RandR, but it would be nice to avoid having to deal with the fallout of 
> desktop environments handling displays apparently vanishing and 
> 

Re: [PATCH] drm/mm: revert "Break long searches in fragmented address spaces"

[Christian König]

Am 31.03.20 um 15:19 schrieb Chris Wilson:

Quoting Daniel Vetter (2020-03-31 11:38:50)

On Tue, Mar 31, 2020 at 11:20 AM Chris Wilson  wrote:

Quoting Daniel Vetter (2020-03-31 10:16:18)

On Tue, Mar 31, 2020 at 10:59:45AM +0200, Christian König wrote:

A not so gentle ping, since this pretty much broke all TTM based drivers.

Could we revert this for now?

Always ack for revert.

Acked-by: Daniel Vetter 

So you didn't check the earlier patch either?

I did, but wasn't super sold on the idea of more flags to smack an r-b
onto it, so figured I'll throw the default ack-for-revert on this
meanwhile.

We allow userspace to poison the drm_mm at roughly 8K intervals, a
search space of 35b with typically O(N^2) behaviour and each node
traversal (rb_next/rb_prev) will itself be costly. Even our simple tests
can generate a search of several minutes before our patience runs out.o
Any drm_mm that allows for userspace to control alignment can be
arbitrarily fragmented, hence a raised eyebrow that this search would be
allowed in atomic context.


Wow, that is indeed quite a lot.

What is the criteria use for ordering the tree? Just the size or is that 
size+alignment?


Never looked into this, but maybe we have a low hanging fruit for an 
improvement here?


I'm not 100% sure, but moving away from atomic context wouldn't be that 
easy.


Christian.


-Chris


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

Re: [PATCH v2 2/2] powerpc: Remove Xilinx PPC405/PPC440 support

[Nick Desaulniers]

On Mon, Mar 30, 2020 at 6:32 AM Michal Simek  wrote:
>
> The latest Xilinx design tools called ISE and EDK has been released in
> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
> These platforms are no longer supported and tested.
>
> PowerPC 405/440 port is orphan from 2013 by
> commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
> commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and 
> maintainership")
> that's why it is time to remove the support fot these platforms.
>
> Signed-off-by: Michal Simek 
> Acked-by: Arnd Bergmann 

Is this per chance related to:
https://lore.kernel.org/linux-next/1e0a9c45-e525-a3ac-b352-e236d8427...@xilinx.com/
We just hit that error today without our CI on ppc32 builds:
https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/builds/157031633

> ---
>
> Changes in v2:
> - Based on my chat with Arnd I removed arch/powerpc/xmon/ changes done in
>   v1 to keep them the same as before. (kbuild reported some issues with it
>   too)
>
>  Documentation/devicetree/bindings/xilinx.txt | 143 --
>  Documentation/powerpc/bootwrapper.rst|  28 +-
>  MAINTAINERS  |   6 -
>  arch/powerpc/Kconfig.debug   |   2 +-
>  arch/powerpc/boot/Makefile   |   7 +-
>  arch/powerpc/boot/dts/Makefile   |   1 -
>  arch/powerpc/boot/dts/virtex440-ml507.dts| 406 
>  arch/powerpc/boot/dts/virtex440-ml510.dts| 466 ---
>  arch/powerpc/boot/ops.h  |   1 -
>  arch/powerpc/boot/serial.c   |   5 -
>  arch/powerpc/boot/uartlite.c |  79 
>  arch/powerpc/boot/virtex.c   |  97 
>  arch/powerpc/boot/virtex405-head.S   |  31 --
>  arch/powerpc/boot/wrapper|   8 -
>  arch/powerpc/configs/40x/virtex_defconfig|  75 ---
>  arch/powerpc/configs/44x/virtex5_defconfig   |  74 ---
>  arch/powerpc/configs/ppc40x_defconfig|   8 -
>  arch/powerpc/configs/ppc44x_defconfig|   8 -
>  arch/powerpc/include/asm/xilinx_intc.h   |  16 -
>  arch/powerpc/include/asm/xilinx_pci.h|  21 -
>  arch/powerpc/kernel/cputable.c   |  39 --
>  arch/powerpc/platforms/40x/Kconfig   |  31 --
>  arch/powerpc/platforms/40x/Makefile  |   1 -
>  arch/powerpc/platforms/40x/virtex.c  |  54 ---
>  arch/powerpc/platforms/44x/Kconfig   |  37 --
>  arch/powerpc/platforms/44x/Makefile  |   2 -
>  arch/powerpc/platforms/44x/virtex.c  |  60 ---
>  arch/powerpc/platforms/44x/virtex_ml510.c|  30 --
>  arch/powerpc/platforms/Kconfig   |   4 -
>  arch/powerpc/sysdev/Makefile |   2 -
>  arch/powerpc/sysdev/xilinx_intc.c|  88 
>  arch/powerpc/sysdev/xilinx_pci.c | 132 --
>  drivers/char/Kconfig |   2 +-
>  drivers/video/fbdev/Kconfig  |   2 +-
>  34 files changed, 7 insertions(+), 1959 deletions(-)
>  delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
>  delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
>  delete mode 100644 arch/powerpc/boot/uartlite.c
>  delete mode 100644 arch/powerpc/boot/virtex.c
>  delete mode 100644 arch/powerpc/boot/virtex405-head.S
>  delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig
>  delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig
>  delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h
>  delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h
>  delete mode 100644 arch/powerpc/platforms/40x/virtex.c
>  delete mode 100644 arch/powerpc/platforms/44x/virtex.c
>  delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
>  delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c
>  delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c
>
> diff --git a/Documentation/devicetree/bindings/xilinx.txt 
> b/Documentation/devicetree/bindings/xilinx.txt
> index d058ace29345..28199b31fe5e 100644
> --- a/Documentation/devicetree/bindings/xilinx.txt
> +++ b/Documentation/devicetree/bindings/xilinx.txt
> @@ -86,149 +86,6 @@
> xlnx,use-parity = <0>;
> };
>
> -   Some IP cores actually implement 2 or more logical devices.  In
> -   this case, the device should still describe the whole IP core with
> -   a single node and add a child node for each logical device.  The
> -   ranges property can be used to translate from parent IP-core to the
> -   registers of each device.  In addition, the parent node should be
> -   compatible with the bus type 'xlnx,compound', and should contain
> -   #address-cells and #size-cells, as with any other bus.  (Note: this
> -   makes the assumption that both logical devices have the same bus
> -   binding.  If this is not true, then separate nodes should be used
> -   for each logical device).  The 'cell-index' property can be used to
> -   enumerate logical devices within an 

Re: INFO: trying to register non-static key in try_to_wake_up

[Dmitry Vyukov]

On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra  wrote:
>
> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
> > git tree:   upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1206ed4be0
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> > dashboard link: https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> > 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+e84d7ebd1361da13c...@syzkaller.appspotmail.com
> >
> > INFO: trying to register non-static key.
> > the code is fine but needs lockdep annotation.
> > turning off the locking correctness validator.
> > CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> > Google 01/01/2011
> > Call Trace:
> >  
> >  __dump_stack lib/dump_stack.c:77 [inline]
> >  dump_stack+0x188/0x20d lib/dump_stack.c:118
> >  assign_lock_key kernel/locking/lockdep.c:880 [inline]
> >  register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> >  __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> >  lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> >  __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> >  _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> >  try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
>
> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
> copy_process(). This should be impossible. Very odd.

The stack mentions fbdev, which is a red flag at the moment. There are
a dozen of bad bugs in fbdev and around. Just few days ago Andy
pointed to another "impossible" crash "general protection fault in
do_syscall_64" which is related to dri:
https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ

There are probably more random manifestations of these bugs already,
and I guess we will be getting more.

+fbdev maintainers



> >  wake_up_worker kernel/workqueue.c:836 [inline]
> >  insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
> >  __queue_work+0x50d/0x1280 kernel/workqueue.c:1488
> >  call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
> >  expire_timers kernel/time/timer.c:1444 [inline]
> >  __run_timers kernel/time/timer.c:1773 [inline]
> >  __run_timers kernel/time/timer.c:1740 [inline]
> >  run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
> >  __do_softirq+0x26c/0x99d kernel/softirq.c:292
> >  invoke_softirq kernel/softirq.c:373 [inline]
> >  irq_exit+0x192/0x1d0 kernel/softirq.c:413
> >  exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> >  smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
> >  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> >  
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/syzkaller-bugs/20200331095737.GO20730%40hirez.programming.kicks-ass.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 20/22] drm/vkms: Use simple encoder

[Thomas Zimmermann]

Hi

Am 24.03.20 um 12:59 schrieb Rodrigo Siqueira:
> Hi Thomas,
> 
> First of all, thanks for your patch!
> 
> I applied all your series, compiled it, and when I tried
> `make INSTALL_MOD_PATH=/PATH/ modules_instal` I got the following
> message:
> 
>  depmod: ERROR: Cycle detected: drm_kms_helper -> drm -> drm_kms_helper
>  depmod: ERROR: Found 2 modules in dependency cycles!
>  make: *** [Makefile:1317: _modinst_post] Error 1
> 
> I cleaned up my local files and tried again, but I got the same error;
> If I just use `drm-misc-next` everything is fine.  Did I miss something?

I figured out that this problem is caused by the patch for the writeback
encoder, which is located in the DRM core. I'll drop the patch. Thanks
for testing!

Best regards
Thomas

> 
> Thanks
> 
> On 03/05, Thomas Zimmermann wrote:
>> The vkms driver uses an empty implementation for its encoder. Replace
>> the code with the generic simple encoder.
>>
>> Signed-off-by: Thomas Zimmermann 
>> ---
>>  drivers/gpu/drm/vkms/vkms_output.c | 8 ++--
>>  1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vkms/vkms_output.c 
>> b/drivers/gpu/drm/vkms/vkms_output.c
>> index fb1941a6522c..85afb77e97f0 100644
>> --- a/drivers/gpu/drm/vkms/vkms_output.c
>> +++ b/drivers/gpu/drm/vkms/vkms_output.c
>> @@ -3,6 +3,7 @@
>>  #include "vkms_drv.h"
>>  #include 
>>  #include 
>> +#include 
>>  
>>  static void vkms_connector_destroy(struct drm_connector *connector)
>>  {
>> @@ -17,10 +18,6 @@ static const struct drm_connector_funcs 
>> vkms_connector_funcs = {
>>  .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>  };
>>  
>> -static const struct drm_encoder_funcs vkms_encoder_funcs = {
>> -.destroy = drm_encoder_cleanup,
>> -};
>> -
>>  static int vkms_conn_get_modes(struct drm_connector *connector)
>>  {
>>  int count;
>> @@ -70,8 +67,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int 
>> index)
>>  
>>  drm_connector_helper_add(connector, _conn_helper_funcs);
>>  
>> -ret = drm_encoder_init(dev, encoder, _encoder_funcs,
>> -   DRM_MODE_ENCODER_VIRTUAL, NULL);
>> +ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_VIRTUAL);
>>  if (ret) {
>>  DRM_ERROR("Failed to init encoder\n");
>>  goto err_encoder;
>> -- 
>> 2.25.1
>>
> 
> 
> ___
> 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: How to handle disconnection of eDP panels due to dynamic display mux switches

[Daniel Dadap]

On 3/31/20 2:32 AM, Daniel Vetter wrote:

Since I see no mention of this anywhere in your mail ... have you
tried looking at drivers/gpu/vga/vga_switcheroo.c? This also supports
switching of just outputs, not just the old optimus way of switching
out the entire gpu and having to disable the other one.



We did look into vga-switcheroo while developing our PoC, but found it 
insufficient for supporting the use case we had in mind in its current 
form. Among the limitations we observed were that it didn't seem to be 
possible to switch with output-level granularity, only with gpu-level 
granularity, with the whole switched-away-to GPU being powered down. 
Your description suggests that this is indeed possible, but if that's 
the case, then the mechanism for doing so isn't obvious in what I can 
see of the API from the kernel source code, even in the drm-next tree. 
Do you have pointers to documentation on how the per-output switching is 
supposed to work?


Other limitations of vga-switcheroo included:

* The can_switch() callbacks for all current vga-switcheroo-capable GPU 
drivers don't seem to allow for a switch to occur while there are active 
KMS clients. This has the effect of making it so that non-deferred 
switches can only be initiated under the same circumstances that 
deferred switches wait for.
* It's only possible to address one mux device. Some systems have 
separate muxes for internal and external displays. From what I could see 
in existing vga-switcheroo mux handlers, it seems that multi-muxed 
systems just switch all of the muxes simultaneously, which makes sense 
for the all-or-nothing "power down the GPU not in use" approach, but 
might not be desirable for fine-grained output-level switching.
* On some systems, it's possible to put the panel into a self-refresh 
mode before switching the mux and exit self-refresh mode after 
switching, to hide any glitches that might otherwise appear while 
transitioning. Additional handler callbacks for pre-switch and 
post-switch operations would be useful.


If vga-switcheroo could be updated to address these limitatons, then it 
could make sense to handle the display disconnect/connect notifications 
and display refreshing as part of a vga_switcheroo client driver's 
set_gpu_state() callback (or a finer-grained per-output callback); 
however, it also seems that it should be possible to implement APIs 
within the DRM subsystem to accomplish the desired functionality 
independently of current or future vga-switcheroo design.




There's some rough corners (like the uapi doesn't exist, it's in
debugfs), and the locking has an inversion problem (I have ideas), but
generally what you want exists already.
-Daniel

On Mon, Mar 30, 2020 at 9:12 AM Daniel Dadap  wrote:

A number of hybrid GPU notebook computer designs with dual (integrated
plus discrete) GPUs are equipped with multiplexers (muxes) that allow
display panels to be driven by either the integrated GPU or the discrete
GPU. Typically, this is a selection that can be made at boot time as a
menu option in the system firmware's setup screen, and the mux selection
stays fixed for as long as the system is running and persists across
reboots until it is explicitly changed. However, some muxed hybrid GPU
systems have dynamically switchable muxes which can be switched while
the system is running.

NVIDIA is exploring the possibility of taking advantage of dynamically
switchable muxes to enhance the experience of using a hybrid GPU system.
For example, on a system configured for PRIME render offloading, it may
be possible to keep the discrete GPU powered down and use the integrated
GPU for rendering and displaying the desktop when no applications are
using the discrete GPU, and dynamically switch the panel to be driven
directly by the discrete GPU when render-offloading a fullscreen
application.

We have been conducting some experiments on systems with dynamic muxes,
and have found some limitations that would need to be addressed in order
to support use cases like the one suggested above:

* In at least the i915 DRM-KMS driver, and likely in other DRM-KMS
drivers as well, eDP panels are assumed to be always connected. This
assumption is broken when the panel is muxed away, which can cause
problems. A typical symptom is i915 repeatedly attempting to retrain the
link, severely impacting system performance and printing messages like
the following every five seconds or so:

[drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link
training
[drm] Reducing the compressed framebuffer size. This may lead to less
power savings than a non-reduced-size. Try to increase stolen memory
size if available in BIOS.

This symptom might occur if something causes the DRM-KMS driver to probe
the display while it's muxed away, for example a modeset or DPMS state
change.

* When switching the mux back to a GPU that was previously driving a
mode, it is necessary to at the very least retrain DP links to restore
the 

[PATCH] drm/bridge: adv7511: Fix cec clock EPROBE_DEFER handling

[Vincent Whitchurch]

If adv7511's devm_clk_get() for the cec clock returns -EPROBE_DEFER, we
end up in an infinite probe loop.  This happens:

 (1) adv7511's probe is called.

 (2) adv7511's probe adds some secondary i2c devices which bind to the
 dummy driver and thus call driver_deferred_probe_trigger() and
 increment deferred_trigger_count (see driver_bound()).

 (3) adv7511's probe returns -EPROBE_DEFER, and since the
 deferred_trigger_count has changed during the probe call,
 driver_deferred_probe_trigger() is called immediately (see
 really_probe()) and adv7511's probe is scheduled.

 (4) Goto step 1.

[   61.972915] really_probe: bus: 'i2c': really_probe: probing driver adv7511 
with device 0-0039
[   61.992734] really_probe: bus: 'i2c': really_probe: probing driver dummy 
with device 0-003f
[   61.993343] driver_bound: driver: 'dummy': driver_bound: bound to device 
'0-003f'
[   61.993626] really_probe: bus: 'i2c': really_probe: bound device 0-003f to 
driver dummy
[   61.995604] really_probe: bus: 'i2c': really_probe: probing driver dummy 
with device 0-0038
[   61.996381] driver_bound: driver: 'dummy': driver_bound: bound to device 
'0-0038'
[   61.996663] really_probe: bus: 'i2c': really_probe: bound device 0-0038 to 
driver dummy
[   61.998651] really_probe: bus: 'i2c': really_probe: probing driver dummy 
with device 0-003c
[   61.999222] driver_bound: driver: 'dummy': driver_bound: bound to device 
'0-003c'
[   61.999496] really_probe: bus: 'i2c': really_probe: bound device 0-003c to 
driver dummy
[   62.010050] really_probe: i2c 0-0039: Driver adv7511 requests probe deferral
[   62.011380] really_probe: bus: 'platform': really_probe: probing driver 
pwm-clock with device clock-cec
[   62.012812] really_probe: platform clock-cec: Driver pwm-clock requests 
probe deferral
[   62.024679] really_probe: bus: 'i2c': really_probe: probing driver adv7511 
with device 0-0039

Fix this by calling devm_clk_get() before registering the secondary
devices.

Signed-off-by: Vincent Whitchurch 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 30 +++-
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 11 +--
 2 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
index a20a45c0b353..4b0fee32be21 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
@@ -286,28 +286,17 @@ static const struct cec_adap_ops adv7511_cec_adap_ops = {
.adap_transmit = adv7511_cec_adap_transmit,
 };
 
-static int adv7511_cec_parse_dt(struct device *dev, struct adv7511 *adv7511)
-{
-   adv7511->cec_clk = devm_clk_get(dev, "cec");
-   if (IS_ERR(adv7511->cec_clk)) {
-   int ret = PTR_ERR(adv7511->cec_clk);
-
-   adv7511->cec_clk = NULL;
-   return ret;
-   }
-   clk_prepare_enable(adv7511->cec_clk);
-   adv7511->cec_clk_freq = clk_get_rate(adv7511->cec_clk);
-   return 0;
-}
-
 int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
 {
unsigned int offset = adv7511->type == ADV7533 ?
ADV7533_REG_CEC_OFFSET : 0;
-   int ret = adv7511_cec_parse_dt(dev, adv7511);
+   int ret;
 
-   if (ret)
-   goto err_cec_parse_dt;
+   if (!adv7511->cec_clk)
+   goto err_cec_no_clock;
+
+   clk_prepare_enable(adv7511->cec_clk);
+   adv7511->cec_clk_freq = clk_get_rate(adv7511->cec_clk);
 
adv7511->cec_adap = cec_allocate_adapter(_cec_adap_ops,
adv7511, dev_name(dev), CEC_CAP_DEFAULTS, ADV7511_MAX_ADDRS);
@@ -342,8 +331,11 @@ int adv7511_cec_init(struct device *dev, struct adv7511 
*adv7511)
 err_cec_alloc:
dev_info(dev, "Initializing CEC failed with error %d, disabling CEC\n",
 ret);
-err_cec_parse_dt:
+   clk_disable_unprepare(adv7511->cec_clk);
+   /* Ensure that adv7511_remove() doesn't attempt to disable it again. */
+   adv7511->cec_clk = NULL;
+err_cec_no_clock:
regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
 ADV7511_CEC_CTRL_POWER_DOWN);
-   return ret == -EPROBE_DEFER ? ret : 0;
+   return 0;
 }
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 9e13e466e72c..ebc548e23ece 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1122,6 +1122,15 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
if (ret)
return ret;
 
+   adv7511->cec_clk = devm_clk_get(dev, "cec");
+   if (IS_ERR(adv7511->cec_clk)) {
+   ret = PTR_ERR(adv7511->cec_clk);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+
+   adv7511->cec_clk = NULL;
+   }
+
ret = adv7511_init_regulators(adv7511);
  

Re: [PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michal Simek]

On 01. 04. 20 4:07, Michael Ellerman wrote:
> Michal Simek  writes:
>> Hi,
>>
>> recently we wanted to update xilinx intc driver and we found that function
>> which we wanted to remove is still wired by ancient Xilinx PowerPC
>> platforms. Here is the thread about it.
>> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/
>>
>> I have been talking about it internally and there is no interest in these
>> platforms and it is also orphan for quite a long time. None is really
>> running/testing these platforms regularly that's why I think it makes sense
>> to remove them also with drivers which are specific to this platform.
>>
>> U-Boot support was removed in 2017 without anybody complain about it
>> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed
>>
>> Based on current ppc/next.
>>
>> If anyone has any objection about it, please let me know.
> 
> Thanks for taking the time to find all this code and remove it.
> 
> I'm not going to take this series for v5.7, it was posted too close to
> the merge window, and doing so wouldn't give people much time to object,
> especially given people are distracted at the moment.
> 
> I'm happy to take it for v5.8, assuming there's no major objections.

Sure. Just to let you know Christophe Leroy included this patch in his
series about ppc405 removal. It should be the same.

If you don't want to take that alsa patch I can send it separately and
this patch can be taken from his series. I don't really mind but please
let me know what way you prefer.

Thanks,
Michal

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

Re: [PATCH v3 3/4] phy: mediatek: Move mtk_hdmi_phy driver into drivers/phy/mediatek folder

[Chunfeng Yun]

On Tue, 2020-03-31 at 23:57 +0800, Chun-Kuang Hu wrote:
> From: CK Hu 
> 
> mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
> more suitable to place a phy driver into phy driver folder, so move
> mtk_hdmi_phy driver into phy driver folder.
> 
> Signed-off-by: CK Hu 
> Signed-off-by: Chun-Kuang Hu 
> ---
>  drivers/gpu/drm/mediatek/Kconfig   | 7 ---
>  drivers/gpu/drm/mediatek/Makefile  | 6 --
>  drivers/phy/mediatek/Kconfig   | 7 +++
>  drivers/phy/mediatek/Makefile  | 7 +++
>  .../mediatek/phy-mtk-hdmi-mt2701.c}| 2 +-
>  .../mediatek/phy-mtk-hdmi-mt8173.c}| 2 +-
>  .../mtk_hdmi_phy.c => phy/mediatek/phy-mtk-hdmi.c} | 2 +-
>  .../mtk_hdmi_phy.h => phy/mediatek/phy-mtk-hdmi.h} | 0
>  8 files changed, 17 insertions(+), 16 deletions(-)
>  rename drivers/{gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c => 
> phy/mediatek/phy-mtk-hdmi-mt2701.c} (99%)
>  rename drivers/{gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c => 
> phy/mediatek/phy-mtk-hdmi-mt8173.c} (99%)
>  rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.c => 
> phy/mediatek/phy-mtk-hdmi.c} (99%)
>  rename drivers/{gpu/drm/mediatek/mtk_hdmi_phy.h => 
> phy/mediatek/phy-mtk-hdmi.h} (100%)
> 
Reviewed-by: Chunfeng Yun 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Update my email address in various drivers

[Hans Verkuil]

On 3/29/20 12:19 PM, Russell King wrote:
> Globally update my email address in six files scattered through the
> tree.
> 
> Signed-off-by: Russell King 

For media/cec files:

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/gpu/drm/armada/armada_drv.c | 2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c   | 2 +-
>  drivers/media/cec/cec-notifier.c| 2 +-
>  drivers/net/phy/swphy.c | 2 +-
>  include/media/cec-notifier.h| 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 3df2dacf4c94..5a82a12cd105 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -389,7 +389,7 @@ static void __exit armada_drm_exit(void)
>  }
>  module_exit(armada_drm_exit);
>  
> -MODULE_AUTHOR("Russell King ");
> +MODULE_AUTHOR("Russell King ");
>  MODULE_DESCRIPTION("Armada DRM Driver");
>  MODULE_LICENSE("GPL");
>  MODULE_ALIAS("platform:armada-drm");
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> index e8e3e9339ff9..f6f55776e43e 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
> @@ -698,7 +698,7 @@ static struct platform_driver snd_dw_hdmi_driver = {
>  
>  module_platform_driver(snd_dw_hdmi_driver);
>  
> -MODULE_AUTHOR("Russell King ");
> +MODULE_AUTHOR("Russell King ");
>  MODULE_DESCRIPTION("Synopsis Designware HDMI AHB ALSA interface");
>  MODULE_LICENSE("GPL v2");
>  MODULE_ALIAS("platform:" DRIVER_NAME);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index 1f9c01be40d7..d6798f716b77 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -739,7 +739,7 @@ static void __exit etnaviv_exit(void)
>  module_exit(etnaviv_exit);
>  
>  MODULE_AUTHOR("Christian Gmeiner ");
> -MODULE_AUTHOR("Russell King ");
> +MODULE_AUTHOR("Russell King ");
>  MODULE_AUTHOR("Lucas Stach ");
>  MODULE_DESCRIPTION("etnaviv DRM Driver");
>  MODULE_LICENSE("GPL v2");
> diff --git a/drivers/media/cec/cec-notifier.c 
> b/drivers/media/cec/cec-notifier.c
> index 7cf42b133dbc..2d4f7dd7cef7 100644
> --- a/drivers/media/cec/cec-notifier.c
> +++ b/drivers/media/cec/cec-notifier.c
> @@ -2,7 +2,7 @@
>  /*
>   * cec-notifier.c - notify CEC drivers of physical address changes
>   *
> - * Copyright 2016 Russell King 
> + * Copyright 2016 Russell King.
>   * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
> reserved.
>   */
>  
> diff --git a/drivers/net/phy/swphy.c b/drivers/net/phy/swphy.c
> index 53c214a22b95..774814714c82 100644
> --- a/drivers/net/phy/swphy.c
> +++ b/drivers/net/phy/swphy.c
> @@ -2,7 +2,7 @@
>  /*
>   * Software PHY emulation
>   *
> - * Code taken from fixed_phy.c by Russell King 
> + * Code taken from fixed_phy.c by Russell King.
>   *
>   * Author: Vitaly Bordug 
>   * Anton Vorontsov 
> diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
> index 985afea1ee36..e2b1b894aae7 100644
> --- a/include/media/cec-notifier.h
> +++ b/include/media/cec-notifier.h
> @@ -2,7 +2,7 @@
>  /*
>   * cec-notifier.h - notify CEC drivers of physical address changes
>   *
> - * Copyright 2016 Russell King 
> + * Copyright 2016 Russell King.
>   * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
> reserved.
>   */
>  
> 

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

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michal Simek]

On 31. 03. 20 11:49, Christophe Leroy wrote:
> 
> 
> Le 31/03/2020 à 09:19, Christophe Leroy a écrit :
>>
>>
>> Le 31/03/2020 à 08:59, Michal Simek a écrit :
>>> On 31. 03. 20 8:56, Christophe Leroy wrote:


 Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
> Christophe Leroy  writes:
>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
 On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
  wrote:
> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
>>>  wrote:
>>> ...
>>>
>>> It does raise a follow-up question about ppc40x though: is it
>>> time to
>>> retire all of it?
>>
>> Who knows?
>>
>> I have in possession nice WD My Book Live, based on this
>> architecture, and I
>> won't it gone from modern kernel support. OTOH I understand that
>> amount of real
>> users not too big.
>
> +Cc: Christian Lamparter, whom I owe for that WD box.

 According to https://openwrt.org/toh/wd/mybooklive, that one is
 based on
 APM82181/ppc464, so it is about several generations newer than
 what I
 asked about (ppc40x).

>> Ah, and I have Amiga board, but that one is being used only for
>> testing, so,
>> I don't care much.

 I think there are a couple of ppc440 based Amiga boards, but again,
 not 405
 to my knowledge.
>>>
>>> Ah, you are right. No objections from ppc40x removal!
>>
>> Removing 40x would help cleaning things a bit. For instance 40x is
>> the
>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove
>> 40x
>> we can get rid of PTE_ATOMIC_UPDATES completely.
>>
>> If no one objects, I can prepare a series to drop support for 40x
>> completely.
>>
>> Michael, any thought ?
>
> I have no attachment to 40x, and I'd certainly be happy to have less
> code in the tree, we struggle to keep even the modern platforms well
> maintained.
>
> At the same time I don't want to render anyone's hardware obsolete
> unnecessarily. But if there's really no one using 40x then we should
> remove it, it could well be broken already.
>
> So I guess post a series to do the removal and we'll see if anyone
> speaks up.
>

 Ok, series sent out, see
 https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
>>>
>>> ok. I see you have done it completely independently of my patchset.
>>> Would be better if you can base it on the top of my 2 patches because
>>> they are in conflict now and I need to also remove virtex 44x platform
>>> also with alsa driver.
>>>
>>
>> I can't see your first patch, only the second one shows up in the
>> series, see
>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
>>
> 
> 
> Ok, I found your first patch on another patchwork, it doesn't touch any
> file in arch/powerpc/

There was just driver dependency on symbol which is removed by 2/2.
Let's see what you get from kbuild if any symbol is removed but still
used in drivers folder.

> 
> I sent a v2 series with your powerpc patch as patch 2/11
> 
> See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167766

Thanks,
Michal


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

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Segher Boessenkool]

On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote:
> While we are at it, can we also remove the 601 ? This one is also full 
> of workarounds and diverges a bit from other 6xx.
> 
> I'm unable to find its end of life date, but it was on the market in 
> 1994, so I guess it must be outdated by more than 10-15 yr old now ?

There probably are still some people running Linux on 601 powermacs.


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

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 31/03/2020 à 12:04, Michal Simek a écrit :

On 31. 03. 20 11:49, Christophe Leroy wrote:



Le 31/03/2020 à 09:19, Christophe Leroy a écrit :



Le 31/03/2020 à 08:59, Michal Simek a écrit :

On 31. 03. 20 8:56, Christophe Leroy wrote:



Le 31/03/2020 à 07:30, Michael Ellerman a écrit :

Christophe Leroy  writes:

Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :

On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:

On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
 wrote:

On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:

On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:

On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
 wrote:

...


It does raise a follow-up question about ppc40x though: is it
time to
retire all of it?


Who knows?

I have in possession nice WD My Book Live, based on this
architecture, and I
won't it gone from modern kernel support. OTOH I understand that
amount of real
users not too big.


+Cc: Christian Lamparter, whom I owe for that WD box.


According to https://openwrt.org/toh/wd/mybooklive, that one is
based on
APM82181/ppc464, so it is about several generations newer than
what I
asked about (ppc40x).


Ah, and I have Amiga board, but that one is being used only for
testing, so,
I don't care much.


I think there are a couple of ppc440 based Amiga boards, but again,
not 405
to my knowledge.


Ah, you are right. No objections from ppc40x removal!


Removing 40x would help cleaning things a bit. For instance 40x is
the
last platform still having PTE_ATOMIC_UPDATES. So if we can remove
40x
we can get rid of PTE_ATOMIC_UPDATES completely.

If no one objects, I can prepare a series to drop support for 40x
completely.

Michael, any thought ?


I have no attachment to 40x, and I'd certainly be happy to have less
code in the tree, we struggle to keep even the modern platforms well
maintained.

At the same time I don't want to render anyone's hardware obsolete
unnecessarily. But if there's really no one using 40x then we should
remove it, it could well be broken already.

So I guess post a series to do the removal and we'll see if anyone
speaks up.



Ok, series sent out, see
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757


ok. I see you have done it completely independently of my patchset.
Would be better if you can base it on the top of my 2 patches because
they are in conflict now and I need to also remove virtex 44x platform
also with alsa driver.



I can't see your first patch, only the second one shows up in the
series, see
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757




Ok, I found your first patch on another patchwork, it doesn't touch any
file in arch/powerpc/


There was just driver dependency on symbol which is removed by 2/2.
Let's see what you get from kbuild if any symbol is removed but still
used in drivers folder.


Nothing bad apparently, see build test at 
http://kisskb.ellerman.id.au/kisskb/head/a4890e3fb046950e9a62dc3eff5b37469551e823/


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

Re: [PATCH v10 00/12] Convert PWM period and duty cycle to u64

[Guru Das Srinagesh]

On Tue, Mar 31, 2020 at 02:48:04PM +0100, Daniel Thompson wrote:
> On Mon, Mar 30, 2020 at 02:00:12PM -0700, Guru Das Srinagesh wrote:
> > On Mon, Mar 30, 2020 at 09:26:36PM +0100, Daniel Thompson wrote:
> > > On Mon, Mar 30, 2020 at 12:15:07PM -0700, Guru Das Srinagesh wrote:
> > > > On Sat, Mar 21, 2020 at 02:47:03PM +0300, Dan Carpenter wrote:
> > > > > This is a giant CC list.
> > > > 
> > > > Yes, this is because I received feedback [1] on an earlier patchset
> > > > directing me to add the reviewers of patches to the cover letter as
> > > > well so that they get some context for the patch.
> > > > ...
> > > > [1] https://www.spinics.net/lists/linux-pwm/msg11735.html
> > > 
> > > Strictly speaking I only asked for backlight maintainers to be Cc:ed.
> > > I was fairly careful to be specific since I'm aware there are a variety
> > > of differing habits when putting together the Cc: list for covering
> > > letters.
> > > 
> > > With the original patch header the purpose of the patch I was Cc:ed on
> > > was impossible to determine without the covering letter.
> > 
> > I suspect this might be the case for all the other reviewers as well -
> > that they also would appreciate context for the specific patch they are
> > being added to review.
> > 
> > I wasn't entirely sure what the convention was, so I applied your
> > suggestion to all the files. How do you suggest I handle this in my next
> > patchset? I fully agree that such a large CC list does look really
> > ungainly.
> 
> IHMO there should not be a mechanical convention. Instead your goal
> needs to be how to make it as easy as possible to review your patches.
> 
> Think about it this way: Each person in the To: of a patch (and maybe
> also Cc: depending on how you construct things) is a person you are
> asking to review and comment on the patch. If that person will find it
> easier to review the patch if they are included in the cover letter then
> either they should be included or you should improve the patch
> description of the patch itself (sometimes both).
> 
> Either way it is about optimizing the patchset for readability. More
> people read them than write them.

Thank you for the explanation! I shall keep your suggestions in mind
while sending out future patchsets.

Thank you.

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

Re: [PATCH v2 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michael Ellerman]

Michal Simek  writes:
> Hi,
>
> recently we wanted to update xilinx intc driver and we found that function
> which we wanted to remove is still wired by ancient Xilinx PowerPC
> platforms. Here is the thread about it.
> https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa...@xilinx.com/
>
> I have been talking about it internally and there is no interest in these
> platforms and it is also orphan for quite a long time. None is really
> running/testing these platforms regularly that's why I think it makes sense
> to remove them also with drivers which are specific to this platform.
>
> U-Boot support was removed in 2017 without anybody complain about it
> https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed
>
> Based on current ppc/next.
>
> If anyone has any objection about it, please let me know.

Thanks for taking the time to find all this code and remove it.

I'm not going to take this series for v5.7, it was posted too close to
the merge window, and doing so wouldn't give people much time to object,
especially given people are distracted at the moment.

I'm happy to take it for v5.8, assuming there's no major objections.

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

Re: [PATCH] drm: fix ifnullfree.cocci warnings

[Julia Lawall]

On Tue, 31 Mar 2020, Daniel Vetter wrote:

> On Fri, Mar 27, 2020 at 09:11:44AM +0100, Julia Lawall wrote:
> > NULL check before kfree is not needed.
> >
> > Generated by: scripts/coccinelle/free/ifnullfree.cocci
> >
> > Fixes: c6603c740e0e ("drm: add managed resources tied to drm_device")
> > Signed-off-by: kbuild test robot 
> > Signed-off-by: Julia Lawall 
> > ---
> >
> > tree:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
>
> Hm this doesn't apply anymore, the patch is for an interim state (because
> bisectability). Care to regen (the pattern still exists), I'm happy to
> apply.

Maybe 0-day will produce it again?

julia

> -Daniel
>
> > head:   9e1ed9fb1eb0a4bc43a26365c592d3095286038b
> > commit: c6603c740e0e3492c9c95fdab833375bf7117b6b [1587/1636] drm: add 
> > managed resources tied to drm_device
> > :: branch date: 8 hours ago
> > :: commit date: 9 hours ago
> >
> > Up to you, if you tihnk it is useful...
> >
> >  drm_drv.c |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -837,8 +837,9 @@ static void drm_dev_release(struct kref
> > if (!dev->driver->release && !dev->managed.final_kfree) {
> > WARN_ON(!list_empty(>managed.resources));
> > kfree(dev);
> > -   } else if (dev->managed.final_kfree)
> > +   } else {
> > kfree(dev->managed.final_kfree);
> > +   }
> >  }
> >
> >  /**
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1] dt-bindings: display: convert rockchip rk3066 hdmi bindings to yaml

[Johan Jonker]

Current dts files with 'hdmi' nodes for rk3066 are manually verified.
In order to automate this process rockchip,rk3066-hdmi.txt
has to be converted to yaml.

Signed-off-by: Johan Jonker 
---
 .../display/rockchip/rockchip,rk3066-hdmi.txt  |  72 ---
 .../display/rockchip/rockchip,rk3066-hdmi.yaml | 141 +
 2 files changed, 141 insertions(+), 72 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
deleted file mode 100644
index d1ad31bca..0
--- 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-Rockchip specific extensions for rk3066 HDMI
-
-
-Required properties:
-- compatible:
-   "rockchip,rk3066-hdmi";
-- reg:
-   Physical base address and length of the controller's registers.
-- clocks, clock-names:
-   Phandle to HDMI controller clock, name should be "hclk".
-- interrupts:
-   HDMI interrupt number.
-- power-domains:
-   Phandle to the RK3066_PD_VIO power domain.
-- rockchip,grf:
-   This soc uses GRF regs to switch the HDMI TX input between vop0 and 
vop1.
-- ports:
-   Contains one port node with two endpoints, numbered 0 and 1,
-   connected respectively to vop0 and vop1.
-   Contains one port node with one endpoint
-   connected to a hdmi-connector node.
-- pinctrl-0, pinctrl-name:
-   Switch the iomux for the HPD/I2C pins to HDMI function.
-
-Example:
-   hdmi: hdmi@10116000 {
-   compatible = "rockchip,rk3066-hdmi";
-   reg = <0x10116000 0x2000>;
-   interrupts = ;
-   clocks = < HCLK_HDMI>;
-   clock-names = "hclk";
-   power-domains = < RK3066_PD_VIO>;
-   rockchip,grf = <>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_xfer>, <_hpd>;
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   hdmi_in: port@0 {
-   reg = <0>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   hdmi_in_vop0: endpoint@0 {
-   reg = <0>;
-   remote-endpoint = <_out_hdmi>;
-   };
-   hdmi_in_vop1: endpoint@1 {
-   reg = <1>;
-   remote-endpoint = <_out_hdmi>;
-   };
-   };
-   hdmi_out: port@1 {
-   reg = <1>;
-   hdmi_out_con: endpoint {
-   remote-endpoint = <_con_in>;
-   };
-   };
-   };
-   };
-
- {
-   hdmi {
-   hdmi_hpd: hdmi-hpd {
-   rockchip,pins = <0 RK_PA0 1 _pull_default>;
-   };
-   hdmii2c_xfer: hdmii2c-xfer {
-   rockchip,pins = <0 RK_PA1 1 _pull_none>,
-   <0 RK_PA2 1 _pull_none>;
-   };
-   };
-};
diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
new file mode 100644
index 0..8f4acf707
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,rk3066-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip rk3066 HDMI controller
+
+maintainers:
+  - Sandy Huang 
+  - Heiko Stuebner 
+
+properties:
+  compatible:
+const: rockchip,rk3066-hdmi
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: hclk
+
+  pinctrl-0:
+maxItems: 2
+
+  pinctrl-names:
+const: default
+description:
+  Switch the iomux for the HPD/I2C pins to HDMI function.
+
+  power-domains:
+maxItems: 1
+
+  rockchip,grf:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+  This soc uses GRF regs to switch the HDMI TX input between vop0 and vop1.
+
+  ports:
+type: object
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+

[PATCH -next] drm/i915/gt: fix spelling mistake "undeflow" -> "underflow"

[Chen Zhou]

There is a spelling mistake in comment, fix it.

Signed-off-by: Chen Zhou 
---
 drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index b6cf284..3be6797 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -181,7 +181,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs 
*engine)
 * Ergo, if we put ourselves on the timelines.active_list
 * (se intel_timeline_enter()) before we increment the
 * engine->wakeref.count, we may see the request completion and retire
-* it causing an undeflow of the engine->wakeref.
+* it causing an underflow of the engine->wakeref.
 */
flags = __timeline_mark_lock(ce);
GEM_BUG_ON(atomic_read(>timeline->active_count) < 0);
-- 
2.7.4

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

[PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep

[Kalyan Thota]

"The PM core always increments the runtime usage counter
before calling the ->suspend() callback and decrements it
after calling the ->resume() callback"

DPU and DSI are managed as runtime devices. When
suspend is triggered, PM core adds a refcount on all the
devices and calls device suspend, since usage count is
already incremented, runtime suspend was not getting called
and it kept the clocks on which resulted in target not
entering into XO shutdown.

Add changes to force suspend on runtime devices during pm sleep.

Changes in v1:
 - Remove unnecessary checks in the function
_dpu_kms_disable_dpu (Rob Clark).

Changes in v2:
 - Avoid using suspend_late to reset the usagecount
   as suspend_late might not be called during suspend
   call failures (Doug).

Changes in v3:
 - Use force suspend instead of managing device usage_count
   via runtime put and get API's to trigger callbacks (Doug).

Signed-off-by: Kalyan Thota 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 ++
 drivers/gpu/drm/msm/dsi/dsi.c   | 2 ++
 drivers/gpu/drm/msm/msm_drv.c   | 4 
 3 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ce19f1d..b886d9d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1123,6 +1123,8 @@ static int __maybe_unused dpu_runtime_resume(struct 
device *dev)
 
 static const struct dev_pm_ops dpu_pm_ops = {
SET_RUNTIME_PM_OPS(dpu_runtime_suspend, dpu_runtime_resume, NULL)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
 };
 
 static const struct of_device_id dpu_dt_match[] = {
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 55ea4bc2..62704885 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -161,6 +161,8 @@ static int dsi_dev_remove(struct platform_device *pdev)
 
 static const struct dev_pm_ops dsi_pm_ops = {
SET_RUNTIME_PM_OPS(msm_dsi_runtime_suspend, msm_dsi_runtime_resume, 
NULL)
+   SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+   pm_runtime_force_resume)
 };
 
 static struct platform_driver dsi_driver = {
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7d985f8..2b8c99c 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1051,6 +1051,8 @@ static int msm_pm_suspend(struct device *dev)
return ret;
}
 
+   pm_runtime_force_suspend(dev);
+
return 0;
 }
 
@@ -1063,6 +1065,8 @@ static int msm_pm_resume(struct device *dev)
if (WARN_ON(!priv->pm_state))
return -ENOENT;
 
+   pm_runtime_force_resume(dev);
+
ret = drm_atomic_helper_resume(ddev, priv->pm_state);
if (!ret)
priv->pm_state = NULL;
-- 
1.9.1

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

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 31/03/2020 à 08:59, Michal Simek a écrit :

On 31. 03. 20 8:56, Christophe Leroy wrote:



Le 31/03/2020 à 07:30, Michael Ellerman a écrit :

Christophe Leroy  writes:

Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :

On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:

On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
 wrote:

On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:

On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:

On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
 wrote:

...


It does raise a follow-up question about ppc40x though: is it
time to
retire all of it?


Who knows?

I have in possession nice WD My Book Live, based on this
architecture, and I
won't it gone from modern kernel support. OTOH I understand that
amount of real
users not too big.


+Cc: Christian Lamparter, whom I owe for that WD box.


According to https://openwrt.org/toh/wd/mybooklive, that one is
based on
APM82181/ppc464, so it is about several generations newer than what I
asked about (ppc40x).


Ah, and I have Amiga board, but that one is being used only for
testing, so,
I don't care much.


I think there are a couple of ppc440 based Amiga boards, but again,
not 405
to my knowledge.


Ah, you are right. No objections from ppc40x removal!


Removing 40x would help cleaning things a bit. For instance 40x is the
last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x
we can get rid of PTE_ATOMIC_UPDATES completely.

If no one objects, I can prepare a series to drop support for 40x
completely.

Michael, any thought ?


I have no attachment to 40x, and I'd certainly be happy to have less
code in the tree, we struggle to keep even the modern platforms well
maintained.

At the same time I don't want to render anyone's hardware obsolete
unnecessarily. But if there's really no one using 40x then we should
remove it, it could well be broken already.

So I guess post a series to do the removal and we'll see if anyone
speaks up.



Ok, series sent out, see
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757


ok. I see you have done it completely independently of my patchset.
Would be better if you can base it on the top of my 2 patches because
they are in conflict now and I need to also remove virtex 44x platform
also with alsa driver.



I can't see your first patch, only the second one shows up in the 
series, see 
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757


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

Re: [PATCH v3 1/4] drm/mediatek: Move tz_disabled from mtk_hdmi_phy to mtk_hdmi driver

[Chunfeng Yun]

On Tue, 2020-03-31 at 23:57 +0800, Chun-Kuang Hu wrote:
> From: CK Hu 
> 
> tz_disabled is used to control mtk_hdmi output signal, but this variable
> is stored in mtk_hdmi_phy and mtk_hdmi_phy does not use it. So move
> tz_disabled to mtk_hdmi where it's used.
> 
> Signed-off-by: CK Hu 
> Signed-off-by: Chun-Kuang Hu 
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   | 22 ---
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.h   |  1 -
>  .../gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c|  1 -
>  3 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 5e4a4dbda443..878433c09c9b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -144,11 +144,16 @@ struct hdmi_audio_param {
>   struct hdmi_codec_params codec_params;
>  };
>  
> +struct mtk_hdmi_conf {
> + bool tz_disabled;
> +};
> +
>  struct mtk_hdmi {
>   struct drm_bridge bridge;
>   struct drm_bridge *next_bridge;
>   struct drm_connector conn;
>   struct device *dev;
> + const struct mtk_hdmi_conf *conf;
>   struct phy *phy;
>   struct device *cec_dev;
>   struct i2c_adapter *ddc_adpt;
> @@ -230,7 +235,6 @@ static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi, 
> bool black)
>  static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
>  {
>   struct arm_smccc_res res;
> - struct mtk_hdmi_phy *hdmi_phy = phy_get_drvdata(hdmi->phy);
>  
>   /*
>* MT8173 HDMI hardware has an output control bit to enable/disable HDMI
> @@ -238,7 +242,7 @@ static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi 
> *hdmi, bool enable)
>* The ARM trusted firmware provides an API for the HDMI driver to set
>* this control bit to enable HDMI output in supervisor mode.
>*/
> - if (hdmi_phy->conf && hdmi_phy->conf->tz_disabled)
> + if (hdmi->conf->tz_disabled)
>   regmap_update_bits(hdmi->sys_regmap,
>  hdmi->sys_offset + HDMI_SYS_CFG20,
>  0x80008005, enable ? 0x8005 : 0x8000);
> @@ -1688,6 +1692,7 @@ static int mtk_drm_hdmi_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   hdmi->dev = dev;
> + hdmi->conf = of_device_get_match_data(dev);
>  
>   ret = mtk_hdmi_dt_parse_pdata(hdmi, pdev);
>   if (ret)
> @@ -1765,8 +1770,19 @@ static int mtk_hdmi_resume(struct device *dev)
>  static SIMPLE_DEV_PM_OPS(mtk_hdmi_pm_ops,
>mtk_hdmi_suspend, mtk_hdmi_resume);
>  
> +static const struct mtk_hdmi_conf mtk_hdmi_conf_mt2701 = {
> + .tz_disabled = true,
> +};
> +
> +static const struct mtk_hdmi_conf mtk_hdmi_conf_mt8173;
> +
>  static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
> - { .compatible = "mediatek,mt8173-hdmi", },
> + { .compatible = "mediatek,mt2701-hdmi",
> +   .data = _hdmi_conf_mt2701,
> + },
> + { .compatible = "mediatek,mt8173-hdmi",
> +   .data = _hdmi_conf_mt8173,
> + },
>   {}
>  };
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h 
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> index 2d8b3182470d..fc1c2efd1128 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
> @@ -20,7 +20,6 @@
>  struct mtk_hdmi_phy;
>  
>  struct mtk_hdmi_phy_conf {
> - bool tz_disabled;
>   unsigned long flags;
>   const struct clk_ops *hdmi_phy_clk_ops;
>   void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
> b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> index d3cc4022e988..99fe05cd3598 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
> @@ -237,7 +237,6 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy 
> *hdmi_phy)
>  }
>  
>  struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
> - .tz_disabled = true,
>   .flags = CLK_SET_RATE_GATE,
>   .hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
>   .hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,

Reviewed-by: Chunfeng Yun 

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

Re: [PATCH v3 2/4] drm/mediatek: Separate mtk_hdmi_phy to an independent module

[Chunfeng Yun]

On Tue, 2020-03-31 at 23:57 +0800, Chun-Kuang Hu wrote:
> From: CK Hu 
> 
> mtk_hdmi_phy is a part of mtk_hdmi module, but phy driver should be an
> independent module rather than be part of drm module, so separate the phy
> driver to an independent module.
> 
> Signed-off-by: CK Hu 
> Signed-off-by: Chun-Kuang Hu 
> ---
>  drivers/gpu/drm/mediatek/Kconfig|  9 -
>  drivers/gpu/drm/mediatek/Makefile   | 11 +++
>  drivers/gpu/drm/mediatek/mtk_hdmi.c |  2 +-
>  drivers/gpu/drm/mediatek/mtk_hdmi.h |  1 -
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.c |  1 +
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.h |  1 -
>  6 files changed, 17 insertions(+), 8 deletions(-)
Reviewed-by: Chunfeng Yun 

Thanks a lot

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

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Michal Simek]

On 31. 03. 20 8:56, Christophe Leroy wrote:
> 
> 
> Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
>> Christophe Leroy  writes:
>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
 On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
>  wrote:
>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
 On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
  wrote:
 ...

 It does raise a follow-up question about ppc40x though: is it
 time to
 retire all of it?
>>>
>>> Who knows?
>>>
>>> I have in possession nice WD My Book Live, based on this
>>> architecture, and I
>>> won't it gone from modern kernel support. OTOH I understand that
>>> amount of real
>>> users not too big.
>>
>> +Cc: Christian Lamparter, whom I owe for that WD box.
>
> According to https://openwrt.org/toh/wd/mybooklive, that one is
> based on
> APM82181/ppc464, so it is about several generations newer than what I
> asked about (ppc40x).
>
>>> Ah, and I have Amiga board, but that one is being used only for
>>> testing, so,
>>> I don't care much.
>
> I think there are a couple of ppc440 based Amiga boards, but again,
> not 405
> to my knowledge.

 Ah, you are right. No objections from ppc40x removal!
>>>
>>> Removing 40x would help cleaning things a bit. For instance 40x is the
>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x
>>> we can get rid of PTE_ATOMIC_UPDATES completely.
>>>
>>> If no one objects, I can prepare a series to drop support for 40x
>>> completely.
>>>
>>> Michael, any thought ?
>>
>> I have no attachment to 40x, and I'd certainly be happy to have less
>> code in the tree, we struggle to keep even the modern platforms well
>> maintained.
>>
>> At the same time I don't want to render anyone's hardware obsolete
>> unnecessarily. But if there's really no one using 40x then we should
>> remove it, it could well be broken already.
>>
>> So I guess post a series to do the removal and we'll see if anyone
>> speaks up.
>>
> 
> Ok, series sent out, see
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757

ok. I see you have done it completely independently of my patchset.
Would be better if you can base it on the top of my 2 patches because
they are in conflict now and I need to also remove virtex 44x platform
also with alsa driver.

Thanks,
Michal

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

Re: How to handle disconnection of eDP panels due to dynamic display mux switches

[Daniel Dadap]

On 3/30/20 10:11 AM, Jani Nikula wrote:

On Fri, 27 Mar 2020, Daniel Dadap  wrote:

A number of hybrid GPU notebook computer designs with dual (integrated
plus discrete) GPUs are equipped with multiplexers (muxes) that allow
display panels to be driven by either the integrated GPU or the discrete
GPU. Typically, this is a selection that can be made at boot time as a
menu option in the system firmware's setup screen, and the mux selection
stays fixed for as long as the system is running and persists across
reboots until it is explicitly changed. However, some muxed hybrid GPU
systems have dynamically switchable muxes which can be switched while
the system is running.

NVIDIA is exploring the possibility of taking advantage of dynamically
switchable muxes to enhance the experience of using a hybrid GPU system.
For example, on a system configured for PRIME render offloading, it may
be possible to keep the discrete GPU powered down and use the integrated
GPU for rendering and displaying the desktop when no applications are
using the discrete GPU, and dynamically switch the panel to be driven
directly by the discrete GPU when render-offloading a fullscreen
application.

We have been conducting some experiments on systems with dynamic muxes,
and have found some limitations that would need to be addressed in order
to support use cases like the one suggested above:

* In at least the i915 DRM-KMS driver, and likely in other DRM-KMS
drivers as well, eDP panels are assumed to be always connected. This
assumption is broken when the panel is muxed away, which can cause
problems. A typical symptom is i915 repeatedly attempting to retrain the
link, severely impacting system performance and printing messages like
the following every five seconds or so:

[drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link
training
[drm] Reducing the compressed framebuffer size. This may lead to less
power savings than a non-reduced-size. Try to increase stolen memory
size if available in BIOS.

This symptom might occur if something causes the DRM-KMS driver to probe
the display while it's muxed away, for example a modeset or DPMS state
change.

* When switching the mux back to a GPU that was previously driving a
mode, it is necessary to at the very least retrain DP links to restore
the previously displayed image. In a proof of concept I have been
experimenting with, I am able to accomplish this from userspace by
triggering DPMS off and then back on again; however, it would be good to
have an in-kernel API to request that an output owned by a DRM-KMS
driver be refreshed to resume driving a mode on a disconnected and
reconnected display. This API would need to be accessible from outside
of the DRM-KMS driver handling the output. One reason it would be good
to do this within the kernel, rather than rely on e.g. DPMS operations
in the xf86-video-modesetting driver, is that it would be useful for
restoring the console if X crashes or is forcefully killed while the mux
is switched to a GPU other than the one which drives the console.

Basically, we'd like to be able to do the following:

1) Communicate to a DRM-KMS driver that an output is disconnected and
can't be used. Ideally, DRI clients such as X should still see the
output as being connected, so user applications don't need to keep track
of the change.

I think everything will be much easier if you provide a way for
userspace to control the muxing using the KMS API, and not lie to the
userspace about what's going on.

You're not actually saying what component you think should control the
muxing.

Why should the drivers keep telling the userspace the output is
connected when it's not? Obviously the userspace should also switch to
using a different output on a different GPU, right? Or are you planning
some proprietary behind the scenes hack for discrete?



The desire to lie to userspace is driven mainly by trying to avoid 
interactions from desktop environments / window managers reacting to the 
display going away. Many desktops will do things like try to migrate 
windows in response to a change in the current display configuration, 
and updating all of them to avoid doing so when a display appears to 
disappear from one GPU and reappear on another GPU seems harder than 
allowing userspace to believe that nothing has changed. I wouldn't mind 
if e.g. X drivers were in on the lie, and the lie boundary shifts to 
RandR, but it would be nice to avoid having to deal with the fallout of 
desktop environments handling displays apparently vanishing and 
re-appearing.


The particular use case we're envisioning here is as follows:

* GPU A drives an X protocol screen which hosts a desktop session.
Applications are rendered on GPU A by default. The mux is switched to 
GPU A by default.
* GPU B drives a GPU screen that can be used as a PRIME render offload 
source. Applications rendered on GPU B can run in windows presented by 
GPU A via PRIME render offloading.
* If an 

Re: [Freedreno] [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep

[kalyan_t]

On 2020-03-31 00:25, Doug Anderson wrote:

Hi,

On Mon, Mar 30, 2020 at 2:04 AM Kalyan Thota  
wrote:


"The PM core always increments the runtime usage counter
before calling the ->suspend() callback and decrements it
after calling the ->resume() callback"

DPU and DSI are managed as runtime devices. When
suspend is triggered, PM core adds a refcount on all the
devices and calls device suspend, since usage count is
already incremented, runtime suspend was not getting called
and it kept the clocks on which resulted in target not
entering into XO shutdown.

Add changes to manage runtime devices during pm sleep.

Changes in v1:
 - Remove unnecessary checks in the function
   _dpu_kms_disable_dpu (Rob Clark).

Changes in v2:
 - Avoid using suspend_late to reset the usagecount
   as suspend_late might not be called during suspend
   call failures (Doug).

Signed-off-by: Kalyan Thota 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 33 
+

 drivers/gpu/drm/msm/msm_drv.c   |  4 
 drivers/gpu/drm/msm/msm_kms.h   |  2 ++
 3 files changed, 39 insertions(+)


I am still 100% baffled by your patch and I never did quite understand
your response to my previous comments [1].  I think you're saying that
the problem you were facing is that if you call "suspend" but never
called "runtime_suspend" that the device stays active.  Is that right?
 If that's true, did you try something like this suggestion I made?

SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, 
pm_runtime_force_resume)



diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c

index ce19f1d..2343cbd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -26,6 +26,7 @@
 #include "dpu_encoder.h"
 #include "dpu_plane.h"
 #include "dpu_crtc.h"
+#include "dsi.h"

 #define CREATE_TRACE_POINTS
 #include "dpu_trace.h"
@@ -325,6 +326,37 @@ static void dpu_kms_disable_commit(struct msm_kms 
*kms)

pm_runtime_put_sync(_kms->pdev->dev);
 }

+static void _dpu_kms_disable_dpu(struct msm_kms *kms)
+{
+   struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+   struct drm_device *dev = dpu_kms->dev;
+   struct msm_drm_private *priv = dev->dev_private;
+   struct msm_dsi *dsi;
+   int i;
+
+   dpu_kms_disable_commit(kms);
+
+   for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
+   if (!priv->dsi[i])
+   continue;
+   dsi = priv->dsi[i];
+   pm_runtime_put_sync(>pdev->dev);
+   }
+   pm_runtime_put_sync(dev->dev);
+
+   /* Increment the usagecount without triggering a resume */
+   pm_runtime_get_noresume(dev->dev);
+
+   pm_runtime_get_noresume(_kms->pdev->dev);
+
+   for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
+   if (!priv->dsi[i])
+   continue;
+   dsi = priv->dsi[i];
+   pm_runtime_get_noresume(>pdev->dev);
+   }
+}


My pm_runtime knowledge is pretty weak sometimes, but the above
function looks crazy.  Maybe it's just me not understanding, but can
you please summarize what you're trying to accomplish?

-- I was trying to get the runtime callbacks via controlling the device 
usage_count
Since the usage_count was already incremented by PM core, i was 
decrementing and incrementing (without resume)

so that callbacks are triggered.

I have taken your suggestion on forcing the suspend instead of managing 
it via usage_count.

i'll follow it up in the next patchset.


-Doug

[1] 
https://lore.kernel.org/r/114130f68c494f83303c51157e2c5...@codeaurora.org

___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

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

Re: [PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms

[Christophe Leroy]

Le 31/03/2020 à 09:19, Christophe Leroy a écrit :



Le 31/03/2020 à 08:59, Michal Simek a écrit :

On 31. 03. 20 8:56, Christophe Leroy wrote:



Le 31/03/2020 à 07:30, Michael Ellerman a écrit :

Christophe Leroy  writes:

Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :

On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:

On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
 wrote:

On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:

On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:

On Fri, Mar 27, 2020 at 1:12 PM Michal Simek
 wrote:

...


It does raise a follow-up question about ppc40x though: is it
time to
retire all of it?


Who knows?

I have in possession nice WD My Book Live, based on this
architecture, and I
won't it gone from modern kernel support. OTOH I understand that
amount of real
users not too big.


+Cc: Christian Lamparter, whom I owe for that WD box.


According to https://openwrt.org/toh/wd/mybooklive, that one is
based on
APM82181/ppc464, so it is about several generations newer than 
what I

asked about (ppc40x).


Ah, and I have Amiga board, but that one is being used only for
testing, so,
I don't care much.


I think there are a couple of ppc440 based Amiga boards, but again,
not 405
to my knowledge.


Ah, you are right. No objections from ppc40x removal!


Removing 40x would help cleaning things a bit. For instance 40x is the
last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x
we can get rid of PTE_ATOMIC_UPDATES completely.

If no one objects, I can prepare a series to drop support for 40x
completely.

Michael, any thought ?


I have no attachment to 40x, and I'd certainly be happy to have less
code in the tree, we struggle to keep even the modern platforms well
maintained.

At the same time I don't want to render anyone's hardware obsolete
unnecessarily. But if there's really no one using 40x then we should
remove it, it could well be broken already.

So I guess post a series to do the removal and we'll see if anyone
speaks up.



Ok, series sent out, see
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757


ok. I see you have done it completely independently of my patchset.
Would be better if you can base it on the top of my 2 patches because
they are in conflict now and I need to also remove virtex 44x platform
also with alsa driver.



I can't see your first patch, only the second one shows up in the 
series, see 
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757





Ok, I found your first patch on another patchwork, it doesn't touch any 
file in arch/powerpc/


I sent a v2 series with your powerpc patch as patch 2/11

See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167766

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

Re: How to handle disconnection of eDP panels due to dynamic display mux switches

[Daniel Vetter]

On Wed, Apr 1, 2020 at 3:58 AM Daniel Dadap  wrote:
> On 3/31/20 2:32 AM, Daniel Vetter wrote:
> > Since I see no mention of this anywhere in your mail ... have you
> > tried looking at drivers/gpu/vga/vga_switcheroo.c? This also supports
> > switching of just outputs, not just the old optimus way of switching
> > out the entire gpu and having to disable the other one.
>
>
> We did look into vga-switcheroo while developing our PoC, but found it
> insufficient for supporting the use case we had in mind in its current
> form. Among the limitations we observed were that it didn't seem to be
> possible to switch with output-level granularity, only with gpu-level
> granularity, with the whole switched-away-to GPU being powered down.
> Your description suggests that this is indeed possible, but if that's
> the case, then the mechanism for doing so isn't obvious in what I can
> see of the API from the kernel source code, even in the drm-next tree.
> Do you have pointers to documentation on how the per-output switching is
> supposed to work?

I think the per-output switch isn't support (yet), but otherwise there
should be two modes:
- power switch mode, other gpu has to be offlined. This also means
switching needs to wait until all the clients are shut down.
- output switching only. That seems to be roughly what you want,
except you want to switch more than just the integrated panel. I think
all models thus far simply wired all external outputs to the dgpu
always.

I primarily asked about vgaswitcheroo since you didn't mention it at all.

> Other limitations of vga-switcheroo included:
>
> * The can_switch() callbacks for all current vga-switcheroo-capable GPU
> drivers don't seem to allow for a switch to occur while there are active
> KMS clients. This has the effect of making it so that non-deferred
> switches can only be initiated under the same circumstances that
> deferred switches wait for.
> * It's only possible to address one mux device. Some systems have
> separate muxes for internal and external displays. From what I could see
> in existing vga-switcheroo mux handlers, it seems that multi-muxed
> systems just switch all of the muxes simultaneously, which makes sense
> for the all-or-nothing "power down the GPU not in use" approach, but
> might not be desirable for fine-grained output-level switching.
> * On some systems, it's possible to put the panel into a self-refresh
> mode before switching the mux and exit self-refresh mode after
> switching, to hide any glitches that might otherwise appear while
> transitioning. Additional handler callbacks for pre-switch and
> post-switch operations would be useful.
>
> If vga-switcheroo could be updated to address these limitatons, then it
> could make sense to handle the display disconnect/connect notifications
> and display refreshing as part of a vga_switcheroo client driver's
> set_gpu_state() callback (or a finer-grained per-output callback);
> however, it also seems that it should be possible to implement APIs
> within the DRM subsystem to accomplish the desired functionality
> independently of current or future vga-switcheroo design.

vgaswitcheroo was written by Dave Airlie, doesn't get much more
"within the gpu subsystem". I think we should look into extending
vgaswitcheroo instead of inventing a completely new uapi. If we go
with a simplified use-case of
- only integrated panel switches
- external output on the dgpu
then that should match existing systems, so you get support on at
least some desktops for free. Plus no headaches about userspace we
need for merging new uapi. Once we have that (for your mux, and I
guess with i915+nouveau all working) then we can look into how to
extend it, or give the same underlying stuff an interface that's not
in debugfs :-)

Also for your seamless switching with self-refresh this could be
implemented without new userspace, greatly simplifying everything.

Cheers, Daniel

> > There's some rough corners (like the uapi doesn't exist, it's in
> > debugfs), and the locking has an inversion problem (I have ideas), but
> > generally what you want exists already.
> > -Daniel
> >
> > On Mon, Mar 30, 2020 at 9:12 AM Daniel Dadap  wrote:
> >> A number of hybrid GPU notebook computer designs with dual (integrated
> >> plus discrete) GPUs are equipped with multiplexers (muxes) that allow
> >> display panels to be driven by either the integrated GPU or the discrete
> >> GPU. Typically, this is a selection that can be made at boot time as a
> >> menu option in the system firmware's setup screen, and the mux selection
> >> stays fixed for as long as the system is running and persists across
> >> reboots until it is explicitly changed. However, some muxed hybrid GPU
> >> systems have dynamically switchable muxes which can be switched while
> >> the system is running.
> >>
> >> NVIDIA is exploring the possibility of taking advantage of dynamically
> >> switchable muxes to enhance the experience of using a hybrid GPU system.
> >> For 

[Bug 207047] Crash after failed to pin userptr on amdgpu

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=207047

bigbeesh...@gmail.com changed:

   What|Removed |Added

 CC||bigbeesh...@gmail.com

--- Comment #1 from bigbeesh...@gmail.com ---
Can you try on 5.6 kernel. Fixes for userptr where submitted and merged into
that release and I think are lined up for 5.5.14

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel