Re: [RESEND PATCH v2] drm: Add getfb2 ioctl

2019-10-14 Thread Daniel Vetter
On Mon, Oct 14, 2019 at 6:21 PM Li, Juston  wrote:
>
> On Wed, 2019-10-09 at 17:50 +0200, Daniel Vetter wrote:
> > On Thu, Oct 03, 2019 at 11:31:25AM -0700, Juston Li wrote:
> > > From: Daniel Stone 
> > >
> > > getfb2 allows us to pass multiple planes and modifiers, just like
> > > addfb2
> > > over addfb.
> > >
> > > Changes since v1:
> > >  - unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
> > >  - update ioctl number
> > >
> > > Signed-off-by: Daniel Stone 
> > > Signed-off-by: Juston Li 
> >
> > Looks all good from a very quick glance (kernel, libdrm, igt), but
> > where's
> > the userspace? Link to weston/drm_hwc/whatever MR good enough.
> > -Daniel
>
> My use case is a screenshot utility in chromiuomos that breaks with y-
> tiled ccs enabled.
> Review linked is just WIP hack for now since it depends on this
> merging:
> https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1815146

Adding Sean & Daniele to confirm this is real cros.
-Daniel

>
> Thanks
> Juston
>
> > > ---
> > >  drivers/gpu/drm/drm_crtc_internal.h |   2 +
> > >  drivers/gpu/drm/drm_framebuffer.c   | 110
> > > 
> > >  drivers/gpu/drm/drm_ioctl.c |   1 +
> > >  include/uapi/drm/drm.h  |   2 +
> > >  4 files changed, 115 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> > > b/drivers/gpu/drm/drm_crtc_internal.h
> > > index c7d5e4c21423..16f2413403aa 100644
> > > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > > @@ -216,6 +216,8 @@ int drm_mode_rmfb_ioctl(struct drm_device *dev,
> > > void *data, struct drm_file *file_priv);
> > >  int drm_mode_getfb(struct drm_device *dev,
> > >void *data, struct drm_file *file_priv);
> > > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > > + void *data, struct drm_file *file_priv);
> > >  int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> > >void *data, struct drm_file *file_priv);
> > >
> > > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > > b/drivers/gpu/drm/drm_framebuffer.c
> > > index 57564318ceea..6db54f177443 100644
> > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > @@ -31,6 +31,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >
> > > @@ -548,7 +549,116 @@ int drm_mode_getfb(struct drm_device *dev,
> > >
> > >  out:
> > > drm_framebuffer_put(fb);
> > > +   return ret;
> > > +}
> > > +
> > > +/**
> > > + * drm_mode_getfb2 - get extended FB info
> > > + * @dev: drm device for the ioctl
> > > + * @data: data pointer for the ioctl
> > > + * @file_priv: drm file for the ioctl call
> > > + *
> > > + * Lookup the FB given its ID and return info about it.
> > > + *
> > > + * Called by the user via ioctl.
> > > + *
> > > + * Returns:
> > > + * Zero on success, negative errno on failure.
> > > + */
> > > +int drm_mode_getfb2_ioctl(struct drm_device *dev,
> > > + void *data, struct drm_file *file_priv)
> > > +{
> > > +   struct drm_mode_fb_cmd2 *r = data;
> > > +   struct drm_framebuffer *fb;
> > > +   unsigned int i;
> > > +   int ret;
> > > +
> > > +   if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > > +   return -EINVAL;
> > > +
> > > +   fb = drm_framebuffer_lookup(dev, file_priv, r->fb_id);
> > > +   if (!fb)
> > > +   return -ENOENT;
> > > +
> > > +   /* For multi-plane framebuffers, we require the driver to place
> > > the
> > > +* GEM objects directly in the drm_framebuffer. For single-
> > > plane
> > > +* framebuffers, we can fall back to create_handle.
> > > +*/
> > > +   if (!fb->obj[0] &&
> > > +   (fb->format->num_planes > 1 || !fb->funcs->create_handle))
> > > {
> > > +   ret = -ENODEV;
> > > +   goto out;
> > > +   }
> > > +
> > > +   r->height = fb->height;
> > > +   r->width =

Re: [PATCH 7/7] drm/dp-mst: fix warning on unused var

2019-10-14 Thread Daniel Vetter
On Fri, Oct 11, 2019 at 10:58:13AM -0700, Lucas De Marchi wrote:
> +dri, +Daniel
> 
> On Thu, Oct 10, 2019 at 06:09:07PM -0700, Lucas De Marchi wrote:
> > Fixes: 83fa9842afe7 ("drm/dp-mst: Drop connection_mutex check")
> > Signed-off-by: Lucas De Marchi 
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 2 --
> > 1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 9364e4f42975..95e63309 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -4184,8 +4184,6 @@ EXPORT_SYMBOL(drm_dp_mst_topology_state_funcs);
> > struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct 
> > drm_atomic_state *state,
> > struct 
> > drm_dp_mst_topology_mgr *mgr)
> > {
> > -   struct drm_device *dev = mgr->dev;
> > -
> > return to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state, 
> > >base));
> > }
> > EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);

Thanks for fixing this, pushed.
-Daniel

> > -- 
> > 2.23.0
> > 

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

Re: [PATCH v2 1/4] drm/komeda: Add a new helper drm_color_ctm_s31_32_to_qm_n()

2019-10-14 Thread Daniel Vetter
On Mon, Oct 14, 2019 at 09:58:20AM +, james qian wang (Arm Technology 
China) wrote:
> On Mon, Oct 14, 2019 at 10:56:05AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 11, 2019 at 05:43:09AM +, james qian wang (Arm Technology 
> > China) wrote:
> > > Add a new helper function drm_color_ctm_s31_32_to_qm_n() for driver to
> > > convert S31.32 sign-magnitude to Qm.n 2's complement that supported by
> > > hardware.
> > >
> > > Signed-off-by: james qian wang (Arm Technology China) 
> > > 
> > > ---
> > >  drivers/gpu/drm/drm_color_mgmt.c | 23 +++
> > >  include/drm/drm_color_mgmt.h |  2 ++
> > >  2 files changed, 25 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> > > b/drivers/gpu/drm/drm_color_mgmt.c
> > > index 4ce5c6d8de99..3d533d0b45af 100644
> > > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > > @@ -132,6 +132,29 @@ uint32_t drm_color_lut_extract(uint32_t user_input, 
> > > uint32_t bit_precision)
> > >  }
> > >  EXPORT_SYMBOL(drm_color_lut_extract);
> > >
> > > +/**
> > > + * drm_color_ctm_s31_32_to_qm_n
> > > + *
> > > + * @user_input: input value
> > > + * @m: number of integer bits
> > > + * @n: number of fractinal bits
> > > + *
> > > + * Convert and clamp S31.32 sign-magnitude to Qm.n 2's complement.
> >
> > What's the Q meaning here? Also maybe specify that the higher bits above
> > m+n are cleared to all 0 or all 1. Unit test would be lovely too. Anyway:
> 
> The Q used to represent signed two's complement.
> 
> For detail: https://en.wikipedia.org/wiki/Q_(number_format)
> 
> And it Q is 2's complement, so the value of higher bit equal to
> sign-bit.
> All 1 if it is negative
> 0 if it is positive.

Ah I didn't know about this notation, I think in other drm docs we just
used m.n 2's complement to denote this layout. Up to you I think.
-Daniel

> 
> James
> 
> > Reviewed-by: Daniel Vetter 
> >
> > > + */
> > > +uint64_t drm_color_ctm_s31_32_to_qm_n(uint64_t user_input,
> > > + uint32_t m, uint32_t n)
> > > +{
> > > +   u64 mag = (user_input & ~BIT_ULL(63)) >> (32 - n);
> > > +   bool negative = !!(user_input & BIT_ULL(63));
> > > +   s64 val;
> > > +
> > > +   /* the range of signed 2s complement is [-2^n+m, 2^n+m - 1] */
> > > +   val = clamp_val(mag, 0, negative ? BIT(n + m) : BIT(n + m) - 1);
> > > +
> > > +   return negative ? 0ll - val : val;
> > > +}
> > > +EXPORT_SYMBOL(drm_color_ctm_s31_32_to_qm_n);
> > > +
> > >  /**
> > >   * drm_crtc_enable_color_mgmt - enable color management properties
> > >   * @crtc: DRM CRTC
> > > diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> > > index d1c662d92ab7..60fea5501886 100644
> > > --- a/include/drm/drm_color_mgmt.h
> > > +++ b/include/drm/drm_color_mgmt.h
> > > @@ -30,6 +30,8 @@ struct drm_crtc;
> > >  struct drm_plane;
> > >
> > >  uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t 
> > > bit_precision);
> > > +uint64_t drm_color_ctm_s31_32_to_qm_n(uint64_t user_input,
> > > + uint32_t m, uint32_t n);
> > >
> > >  void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> > > uint degamma_lut_size,
> > > --
> > > 2.20.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane

2019-10-14 Thread Daniel Vetter
On Mon, Oct 14, 2019 at 09:11:17AM +, Brian Starkey wrote:
> On Fri, Oct 11, 2019 at 07:25:02PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 11, 2019 at 12:56 PM Brian Starkey  
> > wrote:
> > >
> > > Hi,
> > >
> > > On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> > > > Hi Brian,
> > > >
> > > > On 11/10/2019 10:41, Brian Starkey wrote:
> > 
> > > > > Are you sure the GPU supports other orders? I think any Arm driver
> > > > > will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888>
> > > > > I'm not convinced the GPU HW actually supports any other order, but
> > > > > it's all rather confusing with texture swizzling. What I can tell you
> > > > > for sure is that it _does_ support BGR order (in DRM naming
> > > > > convention).
> > > >
> > > > Well, since the Bifrost Mali blobs are closed-source and delivered
> > > > by licensees, it's hard to define what is supported from a closed
> > > > GPU HW, closed SW implementation to a closed pixel format 
> > > > implementation.
> > > >
> > >
> > > I hear you. IMO the only way to make any of this clear is to publish
> > > reference data and tests which make sure implementations match each
> > > other. It's something I'm trying to make happen.
> > 
> > *cough* igt test with crc/writeback validation *cough*
> > 
> > And you don't even need anything that actually compresses. All you
> > need is the minimal enough AFBC knowledge to set up the metadata that
> > everything is uncompressed. We're doing that for our intel compression
> > formats already, and it works great in making sure that we have
> > end-to-end agreement on all the bits and ordering and everything.
> 
> Yeah this was my original thinking too. Sadly, a decent number of the
> AFBC parameters can't be tested with uncompressed data, as the codec
> kicks into a different mode there.

Hm right I guess some of the flags/parameters only matter if you deal with
actual compressed data. Still, better than nothing I guess - this should
at least catch stuff like color channels wired up the wrong way compared
to linear, and fun stuff like that.

> > Ofc
> > it doesn't validate the decoder, but that's not really igts job.
> > Should be possible to convince ARM to release that (as open source, in
> > igt), since it would be fairly valuable for the entire ecosystem here
> > ...
> 
> I fully agree about the value proposition.

I'll be waiting for patch from arm then :-)

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

Re: WARNING in vkms_gem_free_object

2019-10-14 Thread Daniel Vetter
0006d41a0 R14:  R15: 
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: WARNING in drm_mode_createblob_ioctl

2019-10-14 Thread Daniel Vetter
On Sun, Oct 13, 2019 at 11:09:09PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:8ada228a Add linux-next specific files for 20191011
> git tree:   linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1423a87f60
> kernel config:  https://syzkaller.appspot.com/x/.config?x=7cf4eed5fe42c31a
> dashboard link: https://syzkaller.appspot.com/bug?extid=fb77e97ebf0612ee6914
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> 
> Unfortunately, I don't have any reproducer for this crash yet.

Hm only thing that could go wrong is how we allocate the target for the
user_copy, which is an argument directly from the ioctl parameter struct.
Does syzbot not track that? We use the standard linux ioctl struct
encoding in drm.

Otherwise I have no idea why it can't create a reliable reproducer for
this ... I'm also not seeing the bug, all the input validation we have
seems correct :-/
-Daniel
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com
> 
> [ cut here ]
> WARNING: CPU: 1 PID: 30449 at include/linux/thread_info.h:150
> check_copy_size include/linux/thread_info.h:150 [inline]
> WARNING: CPU: 1 PID: 30449 at include/linux/thread_info.h:150 copy_from_user
> include/linux/uaccess.h:143 [inline]
> WARNING: CPU: 1 PID: 30449 at include/linux/thread_info.h:150
> drm_mode_createblob_ioctl+0x398/0x490 drivers/gpu/drm/drm_property.c:800
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 1 PID: 30449 Comm: syz-executor.5 Not tainted 5.4.0-rc2-next-20191011
> #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+0x172/0x1f0 lib/dump_stack.c:113
>  panic+0x2e3/0x75c kernel/panic.c:221
>  __warn.cold+0x2f/0x35 kernel/panic.c:582
>  report_bug+0x289/0x300 lib/bug.c:195
>  fixup_bug arch/x86/kernel/traps.c:174 [inline]
>  fixup_bug arch/x86/kernel/traps.c:169 [inline]
>  do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
>  do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
>  invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1028
> RIP: 0010:check_copy_size include/linux/thread_info.h:150 [inline]
> RIP: 0010:copy_from_user include/linux/uaccess.h:143 [inline]
> RIP: 0010:drm_mode_createblob_ioctl+0x398/0x490
> drivers/gpu/drm/drm_property.c:800
> Code: c1 ea 03 80 3c 02 00 0f 85 ed 00 00 00 49 89 5d 00 e8 3c 28 cb fd 4c
> 89 f7 e8 64 92 9e 03 31 c0 e9 75 fd ff ff e8 28 28 cb fd <0f> 0b e8 21 28 cb
> fd 4d 85 e4 b8 f2 ff ff ff 0f 84 5b fd ff ff 89
> RSP: 0018:8880584efaa8 EFLAGS: 00010246
> RAX: 0004 RBX: 8880a3a9 RCX: c900109da000
> RDX: 0004 RSI: 83a7eaf8 RDI: 0007
> RBP: 8880584efae8 R08: 888096c40080 R09: ed1014752110
> R10: ed101475210f R11: 8880a3a9087f R12: c90014907000
> R13: 888028aa R14: 9a6c7969 R15: c90014907058
> 
> 
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

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

Re: [PATCH v4] drm/ioctl: Add a ioctl to label GEM objects

2019-10-14 Thread Daniel Vetter
 drm_gem_adopt_label(struct drm_gem_object *gem_obj, const char *label);
>  
>  /* drm_debugfs.c drm_debugfs_crc.c */
>  #if defined(CONFIG_DEBUG_FS)
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index fcd728d7cf72..f34e1571d70f 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -714,6 +714,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>   DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl, 
> DRM_MASTER),
>   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl, 
> DRM_MASTER),
>   DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, drm_mode_revoke_lease_ioctl, 
> DRM_MASTER),
> + DRM_IOCTL_DEF(DRM_IOCTL_DUMB_SET_LABEL, drm_dumb_set_label_ioctl, 
> DRM_RENDER_ALLOW),
>  };
>  
>  #define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index cf13470810a5..501a3924354a 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -715,6 +715,22 @@ struct drm_driver {
>   struct drm_device *dev,
>   uint32_t handle);
>  
> + /**
> +  * @label:
> +  *
> +  * This label's a buffer object.
> +  *
> +  * Called by the user via ioctl.
> +  *
> +  * Returns:
> +  *
> +  * Zero on success, negative errno on failure.
> +  */
> + int (*label)(struct drm_device *dev,
> + struct drm_file *file_priv,
> + uint32_t handle,
> + char *label);
> +
>   /**
>* @gem_vm_ops: Driver private ops for this object
>*
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 6aaba14f5972..f801c054e972 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -237,6 +237,13 @@ struct drm_gem_object {
>*/
>   int name;
>  
> + /**
> +  * @label:
> +  *
> +  * Label for this object, should be a human readable string.
> +  */
> + char *label;
> +
>   /**
>* @dma_buf:
>*
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 8a5b2f8f8eb9..309c3c091385 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -626,6 +626,25 @@ struct drm_gem_open {
>   __u64 size;
>  };
>  
> +/** struct drm_dumb_set_label_object - ioctl argument for labelling BOs.
> + *
> + * This label's a BO with a userspace label
> + *
> + */
> +struct drm_dumb_set_label_object {
> + /** Handle for the object being labelled. */
> + __u32 handle;
> +
> + /** Label and label length.
> +  *  len includes the trailing NUL.
> +  */
> + __u32 len;
> + __u64 name;
> +
> + /** Flags */
> + int flags;
> +};
> +
>  #define DRM_CAP_DUMB_BUFFER  0x1
>  #define DRM_CAP_VBLANK_HIGH_CRTC 0x2
>  #define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
> @@ -946,6 +965,7 @@ extern "C" {
>  #define DRM_IOCTL_SYNCOBJ_QUERY  DRM_IOWR(0xCB, struct 
> drm_syncobj_timeline_array)
>  #define DRM_IOCTL_SYNCOBJ_TRANSFER   DRM_IOWR(0xCC, struct 
> drm_syncobj_transfer)
>  #define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNALDRM_IOWR(0xCD, struct 
> drm_syncobj_timeline_array)
> +#define DRM_IOCTL_DUMB_SET_LABEL  DRM_IOWR(0xCE, struct 
> drm_dumb_set_label_object)
>  
>  /**
>   * Device specific ioctls should only be in their respective headers
> -- 
> 2.17.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v4] drm/ioctl: Add a ioctl to label GEM objects

2019-10-14 Thread Daniel Vetter
On Fri, Oct 11, 2019 at 07:55:36PM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 11.10.19 um 19:09 schrieb Daniel Stone:
> > Hi Rohan,
> > 
> > On Fri, 11 Oct 2019 at 15:30, Rohan Garg  wrote:
> > > DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it
> > > easier to debug issues in userspace applications.
> > 
> > I'm not sure if this was pointed out already, but dumb buffers != GEM
> > buffers. GEM buffers _can_ be dumb, but might not be.
> > 
> > Could you please rename to GEM_SET_LABEL?
> 
> This change to build upon dumb buffers was suggested by me, as dumb buffers
> is the closes thing there is to a buffer management interface. Drivers with
> 'smart buffers' would have to add their own ioctl interfaces.

We already have some IOCTLs that apply to gem buffers, not just dumb
buffers, so GEM_SET_LABEL seems a lot more reasonable to me, too.

> What I really miss here is a userspace application that uses this
> functionality. It would be much easier to discuss if there was an actual
> example.

+1.

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

Re: [PATCH v2 1/4] drm/komeda: Add a new helper drm_color_ctm_s31_32_to_qm_n()

2019-10-14 Thread Daniel Vetter
On Fri, Oct 11, 2019 at 05:43:09AM +, james qian wang (Arm Technology 
China) wrote:
> Add a new helper function drm_color_ctm_s31_32_to_qm_n() for driver to
> convert S31.32 sign-magnitude to Qm.n 2's complement that supported by
> hardware.
> 
> Signed-off-by: james qian wang (Arm Technology China) 
> 
> ---
>  drivers/gpu/drm/drm_color_mgmt.c | 23 +++
>  include/drm/drm_color_mgmt.h |  2 ++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 4ce5c6d8de99..3d533d0b45af 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -132,6 +132,29 @@ uint32_t drm_color_lut_extract(uint32_t user_input, 
> uint32_t bit_precision)
>  }
>  EXPORT_SYMBOL(drm_color_lut_extract);
>  
> +/**
> + * drm_color_ctm_s31_32_to_qm_n
> + *
> + * @user_input: input value
> + * @m: number of integer bits
> + * @n: number of fractinal bits
> + *
> + * Convert and clamp S31.32 sign-magnitude to Qm.n 2's complement.

What's the Q meaning here? Also maybe specify that the higher bits above
m+n are cleared to all 0 or all 1. Unit test would be lovely too. Anyway:

Reviewed-by: Daniel Vetter 

> + */
> +uint64_t drm_color_ctm_s31_32_to_qm_n(uint64_t user_input,
> +   uint32_t m, uint32_t n)
> +{
> + u64 mag = (user_input & ~BIT_ULL(63)) >> (32 - n);
> + bool negative = !!(user_input & BIT_ULL(63));
> + s64 val;
> +
> + /* the range of signed 2s complement is [-2^n+m, 2^n+m - 1] */
> + val = clamp_val(mag, 0, negative ? BIT(n + m) : BIT(n + m) - 1);
> +
> + return negative ? 0ll - val : val;
> +}
> +EXPORT_SYMBOL(drm_color_ctm_s31_32_to_qm_n);
> +
>  /**
>   * drm_crtc_enable_color_mgmt - enable color management properties
>   * @crtc: DRM CRTC
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index d1c662d92ab7..60fea5501886 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -30,6 +30,8 @@ struct drm_crtc;
>  struct drm_plane;
>  
>  uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
> +uint64_t drm_color_ctm_s31_32_to_qm_n(uint64_t user_input,
> +   uint32_t m, uint32_t n);
>  
>  void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>   uint degamma_lut_size,
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] drm: Funnel drm logs to tracepoints

2019-10-14 Thread Daniel Vetter
On Thu, Oct 10, 2019 at 04:48:08PM -0400, Sean Paul wrote:
> From: Sean Paul 
> 
> *Record scratch* You read that subject correctly, I bet you're wondering
> how we got here. At least hear me out before you flame :-)
> 
> For a long while now, we (ChromeOS) have been struggling getting any
> value out of user feedback reports of display failures (notably external
> displays not working). The problem is that all logging, even fatal
> errors (well, fatal in the sense that a display won't light up) are
> logged at DEBUG log level. So in order to extract these logs, you need
> to be able to turn on logging, and reproduce the issue with debug
> enabled. Unfortunately, this isn't really something we can ask CrOS users
> I spoke with airlied about this and RHEL has similar issues.
> 
> This is the point where you ask me, "So Sean, why don't you just enable
> DRM_UT_BLAH?". Good question! Here are the reasons in ascending order of
> severity:
>  1- People aren't consistent with their categories, so we'd have to
> enable a bunch to get proper coverage
>  2- We don't want to overwhelm syslog with drm spam, others have to use
> it too
>  3- Console logging is slow
> 
> Hopefully you're with me so far. I have a problem that has no existing
> solution. What I really want is a ringbuffer of the most recent logs
> (in the categories I'm interested in) exposed via debugfs so I can
> extract it when users file feedback.
> 
> It just so happens that there is something which does _exactly_ this! I
> can dump the most recent logs into tracepoints, turn them on and off
> depending on which category I want, and pull them from debugfs on demand.
> 
> "What about trace_printk()?" You'll say. It doesn't give us the control we
> get from using tracepoints and it's not meant to be left sprinkled around
> in code.
> 
> So that is how we got here, now it's time for you to tell me why this is
> a horrible idea :-)
> 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Signed-off-by: Sean Paul 

I think if this comes with example script for how to use it (enable the
right tracepoints in debugfs, capture the trace) in the commit message or
somewhere else (igt/tools maybe?) then this is ok with me. If you can also
get some other distro/OS people to ack it, then we're good imo.

Acked-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_print.c  | 143 ++-
>  include/trace/events/drm_print.h | 116 +
>  2 files changed, 239 insertions(+), 20 deletions(-)
>  create mode 100644 include/trace/events/drm_print.h
> 
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 9a25d73c155c..f591292811aa 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -27,11 +27,15 @@
>  
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  
> +#define CREATE_TRACE_POINTS
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -241,10 +245,10 @@ void drm_dev_printk(const struct device *dev, const 
> char *level,
>   struct va_format vaf;
>   va_list args;
>  
> - va_start(args, format);
>   vaf.fmt = format;
>   vaf.va = 
>  
> + va_start(args, format);
>   if (dev)
>   dev_printk(level, dev, "[" DRM_NAME ":%ps] %pV",
>  __builtin_return_address(0), );
> @@ -253,49 +257,145 @@ void drm_dev_printk(const struct device *dev, const 
> char *level,
>  level, __builtin_return_address(0), );
>  
>   va_end(args);
> +
> + va_start(args, format);
> + trace_drm_log(level, dev, );
> + va_end(args);
>  }
>  EXPORT_SYMBOL(drm_dev_printk);
>  
> +static unsigned int drm_trace_enabled(unsigned int category)
> +{
> + unsigned int bit;
> +
> + for_each_set_bit(bit, (unsigned long*), sizeof(category) * 8) {
> + switch (BIT(bit)) {
> + case DRM_UT_NONE:
> + return trace_drm_dbg_none_enabled();
> + case DRM_UT_CORE:
> + return trace_drm_dbg_core_enabled();
> + case DRM_UT_DRIVER:
> + return trace_drm_dbg_driver_enabled();
> + case DRM_UT_KMS:
> + return trace_drm_dbg_kms_enabled();
> + case DRM_UT_PRIME:
> + return trace_drm_dbg_prime_enabled();
> + case DRM_UT_ATOMIC:
> + return trace_drm_dbg_atomic_enabled();
> + case DRM_UT_VBL:
> + return trace_drm_dbg_vbl_enabled();
> + case DRM_UT_STATE:
> +   

Re: [PATCH 0/4] treewide: fix interrupted release

2019-10-14 Thread Daniel Vetter
On Fri, Oct 11, 2019 at 11:36:33AM +0200, Johan Hovold wrote:
> On Thu, Oct 10, 2019 at 03:50:43PM +0200, Daniel Vetter wrote:
> > On Thu, Oct 10, 2019 at 03:13:29PM +0200, Johan Hovold wrote:
> > > Two old USB drivers had a bug in them which could lead to memory leaks
> > > if an interrupted process raced with a disconnect event.
> > > 
> > > Turns out we had a few more driver in other subsystems with the same
> > > kind of bug in them.
> 
> > Random funny idea: Could we do some debug annotations (akin to
> > might_sleep) that splats when you might_sleep_interruptible somewhere
> > where interruptible sleeps are generally a bad idea? Like in
> > fops->release?
> 
> There's nothing wrong with interruptible sleep in fops->release per se,
> it's just that drivers cannot return -ERESTARTSYS and friends and expect
> to be called again later.

Do you have a legit usecase for interruptible sleeps in fops->release?

I'm not even sure killable is legit in there, since it's an fd, not a
process context ...

> The return value from release() is ignored by vfs, and adding a splat in
> __fput() to catch these buggy drivers might be overkill.

Ime once you have a handful of instances of a broken pattern, creating a
check for it (under a debug option only ofc) is very much justified.
Otherwise they just come back to life like the undead, all the time. And
there's a _lot_ of fops->release callbacks in the kernel.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH 5/6] drm/amdgpu/dm/mst: Report possible_crtcs incorrectly, for now

2019-10-14 Thread Daniel Vetter
On Fri, Oct 11, 2019 at 04:51:13PM -0400, Lyude Paul wrote:
> a little late but: i915 does have this hack (or rather-possible_crtcs with MST
> in i915 has been broken for a while and got fixed, but had to get reverted
> because of this issue), it's where this originally came from.

Hm since this is widespread I think we should check for this when we
register connectors (either in drm_dev_register, or hotplugged ones). I
think just validating that all encoder->possible_crtc match and WARN_ON if
not would be really good.

2nd option would be to do that in the GETENCODERS ioctl. That would at
least keep the encoders useful for driver-internal stuff. We could then
un-revert the i915 patch again.

Either way I think we should have this hack + comment with links to the
offending userspace in common code, not duplicated over all drivers.
-Daniel

> 
> On Wed, 2019-10-09 at 17:01 +0200, Daniel Vetter wrote:
> > On Fri, Sep 27, 2019 at 11:27:41AM -0400, Sean Paul wrote:
> > > On Thu, Sep 26, 2019 at 06:51:07PM -0400, Lyude Paul wrote:
> > > > This commit is seperate from the previous one to make it easier to
> > > > revert in the future. Basically, there's multiple userspace applications
> > > > that interpret possible_crtcs very wrong:
> > > > 
> > > > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277
> > > > https://gitlab.gnome.org/GNOME/mutter/issues/759
> > > > 
> > > > While work is ongoing to fix these issues in userspace, we need to
> > > > report ->possible_crtcs incorrectly for now in order to avoid
> > > > introducing a regression in in userspace. Once these issues get fixed,
> > > > this commit should be reverted.
> > > > 
> > > > Signed-off-by: Lyude Paul 
> > > > Cc: Ville Syrjälä 
> > > > ---
> > > >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++
> > > >  1 file changed, 11 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > index b404f1ae6df7..fe8ac801d7a5 100644
> > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > > @@ -4807,6 +4807,17 @@ static int amdgpu_dm_crtc_init(struct
> > > > amdgpu_display_manager *dm,
> > > > if (!acrtc->mst_encoder)
> > > > goto fail;
> > > >  
> > > > +   /*
> > > > +* FIXME: This is a hack to workaround the following issues:
> > > > +*
> > > > +* https://gitlab.gnome.org/GNOME/mutter/issues/759
> > > > +* 
> > > > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277
> > > > +*
> > > > +* One these issues are closed, this should be removed
> > > 
> > > Even when these issues are closed, we'll still be introducing a regression
> > > if we
> > > revert this change. Time for actually_possible_crtcs? :)
> > > 
> > > You also might want to briefly explain the u/s bug in case the links go
> > > sour.
> > > 
> > > > +*/
> > > > +   acrtc->mst_encoder->base.possible_crtcs =
> > > > +   amdgpu_dm_get_encoder_crtc_mask(dm->adev);
> > > 
> > > Why don't we put this hack in amdgpu_dm_dp_create_fake_mst_encoder()?
> > 
> > If we don't have the same hack for i915 mst I think we shouldn't merge
> > this ... broken userspace is broken.
> > -Daniel
> -- 
> Cheers,
>   Lyude Paul
> 

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

Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10

2019-10-14 Thread Daniel Vetter
; > > > > > > > > 4, 4, 0 }, .block_h = { 4, 4, 0 },
> > > > > > > > > > > > +  .hsub = 2, .vsub = 1, .is_yuv = true},
> > > > > > > > > > > > +    { .format = DRM_FORMAT_NV61_10,    .depth =
> > > > > > > > > > > > 0,  .num_planes = 2,
> > > > > > > > > > > > +  .char_per_block = { 5, 10, 0 }, .block_w = {
> > > > > > > > > > > > 4, 4, 0 }, .block_h = { 4, 4, 0 },
> > > > > > > > > > > > +  .hsub = 2, .vsub = 1, .is_yuv = true},
> > > > > > > > > > > > +    { .format = DRM_FORMAT_NV24_10,    .depth =
> > > > > > > > > > > > 0,  .num_planes = 2,
> > > > > > > > > > > > +  .char_per_block = { 5, 10, 0 }, .block_w = {
> > > > > > > > > > > > 4, 4, 0 }, .block_h = { 4, 4, 0 },
> > > > > > > > > > > > +  .hsub = 1, .vsub = 1, .is_yuv = true},
> > > > > > > > > > > > +    { .format = DRM_FORMAT_NV42_10,    .depth =
> > > > > > > > > > > > 0,  .num_planes = 2,
> > > > > > > > > > > > +  .char_per_block = { 5, 10, 0 }, .block_w = {
> > > > > > > > > > > > 4, 4, 0 }, .block_h = { 4, 4, 0 },
> > > > > > > > > > > > +  .hsub = 1, .vsub = 1, .is_yuv = true},
> > > > > > > > > > > >   { .format = DRM_FORMAT_P210,    
> > > > > > > > > > > > .depth = 0,
> > > > > > > > > > > > .num_planes = 2, .char_per_block = { 2, 
> > > > > > > > > > > > 4, 0 },
> > > > > > > > > > > > .block_w = { 1, 0, 0 }, .block_h = { 1, 
> > > > > > > > > > > > 0,
> > > > > > > > > > > > 0 }, .hsub = 2,
> > > > > > > > > > > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > > > > > > > > > > b/include/uapi/drm/drm_fourcc.h
> > > > > > > > > > > > index 3feeaa3..08e2221 100644
> > > > > > > > > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > > > > > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > > > > > > > > @@ -238,6 +238,20 @@ extern "C" {
> > > > > > > > > > > >   #define DRM_FORMAT_NV42    fourcc_code('N', 
> > > > > > > > > > > > 'V',
> > > > > > > > > > > > '4', '2') /* non-subsampled Cb:Cr plane */
> > > > > > > > > > > >      /*
> > > > > > > > > > > > + * 2 plane YCbCr
> > > > > > > > > > > > + * index 0 = Y plane, Y3:Y2:Y1:Y0 10:10:10:10
> > > > > > > > > > > > + * index 1 = Cb:Cr plane,
> > > > > > > > > > > > Cb3:Cr3:Cb2:Cr2:Cb1:Cr1:Cb0:Cr0 10:10:10:10:10:10:10:10
> > > > > > > > > > > > + * or
> > > > > > > > > > > > + * index 1 = Cr:Cb plane,
> > > > > > > > > > > > Cr3:Cb3:Cr2:Cb2:Cr1:Cb1:Cr0:Cb0 10:10:10:10:10:10:10:10
> > > > > > > > > > > So now you're defining it as some kind of byte aligned 
> > > > > > > > > > > block.
> > > > > > > > > > > With that specifying endianness would now make sense since
> > > > > > > > > > > otherwise this tells us absolutely nothing about the 
> > > > > > > > > > > memory
> > > > > > > > > > > layout.
> > > > > > > > > > > 
> > > > > > > > > > > So I'd either do that, or go back to not specifying 
> > > > > > > > > > > anything and
> > > > > > > > > > > use some weasel words like "mamory layout is 
> > > > > > > > > > > implementation defined"
> > > > > > > > > > > which of course means no one can use it for anything that 
> > > > > > > > > > > involves
> > > > > > > > > > > any kind of cross vendor stuff.
> > > > > > > > > > /*
> > > > > > > > > >   * 2 plane YCbCr
> > > > > > > > > >   * index 0 = Y plane, [39: 0] Y3:Y2:Y1:Y0 10:10:10:10 
> > > > > > > > > > little endian
> > > > > > > > > >   * index 1 = Cb:Cr plane, [79: 0] 
> > > > > > > > > > Cb3:Cr3:Cb2:Cr2:Cb1:Cr1:Cb0:Cr0
> > > > > > > > > > 10:10:10:10:10:10:10:10  little endian
> > > > > > > > > >   * or
> > > > > > > > > >   * index 1 = Cr:Cb plane, [79: 0] 
> > > > > > > > > > Cr3:Cb3:Cr2:Cb2:Cr1:Cb1:Cr0:Cb0
> > > > > > > > > > 10:10:10:10:10:10:10:10  little endian
> > > > > > > > > >   */
> > > > > > > > > > 
> > > > > > > > > > Is this description ok?
> > > > > > > > > Seems OK to me, if it actually describes the format correctly.
> > > > > > > > > 
> > > > > > > > > Though I'm not sure why the CbCr is defines as an 80bit block
> > > > > > > > > and Y has a 40bit block. 40bits should be enough for CbCr as 
> > > > > > > > > well.
> > > > > > > > > 
> > > > > > > > well, this is taken into account yuv444,  4 y point 
> > > > > > > > corresponding with 4
> > > > > > > > uv point.
> > > > > > > > 
> > > > > > > > if only describes the layout memory, here can change to 40bit 
> > > > > > > > block.
> > > > > > > > 
> > > > > > > > thanks.
> > > > > > > > 
> > > > > > > > > > > > + */
> > > > > > > > > > > > +#define DRM_FORMAT_NV12_10    fourcc_code('N', 'A',
> > > > > > > > > > > > '1', '2') /* 2x2 subsampled Cr:Cb plane */
> > > > > > > > > > > > +#define DRM_FORMAT_NV21_10    fourcc_code('N', 'A',
> > > > > > > > > > > > '2', '1') /* 2x2 subsampled Cb:Cr plane */
> > > > > > > > > > > > +#define DRM_FORMAT_NV16_10    fourcc_code('N', 'A',
> > > > > > > > > > > > '1', '6') /* 2x1 subsampled Cr:Cb plane */
> > > > > > > > > > > > +#define DRM_FORMAT_NV61_10    fourcc_code('N', 'A',
> > > > > > > > > > > > '6', '1') /* 2x1 subsampled Cb:Cr plane */
> > > > > > > > > > > > +#define DRM_FORMAT_NV24_10    fourcc_code('N', 'A',
> > > > > > > > > > > > '2', '4') /* non-subsampled Cr:Cb plane */
> > > > > > > > > > > > +#define DRM_FORMAT_NV42_10    fourcc_code('N', 'A',
> > > > > > > > > > > > '4', '2') /* non-subsampled Cb:Cr plane */
> > > > > > > > > > > > +
> > > > > > > > > > > > +/*
> > > > > > > > > > > >    * 2 plane YCbCr MSB aligned
> > > > > > > > > > > >    * index 0 = Y plane, [15:0] Y:x [10:6] little 
> > > > > > > > > > > > endian
> > > > > > > > > > > >    * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x
> > > > > > > > > > > > [10:6:10:6] little endian
> > > > > > > > > > > > -- 
> > > > > > > > > > > > 2.7.4
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > ___
> > > > > > > > > > > > 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
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH] drm: add fb max width/height fields to drm_mode_config

2019-10-14 Thread Daniel Vetter
n't assume that everything will just work

+1 on this approach. We already have that for 3d modes, another client cap
for "modes bigger than max fb" sounds like a good idea.

For "max plane size" I'm leaning towards drivers should virtualize at
least the primary plane if that's needed to scan out the biggest
resolution. Since there's way too much userspace which will simply not
work otherwise (iirc that's what a bunch of dual-pipe dsi drivers did).

> > > b) Maybe we could just tie that in with the atomic cap since
> > >atomic clients are pretty much required to do the TEST_ONLY
> > >dance anyway, so one might hope they have a working fallback
> > >strategy. Though I suspect eg. the modesetting ddx wouldn't
> > >like this. But we no longer allow atomic with X anyway so
> > >that partcular argument may not hold much weight anymore.
> > 
> > What was the conclusion of the hack to not expose atomic to
> > modesetting ddx, due to the brokenness of it's atomic use?  I guess
> > that could also make the modesetting case go away..
> 
> I thought it went in? Maybe I'm mistaken.

I did:

commit 26b1d3b527e7bf3e24b814d617866ac5199ce68d
Author: Daniel Vetter 
Date:   Thu Sep 5 20:53:18 2019 +0200

drm/atomic: Take the atomic toys away from X

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

Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane

2019-10-11 Thread Daniel Vetter
On Fri, Oct 11, 2019 at 12:56 PM Brian Starkey  wrote:
>
> Hi,
>
> On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> > Hi Brian,
> >
> > On 11/10/2019 10:41, Brian Starkey wrote:

> > > Are you sure the GPU supports other orders? I think any Arm driver
> > > will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888>
> > > I'm not convinced the GPU HW actually supports any other order, but
> > > it's all rather confusing with texture swizzling. What I can tell you
> > > for sure is that it _does_ support BGR order (in DRM naming
> > > convention).
> >
> > Well, since the Bifrost Mali blobs are closed-source and delivered
> > by licensees, it's hard to define what is supported from a closed
> > GPU HW, closed SW implementation to a closed pixel format implementation.
> >
>
> I hear you. IMO the only way to make any of this clear is to publish
> reference data and tests which make sure implementations match each
> other. It's something I'm trying to make happen.

*cough* igt test with crc/writeback validation *cough*

And you don't even need anything that actually compresses. All you
need is the minimal enough AFBC knowledge to set up the metadata that
everything is uncompressed. We're doing that for our intel compression
formats already, and it works great in making sure that we have
end-to-end agreement on all the bits and ordering and everything. Ofc
it doesn't validate the decoder, but that's not really igts job.
Should be possible to convince ARM to release that (as open source, in
igt), since it would be fairly valuable for the entire ecosystem here
...
-Daniel

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

Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane

2019-10-11 Thread Daniel Vetter
>> +  if (!meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM) &&
> > >> +  !meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
> > >> +  return false;
> > >> +
> > >> +  if (modifier & ~DRM_FORMAT_MOD_ARM_AFBC(MESON_MOD_AFBC_VALID_BITS))
> > >> +  return false;
> > >> +
> > >> +  for (i = 0 ; i < plane->modifier_count ; ++i)
> > >> +  if (plane->modifiers[i] == modifier)
> > >> +  break;
> > >> +
> > >> +  if (i == plane->modifier_count) {
> > >> +  DRM_DEBUG_KMS("Unsupported modifier\n");
> > >> +  return false;
> > >> +  }
> >
> > I can add a warn_once here, would it be enough ?
> >
> > >> +
> > >> +  if (priv->afbcd.ops && priv->afbcd.ops->supported_fmt)
> > >> +  return priv->afbcd.ops->supported_fmt(modifier, format);
> > >> +
> > >> +  DRM_DEBUG_KMS("AFBC Unsupported\n");
> > >> +  return false;
> > >> +}
> > >> +
> > >>  static const struct drm_plane_funcs meson_plane_funcs = {
> > >>.update_plane   = drm_atomic_helper_update_plane,
> > >>.disable_plane  = drm_atomic_helper_disable_plane,
> > >> @@ -353,6 +457,7 @@ static const struct drm_plane_funcs 
> > >> meson_plane_funcs = {
> > >>.reset  = drm_atomic_helper_plane_reset,
> > >>.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> > >>.atomic_destroy_state   = drm_atomic_helper_plane_destroy_state,
> > >> +  .format_mod_supported   = meson_plane_format_mod_supported,
> > >>  };
> > >>
> > >>  static const uint32_t supported_drm_formats[] = {
> > >> @@ -364,10 +469,53 @@ static const uint32_t supported_drm_formats[] = {
> > >>DRM_FORMAT_RGB565,
> > >>  };
> > >>
> > >> +static const uint64_t format_modifiers_afbc_gxm[] = {
> > >> +  DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> > >> +  AFBC_FORMAT_MOD_SPARSE |
> > >> +  AFBC_FORMAT_MOD_YTR),
> > >> +  /* SPLIT mandates SPARSE, RGB modes mandates YTR */
> > >> +  DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> > >> +  AFBC_FORMAT_MOD_YTR |
> > >> +  AFBC_FORMAT_MOD_SPARSE |
> > >> +  AFBC_FORMAT_MOD_SPLIT),
> > >> +  DRM_FORMAT_MOD_LINEAR,
> > >> +  DRM_FORMAT_MOD_INVALID,
> > >> +};
> > >> +
> > >> +static const uint64_t format_modifiers_afbc_g12a[] = {
> > >> +  /*
> > >> +   * - TOFIX Support AFBC modifiers for YUV formats (16x16 + TILED)
> > >> +   * - AFBC_FORMAT_MOD_YTR is mandatory since we only support RGB
> > >> +   * - SPLIT is mandatory for performances reasons when in 16x16
> > >> +   *   block size
> > >> +   * - 32x8 block size + SPLIT is mandatory with 4K frame size
> > >> +   *   for performances reasons
> > >> +   */
> > >> +  DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> > >> +  AFBC_FORMAT_MOD_YTR |
> > >> +  AFBC_FORMAT_MOD_SPARSE |
> > >> +  AFBC_FORMAT_MOD_SPLIT),
> > >> +  DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |
> > >> +  AFBC_FORMAT_MOD_YTR |
> > >> +  AFBC_FORMAT_MOD_SPARSE),
> > >> +  DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 |
> > >> +  AFBC_FORMAT_MOD_YTR |
> > >> +  AFBC_FORMAT_MOD_SPARSE |
> > >> +  AFBC_FORMAT_MOD_SPLIT),
> > >> +  DRM_FORMAT_MOD_LINEAR,
> > >> +  DRM_FORMAT_MOD_INVALID,
> > >> +};
> > >> +
> > >> +static const uint64_t format_modifiers_default[] = {
> > >> +  DRM_FORMAT_MOD_LINEAR,
> > >> +  DRM_FORMAT_MOD_INVALID,
> > >> +};
> > >> +
> > >>  int meson_plane_create(struct meson_drm *priv)
> > >>  {
> > >>struct meson_plane *meson_plane;
> > >>struct drm_plane *plane;
> > >> +  const uint64_t *format_modifiers = format_modifiers_default;
> > >>
> > >>meson_plane = devm_kzalloc(priv->drm->dev, sizeof(*meson_plane),
> > >>   GFP_KERNEL);
> > >> @@ -377,11 +525,16 @@ int meson_plane_create(struct meson_drm *priv)
> > >>meson_plane->priv = priv;
> > >>plane = _plane->base;
> > >>
> > >> +  if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM))
> > >> +  format_modifiers = format_modifiers_afbc_gxm;
> > >> +  else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
> > >> +  format_modifiers = format_modifiers_afbc_g12a;
> > >> +
> > >>drm_universal_plane_init(priv->drm, plane, 0xFF,
> > >> _plane_funcs,
> > >> supported_drm_formats,
> > >> ARRAY_SIZE(supported_drm_formats),
> > >> -   NULL,
> > >> +   format_modifiers,
> > >> DRM_PLANE_TYPE_PRIMARY, 
> > >> "meson_primary_plane");
> > >>
> > >>drm_plane_helper_add(plane, _plane_helper_funcs);
> > >> --
> > >> 2.22.0
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [pull] ttm drm-fixes-5.4

2019-10-11 Thread Daniel Vetter
On Fri, Oct 11, 2019 at 6:24 AM Dave Airlie  wrote:
>
> On Fri, 11 Oct 2019 at 14:20, Dave Airlie  wrote:
> >
> > On Thu, 10 Oct 2019 at 21:58, Koenig, Christian
> >  wrote:
> > >
> > > Am 09.10.19 um 09:47 schrieb Arkadiusz Hiler:
> > > > On Tue, Oct 08, 2019 at 09:13:41AM -0400, Alex Deucher wrote:
> > > >> On Tue, Oct 8, 2019 at 4:04 AM Koenig, Christian
> > > >>  wrote:
> > > >>> My git version should be relative new, but I'm usually using 
> > > >>> thunderbird
> > > >>> to send pull requests not git itself since I want to edit the message
> > > >>> before sending.
> > > >>>
> > > >>> How would I do this in a way patchwork likes it with git?
> > > >> FWIW, I usually generate the email first and then use git-send-email
> > > >> to actually send it.
> > > >>
> > > >> Alex
> > > > Hey,
> > > >
> > > > FDO patchwork maintainer here.
> > > >
> > > > I have tried few things quickly with no luck. There is something fishy
> > > > about FDO deployment of patchwork - you email works just fine on my
> > > > development instance.
> > > >
> > > > I have created issue for this:
> > > > https://gitlab.freedesktop.org/patchwork-fdo/patchwork-fdo/issues/28
> > > >
> > > > Sorry for the inconvenience.
> > >
> > > Maybe it's the non-Latin letter in my last name? Anyway we need to get
> > > the TTM fixes upstream for 5.4.
> > >
> > > Dave/Daniel any objections that I push those directly to drm-misc-fixes?
> >
> > Don't bother, I can manually process it, just takes a bit more effort.
>
> Actually it has a problem, you need to Signed-off-by any commits you touch.
>
> The first patch should to be correect have your Sob after Thomas
> review as you touched it last,
> the second patch needs your Sob somewhere in it.

So yeah maybe -misc because that makes sure this is all correct :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1

2019-10-10 Thread Daniel Vetter
On Thu, Oct 10, 2019 at 6:28 PM Hans de Goede  wrote:
>
> Bail from the pci_driver probe function instead of from the drm_driver
> load function.
>
> This avoid /dev/dri/card0 temporarily getting registered and then
> unregistered again, sending unwanted add / remove udev events to
> userspace.
>
> Specifically this avoids triggering the (userspace) bug fixed by this
> plymouth merge-request:
> https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59
>
> Note that despite that being a userspace bug, not sending unnecessary
> udev events is a good idea in general.

I think even better would be getting rid of the load/unload callbacks,
this issue here isn't the only problem with them.

Reviewed-by: Daniel Vetter 

I guess also cc: stable material?
-Daniel
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 35 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 35 -
>  2 files changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 6f8aaf655a9f..2a00a36106b2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1048,6 +1048,41 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> return -ENODEV;
> }
>
> +#ifdef CONFIG_DRM_AMDGPU_SI
> +   if (!amdgpu_si_support) {
> +   switch (flags & AMD_ASIC_MASK) {
> +   case CHIP_TAHITI:
> +   case CHIP_PITCAIRN:
> +   case CHIP_VERDE:
> +   case CHIP_OLAND:
> +   case CHIP_HAINAN:
> +   dev_info(>dev,
> +"SI support provided by radeon.\n");
> +   dev_info(>dev,
> +"Use radeon.si_support=0 amdgpu.si_support=1 
> to override.\n"
> +   );
> +   return -ENODEV;
> +   }
> +   }
> +#endif
> +#ifdef CONFIG_DRM_AMDGPU_CIK
> +   if (!amdgpu_cik_support) {
> +   switch (flags & AMD_ASIC_MASK) {
> +   case CHIP_KAVERI:
> +   case CHIP_BONAIRE:
> +   case CHIP_HAWAII:
> +   case CHIP_KABINI:
> +   case CHIP_MULLINS:
> +   dev_info(>dev,
> +"CIK support provided by radeon.\n");
> +   dev_info(>dev,
> +"Use radeon.cik_support=0 
> amdgpu.cik_support=1 to override.\n"
> +   );
> +   return -ENODEV;
> +   }
> +   }
> +#endif
> +
> /* Get rid of things like offb */
> ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, 0, 
> "amdgpudrmfb");
> if (ret)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index f2c097983f48..d55f5baa83d3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -144,41 +144,6 @@ int amdgpu_driver_load_kms(struct drm_device *dev, 
> unsigned long flags)
> struct amdgpu_device *adev;
> int r, acpi_status;
>
> -#ifdef CONFIG_DRM_AMDGPU_SI
> -   if (!amdgpu_si_support) {
> -   switch (flags & AMD_ASIC_MASK) {
> -   case CHIP_TAHITI:
> -   case CHIP_PITCAIRN:
> -   case CHIP_VERDE:
> -   case CHIP_OLAND:
> -   case CHIP_HAINAN:
> -   dev_info(dev->dev,
> -"SI support provided by radeon.\n");
> -   dev_info(dev->dev,
> -"Use radeon.si_support=0 amdgpu.si_support=1 
> to override.\n"
> -   );
> -   return -ENODEV;
> -   }
> -   }
> -#endif
> -#ifdef CONFIG_DRM_AMDGPU_CIK
> -   if (!amdgpu_cik_support) {
> -   switch (flags & AMD_ASIC_MASK) {
> -   case CHIP_KAVERI:
> -   case CHIP_BONAIRE:
> -   case CHIP_HAWAII:
> -   case CHIP_KABINI:
> -   case CHIP_MULLINS:
> -   dev_info(dev->dev,
> -"CIK support provided by radeon.\n");
> -   dev_info(dev->dev,
> -   

Re: [PATCH] Revert "drm/msm: dpu: Add modeset lock checks where applicable"

2019-10-10 Thread Daniel Vetter
On Thu, Oct 10, 2019 at 5:13 PM Sean Paul  wrote:
>
> From: Sean Paul 
>
> This reverts commit 1dfdb0e107dbe6ebff3f6bbbe4aad0b5aa87bba4.
>
> As Daniel mentions in his email [1], non-blocking commits don't hold the
> modeset locks, so we can safely access state as long as these functions
> are in the commit path. I'm not entirely sure if these have always been
> isolated to the commit path, but they seem to be now.
>
> [1]- https://lists.freedesktop.org/archives/dri-devel/2019-October/239441.html
>
> Fixes: 1dfdb0e107db ("drm/msm: dpu: Add modeset lock checks where applicable")
> Cc: Jeykumar Sankaran 
> Cc: Rob Clark 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 1 -
>  2 files changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index db6c9ccf3be26..c645dd201368b 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -282,8 +282,6 @@ enum dpu_intf_mode dpu_crtc_get_intf_mode(struct drm_crtc 
> *crtc)
> return INTF_MODE_NONE;
> }
>
> -   WARN_ON(!drm_modeset_is_locked(>mutex));

This one is worse ... it's used in two places:
- debugfs, where you actually want to make sure you're holding this lock
- atomic_check, where this is broken since you're supposed to look at
the free-standing states only, except if you really know what you're
doing. Given that there's no comment here, I suspect that's not the
case. Note that for atomic_check you're guaranteed to hold the modeset
lock.

I'd put a FIXME here, but leave the WARN_ON until this is fixed properly.
> -
> /* TODO: Returns the first INTF_MODE, could there be multiple values? 
> */
> drm_for_each_encoder_mask(encoder, crtc->dev, 
> crtc->state->encoder_mask)
> return dpu_encoder_get_intf_mode(encoder);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index e393a423d7d7a..0e68e20d19c87 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -305,7 +305,6 @@ void dpu_kms_encoder_enable(struct drm_encoder *encoder)
> if (funcs && funcs->commit)
> funcs->commit(encoder);
>
> -   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));

Reviewed-by: Daniel Vetter 

but only for this hunk here.
-Daniel

> drm_for_each_crtc(crtc, dev) {
>     if (!(crtc->state->encoder_mask & drm_encoder_mask(encoder)))
> continue;
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>


-- 
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: [pull] amdgpu/kfd, radeon, ttm drm-next-5.5

2019-10-10 Thread Daniel Vetter
On Thu, Oct 10, 2019 at 4:37 PM Koenig, Christian
 wrote:
> Am 10.10.19 um 16:34 schrieb Alex Deucher:
> > AOn Thu, Oct 10, 2019 at 5:54 AM Daniel Vetter  
> > wrote:
> >> On Thu, Oct 10, 2019 at 6:17 AM Alex Deucher  wrote:
> >>> [SNIP]
> >>> Christian König (22):
> >>>drm/amdgpu: use moving fence instead of exclusive for VM updates
> >>>drm/amdgpu: reserve at least 4MB of VRAM for page tables v2
> >>>drm/amdgpu: remove amdgpu_cs_try_evict
> >> Patch no handy for a direct reply, so asking here (but this is totally
> >> unrelated to the pull):
> >>
> >> Do you have other stuff than scanout and pagetables that need to be in
> >> vram? I was kinda assume this is needed for big vram-only objects to
> >> fit, making space by throwing stuff out that could also be put into
> >> system memory. But sounds like it was only for making pagetables fit.
> > Yes, basically making page tables fit.  If you push a bunch of stuff
> > to system ram, your page table requirements go up too.  See the
> > discussion here:
> > https://www.spinics.net/lists/amd-gfx/msg38640.html

Yeah read that, that's why I asked whether pagetables was the only big thing.

> Yeah, typical chicken and egg problem.
>
> When you evict things to system memory because you don't have enough
> VRAM you need more VRAM for page tables so you need to evict even more
> things to system memory
>
> Additional to that we have a few other cases where we really need VRAM
> for correct operation (firmware, old MM engines etc...), but nothing
> major like page tables.

Yeah makes sense. Afaiui we'll have a few more big things in vram
only, so I think we'll steal this idea for i915.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] treewide: fix interrupted release

2019-10-10 Thread Daniel Vetter
On Thu, Oct 10, 2019 at 03:13:29PM +0200, Johan Hovold wrote:
> Two old USB drivers had a bug in them which could lead to memory leaks
> if an interrupted process raced with a disconnect event.
> 
> Turns out we had a few more driver in other subsystems with the same
> kind of bug in them.
> 
> Note that all but the s390 patch have only been compile tested, while
> the s390 one has not even been built.

Random funny idea: Could we do some debug annotations (akin to
might_sleep) that splats when you might_sleep_interruptible somewhere
where interruptible sleeps are generally a bad idea? Like in
fops->release?

Something like non_block_start/end that I've recently done, but for
interruptible sleeps only? Would need might_sleep_interruptibly()
annotations and non_interruptly_sleep_start/end annotations.
-Daniel

> 
> Johan
> 
> 
> Johan Hovold (4):
>   drm/msm: fix memleak on release
>   media: bdisp: fix memleak on release
>   media: radio: wl1273: fix interrupt masking on release
>   s390/zcrypt: fix memleak at release
> 
>  drivers/gpu/drm/msm/msm_debugfs.c | 6 +-
>  drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 3 +--
>  drivers/media/radio/radio-wl1273.c| 3 +--
>  drivers/s390/crypto/zcrypt_api.c  | 3 +--
>  4 files changed, 4 insertions(+), 11 deletions(-)
> 
> -- 
> 2.23.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH -next] drm/vkms: Remove duplicated include from vkms_drv.c

2019-10-10 Thread Daniel Vetter
On Thu, Oct 10, 2019 at 11:52:13AM +, YueHaibing wrote:
> Remove duplicated include.
> 
> Signed-off-by: YueHaibing 

Applied, thanks.
-Daniel

> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 54703463d966..d1fe144aa289 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -19,7 +19,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> 
> 
> 
> 
> 

-- 
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: linux-next: build failure after merge of the tip tree

2019-10-10 Thread Daniel Vetter
On Thu, Oct 10, 2019 at 10:23:21PM +1100, Stephen Rothwell wrote:
> Hi Ingo,
> 
> On Thu, 10 Oct 2019 10:02:07 +0200 Ingo Molnar  wrote:
> >
> > I suspect -next will have to carry this semantic merge conflict 
> > resolution until the DRM tree is merged upstream.
> 
> Yep, its not a real problem, I get a few like this every cycle.

Yeah totally within expectations when I acked that cleanup patch. We'll
probably have a few more lockdep annotation patches/changes that will
conflict in drm.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] drm/gem: refine drm_gem_objects_lookup

2019-10-10 Thread Daniel Vetter
On Thu, Oct 10, 2019 at 10:02:31AM +0800, Qiang Yu wrote:
> On Wed, Oct 9, 2019 at 10:57 PM Daniel Vetter  wrote:
> >
> > On Fri, Sep 27, 2019 at 08:09:52AM +0800, Qiang Yu wrote:
> > > On Thu, Sep 26, 2019 at 11:01 PM Rob Herring  wrote:
> > > >
> > > > On Thu, Sep 26, 2019 at 9:12 AM Qiang Yu  wrote:
> > > > >
> > > > > Do not use user space bo handles directly and left the user
> > > > > to kernel copy work to drivers calling this function.
> > > > >
> > > > > This is for driver like lima which does not pass gem bo
> > > > > handles continously in an array in ioctl argument.
> > > > >
> > > > > Cc: Rob Herring 
> > > > > Cc: Tomeu Vizoso 
> > > > > Cc: Steven Price 
> > > > > Cc: Alyssa Rosenzweig 
> > > > > Signed-off-by: Qiang Yu 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_gem.c   | 28 
> > > > > +++--
> > > > >  drivers/gpu/drm/panfrost/panfrost_drv.c | 23 +---
> > > >
> > > > Please keep the current variant. While only panfrost is converted ATM,
> > > > vc4 and v3d will use this too.
> > > >
> > > > >  include/drm/drm_gem.h   |  2 +-
> > > > >  3 files changed, 29 insertions(+), 24 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > > > > index 6854f5867d51..9f73e5f3b53f 100644
> > > > > --- a/drivers/gpu/drm/drm_gem.c
> > > > > +++ b/drivers/gpu/drm/drm_gem.c
> > > > > @@ -679,11 +679,11 @@ static int objects_lookup(struct drm_file 
> > > > > *filp, u32 *handle, int count,
> > > > >  /**
> > > > >   * drm_gem_objects_lookup - look up GEM objects from an array of 
> > > > > handles
> > > > >   * @filp: DRM file private date
> > > > > - * @bo_handles: user pointer to array of userspace handle
> > > > > + * @bo_handles: array of GEM object handles
> > > > >   * @count: size of handle array
> > > > >   * @objs_out: returned pointer to array of drm_gem_object pointers
> > > > >   *
> > > > > - * Takes an array of userspace handles and returns a newly allocated 
> > > > > array of
> > > > > + * Takes an array of GEM object handles and returns a newly 
> > > > > allocated array of
> > > > >   * GEM objects.
> > > > >   *
> > > > >   * For a single handle lookup, use drm_gem_object_lookup().
> > > > > @@ -695,11 +695,10 @@ static int objects_lookup(struct drm_file 
> > > > > *filp, u32 *handle, int count,
> > > > >   * failure. 0 is returned on success.
> > > > >   *
> > > > >   */
> > > > > -int drm_gem_objects_lookup(struct drm_file *filp, void __user 
> > > > > *bo_handles,
> > > > > +int drm_gem_objects_lookup(struct drm_file *filp, u32 *bo_handles,
> > > > >int count, struct drm_gem_object 
> > > > > ***objs_out)
> > > >
> > > > Either split into drm_gem_objects_lookup() and a
> > > > drm_gem_objects_lookup_user() with the latter calling the former or
> > > > just make the helper take both a user and u32* ptr with the
> > > > expectation that only one of them is non-NULL.
> > > >
> > > OK, I prefer the first way, will send v2 for it.
> >
> > Note that hopefully soon (Christian König is working on it) we'll have
> > ww_mutex locking helpers, which will introduce a drm_gem_operation_ctx.
> > Once we have that I think we can unify a lot of these helpers (Gerd
> > Hoffmann has looked into it) all while making them more flexible (i.e. not
> > only works with arrays). So might be worth to coordinate a bit here, and
> > maybe hold off on just this part for lima for a bit.
> 
> I don't know the context of these works, so I think I'd better wait some time
> for the new interface and send the rest of lima patches as v4.

Yeah I think with the new stuff we might be able to avoid the
kvmalloc_array, that's not really a great idea to plug into a fastpath
like execbuf. The other patches can imo still go ahead, I don't want to
hold up everything :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp-mst: Drop connection_mutex check

2019-10-10 Thread Daniel Vetter
On Wed, Oct 09, 2019 at 06:46:38PM -0400, Lyude Paul wrote:
> oh, completely forgot about this one
> 
> Reviewed-by: Lyude Paul 

Thanks for your review, applied to drm-misc-next.
-Daniel
> 
> On Thu, 2019-10-10 at 00:41 +0200, Daniel Vetter wrote:
> > Private atomic objects have grown their own locking with
> > 
> > commit b962a12050a387e4bbf3a48745afe1d29d396b0d
> > Author: Rob Clark 
> > Date:   Mon Oct 22 14:31:22 2018 +0200
> > 
> > drm/atomic: integrate modeset lock with private objects
> > 
> > which means we're no longer relying on connection_mutex for mst state
> > locking needs.
> > 
> > Cc: Lyude Paul 
> > Cc: Sean Paul 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 6b14b63b8d62..9364e4f42975 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -4186,7 +4186,6 @@ struct drm_dp_mst_topology_state
> > *drm_atomic_get_mst_topology_state(struct drm_a
> >  {
> > struct drm_device *dev = mgr->dev;
> >  
> > -   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> > return
> > to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state, 
> > >base));
> >  }
> >  EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
> -- 
> Cheers,
>   Lyude Paul
> 

-- 
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: [pull] amdgpu/kfd, radeon, ttm drm-next-5.5

2019-10-10 Thread Daniel Vetter
ivers/gpu/drm/amd/powerplay/renoir_ppt.h |  25 +
>  drivers/gpu/drm/amd/powerplay/smu_v11_0.c  |  45 +-
>  drivers/gpu/drm/amd/powerplay/smu_v12_0.c  |  92 +++-
>  .../gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c|   2 +-
>  drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c |   2 -
>  .../gpu/drm/amd/powerplay/smumgr/vega10_smumgr.c   |   2 +-
>  .../gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c   |   2 +-
>  .../gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c   |   4 +-
>  drivers/gpu/drm/amd/powerplay/vega20_ppt.c |  13 +-
>  drivers/gpu/drm/radeon/radeon_audio.c  |   4 +-
>  drivers/gpu/drm/radeon/radeon_drv.c|  31 ++
>  drivers/gpu/drm/radeon/radeon_kms.c|  25 -
>  drivers/gpu/drm/ttm/ttm_bo.c   |  44 +-
>  include/drm/amd_asic_type.h|  56 +-
>  include/linux/device_cgroup.h  |  19 +-
>  include/uapi/drm/amdgpu_drm.h  |   4 +
>  security/device_cgroup.c   |  15 +-
>  276 files changed, 11831 insertions(+), 4303 deletions(-)
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_mmhub.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/mxgpu_nv.h
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/umc_v6_0.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/umc_v6_0.h
>  create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c
>  create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.h
>  create mode 100644 drivers/gpu/drm/amd/display/dc/dm_cp_psp.h
>  create mode 100644 drivers/gpu/drm/amd/display/dc/hdcp/Makefile
>  create mode 100644 drivers/gpu/drm/amd/display/dc/hdcp/hdcp_msg.c
>  create mode 100644 drivers/gpu/drm/amd/display/include/hdcp_types.h
>  create mode 100644 drivers/gpu/drm/amd/display/modules/hdcp/Makefile
>  create mode 100644 drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c
>  create mode 100644 drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h
>  create mode 100644 drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c
>  create mode 100644 
> drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_transition.c
>  create mode 100644 drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c
>  create mode 100644 drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.c
>  create mode 100644 drivers/gpu/drm/amd/display/modules/hdcp/hdcp_log.h
>  create mode 100644 drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c
>  create mode 100644 drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.h
>  create mode 100644 drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h
>  create mode 100644 
> drivers/gpu/drm/amd/include/ivsrcid/nbio/irqsrcs_nbif_7_4.h



-- 
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 1/2] drm/nouveau: move io_reserve_lru handling into the driver

2019-10-10 Thread Daniel Vetter
On Thu, Oct 10, 2019 at 9:54 AM Christian König
 wrote:
>
> Am 09.10.19 um 17:39 schrieb Daniel Vetter:
> > On Mon, Sep 30, 2019 at 03:12:53PM +0200, Christian König wrote:
> > [SNIP]
> >> +static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
> >> +{
> >> +struct vm_area_struct *vma = vmf->vma;
> >> +struct ttm_buffer_object *bo = vma->vm_private_data;
> >> +pgprot_t prot;
> >> +vm_fault_t ret;
> >> +
> >> +ret = ttm_bo_vm_reserve(bo, vmf);
> >> +if (ret)
> >> +return ret;
> >> +
> >> +nouveau_bo_del_io_reserve_lru(bo);
> > Isn't this opening up a can of worms (in theory) where a lot of concurrent
> > faults will all fail because they're all removed themselves from the lru,
> > so can't see anyone else to throw out?
> >
> > Same problem really that ttm had (well still has I think for !amdgpu) with
> > its other lru ...
> >
> > Or am I getting totally lost again here?
>
> No, your are pretty much correct. But we are not opening up that can of
> worms, it has been here for like always.

Ah, I didn't check the ttm-based version closely enough to convince
myself it has the same problem.

> You just need to imagine that you have two processes kicking out the
> page tables of each other before somebody had a chance to make progress.
> This will just loop forever :)
>
> The correct solution is to not use a BO based approach at all, but
> rather a window based approach where you have an LRU of the window you
> gave out last to access something. This way you have a much larger
> number of windows you can use (4k if you use 64kB window size on a 256MB
> BAR).
>
> This way you can safely assume that the number of windows you have
> available is always larger than the number of faults you can process at
> the same time. But that would require quite a bunch of changes for TTM
> as well as nouveau.

Yeah we do that on i915 since a while, buffers became way too big.
Somewhat tricky on older hw where we also detile, there the window we
pick needs to be at least a full tile row.

> BTW: This is one of the reasons (additional to that it is horrible slow)
> why we never used the remapping feature on AMD hardware for Linux.

Not feeling like a full r-b, and you definitely want someone to test
this on nouveau, but at leat

Acked-by: Daniel Vetter 

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

Re: [PATCH v6] drm: two planes with the same zpos have undefined ordering

2019-10-09 Thread Daniel Vetter
On Wed, Oct 09, 2019 at 03:10:49PM +, Simon Ser wrote:
> Currently the property docs don't specify whether it's okay for two planes to
> have the same zpos value and what user-space should expect in this case.
> 
> The unspoken, legacy rule used in the past was to make user-space figure
> out the zpos from object IDs. However some drivers break this rule,
> that's why the ordering is documented as unspecified in case the zpos
> property is missing. User-space should rely on the zpos property only.
> 
> There are some cases in which user-space might read identical zpos
> values for different planes.
> 
> For instance, in case the property is mutable, user-space might set two
> planes' zpos to the same value. This is necessary to support user-space
> using the legacy DRM API where atomic commits are not possible:
> user-space needs to update the planes' zpos one by one.
> 
> Because of this, user-space should handle multiple planes with the same
> zpos.
> 
> While at it, remove the assumption that zpos is only for overlay planes.
> 
> Additionally, update the drm_plane_state.zpos docs to clarify that zpos
> disambiguation via plane object IDs is a recommendation for drivers, not
> something user-space can rely on. In other words, when user-space sets
> the same zpos on two planes, drivers should rely on the plane object ID.
> 
> v2: clarify drm_plane_state.zpos docs (Daniel)
> 
> v3: zpos is for all planes (Marius, Daniel)
> 
> v4: completely reword the drm_plane_state.zpos docs to make it clear the
> recommendation to use plane IDs is for drivers in case user-space uses
> duplicate zpos values (Pekka)
> 
> v5: reword commit message (Pekka, James)
> 
> v6: remove mention of Arm GPUs having planes which can't overlap,
> because this isn't uAPI yet (Daniel)
> 
> Signed-off-by: Simon Ser 
> Reviewed-by: Pekka Paalanen 
> Cc: Marius Vlad 
> Cc: Daniel Vetter 
> Cc: James Qian Wang 

Applied, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_blend.c | 8 
>  include/drm/drm_plane.h | 9 +
>  2 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index d02709dd2d4a..121481f6aa71 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -132,10 +132,10 @@
>   *   planes. Without this property the primary plane is always below the 
> cursor
>   *   plane, and ordering between all other planes is undefined. The positive
>   *   Z axis points towards the user, i.e. planes with lower Z position values
> - *   are underneath planes with higher Z position values. Note that the Z
> - *   position value can also be immutable, to inform userspace about the
> - *   hard-coded stacking of overlay planes, see
> - *   drm_plane_create_zpos_immutable_property().
> + *   are underneath planes with higher Z position values. Two planes with the
> + *   same Z position value have undefined ordering. Note that the Z position
> + *   value can also be immutable, to inform userspace about the hard-coded
> + *   stacking of planes, see drm_plane_create_zpos_immutable_property().
>   *
>   * pixel blend mode:
>   *   Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index cd5903ad33f7..328773690851 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -140,10 +140,11 @@ struct drm_plane_state {
>* @zpos:
>* Priority of the given plane on crtc (optional).
>*
> -  * Note that multiple active planes on the same crtc can have an
> -  * identical zpos value. The rule to solving the conflict is to compare
> -  * the plane object IDs; the plane with a higher ID must be stacked on
> -  * top of a plane with a lower ID.
> +  * User-space may set mutable zpos properties so that multiple active
> +  * planes on the same CRTC have identical zpos values. This is a
> +  * user-space bug, but drivers can solve the conflict by comparing the
> +  * plane object IDs; the plane with a higher ID is stacked on top of a
> +  * plane with a lower ID.
>*
>* See drm_plane_create_zpos_property() and
>* drm_plane_create_zpos_immutable_property() for more details.
> --
> 2.23.0
> 
> 

-- 
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] drm/dp-mst: Drop connection_mutex check

2019-10-09 Thread Daniel Vetter
Private atomic objects have grown their own locking with

commit b962a12050a387e4bbf3a48745afe1d29d396b0d
Author: Rob Clark 
Date:   Mon Oct 22 14:31:22 2018 +0200

drm/atomic: integrate modeset lock with private objects

which means we're no longer relying on connection_mutex for mst state
locking needs.

Cc: Lyude Paul 
Cc: Sean Paul 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6b14b63b8d62..9364e4f42975 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4186,7 +4186,6 @@ struct drm_dp_mst_topology_state 
*drm_atomic_get_mst_topology_state(struct drm_a
 {
struct drm_device *dev = mgr->dev;
 
-   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
return to_dp_mst_topology_state(drm_atomic_get_private_obj_state(state, 
>base));
 }
 EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
-- 
2.23.0

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

Re: [PATCH v2 16/24] drm/msm: dpu: Add modeset lock checks where applicable

2019-10-09 Thread Daniel Vetter
On Fri, Nov 16, 2018 at 7:44 PM Sean Paul  wrote:
>
> From: Sean Paul 
>
> Add modeset lock checks to functions that could be called outside the
> core atomic stack.
>
> Changes in v2:
> - None
>
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 1 +
>  2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index a008a87a8113..cd0a0bea4335 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -284,6 +284,8 @@ enum dpu_intf_mode dpu_crtc_get_intf_mode(struct drm_crtc 
> *crtc)
> return INTF_MODE_NONE;
> }
>
> +   WARN_ON(!drm_modeset_is_locked(>mutex));
> +
> /* TODO: Returns the first INTF_MODE, could there be multiple values? 
> */
> drm_for_each_encoder_mask(encoder, crtc->dev, 
> crtc->state->encoder_mask)
> return dpu_encoder_get_intf_mode(encoder);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 64134d619748..5104fc01147e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -358,6 +358,7 @@ void dpu_kms_encoder_enable(struct drm_encoder *encoder)
> if (funcs && funcs->commit)
> funcs->commit(encoder);
>
> +   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> drm_for_each_crtc(crtc, dev) {
> if (!(crtc->state->encoder_mask & drm_encoder_mask(encoder)))
> continue;

I'm fairly sure this is called in the atomic_commit path, and in there
you might not actually hold these locks (if you do a nonblocking
modeset).

The locking rules for ->state are pretty fun: Either hold the lock, or
be in atomic commit. In the later case atomic helpers' commit ordering
guarantees that you can safely access ->state (but read-only only)
without hodling any locks. You might want to revert.

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

Re: drm/amd/display: Add HDCP module - static analysis bug report

2019-10-09 Thread Daniel Vetter
On Wed, Oct 9, 2019 at 10:46 PM Lakha, Bhawanpreet
 wrote:
>
> I misunderstood and was talking about the ksv validation specifically
> (usage of drm_hdcp_check_ksvs_revoked()).

Hm for that specifically I think you want to do both, i.e. both
consult your psp, but also check for revoked ksvs with the core
helper. At least on some platforms only the core helper might have the
updated revoke list.

> For the defines I will create patches to use drm_hdcp where it is usable.

Thanks a lot. Ime once we have shared definitions it's much easier to
also share some helpers, where it makes sense.

Aside I think the hdcp code could also use a bit of demidlayering. At
least I'm not understanding why you add a 2nd abstraction layer for
i2c/dpcd, dm_helper already has that. That seems like one abstraction
layer too much.
-Daniel

>
>
> Bhawan
>
> On 2019-10-09 2:43 p.m., Daniel Vetter wrote:
> > On Wed, Oct 9, 2019 at 8:23 PM Lakha, Bhawanpreet
> >  wrote:
> >> Hi,
> >>
> >> The reason we don't use drm_hdcp is because our policy is to do hdcp
> >> verification using PSP/HW (onboard secure processor).
> > i915 also uses hw to auth, we still use the parts from drm_hdcp ...
> > Did you actually look at what's in there? It's essentially just shared
> > defines and data structures from the standard, plus a few minimal
> > helpers to en/decode some bits. Just from a quick read the entire
> > patch very much looks like midlayer everywhere design that we
> > discussed back when DC landed ...
> > -Daniel
> >
> >> Bhawan
> >>
> >> On 2019-10-09 12:32 p.m., Daniel Vetter wrote:
> >>> On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
> >>>> Hi,
> >>>>
> >>>> Static analysis with Coverity has detected a potential issue with
> >>>> function validate_bksv in
> >>>> drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
> >>>> commit:
> >>>>
> >>>> commit ed9d8e2bcb003ec94658cafe9b1bb3960e2139ec
> >>>> Author: Bhawanpreet Lakha 
> >>>> Date:   Tue Aug 6 17:52:01 2019 -0400
> >>>>
> >>>>   drm/amd/display: Add HDCP module
> >>> I think the real question here is ... why is this not using drm_hdcp?
> >>> -Daniel
> >>>
> >>>> The analysis is as follows:
> >>>>
> >>>>28 static inline enum mod_hdcp_status validate_bksv(struct mod_hdcp 
> >>>> *hdcp)
> >>>>29 {
> >>>>
> >>>> CID 89852 (#1 of 1): Out-of-bounds read (OVERRUN)
> >>>>
> >>>> 1. overrun-local:
> >>>> Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
> >>>> (uint64_t *)hdcp->auth.msg.hdcp1.bksv.
> >>>>
> >>>>30uint64_t n = *(uint64_t *)hdcp->auth.msg.hdcp1.bksv;
> >>>>31uint8_t count = 0;
> >>>>32
> >>>>33while (n) {
> >>>>34count++;
> >>>>35n &= (n - 1);
> >>>>36}
> >>>>
> >>>> hdcp->auth.msg.hdcp1.bksv is an array of 5 uint8_t as defined in
> >>>> drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h as follows:
> >>>>
> >>>> struct mod_hdcp_message_hdcp1 {
> >>>>   uint8_t an[8];
> >>>>   uint8_t aksv[5];
> >>>>   uint8_t     ainfo;
> >>>>   uint8_t bksv[5];
> >>>>   uint16_tr0p;
> >>>>   uint8_t bcaps;
> >>>>   uint16_tbstatus;
> >>>>   uint8_t ksvlist[635];
> >>>>   uint16_tksvlist_size;
> >>>>   uint8_t vp[20];
> >>>>
> >>>>   uint16_tbinfo_dp;
> >>>> };
> >>>>
> >>>> variable n is going to contain the contains of r0p and bcaps. I'm not
> >>>> sure if that is intentional. If not, then the count is going to be
> >>>> incorrect if these are non-zero.
> >>>>
> >>>> Colin
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >



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

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

2019-10-09 Thread Daniel Vetter
On Wed, Oct 9, 2019 at 8:52 PM Greathouse, Joseph
 wrote:
>
> > From: Daniel Vetter  On Behalf Of Daniel Vetter
> > Sent: Wednesday, October 9, 2019 11:07 AM
> > On Wed, Oct 09, 2019 at 03:53:42PM +, Kuehling, Felix wrote:
> > > On 2019-10-09 11:34, Daniel Vetter wrote:
> > > > On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> > > >> On 2019-10-09 6:31, Daniel Vetter wrote:
> > > >>> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> > > >>>> The description sounds reasonable to me and maps well to the CU 
> > > >>>> masking
> > > >>>> feature in our GPUs.
> > > >>>>
> > > >>>> It would also allow us to do more coarse-grained masking for example 
> > > >>>> to
> > > >>>> guarantee balanced allocation of CUs across shader engines or
> > > >>>> partitioning of memory bandwidth or CP pipes (if that is supported by
> > > >>>> the hardware/firmware).
> > > >>> Hm, so this sounds like the definition for how this cgroup is 
> > > >>> supposed to
> > > >>> work is "amd CU masking" (whatever that exactly is). And the abstract
> > > >>> description is just prettification on top, but not actually the real
> > > >>> definition you guys want.
> > > >> I think you're reading this as the opposite of what I was trying to 
> > > >> say.
> > > >> Using CU masking is one possible implementation of LGPUs on AMD
> > > >> hardware. It's the one that Kenny implemented at the end of this patch
> > > >> series, and I pointed out some problems with that approach. Other ways
> > > >> to partition the hardware into LGPUs are conceivable. For example we're
> > > >> considering splitting it along the lines of shader engines, which is
> > > >> more coarse-grain and would also affect memory bandwidth available to
> > > >> each partition.
> > > > If this is supposed to be useful for admins then "other ways to 
> > > > partition
> > > > the hw are conceivable" is the problem. This should be unique for
> > > > admins/end-users. Reading the implementation details and realizing that
> > > > the actual meaning is "amd CU masking" isn't good enough by far, since
> > > > that's meaningless on any other hw.
> > > >
> > > > And if there's other ways to implement this cgroup for amd, it's also
> > > > meaningless (to sysadmins/users) for amd hw.
> > > >
> > > >> We could also consider partitioning pipes in our command processor,
> > > >> although that is not supported by our current CP scheduler firmware.
> > > >>
> > > >> The bottom line is, the LGPU model proposed by Kenny is quite abstract
> > > >> and allows drivers implementing it a lot of flexibility depending on 
> > > >> the
> > > >> capability of their hardware and firmware. We haven't settled on a 
> > > >> final
> > > >> implementation choice even for AMD.
> > > > That abstract model of essentially "anything goes" is the problem here
> > > > imo. E.g. for cpu cgroups this would be similar to allowing the bitmaks 
> > > > to
> > > > mean "cpu core" on one machine "physical die" on the next and maybe
> > > > "hyperthread unit" on the 3rd. Useless for admins.
> > > >
> > > > So if we have a gpu bitmaks thing that might mean a command submissio 
> > > > pipe
> > > > on one hw (maybe matching what vk exposed, maybe not), some compute unit
> > > > mask on the next and something entirely different (e.g. intel has so
> > > > called GT slices with compute cores + more stuff around) on the 3rd 
> > > > vendor
> > > > then that's not useful for admins.
> > >
> > > The goal is to partition GPU compute resources to eliminate as much
> > > resource contention as possible between different partitions. Different
> > > hardware will have different capabilities to implement this. No
> > > implementation will be perfect. For example, even with CPU cores that
> > > are supposedly well defined, you can still have different behaviours
> > > depending on CPU cache architectures, NUMA and thermal management across
> > > CPU cores. The a

Re: drm/amd/display: Add HDCP module - static analysis bug report

2019-10-09 Thread Daniel Vetter
On Wed, Oct 9, 2019 at 8:23 PM Lakha, Bhawanpreet
 wrote:
>
> Hi,
>
> The reason we don't use drm_hdcp is because our policy is to do hdcp
> verification using PSP/HW (onboard secure processor).

i915 also uses hw to auth, we still use the parts from drm_hdcp ...
Did you actually look at what's in there? It's essentially just shared
defines and data structures from the standard, plus a few minimal
helpers to en/decode some bits. Just from a quick read the entire
patch very much looks like midlayer everywhere design that we
discussed back when DC landed ...
-Daniel

>
> Bhawan
>
> On 2019-10-09 12:32 p.m., Daniel Vetter wrote:
> > On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
> >> Hi,
> >>
> >> Static analysis with Coverity has detected a potential issue with
> >> function validate_bksv in
> >> drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
> >> commit:
> >>
> >> commit ed9d8e2bcb003ec94658cafe9b1bb3960e2139ec
> >> Author: Bhawanpreet Lakha 
> >> Date:   Tue Aug 6 17:52:01 2019 -0400
> >>
> >>  drm/amd/display: Add HDCP module
> > I think the real question here is ... why is this not using drm_hdcp?
> > -Daniel
> >
> >>
> >> The analysis is as follows:
> >>
> >>   28 static inline enum mod_hdcp_status validate_bksv(struct mod_hdcp 
> >> *hdcp)
> >>   29 {
> >>
> >> CID 89852 (#1 of 1): Out-of-bounds read (OVERRUN)
> >>
> >> 1. overrun-local:
> >> Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
> >> (uint64_t *)hdcp->auth.msg.hdcp1.bksv.
> >>
> >>   30uint64_t n = *(uint64_t *)hdcp->auth.msg.hdcp1.bksv;
> >>   31uint8_t count = 0;
> >>   32
> >>   33while (n) {
> >>   34count++;
> >>   35n &= (n - 1);
> >>   36}
> >>
> >> hdcp->auth.msg.hdcp1.bksv is an array of 5 uint8_t as defined in
> >> drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h as follows:
> >>
> >> struct mod_hdcp_message_hdcp1 {
> >>  uint8_t an[8];
> >>  uint8_t aksv[5];
> >>  uint8_t ainfo;
> >>  uint8_t bksv[5];
> >>  uint16_tr0p;
> >>  uint8_t bcaps;
> >>  uint16_tbstatus;
> >>  uint8_t ksvlist[635];
> >>  uint16_tksvlist_size;
> >>  uint8_t vp[20];
> >>
> >>  uint16_tbinfo_dp;
> >> };
> >>
> >> variable n is going to contain the contains of r0p and bcaps. I'm not
> >> sure if that is intentional. If not, then the count is going to be
> >> incorrect if these are non-zero.
> >>
> >> Colin
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: drm/amd/display: Add HDCP module - static analysis bug report

2019-10-09 Thread Daniel Vetter
On Thu, Oct 03, 2019 at 11:08:03PM +0100, Colin Ian King wrote:
> Hi,
> 
> Static analysis with Coverity has detected a potential issue with
> function validate_bksv in
> drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
> commit:
> 
> commit ed9d8e2bcb003ec94658cafe9b1bb3960e2139ec
> Author: Bhawanpreet Lakha 
> Date:   Tue Aug 6 17:52:01 2019 -0400
> 
> drm/amd/display: Add HDCP module

I think the real question here is ... why is this not using drm_hdcp?
-Daniel

> 
> 
> The analysis is as follows:
> 
>  28 static inline enum mod_hdcp_status validate_bksv(struct mod_hdcp *hdcp)
>  29 {
> 
> CID 89852 (#1 of 1): Out-of-bounds read (OVERRUN)
> 
> 1. overrun-local:
> Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
> (uint64_t *)hdcp->auth.msg.hdcp1.bksv.
> 
>  30uint64_t n = *(uint64_t *)hdcp->auth.msg.hdcp1.bksv;
>  31uint8_t count = 0;
>  32
>  33while (n) {
>  34count++;
>  35n &= (n - 1);
>  36}
> 
> hdcp->auth.msg.hdcp1.bksv is an array of 5 uint8_t as defined in
> drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h as follows:
> 
> struct mod_hdcp_message_hdcp1 {
> uint8_t an[8];
> uint8_t aksv[5];
> uint8_t ainfo;
> uint8_t bksv[5];
> uint16_tr0p;
> uint8_t bcaps;
> uint16_tbstatus;
> uint8_t ksvlist[635];
> uint16_tksvlist_size;
> uint8_t vp[20];
> 
> uint16_tbinfo_dp;
> };
> 
> variable n is going to contain the contains of r0p and bcaps. I'm not
> sure if that is intentional. If not, then the count is going to be
> incorrect if these are non-zero.
> 
> Colin

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

Re: [PATCH v2 1/6] drm/gem: refine drm_gem_objects_lookup

2019-10-09 Thread Daniel Vetter
On Wed, Oct 09, 2019 at 11:05:31AM -0500, Rob Herring wrote:
> On Wed, Oct 9, 2019 at 10:07 AM Daniel Vetter  wrote:
> >
> > On Fri, Sep 27, 2019 at 09:46:11PM +0800, Qiang Yu wrote:
> > > drm_gem_objects_lookup does not use user space bo handles
> > > directly and left the user to kernel copy work to a new
> > > interface drm_gem_objects_lookup_user.
> > >
> > > This is for driver like lima which does not pass gem bo
> > > handles continously in an array in ioctl argument.
> > >
> > > v2:
> > > 1. add drm_gem_objects_lookup_user
> > > 2. remove none-zero check as all caller will check before
> > >calling this function
> > >
> > > Cc: Rob Herring 
> > > Cc: Tomeu Vizoso 
> > > Cc: Steven Price 
> > > Cc: Alyssa Rosenzweig 
> > > Suggested-by: Rob Herring 
> > > Signed-off-by: Qiang Yu 
> > > ---
> > >  drivers/gpu/drm/drm_gem.c   | 57 +++--
> > >  drivers/gpu/drm/panfrost/panfrost_drv.c |  6 +--
> > >  include/drm/drm_gem.h   |  4 +-
> > >  3 files changed, 49 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > > index 6854f5867d51..a5e88c3e6d25 100644
> > > --- a/drivers/gpu/drm/drm_gem.c
> > > +++ b/drivers/gpu/drm/drm_gem.c
> > > @@ -679,11 +679,11 @@ static int objects_lookup(struct drm_file *filp, 
> > > u32 *handle, int count,
> > >  /**
> > >   * drm_gem_objects_lookup - look up GEM objects from an array of handles
> > >   * @filp: DRM file private date
> > > - * @bo_handles: user pointer to array of userspace handle
> > > + * @bo_handles: array of GEM object handles
> > >   * @count: size of handle array
> > >   * @objs_out: returned pointer to array of drm_gem_object pointers
> > >   *
> > > - * Takes an array of userspace handles and returns a newly allocated 
> > > array of
> > > + * Takes an array of GEM object handles and returns a newly allocated 
> > > array of
> > >   * GEM objects.
> > >   *
> > >   * For a single handle lookup, use drm_gem_object_lookup().
> > > @@ -695,26 +695,56 @@ static int objects_lookup(struct drm_file *filp, 
> > > u32 *handle, int count,
> > >   * failure. 0 is returned on success.
> > >   *
> > >   */
> > > -int drm_gem_objects_lookup(struct drm_file *filp, void __user 
> > > *bo_handles,
> > > +int drm_gem_objects_lookup(struct drm_file *filp, u32 *bo_handles,
> > >  int count, struct drm_gem_object ***objs_out)
> >
> > You can't do this change without updating all the drivers. Simpler to keep
> > this one as-is, and create a new function with an _internal suffix.
> 
> The only driver currently is panfrost and it is updated in this patch.

Oops sry missed that in the diffstat somehow.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 0/2]: Finally delete drmP.h

2019-10-09 Thread Daniel Vetter
On Tue, Oct 08, 2019 at 06:51:54PM +0200, Sam Ravnborg wrote:
> On Mon, Oct 07, 2019 at 07:12:22PM +0200, Sam Ravnborg wrote:
> > One user of drmP.h sneaked in after the merge window.
> > Drop the use of drmP.h and delete the header file for good.
> > 
> > Small band-aid on top of not going to xdc :-)
> > 
> > Build tested with various architectures and configs.
> 
> Applied and pushed to drm-misc-next.

Yeah awesome stuff, let me pile in with the congratulations!!!
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Documentation: Fix warning in drm-kmsc-helpers.rst

2019-10-09 Thread Daniel Vetter
On Mon, Oct 07, 2019 at 11:19:01AM -0400, Sean Paul wrote:
> From: Sean Paul 
> 
> Fixes the following warning:
> ../include/drm/drm_atomic_state_helper.h:1: warning: no structured comments 
> found
> 
> Fixes: 9ef8a9dc4b21 ("drm: Extract drm_atomic_state_helper.[hc]")
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Sean Paul 

Reviewed-by: Daniel Vetter 

> ---
>  Documentation/gpu/drm-kms-helpers.rst | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 3868008db8a9..9668a7fe2408 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -77,9 +77,6 @@ Atomic State Reset and Initialization
>  Atomic State Helper Reference
>  -
>  
> -.. kernel-doc:: include/drm/drm_atomic_state_helper.h
> -   :internal:
> -
>  .. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c
> :export:
>  
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH] drm/drm_syncobj: Dead code removal

2019-10-09 Thread Daniel Vetter
On Fri, Oct 04, 2019 at 03:25:00PM +0300, Lionel Landwerlin wrote:
> On 04/10/2019 15:16, Zbigniew Kempczyński wrote:
> > Remove dead code, likely overseened during review process.
> > 
> > Signed-off-by: Zbigniew Kempczyński 
> > Cc: Chunming Zhou 
> > Cc: Daniel Vetter 
> > Cc: Jason Ekstrand 
> > ---
> >   drivers/gpu/drm/drm_syncobj.c | 4 
> >   1 file changed, 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index 4b5c7b0ed714..21a22e39c9fa 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -192,8 +192,6 @@ static void drm_syncobj_fence_add_wait(struct 
> > drm_syncobj *syncobj,
> > if (!fence || dma_fence_chain_find_seqno(, wait->point)) {
> > dma_fence_put(fence);
> > list_add_tail(>node, >cb_list);
> > -   } else if (!fence) {
> > -   wait->fence = dma_fence_get_stub();
> > } else {
> > wait->fence = fence;
> > }
> > @@ -856,8 +854,6 @@ static void syncobj_wait_syncobj_func(struct 
> > drm_syncobj *syncobj,
> > if (!fence || dma_fence_chain_find_seqno(, wait->point)) {
> > dma_fence_put(fence);
> > return;
> > -   } else if (!fence) {
> > -   wait->fence = dma_fence_get_stub();
> > } else {
> > wait->fence = fence;
> > }
> 
> Like Chris said, dma_fence_chain_find_seqno() will update the fence pointer,
> so a subsequent check might not be dealing with the same value.
> 
> A bit cheeky, but...

Feels like warrants a comment, I missed this one too. Maybe even extract
it into one common function since it's the same code in both places?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

2019-10-09 Thread Daniel Vetter
On Wed, Oct 09, 2019 at 03:53:42PM +, Kuehling, Felix wrote:
> On 2019-10-09 11:34, Daniel Vetter wrote:
> > On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> >> On 2019-10-09 6:31, Daniel Vetter wrote:
> >>> On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> >>>> The description sounds reasonable to me and maps well to the CU masking
> >>>> feature in our GPUs.
> >>>>
> >>>> It would also allow us to do more coarse-grained masking for example to
> >>>> guarantee balanced allocation of CUs across shader engines or
> >>>> partitioning of memory bandwidth or CP pipes (if that is supported by
> >>>> the hardware/firmware).
> >>> Hm, so this sounds like the definition for how this cgroup is supposed to
> >>> work is "amd CU masking" (whatever that exactly is). And the abstract
> >>> description is just prettification on top, but not actually the real
> >>> definition you guys want.
> >> I think you're reading this as the opposite of what I was trying to say.
> >> Using CU masking is one possible implementation of LGPUs on AMD
> >> hardware. It's the one that Kenny implemented at the end of this patch
> >> series, and I pointed out some problems with that approach. Other ways
> >> to partition the hardware into LGPUs are conceivable. For example we're
> >> considering splitting it along the lines of shader engines, which is
> >> more coarse-grain and would also affect memory bandwidth available to
> >> each partition.
> > If this is supposed to be useful for admins then "other ways to partition
> > the hw are conceivable" is the problem. This should be unique for
> > admins/end-users. Reading the implementation details and realizing that
> > the actual meaning is "amd CU masking" isn't good enough by far, since
> > that's meaningless on any other hw.
> >
> > And if there's other ways to implement this cgroup for amd, it's also
> > meaningless (to sysadmins/users) for amd hw.
> >
> >> We could also consider partitioning pipes in our command processor,
> >> although that is not supported by our current CP scheduler firmware.
> >>
> >> The bottom line is, the LGPU model proposed by Kenny is quite abstract
> >> and allows drivers implementing it a lot of flexibility depending on the
> >> capability of their hardware and firmware. We haven't settled on a final
> >> implementation choice even for AMD.
> > That abstract model of essentially "anything goes" is the problem here
> > imo. E.g. for cpu cgroups this would be similar to allowing the bitmaks to
> > mean "cpu core" on one machine "physical die" on the next and maybe
> > "hyperthread unit" on the 3rd. Useless for admins.
> >
> > So if we have a gpu bitmaks thing that might mean a command submissio pipe
> > on one hw (maybe matching what vk exposed, maybe not), some compute unit
> > mask on the next and something entirely different (e.g. intel has so
> > called GT slices with compute cores + more stuff around) on the 3rd vendor
> > then that's not useful for admins.
> 
> The goal is to partition GPU compute resources to eliminate as much 
> resource contention as possible between different partitions. Different 
> hardware will have different capabilities to implement this. No 
> implementation will be perfect. For example, even with CPU cores that 
> are supposedly well defined, you can still have different behaviours 
> depending on CPU cache architectures, NUMA and thermal management across 
> CPU cores. The admin will need some knowledge of their hardware 
> architecture to understand those effects that are not described by the 
> abstract model of cgroups.

That's not the point I was making. For cpu cgroups there's a very well
defined connection between the cpu bitmasks/numbers in cgroups and the cpu
bitmasks you use in various system calls (they match). And that stuff
works across vendors.

We need the same for gpus.

> The LGPU model is deliberately flexible, because GPU architectures are 
> much less standardized than CPU architectures. Expecting a common model 
> that is both very specific and applicable to to all GPUs is unrealistic, 
> in my opinion.

So pure abstraction isn't useful, we need to know what these bits mean.
Since if they e.g. mean vk pipes, then maybe I shouldn't be using those vk
pipes in my application anymore. Or we need to define that the userspace
driver needs to filter out any pipes that arent' accessible (if that's
possible, no idea).

cgroups that e

Re: [Intel-gfx] [PATCH 5/5] drm/mm: Use clear_bit_unlock() for releasing the drm_mm_node()

2019-10-09 Thread Daniel Vetter
On Fri, Oct 04, 2019 at 01:01:36PM +0100, Tvrtko Ursulin wrote:
> 
> On 04/10/2019 12:17, Chris Wilson wrote:
> > Quoting Chris Wilson (2019-10-04 12:07:10)
> > > Quoting Tvrtko Ursulin (2019-10-04 10:15:20)
> > > > 
> > > > On 03/10/2019 22:01, Chris Wilson wrote:
> > > > > A few callers need to serialise the destruction of their drm_mm_node 
> > > > > and
> > > > > ensure it is removed from the drm_mm before freeing. However, to be
> > > > > completely sure that any access from another thread is complete before
> > > > > we free the struct, we require the RELEASE semantics of
> > > > > clear_bit_unlock().
> > > > > 
> > > > > This allows the conditional locking such as
> > > > > 
> > > > > Thread A  Thread B
> > > > >   mutex_lock(mm_lock);if 
> > > > > (drm_mm_node_allocated(node)) {
> > > > >   drm_mm_node_remove(node);   mutex_lock(mm_lock);
> > > > >   mutex_unlock(mm_lock);  
> > > > > drm_mm_node_remove(node);
> > > > >   mutex_unlock(mm_lock);
> > > > >}
> > > > >kfree(node);
> > > > 
> > > > My understanding is that release semantics on node allocated mean 1 -> 0
> > > > transition is guaranteed to be seen only when thread A
> > > > drm_mm_node_remove is fully done with the removal. But if it is in the
> > > > middle of removal, node is still seen as allocated outside and thread B
> > > > can enter the if-body, wait for the lock, and then drm_mm_node_remove
> > > > will attempt a double removal. So I think another drm_mm_node_allocated
> > > > under the lock is needed.
> > > 
> > > Yes. Check after the lock is indeed required in this scenario. And
> > > drm_mm_node_remove() insists the caller doesn't try a double remove.
> > 
> > I had to go back and double check the vma code, and that's fine.
> > (We hit this case where one thread is evicting and another thread is
> > destroying the object. And for us we do the check under the lock inside
> > __i915_vma_unbind() on the destroy path.)
> 
> So I think if you amend the commit message to contain the repeated check
> under the lock patch looks good to me. With that:
> 
> Reviewed-by: Tvrtko Ursulin 

I think a follow-up patch to update the kerneldoc to mention that we're
guaranteeing this now is missing here (best with the above fixed example).
Plus maybe a oneline code comment for the ALLOCATED_BIT.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH v2] drm: Add getfb2 ioctl

2019-10-09 Thread Daniel Vetter
   >handles[i]);
> + } else {
> + WARN_ON(i > 0);
> + ret = fb->funcs->create_handle(fb, file_priv,
> +>handles[i]);
> + }
> +
> + if (ret != 0)
> + goto out;
> + }
> +
> +out:
> + if (ret != 0) {
> + /* Delete any previously-created handles on failure. */
> + for (i = 0; i < ARRAY_SIZE(r->handles); i++) {
> + int j;
> +
> + if (r->handles[i])
> + drm_gem_handle_delete(file_priv, r->handles[i]);
> +
> + /* Zero out any handles identical to the one we just
> +  * deleted.
> +  */
> + for (j = i + 1; j < ARRAY_SIZE(r->handles); j++) {
> + if (r->handles[j] == r->handles[i])
> + r->handles[j] = 0;
> + }
> + }
> + }
> +
> + drm_framebuffer_put(fb);
>   return ret;
>  }
>  
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index fcd728d7cf72..b1fafce3ad8c 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -671,6 +671,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>   DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPROPERTY, 
> drm_connector_property_set_ioctl, DRM_MASTER),
>   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl, 0),
>   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb, 0),
> + DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB2, drm_mode_getfb2_ioctl, 0),
>   DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb_ioctl, 0),
>   DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB2, drm_mode_addfb2_ioctl, 0),
>   DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb_ioctl, 0),
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 8a5b2f8f8eb9..021f33675ba2 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -947,6 +947,8 @@ extern "C" {
>  #define DRM_IOCTL_SYNCOBJ_TRANSFER   DRM_IOWR(0xCC, struct 
> drm_syncobj_transfer)
>  #define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNALDRM_IOWR(0xCD, struct 
> drm_syncobj_timeline_array)
>  
> +#define DRM_IOCTL_MODE_GETFB2DRM_IOWR(0xCE, struct 
> drm_mode_fb_cmd2)
> +
>  /**
>   * Device specific ioctls should only be in their respective headers
>   * The device specific ioctl range is from 0x40 to 0x9f.
> -- 
> 2.21.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH i-g-t v2 2/2] NOMERGE: Import drm.h up to 54ecb8f7028c

2019-10-09 Thread Daniel Vetter
On Thu, Oct 03, 2019 at 11:46:28AM -0700, Juston Li wrote:
> Depends on ummerged kernel code for getfb2
> 
> Rest of drm.h taken from:
> commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c
> Author: Linus Torvalds 
> Date:   Mon Sep 30 10:35:40 2019 -0700
> 
> Linux 5.4-rc1
> 
> Signed-off-by: Juston Li 

I guess this should be first, then the patch that uses it?
-Daniel

> ---
>  include/drm-uapi/drm.h | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/include/drm-uapi/drm.h b/include/drm-uapi/drm.h
> index 85c685a2075e..0b02f4c92d1e 100644
> --- a/include/drm-uapi/drm.h
> +++ b/include/drm-uapi/drm.h
> @@ -643,6 +643,7 @@ struct drm_gem_open {
>  #define DRM_CAP_PAGE_FLIP_TARGET 0x11
>  #define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
>  #define DRM_CAP_SYNCOBJ  0x13
> +#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
>  
>  /** DRM_IOCTL_GET_CAP ioctl argument type */
>  struct drm_get_cap {
> @@ -729,8 +730,18 @@ struct drm_syncobj_handle {
>   __u32 pad;
>  };
>  
> +struct drm_syncobj_transfer {
> + __u32 src_handle;
> + __u32 dst_handle;
> + __u64 src_point;
> + __u64 dst_point;
> + __u32 flags;
> + __u32 pad;
> +};
> +
>  #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
>  #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
> +#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time 
> point to become available */
>  struct drm_syncobj_wait {
>   __u64 handles;
>   /* absolute timeout */
> @@ -741,12 +752,33 @@ struct drm_syncobj_wait {
>   __u32 pad;
>  };
>  
> +struct drm_syncobj_timeline_wait {
> + __u64 handles;
> + /* wait on specific timeline point for every handles*/
> + __u64 points;
> + /* absolute timeout */
> + __s64 timeout_nsec;
> + __u32 count_handles;
> + __u32 flags;
> + __u32 first_signaled; /* only valid when not waiting all */
> + __u32 pad;
> +};
> +
> +
>  struct drm_syncobj_array {
>   __u64 handles;
>   __u32 count_handles;
>   __u32 pad;
>  };
>  
> +struct drm_syncobj_timeline_array {
> + __u64 handles;
> + __u64 points;
> + __u32 count_handles;
> + __u32 pad;
> +};
> +
> +
>  /* Query current scanout sequence number */
>  struct drm_crtc_get_sequence {
>   __u32 crtc_id;  /* requested crtc_id */
> @@ -903,6 +935,13 @@ extern "C" {
>  #define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct 
> drm_mode_get_lease)
>  #define DRM_IOCTL_MODE_REVOKE_LEASE  DRM_IOWR(0xC9, struct 
> drm_mode_revoke_lease)
>  
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT  DRM_IOWR(0xCA, struct 
> drm_syncobj_timeline_wait)
> +#define DRM_IOCTL_SYNCOBJ_QUERY  DRM_IOWR(0xCB, struct 
> drm_syncobj_timeline_array)
> +#define DRM_IOCTL_SYNCOBJ_TRANSFER   DRM_IOWR(0xCC, struct 
> drm_syncobj_transfer)
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNALDRM_IOWR(0xCD, struct 
> drm_syncobj_timeline_array)
> +
> +#define DRM_IOCTL_MODE_GETFB2DRM_IOWR(0xCE, struct 
> drm_mode_fb_cmd2)
> +
>  /**
>   * Device specific ioctls should only be in their respective headers
>   * The device specific ioctl range is from 0x40 to 0x9f.
> -- 
> 2.21.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: [igt-dev] [PATCH i-g-t] tests/kms_crtc_background_color: overhaul to match upstream ABI (v5.1)

2019-10-09 Thread Daniel Vetter
On Tue, Oct 01, 2019 at 03:27:41PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 30, 2019 at 10:18:17PM -0400, Martin Peres wrote:
> > On 30/09/2019 19:13, Matt Roper wrote:
> > > CRTC background color kernel patches were written about 2.5 years ago
> > > and floated on the upstream mailing list, but since no opensource
> > > userspace materialized, we never actually merged them.  However the
> > > corresponding IGT test did get merged and has basically been dead code
> > > ever since.
> > > 
> > > A couple years later we finally have an open source userspace
> > > (ChromeOS), so lets update the IGT test to match the ABI that's actually
> > > going upstream and to remove some of the cruft from the original test
> > > that wouldn't actually work.
> > > 
> > > It's worth noting that CRC's don't seem to work properly on Intel gen9.
> > > The bspec does tell us that we must have one plane enabled before taking
> > > a pipe-level ("dmux") CRC, so this test is violating that by disabling
> > > all planes; it's quite possible that this is the source of the CRC
> > > mismatch.  If running on an Intel platform, you may want to run in
> > > interactive mode ("--interactive-debug=bgcolor --skip-crc-compare") to
> > > ensure that the colors being generated actually do match visually since
> > > the CRC's can't be trusted.
> > 
> > Hmm, landing a feature without automating testing for it is a bit too
> > much to ask IMO.
> > 
> > I have two proposals to make it happen:
> > 
> > - Could we add a workaround for the affected intel platforms? If the
> > problem really is because no planes are enabled, then surely a
> > fully-transparent plane would be a sufficient workaround.
> 
> Just have to make sure that plane is the cursor since the blending
> fail on the universal planes.
> 
> > 
> > - If CRCs really cannot be used for this, then we should use the
> > chamelium for it. The idea would be to detect if the connector is
> > connected to a chamelium, and if so use chamelium's CRC.
> 
> Third option would be to use the port crc instead.

Yeah that might be a w/a, we're using that on gen4 already for some ports.
We'd have to use these port crcs always though, since we can't tell
upfront whether the testcase is testing the background color.
-Daniel

> 
> > 
> > How does this sound?
> > 
> > Martin
> > 
> > > 
> > > v2:
> > >  - Swap red and blue ordering in property value to reflect change
> > >in v2 of kernel series.
> > > 
> > > v3:
> > >  - Minor updates to proposed uapi helpers (s/rgba/argb/).
> > > 
> > > v4:
> > >  - General restructuring into pipe/color subtests.
> > >  - Use RGB2101010 framebuffers for comparison so that we match the bits
> > >of precision that Intel hardware background color accepts
> > > 
> > > v5:
> > >  - Re-enable CRC comparisons; just because these don't work on Intel
> > >doesn't mean we shouldn't use them on other vendors' platforms
> > >(Daniel).
> > >  - Use DRIVER_ANY rather than DRIVER_INTEL. (Heiko Stuebner)
> > > 
> > > v5.1:
> > >  - Update commit message body discussion of CRC issues.
> > > 
> > > Cc: igt-...@lists.freedesktop.org
> > > Cc: Daniel Vetter 
> > > Cc: Heiko Stuebner 
> > > Signed-off-by: Matt Roper 
> > > ---
> > >  lib/igt_kms.c |   2 +-
> > >  tests/kms_crtc_background_color.c | 263 ++
> > >  2 files changed, 127 insertions(+), 138 deletions(-)
> > > 
> > > diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > > index e9b80b9b..9a7f0e23 100644
> > > --- a/lib/igt_kms.c
> > > +++ b/lib/igt_kms.c
> > > @@ -391,7 +391,7 @@ const char * const 
> > > igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
> > >  };
> > >  
> > >  const char * const igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
> > > - [IGT_CRTC_BACKGROUND] = "background_color",
> > > + [IGT_CRTC_BACKGROUND] = "BACKGROUND_COLOR",
> > >   [IGT_CRTC_CTM] = "CTM",
> > >   [IGT_CRTC_GAMMA_LUT] = "GAMMA_LUT",
> > >   [IGT_CRTC_GAMMA_LUT_SIZE] = "GAMMA_LUT_SIZE",
> > > diff --git a/tests/kms_crtc_background_color.c 
> > > b/tests/kms_crtc_background_color.c
> > > index 3df3401f..58cdd7a9 100644
> > > --- a/tests/kms_crtc_background_color.c
> > > +++ b/test

Re: [PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver

2019-10-09 Thread Daniel Vetter
 *bo);
>  
>  /* TODO: submit equivalent to TTM generic API upstream? */
>  static inline void __iomem *
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> index 70f34cacc552..060e2ab1fd95 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -158,6 +158,8 @@ struct nouveau_drm {
>   int type_vram;
>   int type_host[2];
>   int type_ncoh[2];
> + struct mutex io_reserve_mutex;
> + struct list_head io_reserve_lru;
>   } ttm;
>  
>   /* GEM interface support */
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index f0daf958e03a..7f8495066e8b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -162,13 +162,51 @@ const struct ttm_mem_type_manager_func 
> nv04_gart_manager = {
>   .debug = nouveau_manager_debug
>  };
>  
> +static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct ttm_buffer_object *bo = vma->vm_private_data;
> + pgprot_t prot;
> + vm_fault_t ret;
> +
> + ret = ttm_bo_vm_reserve(bo, vmf);
> + if (ret)
> + return ret;
> +
> + nouveau_bo_del_io_reserve_lru(bo);

Isn't this opening up a can of worms (in theory) where a lot of concurrent
faults will all fail because they're all removed themselves from the lru,
so can't see anyone else to throw out?

Same problem really that ttm had (well still has I think for !amdgpu) with
its other lru ...

Or am I getting totally lost again here?
-Daniel

> +
> + prot = vm_get_page_prot(vma->vm_flags);
> + ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
> + if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> + return ret;
> +
> + nouveau_bo_add_io_reserve_lru(bo);
> +
> + dma_resv_unlock(bo->base.resv);
> +
> + return ret;
> +}
> +
> +static struct vm_operations_struct nouveau_ttm_vm_ops = {
> + .fault = nouveau_ttm_fault,
> + .open = ttm_bo_vm_open,
> + .close = ttm_bo_vm_close,
> + .access = ttm_bo_vm_access
> +};
> +
>  int
>  nouveau_ttm_mmap(struct file *filp, struct vm_area_struct *vma)
>  {
>   struct drm_file *file_priv = filp->private_data;
>   struct nouveau_drm *drm = nouveau_drm(file_priv->minor->dev);
> + int ret;
>  
> - return ttm_bo_mmap(filp, vma, >ttm.bdev);
> + ret = ttm_bo_mmap(filp, vma, >ttm.bdev);
> + if (ret)
> + return ret;
> +
> + vma->vm_ops = _ttm_vm_ops;
> + return 0;
>  }
>  
>  static int
> @@ -272,6 +310,9 @@ nouveau_ttm_init(struct nouveau_drm *drm)
>   return ret;
>   }
>  
> + mutex_init(>ttm.io_reserve_mutex);
> + INIT_LIST_HEAD(>ttm.io_reserve_lru);
> +
>   NV_INFO(drm, "VRAM: %d MiB\n", (u32)(drm->gem.vram_available >> 20));
>   NV_INFO(drm, "GART: %d MiB\n", (u32)(drm->gem.gart_available >> 20));
>   return 0;
> -- 
> 2.14.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 RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

2019-10-09 Thread Daniel Vetter
On Wed, Oct 09, 2019 at 03:25:22PM +, Kuehling, Felix wrote:
> On 2019-10-09 6:31, Daniel Vetter wrote:
> > On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> >>
> >> The description sounds reasonable to me and maps well to the CU masking
> >> feature in our GPUs.
> >>
> >> It would also allow us to do more coarse-grained masking for example to
> >> guarantee balanced allocation of CUs across shader engines or
> >> partitioning of memory bandwidth or CP pipes (if that is supported by
> >> the hardware/firmware).
> > Hm, so this sounds like the definition for how this cgroup is supposed to
> > work is "amd CU masking" (whatever that exactly is). And the abstract
> > description is just prettification on top, but not actually the real
> > definition you guys want.
> 
> I think you're reading this as the opposite of what I was trying to say. 
> Using CU masking is one possible implementation of LGPUs on AMD 
> hardware. It's the one that Kenny implemented at the end of this patch 
> series, and I pointed out some problems with that approach. Other ways 
> to partition the hardware into LGPUs are conceivable. For example we're 
> considering splitting it along the lines of shader engines, which is 
> more coarse-grain and would also affect memory bandwidth available to 
> each partition.

If this is supposed to be useful for admins then "other ways to partition
the hw are conceivable" is the problem. This should be unique for
admins/end-users. Reading the implementation details and realizing that
the actual meaning is "amd CU masking" isn't good enough by far, since
that's meaningless on any other hw.

And if there's other ways to implement this cgroup for amd, it's also
meaningless (to sysadmins/users) for amd hw.

> We could also consider partitioning pipes in our command processor, 
> although that is not supported by our current CP scheduler firmware.
> 
> The bottom line is, the LGPU model proposed by Kenny is quite abstract 
> and allows drivers implementing it a lot of flexibility depending on the 
> capability of their hardware and firmware. We haven't settled on a final 
> implementation choice even for AMD.

That abstract model of essentially "anything goes" is the problem here
imo. E.g. for cpu cgroups this would be similar to allowing the bitmaks to
mean "cpu core" on one machine "physical die" on the next and maybe
"hyperthread unit" on the 3rd. Useless for admins.

So if we have a gpu bitmaks thing that might mean a command submissio pipe
on one hw (maybe matching what vk exposed, maybe not), some compute unit
mask on the next and something entirely different (e.g. intel has so
called GT slices with compute cores + more stuff around) on the 3rd vendor
then that's not useful for admins.
-Daniel

> 
> Regards,
>    Felix
> 
> 
> >
> > I think adding a cgroup which is that much depending upon the hw
> > implementation of the first driver supporting it is not a good idea.
> > -Daniel
> >
> >> I can't comment on the code as I'm unfamiliar with the details of the
> >> cgroup code.
> >>
> >> Acked-by: Felix Kuehling 
> >>
> >>
> >>> ---
> >>>Documentation/admin-guide/cgroup-v2.rst |  46 
> >>>include/drm/drm_cgroup.h|   4 +
> >>>include/linux/cgroup_drm.h  |   6 ++
> >>>kernel/cgroup/drm.c | 135 
> >>>4 files changed, 191 insertions(+)
> >>>
> >>> diff --git a/Documentation/admin-guide/cgroup-v2.rst 
> >>> b/Documentation/admin-guide/cgroup-v2.rst
> >>> index 87a195133eaa..57f18469bd76 100644
> >>> --- a/Documentation/admin-guide/cgroup-v2.rst
> >>> +++ b/Documentation/admin-guide/cgroup-v2.rst
> >>> @@ -1958,6 +1958,52 @@ DRM Interface Files
> >>>   Set largest allocation for /dev/dri/card1 to 4MB
> >>>   echo "226:1 4m" > drm.buffer.peak.max
> >>>
> >>> +  drm.lgpu
> >>> + A read-write nested-keyed file which exists on all cgroups.
> >>> + Each entry is keyed by the DRM device's major:minor.
> >>> +
> >>> + lgpu stands for logical GPU, it is an abstraction used to
> >>> + subdivide a physical DRM device for the purpose of resource
> >>> + management.
> >>> +
> >>> + The lgpu is a discrete quantity that is device specific (i.e.
> >>> + some DRM devices may have 64 lgpus while others may have 100
> >>> + lgpus.)  The 

Re: kernel warning related to i915 code

2019-10-09 Thread Daniel Vetter
 0010 DS:  ES:  CR0: 80050033
> [ 6180.832745] CR2: 7fc7a50c2000 CR3: 000118c0a005 CR4: 
> 003606e0
> [ 6180.832746] Call Trace:
> [ 6180.832750]  __flush_work+0x92/0x1b0
> [ 6180.832753]  ? enqueue_hrtimer+0x36/0x90
> [ 6180.832755]  ? hrtimer_start_range_ns+0x18b/0x2c0
> [ 6180.832757]  __cancel_work_timer+0x100/0x190
> [ 6180.832760]  ? _cond_resched+0x15/0x30
> [ 6180.832762]  ? synchronize_irq+0x3a/0xa0
> [ 6180.832764]  ? _raw_spin_lock_irqsave+0x25/0x30
> [ 6180.832783]  ? fwtable_write32+0x4f/0x210 [i915]
> [ 6180.832799]  gen6_disable_rps_interrupts+0x79/0xa0 [i915]
> [ 6180.832817]  gen6_rps_idle+0x13/0xe0 [i915]
> [ 6180.832836]  intel_gt_park+0x54/0x60 [i915]
> [ 6180.832854]  __intel_wakeref_put_last+0x17/0x50 [i915]
> [ 6180.832873]  __engine_park+0xbc/0xd0 [i915]
> [ 6180.832890]  __intel_wakeref_put_last+0x17/0x50 [i915]
> [ 6180.832912]  i915_request_retire+0x178/0x310 [i915]
> [ 6180.832934]  ring_retire_requests+0x4e/0x60 [i915]
> [ 6180.832955]  i915_retire_requests+0x43/0x80 [i915]
> [ 6180.832976]  i915_gem_shrink+0xcb/0x4c0 [i915]
> [ 6180.832997]  i915_gem_shrinker_scan+0x63/0x110 [i915]
> [ 6180.833007]  do_shrink_slab+0x149/0x290
> [ 6180.833011]  shrink_slab+0xac/0x2b0
> [ 6180.833013]  shrink_node+0xf5/0x490
> [ 6180.833016]  balance_pgdat+0x2bb/0x500
> [ 6180.833019]  kswapd+0x1e8/0x3b0
> [ 6180.833024]  ? wait_woken+0x70/0x70
> [ 6180.833026]  ? balance_pgdat+0x500/0x500
> [ 6180.833029]  kthread+0x118/0x130
> [ 6180.833032]  ? kthread_create_worker_on_cpu+0x70/0x70
> [ 6180.833034]  ret_from_fork+0x35/0x40
> [ 6180.833036] ---[ end trace 765b2991cf66218a ]---
> 
> Best
> 
> Norbert
> 
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

2019-10-09 Thread Daniel Vetter
On Wed, Oct 09, 2019 at 11:08:45AM -0400, Kenny Ho wrote:
> Hi Daniel,
> 
> Can you elaborate what you mean in more details?  The goal of lgpu is
> to provide the ability to subdivide a GPU device and give those slices
> to different users as needed.  I don't think there is anything
> controversial or vendor specific here as requests for this are well
> documented.  The underlying representation is just a bitmap, which is
> neither unprecedented nor vendor specific (bitmap is used in cpuset
> for instance.)
> 
> An implementation of this abstraction is not hardware specific either.
> For example, one can associate a virtual function in SRIOV as a lgpu.
> Alternatively, a device can also declare to have 100 lgpus and treat
> the lgpu quantity as a percentage representation of GPU subdivision.
> The fact that an abstraction works well with a vendor implementation
> does not make it a "prettification" of a vendor feature (by this
> logic, I hope you are not implying an abstraction is only valid if it
> does not work with amd CU masking because that seems fairly partisan.)
> 
> Did I misread your characterization of this patch?

Scenario: I'm a gpgpu customer, and I type some gpgpu program (probably in
cude, transpiled for amd using rocm).

How does the stuff I'm seeing in cuda (or vk compute, or whatever) map to
the bitmasks I can set in this cgroup controller?

That's the stuff which this spec needs to explain. Currently the answer is
"amd CU masking", and that's not going to work on e.g. nvidia hw. We need
to come up with end-user relevant resources/meanings for these bits which
works across vendors.

On cpu a "cpu core" is rather well-defined, and customers actually know
what it means on intel, amd, ibm powerpc or arm. Both on the program side
(e.g. what do I need to stuff into relevant system calls to run on a
specific "cpu core") and on the admin side.

We need to achieve the same for gpus. "it's a bitmask" is not even close
enough imo.
-Daniel

> 
> Regards,
> Kenny
> 
> 
> On Wed, Oct 9, 2019 at 6:31 AM Daniel Vetter  wrote:
> >
> > On Tue, Oct 08, 2019 at 06:53:18PM +, Kuehling, Felix wrote:
> > > On 2019-08-29 2:05 a.m., Kenny Ho wrote:
> > > > drm.lgpu
> > > >  A read-write nested-keyed file which exists on all cgroups.
> > > >  Each entry is keyed by the DRM device's major:minor.
> > > >
> > > >  lgpu stands for logical GPU, it is an abstraction used to
> > > >  subdivide a physical DRM device for the purpose of resource
> > > >  management.
> > > >
> > > >  The lgpu is a discrete quantity that is device specific (i.e.
> > > >  some DRM devices may have 64 lgpus while others may have 100
> > > >  lgpus.)  The lgpu is a single quantity with two representations
> > > >  denoted by the following nested keys.
> > > >
> > > >= 
> > > >count Representing lgpu as anonymous resource
> > > >list  Representing lgpu as named resource
> > > >= 
> > > >
> > > >  For example:
> > > >  226:0 count=256 list=0-255
> > > >  226:1 count=4 list=0,2,4,6
> > > >  226:2 count=32 list=32-63
> > > >
> > > >  lgpu is represented by a bitmap and uses the bitmap_parselist
> > > >  kernel function so the list key input format is a
> > > >  comma-separated list of decimal numbers and ranges.
> > > >
> > > >  Consecutively set bits are shown as two hyphen-separated 
> > > > decimal
> > > >  numbers, the smallest and largest bit numbers set in the range.
> > > >  Optionally each range can be postfixed to denote that only 
> > > > parts
> > > >  of it should be set.  The range will divided to groups of
> > > >  specific size.
> > > >  Syntax: range:used_size/group_size
> > > >  Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769
> > > >
> > > >  The count key is the hamming weight / hweight of the bitmap.
> > > >
> > > >  Both count and list accept the max and default keywords.
> > > >
> > > >  Some DRM devices may only support lgpu as anonymous resources.
> > > >  In such case, the significance of the 

Re: [PATCH 2/3] drm/komeda: Add drm_ctm_to_coeffs()

2019-10-09 Thread Daniel Vetter
On Mon, Sep 30, 2019 at 07:56:13AM -0400, Ilia Mirkin wrote:
> On Mon, Sep 30, 2019 at 7:05 AM Brian Starkey  wrote:
> >
> > Hi James,
> >
> > On Mon, Sep 30, 2019 at 04:54:41AM +, james qian wang (Arm Technology 
> > China) wrote:
> > > This function is used to convert drm_color_ctm S31.32 sign-magnitude
> > > value to komeda required Q2.12 2's complement
> > >
> > > Signed-off-by: james qian wang (Arm Technology China) 
> > > 
> > > ---
> > >  .../arm/display/komeda/komeda_color_mgmt.c| 27 +++
> > >  .../arm/display/komeda/komeda_color_mgmt.h|  1 +
> > >  2 files changed, 28 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c 
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> > > index c180ce70c26c..c92c82eebddb 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> > > @@ -117,3 +117,30 @@ void drm_lut_to_fgamma_coeffs(struct 
> > > drm_property_blob *lut_blob, u32 *coeffs)
> > >  {
> > >   drm_lut_to_coeffs(lut_blob, coeffs, sector_tbl, 
> > > ARRAY_SIZE(sector_tbl));
> > >  }
> > > +
> > > +/* Convert from S31.32 sign-magnitude to HW Q2.12 2's complement */
> > > +static s32 drm_ctm_s31_32_to_q2_12(u64 input)
> > > +{
> > > + u64 mag = (input & ~BIT_ULL(63)) >> 20;
> > > + bool negative = !!(input & BIT_ULL(63));
> > > + u32 val;
> > > +
> > > + /* the range of signed 2s complement is [-2^n, 2^n - 1] */
> > > + val = clamp_val(mag, 0, negative ? BIT(14) : BIT(14) - 1);
> > > +
> > > + return negative ? 0 - val : val;
> > > +}
> >
> > This function looks generally useful. Should it be in DRM core
> > (assuming there isn't already one there)?
> >
> > You can use a parameter to determine the number of bits desired in the
> > output.
> 
> I suspect every driver needs to do something similar. You can see what
> I did for nouveau here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=88b703527ba70659365d989f29579f1292ebf9c3
> 
> (look for csc_drm_to_base)
> 
> Would be great to have a common helper which correctly accounts for
> all the variability.

Yeah the sign-bit 31.32 fixed point format is probably the most ludicrous
uapi fumble we've ever done. A shared function, rolled out to drivers, to
switch it to a signed 2 complements integer sounds like a _very_ good
idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/6] drm/gem: refine drm_gem_objects_lookup

2019-10-09 Thread Daniel Vetter
/drm/panfrost/panfrost_drv.c 
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index d74442d71048..486ca51d5662 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -130,9 +130,9 @@ panfrost_lookup_bos(struct drm_device *dev,
>   if (!job->implicit_fences)
>   return -ENOMEM;
>  
> - return drm_gem_objects_lookup(file_priv,
> -   (void __user 
> *)(uintptr_t)args->bo_handles,
> -   job->bo_count, >bos);
> + return drm_gem_objects_lookup_user(file_priv,
> +(void __user 
> *)(uintptr_t)args->bo_handles,
> +job->bo_count, >bos);
>  }
>  
>  /**
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 6aaba14f5972..354fc8d240e4 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -387,8 +387,10 @@ struct page **drm_gem_get_pages(struct drm_gem_object 
> *obj);
>  void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
>   bool dirty, bool accessed);
>  
> -int drm_gem_objects_lookup(struct drm_file *filp, void __user *bo_handles,
> +int drm_gem_objects_lookup(struct drm_file *filp, u32 *bo_handles,
>  int count, struct drm_gem_object ***objs_out);
> +int drm_gem_objects_lookup_user(struct drm_file *filp, void __user 
> *bo_handles,
> + int count, struct drm_gem_object ***objs_out);
>  struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32 
> handle);
>  long drm_gem_dma_resv_wait(struct drm_file *filep, u32 handle,
>   bool wait_all, unsigned long timeout);
> -- 
> 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 5/6] drm/amdgpu/dm/mst: Report possible_crtcs incorrectly, for now

2019-10-09 Thread Daniel Vetter
On Fri, Sep 27, 2019 at 11:27:41AM -0400, Sean Paul wrote:
> On Thu, Sep 26, 2019 at 06:51:07PM -0400, Lyude Paul wrote:
> > This commit is seperate from the previous one to make it easier to
> > revert in the future. Basically, there's multiple userspace applications
> > that interpret possible_crtcs very wrong:
> > 
> > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277
> > https://gitlab.gnome.org/GNOME/mutter/issues/759
> > 
> > While work is ongoing to fix these issues in userspace, we need to
> > report ->possible_crtcs incorrectly for now in order to avoid
> > introducing a regression in in userspace. Once these issues get fixed,
> > this commit should be reverted.
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index b404f1ae6df7..fe8ac801d7a5 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -4807,6 +4807,17 @@ static int amdgpu_dm_crtc_init(struct 
> > amdgpu_display_manager *dm,
> > if (!acrtc->mst_encoder)
> > goto fail;
> >  
> > +   /*
> > +* FIXME: This is a hack to workaround the following issues:
> > +*
> > +* https://gitlab.gnome.org/GNOME/mutter/issues/759
> > +* https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277
> > +*
> > +* One these issues are closed, this should be removed
> 
> Even when these issues are closed, we'll still be introducing a regression if 
> we
> revert this change. Time for actually_possible_crtcs? :)
> 
> You also might want to briefly explain the u/s bug in case the links go sour.
> 
> > +*/
> > +   acrtc->mst_encoder->base.possible_crtcs =
> > +   amdgpu_dm_get_encoder_crtc_mask(dm->adev);
> 
> Why don't we put this hack in amdgpu_dm_dp_create_fake_mst_encoder()?

If we don't have the same hack for i915 mst I think we shouldn't merge
this ... broken userspace is broken.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] drm/gem: refine drm_gem_objects_lookup

2019-10-09 Thread Daniel Vetter
On Fri, Sep 27, 2019 at 08:09:52AM +0800, Qiang Yu wrote:
> On Thu, Sep 26, 2019 at 11:01 PM Rob Herring  wrote:
> >
> > On Thu, Sep 26, 2019 at 9:12 AM Qiang Yu  wrote:
> > >
> > > Do not use user space bo handles directly and left the user
> > > to kernel copy work to drivers calling this function.
> > >
> > > This is for driver like lima which does not pass gem bo
> > > handles continously in an array in ioctl argument.
> > >
> > > Cc: Rob Herring 
> > > Cc: Tomeu Vizoso 
> > > Cc: Steven Price 
> > > Cc: Alyssa Rosenzweig 
> > > Signed-off-by: Qiang Yu 
> > > ---
> > >  drivers/gpu/drm/drm_gem.c   | 28 +++--
> > >  drivers/gpu/drm/panfrost/panfrost_drv.c | 23 +---
> >
> > Please keep the current variant. While only panfrost is converted ATM,
> > vc4 and v3d will use this too.
> >
> > >  include/drm/drm_gem.h   |  2 +-
> > >  3 files changed, 29 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > > index 6854f5867d51..9f73e5f3b53f 100644
> > > --- a/drivers/gpu/drm/drm_gem.c
> > > +++ b/drivers/gpu/drm/drm_gem.c
> > > @@ -679,11 +679,11 @@ static int objects_lookup(struct drm_file *filp, 
> > > u32 *handle, int count,
> > >  /**
> > >   * drm_gem_objects_lookup - look up GEM objects from an array of handles
> > >   * @filp: DRM file private date
> > > - * @bo_handles: user pointer to array of userspace handle
> > > + * @bo_handles: array of GEM object handles
> > >   * @count: size of handle array
> > >   * @objs_out: returned pointer to array of drm_gem_object pointers
> > >   *
> > > - * Takes an array of userspace handles and returns a newly allocated 
> > > array of
> > > + * Takes an array of GEM object handles and returns a newly allocated 
> > > array of
> > >   * GEM objects.
> > >   *
> > >   * For a single handle lookup, use drm_gem_object_lookup().
> > > @@ -695,11 +695,10 @@ static int objects_lookup(struct drm_file *filp, 
> > > u32 *handle, int count,
> > >   * failure. 0 is returned on success.
> > >   *
> > >   */
> > > -int drm_gem_objects_lookup(struct drm_file *filp, void __user 
> > > *bo_handles,
> > > +int drm_gem_objects_lookup(struct drm_file *filp, u32 *bo_handles,
> > >int count, struct drm_gem_object ***objs_out)
> >
> > Either split into drm_gem_objects_lookup() and a
> > drm_gem_objects_lookup_user() with the latter calling the former or
> > just make the helper take both a user and u32* ptr with the
> > expectation that only one of them is non-NULL.
> >
> OK, I prefer the first way, will send v2 for it.

Note that hopefully soon (Christian König is working on it) we'll have
ww_mutex locking helpers, which will introduce a drm_gem_operation_ctx.
Once we have that I think we can unify a lot of these helpers (Gerd
Hoffmann has looked into it) all while making them more flexible (i.e. not
only works with arrays). So might be worth to coordinate a bit here, and
maybe hold off on just this part for lima for a bit.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10

2019-10-09 Thread Daniel Vetter
On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
> These new format is supported by some rockchip socs:
> 
> DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
> DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
> DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
> 
> Signed-off-by: Sandy Huang 
> ---
>  drivers/gpu/drm/drm_fourcc.c  | 18 ++
>  include/uapi/drm/drm_fourcc.h | 14 ++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index c630064..ccd78a3 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -261,6 +261,24 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_P016,.depth = 0,  
> .num_planes = 2,
> .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 }, 
> .block_h = { 1, 0, 0 },
> .hsub = 2, .vsub = 2, .is_yuv = true},
> + { .format = DRM_FORMAT_NV12_10, .depth = 0,  
> .num_planes = 2,
> +   .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, 
> .block_h = { 4, 4, 0 },
> +   .hsub = 2, .vsub = 2, .is_yuv = true},
> + { .format = DRM_FORMAT_NV21_10, .depth = 0,  
> .num_planes = 2,
> +   .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, 
> .block_h = { 4, 4, 0 },
> +   .hsub = 2, .vsub = 2, .is_yuv = true},
> + { .format = DRM_FORMAT_NV16_10, .depth = 0,  
> .num_planes = 2,
> +   .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, 
> .block_h = { 4, 4, 0 },
> +   .hsub = 2, .vsub = 1, .is_yuv = true},
> + { .format = DRM_FORMAT_NV61_10, .depth = 0,  
> .num_planes = 2,
> +   .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, 
> .block_h = { 4, 4, 0 },
> +   .hsub = 2, .vsub = 1, .is_yuv = true},
> + { .format = DRM_FORMAT_NV24_10, .depth = 0,  
> .num_planes = 2,
> +   .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, 
> .block_h = { 4, 4, 0 },
> +   .hsub = 1, .vsub = 1, .is_yuv = true},
> + { .format = DRM_FORMAT_NV42_10, .depth = 0,  
> .num_planes = 2,
> +   .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, 
> .block_h = { 4, 4, 0 },
> +   .hsub = 1, .vsub = 1, .is_yuv = true},
>   { .format = DRM_FORMAT_P210,.depth = 0,
> .num_planes = 2, .char_per_block = { 2, 4, 0 },
> .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 }, .hsub = 2,

Yup this is what I had in mind with using the block stuff to describe your
new 10bit yuv formats. Thanks for respining.

Once we've nailed the exact bit description of the format precisely this
can be merged imo.
-Daniel

> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3..08e2221 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -238,6 +238,20 @@ extern "C" {
>  #define DRM_FORMAT_NV42  fourcc_code('N', 'V', '4', '2') /* 
> non-subsampled Cb:Cr plane */
>  
>  /*
> + * 2 plane YCbCr
> + * index 0 = Y plane, Y3:Y2:Y1:Y0 10:10:10:10
> + * index 1 = Cb:Cr plane, Cb3:Cr3:Cb2:Cr2:Cb1:Cr1:Cb0:Cr0 
> 10:10:10:10:10:10:10:10
> + * or
> + * index 1 = Cr:Cb plane, Cr3:Cb3:Cr2:Cb2:Cr1:Cb1:Cr0:Cb0 
> 10:10:10:10:10:10:10:10
> + */
> +#define DRM_FORMAT_NV12_10   fourcc_code('N', 'A', '1', '2') /* 2x2 
> subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV21_10   fourcc_code('N', 'A', '2', '1') /* 2x2 
> subsampled Cb:Cr plane */
> +#define DRM_FORMAT_NV16_10   fourcc_code('N', 'A', '1', '6') /* 2x1 
> subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV61_10   fourcc_code('N', 'A', '6', '1') /* 2x1 
> subsampled Cb:Cr plane */
> +#define DRM_FORMAT_NV24_10   fourcc_code('N', 'A', '2', '4') /* 
> non-subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV42_10   fourcc_code('N', 'A', '4', '2') /* 
> non-subsampled Cb:Cr plane */
> +
> +/*
>   * 2 plane YCbCr MSB aligned
>   * index 0 = Y plane, [15:0] Y:x [10:6] little endian
>   * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
> -- 
> 2.7.4
> 
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH v3 00/11] drm: rework mmap() workflow

2019-10-09 Thread Daniel Vetter
On Thu, Sep 19, 2019 at 12:02:12PM +0200, Gerd Hoffmann wrote:
> Add mmap callback to struct drm_gem_object_funcs, which is supposed to
> handle the vma setup.  It will be used by both normal fops->mmap (via
> drm_gem_mmap_obj()) and prime mmap (via drm_gem_prime_mmap()).
> 
> For starters the shmem and vram helpers are switched over to the new
> workflow, to show things in action for review.

I'm confused a bit here, since you're resending patches but:
- no per-patch changelog (making it real hard for reviewers to catch up
  and review just what's changed)
- none of the r-b/a-b tags you've scored already added to the respective
  patches

I'd really like to see this landed, but this way it's not really going to
move forward :-/

Can you pls resend with all that fixed, and then I can do a final pass for
the missing bits and we can get this merged?

Thanks, Daniel

> 
> Gerd Hoffmann (11):
>   drm: add mmap() to drm_gem_object_funcs
>   drm/shmem: switch shmem helper to _gem_object_funcs.mmap
>   drm/shmem: drop VM_DONTDUMP
>   drm/shmem: drop VM_IO
>   drm/shmem: drop DEFINE_DRM_GEM_SHMEM_FOPS
>   drm/ttm: factor out ttm_bo_mmap_vma_setup
>   drm/ttm: rename ttm_fbdev_mmap
>   drm/ttm: add drm_gem_ttm_mmap()
>   drm/vram: switch vram helper to _gem_object_funcs.mmap()
>   drm/vram: drop verify_access
>   drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS
> 
>  include/drm/drm_gem.h | 14 +
>  include/drm/drm_gem_shmem_helper.h| 30 +-
>  include/drm/drm_gem_ttm_helper.h  |  2 +
>  include/drm/drm_gem_vram_helper.h | 25 -
>  include/drm/ttm/ttm_bo_api.h  | 10 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  5 +-
>  drivers/gpu/drm/ast/ast_drv.c |  5 +-
>  drivers/gpu/drm/bochs/bochs_drv.c |  5 +-
>  drivers/gpu/drm/cirrus/cirrus.c   |  2 +-
>  drivers/gpu/drm/drm_gem.c | 27 ++---
>  drivers/gpu/drm/drm_gem_shmem_helper.c| 28 --
>  drivers/gpu/drm/drm_gem_ttm_helper.c  | 17 ++
>  drivers/gpu/drm/drm_gem_vram_helper.c | 56 +--
>  drivers/gpu/drm/drm_prime.c   |  9 +++
>  .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |  5 +-
>  drivers/gpu/drm/mgag200/mgag200_drv.c |  5 +-
>  drivers/gpu/drm/panfrost/panfrost_drv.c   |  2 +-
>  drivers/gpu/drm/panfrost/panfrost_gem.c   |  2 +-
>  drivers/gpu/drm/tiny/gm12u320.c   |  2 +-
>  drivers/gpu/drm/ttm/ttm_bo_vm.c   | 54 +-
>  drivers/gpu/drm/v3d/v3d_bo.c  |  2 +-
>  drivers/gpu/drm/v3d/v3d_drv.c |  2 +-
>  drivers/gpu/drm/vboxvideo/vbox_drv.c  |  5 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.c  |  2 +-
>  drivers/gpu/drm/virtio/virtgpu_object.c   |  2 +-
>  25 files changed, 119 insertions(+), 199 deletions(-)
> 
> -- 
> 2.18.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/3] dma-buf: add dma_resv_ctx for deadlock handling

2019-10-09 Thread Daniel Vetter
On Wed, Oct 09, 2019 at 03:21:06PM +0200, Christian König wrote:
> Am 08.10.19 um 17:16 schrieb Daniel Vetter:
> > On Wed, Sep 18, 2019 at 07:55:23PM +0200, Christian König wrote:
> > > The ww_mutex framework allows for detecting deadlocks when multiple
> > > threads try to acquire the same set of locks in different order.
> > > 
> > > The problem is that handling those deadlocks was the burden of the user of
> > > the ww_mutex implementation and at least some users didn't got that right
> > > on the first try.
> > > 
> > > So introduce a new dma_resv_ctx object which can be used to
> > > simplify the deadlock handling. This is done by tracking all locked
> > > dma_resv objects in the context as well as the last contended object.
> > > 
> > > When a deadlock occurse we now unlock all previously locked objects and
> > > acquire the contended lock in the slow path. After this is done -EDEADLK
> > > is still returned to signal that all other locks now need to be
> > > re-acquired again.
> > > 
> > > Signed-off-by: Christian König 
> > I pondered this quite a bit, some thoughts:
> > 
> > - doing this over dma-buf means we can only use this for the ww_mutx
> >dance, not for anything else. Which means we need another layer on top
> >for shared execbuf utils (which Gerd has started looking into, but I
> >felt like not quite the right approach yet in his first draft series).
> 
> Yes, and I actually realized that this won't work on the dma_resv layer as
> well.
> 
> We need to base this on GEM to be able to do the correct ref/unref the
> locked objects.
> 
> > - With the ttm/gem merger we could just put this into drm_gem_object, and
> >ttm/gem helpers could still use it. Plus we could build some shared
> >execbuf utils on top of this, by essentially merging ttm_operation_ctx
> >into drm_gem_operation_ctx. I think this would also simplify the ttm
> >parameters a bit, since currently the ttm_operation_ctx doesn't have an
> >explicit pointer to the ww_acquire_ctx (which feels like an oversight to
> >me).
> 
> That ttm_operation_ctx doesn't contain a ww_acquire_ctx is intentional and
> mandatory for correct operation.
> 
> See for swapping things out from the MM callbacks you can't work with a
> ww_acquire_ctx and instead need to use trylock.
> 
> When you need a ww_acquire_ctx you can get that from the buffer object you
> try to allocate space for.

Hm I've seen that trick, and I'm not sure I like it. Imo an explicit
pointer that tells you which acquire_ctx to use, with the clear meaning
that if the pointer is NULL then only trylock is ok, would be a lot
cleaner. At least for execbuf utils the acquire_ctx is really central and
really should be in there somehow. Or embed it and have a flag whether
it's ok to use it or not.

Other plan would be to make sure that acquire_ctx and non-acquire_ctx
(i.e. mmu/shrinker callbacks) are clearly separate paths. That might be the
even better option going forward, since mixing them up leads to a huge
mess ime.

> > - Aside, quick question: Any reason why struct amdgpu_cs_parser doesn't
> >subclass ttm_operation_ctx? From my naive understanding this would make
> >tons of sense ...
> 
> amdgpu_cs_parser is already overloaded with to much crap which actually
> should be temporary allocated on the stack.
> 
> > - Maybe we could even build some lru/eviction helpers on top, perhaps with
> >two lists, one for the set of buffers in the execbuf, the other for
> >additional buffers we've reserved as part of the eviction dance (to
> >solve the TODO in ttm_mem_evict_wait_busy).
> 
> That's what I'm currently working on, but some driver still need the
> struct_mutex for GEM ref/unref which is complicating things a bit.
> 
> So prototyping that in TTM BOs first before I move on to using the
> underlying GEM object.
> 
> > - Only downside would be that drivers outside of drivers/gpu won't be able
> >to use these helpers. I don't see any immediate nor near-future need for
> >that. All other drivers use so little memory they don't need to
> >participate in the multi-lock dance, they just pin the few buffers they
> >need and call it a day.
> 
> I can live with that.

Ok, sounds like we're agreing on all this. And I think once your series
here has landed, Gerd could rebase his execbuf helpers on top and we can
see what color suits them to get them landed.
-Daniel

> 
> Regards,
> Christian.
> 
> > 
> > Ofc not everything above would need to be done right away, that's more
> > ideas for todo.rst entries to ma

Re: [PATCH 2/4] drm/ttm: use the parent resv for ghost objects v2

2019-10-09 Thread Daniel Vetter
On Wed, Oct 09, 2019 at 03:10:09PM +0200, Christian König wrote:
> Am 08.10.19 um 11:25 schrieb Daniel Vetter:
> > On Thu, Aug 29, 2019 at 04:29:15PM +0200, Christian König wrote:
> > > This way we can even pipeline imported BO evictions.
> > > 
> > > v2: Limit this to only cases when the parent object uses a separate
> > >  reservation object as well. This fixes another OOM problem.
> > > 
> > > Signed-off-by: Christian König 
> > Since I read quite a bit of ttm I figured I'll review this too, but I'm
> > totally lost. And git blame gives me at best commits with one-liner commit
> > messages, and the docs aren't explaining much at all either (and generally
> > they didn't get updated at all with all the changes in the past years).
> > 
> > I have a vague idea of what you're doing here, but not enough to do review
> > with any confidence. And from other ttm patches from amd it feels a lot
> > like we have essentially a bus factor of 1 for all things ttm :-/
> 
> Yeah, that's one of a couple of reasons why I want to get rid of TTM in the
> long term.
> 
> Basically this is a bug fix for delay freeing ttm objects. When we hang the
> ttm object on a ghost object to be freed and the ttm object is an imported
> DMA-buf we run into the problem that we want to drop the mapping, but have
> the wrong lock taken (the lock of the ghost and not of the parent).

Got intrigued, did some more digging, I guess the bugfix part is related
to:

commit 841e763b40764a7699ae07f4cb1921af62d6316d
Author: Christian König 
Date:   Thu Jul 20 20:55:06 2017 +0200

drm/ttm: individualize BO reservation obj when they are freed

and that's why you switch everything over to useing _resv instead of the
pointer. But then I still don't follow the details ...

> 

> Regards,
> Christian.
> 
> > -Daniel
> > 
> > > ---
> > >   drivers/gpu/drm/ttm/ttm_bo_util.c | 16 +---
> > >   1 file changed, 9 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> > > b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > > index fe81c565e7ef..2ebe9fe7f6c8 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > > @@ -517,7 +517,9 @@ static int ttm_buffer_object_transfer(struct 
> > > ttm_buffer_object *bo,
> > >   kref_init(>base.kref);
> > >   fbo->base.destroy = _transfered_destroy;
> > >   fbo->base.acc_size = 0;
> > > - fbo->base.base.resv = >base.base._resv;
> > > + if (bo->base.resv == >base._resv)
> > > + fbo->base.base.resv = >base.base._resv;

I got confused a bit at first, until I spotted the

fbo->base = *bo;

somewhere above. So I think that part makes sense, together with the above
cited patch. I think at least, confidence on this is very low ...

> > > +
> > >   dma_resv_init(fbo->base.base.resv);
> > >   ret = dma_resv_trylock(fbo->base.base.resv);

Shouldn't this be switched over to _resv too? Otherwise feels like
unbalanced locking.

> > >   WARN_ON(!ret);
> > > @@ -716,7 +718,7 @@ int ttm_bo_move_accel_cleanup(struct 
> > > ttm_buffer_object *bo,
> > >   if (ret)
> > >   return ret;
> > > - dma_resv_add_excl_fence(ghost_obj->base.resv, fence);
> > > + dma_resv_add_excl_fence(_obj->base._resv, fence);
> > >   /**
> > >* If we're not moving to fixed memory, the TTM object
> > > @@ -729,7 +731,7 @@ int ttm_bo_move_accel_cleanup(struct 
> > > ttm_buffer_object *bo,
> > >   else
> > >   bo->ttm = NULL;
> > > - ttm_bo_unreserve(ghost_obj);
> > > + dma_resv_unlock(_obj->base._resv);
> > >   ttm_bo_put(ghost_obj);
> > >   }
> > > @@ -772,7 +774,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
> > >   if (ret)
> > >   return ret;
> > > - dma_resv_add_excl_fence(ghost_obj->base.resv, fence);
> > > + dma_resv_add_excl_fence(_obj->base._resv, fence);
> > >   /**
> > >* If we're not moving to fixed memory, the TTM object
> > > @@ -785,7 +787,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
> > >   else
> > >   bo->ttm = NULL;
> > > -

Re: [PATCH] drm/meson: fix max mode_config height/width

2019-10-09 Thread Daniel Vetter
On Tue, Sep 24, 2019 at 10:28:48AM -0700, Jeykumar Sankaran wrote:
> Reviving this thread from the context of the below conversion:
> 
> https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/#u
> 
> On 2018-10-05 01:19, Neil Armstrong wrote:
> > On 05/10/2018 09:58, Daniel Vetter wrote:
> > > On Fri, Oct 5, 2018 at 9:39 AM Neil Armstrong
> > >  wrote:
> > > > 
> > 
> > [...]
> > 
> > > > OK, won't this be enough ?
> > > > --- a/include/drm/drm_mode_config.h
> > > > +++ b/include/drm/drm_mode_config.h
> > > > @@ -333,6 +333,8 @@ struct drm_mode_config_funcs {
> > > >   * @min_height: minimum fb pixel height on this device
> > > >   * @max_width: maximum fb pixel width on this device
> > > >   * @max_height: maximum fb pixel height on this device
> > > > + * @max_fb_width: maximum fb buffer width if differs from max_width
> > > > + * @max_fb_height: maximum fb buffer height if differs from
> > > > max_height
> > > >   * @funcs: core driver provided mode setting functions
> > > >   * @fb_base: base address of the framebuffer
> > > >   * @poll_enabled: track polling support for this device
> > > > @@ -508,6 +510,7 @@ struct drm_mode_config {
> > > > 
> > > > int min_width, min_height;
> > > > int max_width, max_height;
> > > > +   int max_fb_width, max_fb_height;
> > > > const struct drm_mode_config_funcs *funcs;
> > > > resource_size_t fb_base;
> > > > 
> > > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > > @@ -283,14 +283,20 @@ drm_internal_framebuffer_create(struct
> > > > drm_device *dev,
> > > > return ERR_PTR(-EINVAL);
> > > > }
> > > > 
> > > > -   if ((config->min_width > r->width) || (r->width >
> > > > config->max_width)) {
> > > > +   if ((config->min_width > r->width) ||
> > > > +   (!config->max_fb_width && r->width >
> > > > config->max_width) ||
> > > > +   (config->max_fb_width && r->width >
> > > > config->max_fb_width)) {
> > > > DRM_DEBUG_KMS("bad framebuffer width %d, should
> > > > be >= %d && <= %d\n",
> > > > - r->width, config->min_width,
> > > > config->max_width);
> > > > + r->width, config->min_width,
> > > > config->max_fb_width ?
> > > > + config->max_fb_width : config->max_width);
> > > > return ERR_PTR(-EINVAL);
> > > > }
> > > > -   if ((config->min_height > r->height) || (r->height >
> > > > config->max_height)) {
> > > > +   if ((config->min_height > r->height) ||
> > > > +   (!config->max_fb_height && r->height >
> > > > config->max_height) ||
> > > > +   (config->max_fb_height && r->height >
> > > > config->max_fb_height)) {
> > > > DRM_DEBUG_KMS("bad framebuffer height %d, should
> > > > be >= %d && <= %d\n",
> > > > - r->height, config->min_height,
> > > > config->max_height);
> > > > + r->height, config->min_height,
> > > > config->max_fb_height ?
> > > > + config->max_fb_height :
> > > > config->max_height);
> > > > return ERR_PTR(-EINVAL);
> > > > }
> > > > 
> > > > and in the driver :
> > > > 
> > > > +   drm->mode_config.max_width = 4096;
> > > > +   drm->mode_config.max_height = 3840;
> > > > +   drm->mode_config.max_fb_width = 16384;
> > > > +   drm->mode_config.max_fb_height = 8192;
> > > > 
> > > > With this I leave the mode filtering intact.
> > > 
> > > Not enough. See
> > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#c.drm_connector_helper_funcs
> > > and scroll down to mode_valid. You need to filter modes both in the
> > > detect paths, and th

Re: [1/3] drm/tinydrm/Kconfig: Remove menuconfig DRM_TINYDRM

2019-10-09 Thread Daniel Vetter
On Tue, Oct 01, 2019 at 04:07:38PM +0200, Noralf Trønnes wrote:
> Hi drm-misc maintainers,
> 
> I have just applied a patch to drm-misc-next that as it turns out should
> have been applied to -fixes for this -rc cycle.
> 
> Should I cherry pick it to drm-misc-next-fixes?

Yup, cherry pick and reference the commit that's already in -next (in case
it creates conflicts down the road that reference makes the mess easier to
understand).

> (I know there's a flowchart in the docs but I've never really understood
> it.)

Usually bugfixes for kernel releases should land in drm-misc-next-fixes or
drm-misc-fixes. But cherry-picking over in case of mistakes is ok too.
-Daniel

> 
> Noralf.
> 
> Den 01.10.2019 15.45, skrev Jason Gunthorpe:
> > On Tue, Oct 01, 2019 at 03:28:46PM +0200, Noralf Trønnes wrote:
> >>
> >>
> >> Den 01.10.2019 14.36, skrev Jason Gunthorpe:
> >>> On Thu, Jul 25, 2019 at 12:51:30PM +0200, Noralf Trønnes wrote:
> >>>> This makes the tiny drivers visible by default without having to enable a
> >>>> knob.
> >>>>
> >>>> Signed-off-by: Noralf Trønnes 
> >>>> Reviewed-by: Hans de Goede  to it once
> >>>>  drivers/gpu/drm/Makefile|  2 +-
> >>>>  drivers/gpu/drm/tinydrm/Kconfig | 37 +++--
> >>>>  2 files changed, 22 insertions(+), 17 deletions(-)
> >>>
> >>> Bisection says this patch (28c47e16ea2a19adb47fe2c182cbd61cb854237c)
> >>> breaks kconfig stuff in v5.4-rc by creating circular
> >>> dependencies. Could someone send a -rc patch to fix this please?
> >>>
> >>> THINKPAD_ACPI (defined at drivers/platform/x86/Kconfig:484), with 
> >>> definition...
> >>> ...depends on FB_SSD1307 (defined at drivers/video/fbdev/Kconfig:2259), 
> >>> with definition...
> >>> ...depends on FB (defined at drivers/video/fbdev/Kconfig:12), with 
> >>> definition...
> >>> ...depends on DRM_KMS_FB_HELPER (defined at drivers/gpu/drm/Kconfig:79), 
> >>> with definition...
> >>> ...depends on DRM_KMS_HELPER (defined at drivers/gpu/drm/Kconfig:73), 
> >>> with definition...
> >>> ...depends on TINYDRM_REPAPER (defined at 
> >>> drivers/gpu/drm/tinydrm/Kconfig:51), with definition...
> >>> ...depends on THERMAL (defined at drivers/thermal/Kconfig:6), with 
> >>> definition...
> >>> ...depends on SENSORS_NPCM7XX (defined at drivers/hwmon/Kconfig:1285), 
> >>> with definition...
> >>> ...depends on HWMON (defined at drivers/hwmon/Kconfig:6), with 
> >>> definition...
> >>> ...depends on THINKPAD_ACPI (defined at 
> >>> drivers/platform/x86/Kconfig:484), with definition...
> >>> ...depends on ACPI_VIDEO (defined at drivers/acpi/Kconfig:193), with 
> >>> definition...
> >>> ...depends on ACER_WMI (defined at drivers/platform/x86/Kconfig:19), with 
> >>> definition...
> >>> ...depends on BACKLIGHT_CLASS_DEVICE (defined at 
> >>> drivers/video/backlight/Kconfig:144), with definition...
> >>> ...depends again on THINKPAD_ACPI (defined at 
> >>> drivers/platform/x86/Kconfig:484)
> >>>
> >>
> >> Would this commit fix this by any chance:
> >>
> >> drm/tiny: Kconfig: Remove always-y THERMAL dep. from TINYDRM_REPAPER
> >> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=dfef959803c728c616ad29b008cd91b3446a993a
> > 
> > Yes, thank you, can someone send this to -rc to unbreak 5.4?
> > 
> > Jason
> > 

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

Re: [PATCH v2] drm/vkms: Fix an undefined reference error in vkms_composer_worker

2019-10-09 Thread Daniel Vetter
On Mon, Sep 23, 2019 at 09:24:43AM +0800, zhong jiang wrote:
> I hit the following error when compile the kernel.
> 
> drivers/gpu/drm/vkms/vkms_composer.o: In function `vkms_composer_worker':
> vkms_composer.c:(.text+0x5e4): undefined reference to `crc32_le'
> make: *** [vmlinux] Error 1
> 
> Signed-off-by: zhong jiang 

Queued for -next, thanks for your patch.
-Daniel
> ---
>  drivers/gpu/drm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index e67c194..285d649 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -257,6 +257,7 @@ config DRM_VKMS
>   tristate "Virtual KMS (EXPERIMENTAL)"
>   depends on DRM
>   select DRM_KMS_HELPER
> + select CRC32
>   default n
>   help
> Virtual Kernel Mode-Setting (VKMS) is used for testing or for
> -- 
> 2.7.4
> 

-- 
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 RFC v4 14/16] drm, cgroup: Introduce lgpu as DRM cgroup resource

2019-10-09 Thread Daniel Vetter
p_max, p_max, );
> > +
> > +   if (rc || val < 0) {
> > +   drmcg_pr_cft_err(drmcg, rc, cft_name,
> > +   minor);
> > +   continue;
> > +   }
> > +
> > +   bitmap_zero(tmp_bitmap,
> > +   MAX_DRMCG_LGPU_CAPACITY);
> > +   bitmap_set(tmp_bitmap, 0, val);
> > +   }
> > +
> > +   if (strncmp(sname, LGPU_LIMITS_NAME_LIST, 256) == 0) {
> > +   rc = bitmap_parselist(sval, tmp_bitmap,
> > +   MAX_DRMCG_LGPU_CAPACITY);
> > +
> > +   if (rc) {
> > +   drmcg_pr_cft_err(drmcg, rc, cft_name,
> > +   minor);
> > +   continue;
> > +   }
> > +
> > +   bitmap_andnot(chk_bitmap, tmp_bitmap,
> > +   props->lgpu_slots,
> > +   MAX_DRMCG_LGPU_CAPACITY);
> > +
> > +   if (!bitmap_empty(chk_bitmap,
> > +   MAX_DRMCG_LGPU_CAPACITY)) {
> > +   drmcg_pr_cft_err(drmcg, 0, cft_name,
> > +   minor);
> > +   continue;
> > +   }
> > +   }
> > +
> > +
> > +if (parent != NULL) {
> > +   bitmap_and(chk_bitmap, tmp_bitmap,
> > +   parent->dev_resources[minor]->lgpu_allocated,
> > +   props->lgpu_capacity);
> > +
> > +   if (bitmap_empty(chk_bitmap,
> > +   props->lgpu_capacity)) {
> > +   drmcg_pr_cft_err(drmcg, 0,
> > +   cft_name, minor);
> > +   continue;
> > +           }
> > +   }
> > +
> > +   drmcg_lgpu_values_apply(dev, ddr, tmp_bitmap);
> > +
> > +   break; /* DRMCG_TYPE_LGPU */
> > default:
> > break;
> > } /* switch (type) */
> > @@ -606,6 +720,7 @@ static ssize_t drmcg_limit_write(struct 
> > kernfs_open_file *of, char *buf,
> > break;
> > case DRMCG_TYPE_BANDWIDTH:
> > case DRMCG_TYPE_MEM:
> > +   case DRMCG_TYPE_LGPU:
> > drmcg_nested_limit_parse(of, dm->dev, sattr);
> > break;
> > default:
> > @@ -731,6 +846,20 @@ struct cftype files[] = {
> > .private = DRMCG_CTF_PRIV(DRMCG_TYPE_BANDWIDTH,
> > DRMCG_FTYPE_DEFAULT),
> > },
> > +   {
> > +   .name = "lgpu",
> > +   .seq_show = drmcg_seq_show,
> > +   .write = drmcg_limit_write,
> > +   .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU,
> > +   DRMCG_FTYPE_LIMIT),
> > +   },
> > +   {
> > +   .name = "lgpu.default",
> > +   .seq_show = drmcg_seq_show,
> > +   .flags = CFTYPE_ONLY_ON_ROOT,
> > +   .private = DRMCG_CTF_PRIV(DRMCG_TYPE_LGPU,
> > +   DRMCG_FTYPE_DEFAULT),
> > +   },
> > { } /* terminate */
> >   };
> >   
> > @@ -744,6 +873,10 @@ struct cgroup_subsys drm_cgrp_subsys = {
> >   
> >   static inline void drmcg_update_cg_tree(struct drm_device *dev)
> >   {
> > +bitmap_zero(dev->drmcg_props.lgpu_slots, MAX_DRMCG_LGPU_CAPACITY);
> > +bitmap_fill(dev->drmcg_props.lgpu_slots,
> > +   dev->drmcg_props.lgpu_capacity);
> > +
> > /* init cgroups created before registration (i.e. root cgroup) */
> > if (root_drmcg != NULL) {
> > struct cgroup_subsys_state *pos;
> > @@ -800,6 +933,8 @@ void drmcg_device_early_init(struct drm_device *dev)
> > for (i = 0; i <= TTM_PL_PRIV; i++)
> > dev->drmcg_props.mem_highs_default[i] = S64_MAX;
> >   
> > +   dev->drmcg_props.lgpu_capacity = MAX_DRMCG_LGPU_CAPACITY;
> > +
> > drmcg_update_cg_tree(dev);
> >   }
> >   EXPORT_SYMBOL(drmcg_device_early_init);

-- 
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] dma-buf/resv: fix exclusive fence get

2019-10-08 Thread Daniel Vetter
On Mon, Sep 30, 2019 at 08:57:32AM +, Koenig, Christian wrote:
> Am 30.09.19 um 09:22 schrieb Daniel Vetter:
> > On Sun, Sep 22, 2019 at 2:08 PM Qiang Yu  wrote:
> >> This causes kernel crash when testing lima driver.
> >>
> >> Cc: Christian König 
> >> Fixes: b8c036dfc66f ("dma-buf: simplify reservation_object_get_fences_rcu 
> >> a bit")
> >> Signed-off-by: Qiang Yu 
> > Selftest for this would be lovely, now that the basic infrastructure
> > is in place ...
> 
> What do you have in mind? I wouldn't even know where to start to write 
> an unit test for this.

1. set a few fences (both excl + shared) in a dma_resv
2. get them
3. check that we got them all
4. notice that the exlusive fence isn't actually in the array (because we
increment the index before storing, so the exclusive fence ended past the
array). For robustness the test should check that the fences are listed in
any order, not just the one the current implementation gives you.

I guess the actual crash happens when we're unlucky and overflow the
allocation, which is probably more rare. But KASAN should help catch that
too (run that in your CI if you don't do that yet, it's pretty
impressive).

Or am I totally misunderstanding what's going wrong here?
-Daniel
> 
> Christian.
> 
> > -Daniel
> >
> >> ---
> >>   drivers/dma-buf/dma-resv.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> >> index 42a8f3f11681..709002515550 100644
> >> --- a/drivers/dma-buf/dma-resv.c
> >> +++ b/drivers/dma-buf/dma-resv.c
> >> @@ -471,7 +471,7 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj,
> >>  if (pfence_excl)
> >>  *pfence_excl = fence_excl;
> >>  else if (fence_excl)
> >> -   shared[++shared_count] = fence_excl;
> >> +   shared[shared_count++] = fence_excl;
> >>
> >>  if (!shared_count) {
> >>  kfree(shared);
> >> --
> >> 2.17.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> 

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

Re: [PATCH 2/2] Documentation/gpu: Fix no structured comments warning for drm_gem_ttm_helper.h

2019-10-08 Thread Daniel Vetter
On Mon, Sep 23, 2019 at 09:03:01AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 20.09.19 um 21:35 schrieb Sean Paul:
> > From: Sean Paul 
> > 
> > Fixes
> > include/drm/drm_gem_ttm_helper.h:1: warning: no structured comments found
> 
> That missing documentation looks like an oversight to me.
> 
> Acked-by: Thomas Zimmermann 
> 
> under the premise that there's not currently some patch with the missing
> documentation floating around.

There's no struct or inline functions in that header file, so really
nothing to document. Just need to make sure that if we add anything, we
re-add the include directive.
-Daniel

> 
> Best regards
> Thomas
> 
> > Fixes: ff540b76f14a ("drm/ttm: add drm gem ttm helpers, starting with 
> > drm_gem_ttm_print_info()")
> > Cc: Gerd Hoffmann 
> > Cc: Thomas Zimmermann 
> > Cc: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Sean Paul 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Sean Paul 
> > ---
> >  Documentation/gpu/drm-mm.rst | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> > index 99d56015e077..59619296c84b 100644
> > --- a/Documentation/gpu/drm-mm.rst
> > +++ b/Documentation/gpu/drm-mm.rst
> > @@ -406,9 +406,6 @@ GEM TTM Helper Functions Reference
> >  .. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
> > :doc: overview
> >  
> > -.. kernel-doc:: include/drm/drm_gem_ttm_helper.h
> > -   :internal:
> > -
> >  .. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
> > :export:
> >  
> > 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
> HRB 21284 (AG Nürnberg)
> 




-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH -next] treewide: remove unused argument in lock_release()

2019-10-08 Thread Daniel Vetter
On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> in __lock_release"), @nested is no longer used in lock_release(), so
> remove it from all lock_release() calls and friends.
> 
> Signed-off-by: Qian Cai 

Ack on the concept and for the drm parts (and feel free to keep the ack if
you inevitably have to respin this later on). Might result in some
conflicts, but welp we need to keep Linus busy :-)

Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_connector.c   |  2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  6 +++---
>  drivers/gpu/drm/i915/gt/intel_engine_pm.c |  2 +-
>  drivers/gpu/drm/i915/i915_request.c   |  2 +-
>  drivers/tty/tty_ldsem.c   |  8 
>  fs/dcache.c   |  2 +-
>  fs/jbd2/transaction.c |  4 ++--
>  fs/kernfs/dir.c   |  4 ++--
>  fs/ocfs2/dlmglue.c|  2 +-
>  include/linux/jbd2.h  |  2 +-
>  include/linux/lockdep.h   | 21 ++---
>  include/linux/percpu-rwsem.h  |  4 ++--
>  include/linux/rcupdate.h  |  2 +-
>  include/linux/rwlock_api_smp.h| 16 
>  include/linux/seqlock.h   |  4 ++--
>  include/linux/spinlock_api_smp.h  |  8 
>  include/linux/ww_mutex.h  |  2 +-
>  include/net/sock.h|  2 +-
>  kernel/bpf/stackmap.c |  2 +-
>  kernel/cpu.c  |  2 +-
>  kernel/locking/lockdep.c  |  3 +--
>  kernel/locking/mutex.c|  4 ++--
>  kernel/locking/rtmutex.c  |  6 +++---
>  kernel/locking/rwsem.c| 10 +-
>  kernel/printk/printk.c| 10 +-
>  kernel/sched/core.c   |  2 +-
>  lib/locking-selftest.c| 24 
>  mm/memcontrol.c   |  2 +-
>  net/core/sock.c   |  2 +-
>  tools/lib/lockdep/include/liblockdep/common.h |  3 +--
>  tools/lib/lockdep/include/liblockdep/mutex.h  |  2 +-
>  tools/lib/lockdep/include/liblockdep/rwlock.h |  2 +-
>  tools/lib/lockdep/preload.c   | 16 
>  33 files changed, 90 insertions(+), 93 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 4c766624b20d..4a8b2e5c2af6 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -719,7 +719,7 @@ void drm_connector_list_iter_end(struct 
> drm_connector_list_iter *iter)
>   __drm_connector_put_safe(iter->conn);
>   spin_unlock_irqrestore(>connector_list_lock, flags);
>   }
> - lock_release(_list_iter_dep_map, 0, _RET_IP_);
> + lock_release(_list_iter_dep_map, _RET_IP_);
>  }
>  EXPORT_SYMBOL(drm_connector_list_iter_end);
>  
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> index edd21d14e64f..1a51b3598d63 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> @@ -509,14 +509,14 @@ void i915_gem_shrinker_taints_mutex(struct 
> drm_i915_private *i915,
> I915_MM_SHRINKER, 0, _RET_IP_);
>  
>   mutex_acquire(>dep_map, 0, 0, _RET_IP_);
> - mutex_release(>dep_map, 0, _RET_IP_);
> + mutex_release(>dep_map, _RET_IP_);
>  
> - mutex_release(>drm.struct_mutex.dep_map, 0, _RET_IP_);
> + mutex_release(>drm.struct_mutex.dep_map, _RET_IP_);
>  
>   fs_reclaim_release(GFP_KERNEL);
>  
>   if (unlock)
> - mutex_release(>drm.struct_mutex.dep_map, 0, _RET_IP_);
> + mutex_release(>drm.struct_mutex.dep_map, _RET_IP_);
>  }
>  
>  #define obj_to_i915(obj__) to_i915((obj__)->base.dev)
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 65b5ca74b394..7f647243b3b9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -52,7 +52,7 @@ static inline unsigned long __timeline_mark_lock(struct 
> intel_context *ce)
>  static inline void __timeline_mark_unlock(struct intel_context *ce,
> unsigned long flags)
>  {
> - mutex_release(>timeline->mutex.dep_map, 0, _THIS_IP_);
> + mutex_rele

Re: [PATCH v2] drm/ioctl: Add a ioctl to label GEM objects

2019-10-08 Thread Daniel Vetter
m_object_release - release GEM buffer object resources
> > >   * @obj: GEM buffer object
> > > 
> > > @@ -958,6 +1017,11 @@ drm_gem_object_release(struct drm_gem_object *obj)
> > > 
> > >   dma_resv_fini(>_resv);
> > >   drm_gem_free_mmap_offset(obj);
> > > 
> > > +
> > > + if (obj->label) {
> > > + kfree(obj->label);
> > > + obj->label = NULL;
> > > + }
> > > 
> > >  }
> > >  EXPORT_SYMBOL(drm_gem_object_release);
> > > 
> > > diff --git a/drivers/gpu/drm/drm_internal.h
> > > b/drivers/gpu/drm/drm_internal.h index 51a2055c8f18..8259622f9ab6 100644
> > > --- a/drivers/gpu/drm/drm_internal.h
> > > +++ b/drivers/gpu/drm/drm_internal.h
> > > @@ -137,6 +137,10 @@ int drm_gem_pin(struct drm_gem_object *obj);
> > > 
> > >  void drm_gem_unpin(struct drm_gem_object *obj);
> > >  void *drm_gem_vmap(struct drm_gem_object *obj);
> > >  void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
> > > 
> > > +int drm_bo_set_label_ioctl(struct drm_device *dev, void *data,
> > > + struct drm_file *file_priv);
> > > +int drm_gem_set_label(struct drm_device *dev, struct drm_label_object
> > > *args, +  struct drm_file *file_priv);
> > 
> > This one seems to be unused now.
> > 
> > >  /* drm_debugfs.c drm_debugfs_crc.c */
> > >  #if defined(CONFIG_DEBUG_FS)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > > index f675a3bb2c88..079d1422f9c5 100644
> > > --- a/drivers/gpu/drm/drm_ioctl.c
> > > +++ b/drivers/gpu/drm/drm_ioctl.c
> > > @@ -709,6 +709,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
> > > 
> > >   DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, 
> drm_mode_list_lessees_ioctl,
> > >   DRM_MASTER), DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE,
> > >   drm_mode_get_lease_ioctl, DRM_MASTER),
> > >   DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, 
> drm_mode_revoke_lease_ioctl,
> > >   DRM_MASTER),> 
> > > + DRM_IOCTL_DEF(DRM_IOCTL_BO_SET_LABEL, drm_bo_set_label_ioctl,
> > > DRM_RENDER_ALLOW),> 
> > >  };
> > >  
> > >  #define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
> > > 
> > > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > > index 8976afe48c1c..f736ba1f42a6 100644
> > > --- a/include/drm/drm_drv.h
> > > +++ b/include/drm/drm_drv.h
> > > @@ -715,6 +715,24 @@ struct drm_driver {
> > > 
> > >   struct drm_device *dev,
> > >   uint32_t handle);
> > > 
> > > +
> > > + /**
> > > +  * @label:
> > > +  *
> > > +  * This label's a buffer object.
> > > +  *
> > > +  * Called by the user via ioctl.
> > > +  *
> > > +  * The default implementation is drm_gem_label(). GEM based 
> drivers
> > > +  * must not overwrite this.
> > > +
> > 
> > Spurious blank line.
> > 
> 
> Ack to all the above. I'll address these in v3!
> 
> > > +  * Returns:
> > > +  *
> > > +  * Zero on success, negative errno on failure.
> > > +  */
> > > + int (*label)(struct drm_device *dev, struct drm_label_object 
> *args,
> > > + struct drm_file *file_priv);
> > 
> > If I understand correctly, you use this so that non-GEM drivers can use
> > this IOCTL to label their non-GEM objects. Do you think that's really
> > useful? I mean they've already got quite a bit of special code to deal
> > with their objects, so singling out this IOCTL seems a bit odd.
> > 
> > Then again, I guess it doesn't really hurt since GEM-based drivers will
> > always use the standard implementation.
> > 
> 
> Please refer to Thomas Zimmermann's reply earlier in this thread. This was 
> also specifically requested as part of the v1 review of this patch.

Imo ditch this. There's a grant total of 1 non-gem driver, and that one
uses 0 of the other gem related sharing infrastructure. I don't expect any
new non-gem driver to get merged, ever (we're merging ttm and gem
internally, which was really the only reason).

And if vmwgfx wants to label objects, they can do that through their own
ioctl.
-Daniel

> 
> > > +
> > > 
> > >   /**
> > >   
> > >* @gem_vm_ops: Driver private ops for this object
> > >*
> > > 
> > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > index 6aaba14f5972..f801c054e972 100644
> > > --- a/include/drm/drm_gem.h
> > > +++ b/include/drm/drm_gem.h
> > > @@ -237,6 +237,13 @@ struct drm_gem_object {
> > > 
> > >*/
> > >   
> > >   int name;
> > > 
> > > + /**
> > > +  * @label:
> > > +  *
> > > +  * Label for this object, should be a human readable string.
> > > +  */
> > > + char *label;
> > > +
> > > 
> > >   /**
> > >   
> > >* @dma_buf:
> > >*
> > > 
> > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > index 8a5b2f8f8eb9..23b507f5c571 100644
> > > --- a/include/uapi/drm/drm.h
> > > +++ b/include/uapi/drm/drm.h
> > > @@ -626,6 +626,25 @@ struct drm_gem_open {
> > > 
> > >   __u64 size;
> > >  
> > >  };
> > > 
> > > +/** struct drm_label_object - ioctl argument for labelling BOs.
> > > + *
> > > + * This label's a BO with a userspace label
> > > + *
> > > + */
> > > +struct drm_label_object {
> > > + /** Handle for the object being labelled. */
> > > + __u32 handle;
> > > +
> > > + /** Label and label length.
> > > +  *  length includes the trailing NULL.
> > 
> > Nit: I think you mean "trailing NUL". Also, the parameter is called len
> > below, so the comment here should match.
> > 
> 
> Ack.
> 
> Thanks for the review!
> 
> Cheers
> Rohan Garg



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


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

Re: [PATCH 1/3] dma-buf: add dma_resv_ctx for deadlock handling

2019-10-08 Thread Daniel Vetter
 _LINUX_DMA_RESV_CTX_H
> +
> +#include 
> +#include 
> +
> +/**
> + * struct dma_resv_ctx - context to lock reservation objects
> + * @base: ww_acquire_ctx used for deadlock detection
> + * @locked: list of dma_resv objects locked in this context
> + * @contended: contended dma_resv object
> + */
> +struct dma_resv_ctx {
> + struct ww_acquire_ctx base;
> + struct llist_head locked;
> + struct dma_resv *contended;
> +};
> +
> +/**
> + * dma_resv_ctx_done - wrapper for ww_acquire_done
> + * @ctx: the reservation context which is done with locking
> + */
> +static inline void dma_resv_ctx_done(struct dma_resv_ctx *ctx)
> +{
> + ww_acquire_done(>base);
> +}
> +
> +/**
> + * dma_resv_ctx_fini - wrapper for ww_acquire_fini
> + * @ctx: the reservation context which is finished
> + */
> +static inline void dma_resv_ctx_fini(struct dma_resv_ctx *ctx)
> +{
> + ww_acquire_fini(>base);
> +}
> +
> +void dma_resv_ctx_init(struct dma_resv_ctx *ctx);
> +void dma_resv_ctx_unlock_all(struct dma_resv_ctx *ctx);
> +int dma_resv_ctx_lock(struct dma_resv_ctx *ctx, struct dma_resv *obj,
> +   bool interruptible);
> +
> +#endif /* _LINUX_DMA_RESV_CTX_H */
> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> index ee50d10f052b..1267822c2669 100644
> --- a/include/linux/dma-resv.h
> +++ b/include/linux/dma-resv.h
> @@ -71,6 +71,7 @@ struct dma_resv_list {
>   */
>  struct dma_resv {
>   struct ww_mutex lock;
> + struct llist_node locked;
>   seqcount_t seq;
>  
>   struct dma_fence __rcu *fence_excl;
> -- 
> 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: [v4] drm: two planes with the same zpos have undefined ordering

2019-10-08 Thread Daniel Vetter
On Tue, Oct 8, 2019 at 5:11 PM Simon Ser  wrote:
>
> On Tuesday, October 8, 2019 6:03 PM, Daniel Vetter  wrote:
>
> > > > > > In any case, this doesn't change the patch itself. Probably 
> > > > > > something worth
> > > > > > mentionning in the commit message.
> > > > >
> > > > > Yes, recording these use cases would be very nice.
> > > >
> > > > There's a lot more hw that does the same tricks (qualcom is one for 
> > > > sure).
> > > > Imo before we encode this we should make sure that:
> > > > a) everyone is happy with this new uapi
> > >
> > > Sorry, what new UAPI?
> > > We're just trying to make the documentation match what currently
> > > happens, right?
> >
> > It's so much new uapi that I've sent out a few reverts for 5.4 (it
> > landed in that merge window) to undo the stuff the arm driver team has
> > done (it didn't come with userspace, proper discussion on dri-devel,
> > docs or testcases in igt). I also just spotted that a leftover is that
> > arm/komeda still computes its own version of normalized_zpos, which
> > probably should be ditched too (it's not actually different from the
> > one in helpers without the reverted uapi).
> >
> > So yeah, separate patch :-)
>
> I don't get it. Do you want to split the docs changes for user-space,
> only keeping the doc changes for drivers in this patch?
>
> User-space could already see duplicate zpos because of the non-atomic
> API. I don't think this introduces a new uAPI.

I'm talking specifically about the "duplicated zpos values indicate
special cloned planes like in the arm example" clarification. Not
about splitting the zpos documentation any more, that's indeed just
documenting existing uapi. But assigning the special meaning to
duplicated zpos values (instead of just "can happen because non-atomic
legacy userspace"), that is new uapi. Especially if we allow
duplicated zpos for immutable properties (afaik that doesn't exist
yet).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] drm/virtio: Export resource handles via DMA-buf API

2019-10-08 Thread Daniel Vetter
On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote:
> On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter  wrote:
> >
> > On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote:
> > > Hi Daniel, Gerd,
> > >
> > > On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter  wrote:
> > > >
> > > > On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote:
> > > > > This patch is an early RFC to judge the direction we are following in
> > > > > our virtualization efforts in Chrome OS. The purpose is to start a
> > > > > discussion on how to handle buffer sharing between multiple virtio
> > > > > devices.
> > > > >
> > > > > On a side note, we are also working on a virtio video decoder 
> > > > > interface
> > > > > and implementation, with a V4L2 driver for Linux. Those will be posted
> > > > > for review in the near future as well.
> > > > >
> > > > > Any feedback will be appreciated! Thanks in advance.
> > > > >
> > > > > ===
> > > > >
> > > > > With the range of use cases for virtualization expanding, there is 
> > > > > going
> > > > > to be more virtio devices added to the ecosystem. Devices such as 
> > > > > video
> > > > > decoders, encoders, cameras, etc. typically work together with the
> > > > > display and GPU in a pipeline manner, which can only be implemented
> > > > > efficiently by sharing the buffers between producers and consumers.
> > > > >
> > > > > Existing buffer management framework in Linux, such as the videobuf2
> > > > > framework in V4L2, implements all the DMA-buf handling inside generic
> > > > > code and do not expose any low level information about the buffers to
> > > > > the drivers.
> > > > >
> > > > > To seamlessly enable buffer sharing with drivers using such 
> > > > > frameworks,
> > > > > make the virtio-gpu driver expose the resource handle as the DMA 
> > > > > address
> > > > > of the buffer returned from the DMA-buf mapping operation. Arguably, 
> > > > > the
> > > > > resource handle is a kind of DMA address already, as it is the buffer
> > > > > identifier that the device needs to access the backing memory, which 
> > > > > is
> > > > > exactly the same role a DMA address provides for native devices.
> > > > >
> > > > > A virtio driver that does memory management fully on its own would 
> > > > > have
> > > > > code similar to following. The code is identical to what a regular
> > > > > driver for real hardware would do to import a DMA-buf.
> > > > >
> > > > > static int virtio_foo_get_resource_handle(struct virtio_foo *foo,
> > > > > struct dma_buf *dma_buf, u32 
> > > > > *id)
> > > > > {
> > > > >   struct dma_buf_attachment *attach;
> > > > >   struct sg_table *sgt;
> > > > >   int ret = 0;
> > > > >
> > > > >   attach = dma_buf_attach(dma_buf, foo->dev);
> > > > >   if (IS_ERR(attach))
> > > > >   return PTR_ERR(attach);
> > > > >
> > > > >   sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> > > > >   if (IS_ERR(sgt)) {
> > > > >   ret = PTR_ERR(sgt);
> > > > >   goto err_detach;
> > > > >   }
> > > > >
> > > > >   if (sgt->nents != 1) {
> > > > >   ret = -EINVAL;
> > > > >   goto err_unmap;
> > > > >   }
> > > > >
> > > > >   *id = sg_dma_address(sgt->sgl);
> > > >
> > > > I agree with Gerd, this looks pretty horrible to me.
> > > >
> > > > The usual way we've done these kind of special dma-bufs is:
> > > >
> > > > - They all get allocated at the same place, through some library or
> > > >   whatever.
> > > >
> > > > - You add a dma_buf_is_virtio(dma_buf) function, or maybe something that
> > > >   also upcasts or returns NULL, which checks for dma_buf->ops.
> > > >
> > >
> > > Thanks for a lot o

Re: [v4] drm: two planes with the same zpos have undefined ordering

2019-10-08 Thread Daniel Vetter
On Tue, Oct 8, 2019 at 1:39 PM Pekka Paalanen  wrote:
>
> On Tue, 8 Oct 2019 11:59:04 +0200
> Daniel Vetter  wrote:
>
> > On Mon, Sep 30, 2019 at 10:07:07AM +0300, Pekka Paalanen wrote:
> > > On Sun, 29 Sep 2019 20:30:44 +
> > > Simon Ser  wrote:
> > >
> > > > Hi,
> > > >
> > > > > On Mon, Sep 23, 2019 at 12:39:20PM +, Simon Ser wrote:
> > > > > > Currently the property docs don't specify whether it's okay for two 
> > > > > > planes to
> > > > > > have the same zpos value and what user-space should expect in this 
> > > > > > case.
> > > > > >
> > > > > > The rule mentionned in the past was to disambiguate with object 
> > > > > > IDs. However
> > > > > > some drivers break this rule (that's why the ordering is documented 
> > > > > > as
> > > > > > unspecified in case the zpos property is missing). Additionally it 
> > > > > > doesn't
> > > > > > really make sense for a driver to user identical zpos values if it 
> > > > > > knows their
> > > > > > relative position: the driver can just pick different values 
> > > > > > instead.
> > > > > >
> > > > > > So two solutions would make sense: either disallow completely 
> > > > > > identical zpos
> > > > > > values for two different planes, either make the ordering 
> > > > > > unspecified. To allow
> > > > > > drivers that don't know the relative ordering between two planes to 
> > > > > > still
> > > > > > expose the zpos property, choose the latter solution.
> > > > >
> > > > > Some Arm's usage cases about two planes with same zpos.
> > > > >
> > > > > - "Smart layer"
> > > > > which can accepts 4 different fbs with different src/display rect,
> > > > > but this smart layer has one restriction:
> > > > >
> > > > > 4 display rects must have no overlaps in V direction
> > > > > (A optimization for android window like Toolbar/Navigation bar)
> > > > >
> > > > > So when map this Smart-layer to drm world, it might be 4 different
> > > > > drm-planes, but with same zorder to indicate that these 4 planes are
> > > > > smart-laye planes.
> > > > >
> > > > > - "VR-Layer"
> > > > > One VR-layer comprises two different viewports which can be configured
> > > > > with totoally different fbs, src/display rect.
> > > > > we use two differernt drm-planes to drive on HW "VR-Layer", and these
> > > > > two drm-planes must be configured with same zpos.
> > > >
> > > > Thanks a lot for your feedback James, that's exactly what I was looking 
> > > > for.
> > > > Both of these use-cases make sense to me.
> > > >
> > > > I think user-space should be prepared to handle identical immutable 
> > > > zpos values.
> > > > Pekka and Daniel, thoughts?
> > >
> > > Hi,
> > >
> > > given those explained use cases, sure, I agree.
> > >
> > > > In any case, this doesn't change the patch itself. Probably something 
> > > > worth
> > > > mentionning in the commit message.
> > >
> > > Yes, recording these use cases would be very nice.
> >
> > There's a lot more hw that does the same tricks (qualcom is one for sure).
> > Imo before we encode this we should make sure that:
> > a) everyone is happy with this new uapi
>
> Sorry, what new UAPI?
>
> We're just trying to make the documentation match what currently
> happens, right?

It's so much new uapi that I've sent out a few reverts for 5.4 (it
landed in that merge window) to undo the stuff the arm driver team has
done (it didn't come with userspace, proper discussion on dri-devel,
docs or testcases in igt). I also just spotted that a leftover is that
arm/komeda still computes its own version of normalized_zpos, which
probably should be ditched too (it's not actually different from the
one in helpers without the reverted uapi).

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

Re: [PATCH] drm/komeda: Adds zorder support

2019-10-08 Thread Daniel Vetter
  DRM_DEBUG_ATOMIC("[CRTC:%d:%s] calculating normalized zpos values\n",
> +crtc->base.id, crtc->name);
> +
> +   INIT_LIST_HEAD(_list);
> +
> +   /* This loop also added all effected planes into the new state */
> +   drm_for_each_plane_mask(plane, crtc->dev, crtc_st->plane_mask) {
> +   plane_st = drm_atomic_get_plane_state(state, plane);
> +   if (IS_ERR(plane_st))
> +   return PTR_ERR(plane_st);
> +
> +   /* Build a list by zpos increasing */
> +   err = komeda_plane_state_list_add(plane_st, _list);
> +   if (err)
> +   return err;
> +   }
> +
> +   list_for_each_entry(kplane_st, _list, zlist_node) {
> +   plane_st = _st->base;
> +   fb = plane_st->fb;
> +   plane = plane_st->plane;
> +
> +   plane_st->normalized_zpos = order++;
> +
> +   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] zpos:%d, normalized zpos: 
> %d\n",
> +plane->base.id, plane->name,
> +plane_st->zpos, plane_st->normalized_zpos);
> +   }
> +
> +   crtc_st->zpos_changed = true;
> +
> +   return 0;
> +}
> +
>  static int komeda_kms_check(struct drm_device *dev,
> struct drm_atomic_state *state)
>  {
> @@ -111,7 +195,7 @@ static int komeda_kms_check(struct drm_device *dev,
> if (err)
> return err;
>
> -   /* komeda need to re-calculate resource assumption in every commit
> +   /* Komeda need to re-calculate resource assumption in every commit
>  * so need to add all affected_planes (even unchanged) to
>  * drm_atomic_state.
>  */
> @@ -119,6 +203,10 @@ static int komeda_kms_check(struct drm_device *dev,
> err = drm_atomic_add_affected_planes(state, crtc);
> if (err)
> return err;
> +
> +   err = komeda_crtc_normalize_zpos(crtc, new_crtc_st);
> +   if (err)
> +   return err;
> }
>
> err = drm_atomic_helper_check_planes(dev, state);
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h 
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> index 178bee6..d1cef46 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> @@ -7,6 +7,7 @@
>  #ifndef _KOMEDA_KMS_H_
>  #define _KOMEDA_KMS_H_
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -46,6 +47,8 @@ struct komeda_plane {
>  struct komeda_plane_state {
> /** @base: _plane_state */
> struct drm_plane_state base;
> +   /** @zlist_node: zorder list node */
> +   struct list_head zlist_node;
>
> /* @img_enhancement: on/off image enhancement */
> u8 img_enhancement : 1;
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> index bcf30a7..aad7663 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> @@ -21,7 +21,7 @@
>
> memset(dflow, 0, sizeof(*dflow));
>
> -   dflow->blending_zorder = st->zpos;
> +   dflow->blending_zorder = st->normalized_zpos;
>
> /* if format doesn't have alpha, fix blend mode to PIXEL_NONE */
> dflow->pixel_blend_mode = fb->format->has_alpha ?
> @@ -343,6 +343,10 @@ static int komeda_plane_add(struct komeda_kms_dev *kms,
> if (err)
> goto cleanup;
>
> +   err = drm_plane_create_zpos_property(plane, layer->base.id, 0, 8);
> +   if (err)
> +   goto cleanup;
> +
> return 0;
>  cleanup:
> komeda_plane_destroy(plane);
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: liboutput: thoughts about shared library on top of DRM/KMS

2019-10-08 Thread Daniel Vetter
On Tue, Oct 8, 2019 at 4:36 PM Alex Deucher  wrote:
>
> On Tue, Oct 8, 2019 at 5:32 AM Daniel Stone  wrote:
> >
> > Hi,
> >
> > On Mon, 7 Oct 2019 at 19:16, Keith Packard  wrote:
> > > Daniel Stone  writes:
> > > > I think there would be a load of value in starting with simple helpers
> > > > which can be used independently of any larger scheme, tackling that
> > > > list above.
> > >
> > > Yeah, a helper library that didn't enforce at tonne of policy and just
> > > let the user glue things together on their own is probably going to be
> > > more generally usable by existing and new systems.
> >
> > To elaborate a little bit, one of the reasons I'm loath to hide
> > complexity like transforms, colour management, and timing away in an
> > encapsulated lower layer, is because I have to expose all those
> > details anyway. Ultimately to make those work properly, we'll require
> > awareness not just in the compositor itself, but pushed through to
> > clients.
> >
> > Wayland already has facility for informing clients about output
> > transforms so they can render pre-rotated and avoid the
> > compositor-side transform; in order to make HDR and other colour
> > management (e.g. just simple calibration) properly we need to have
> > full plumbing back through to clients; doing timing properly,
> > particularly for multiple simultaneous clients, also requires a fair
> > bit of mechanics and back-and-forth.
> >
> > There's a lot that we could usefully share between all the users, and
> > having a shared library to help with that would be great. But the
> > thought of tucking it all away in an opaque layer which (*waves
> > hands*) just does it, gives me cold EGLStreams sweats.
> >
> > Maybe a good place to start is if we all listed the bits of code which
> > we'd be delighted to jettison?
>
> On the flipside, it would be nice to have one set of code to do
> modesets from userspace.  Certainly simplifies QA since in theory we
> should be seeing the same sequences from all apps using the helpers
> rather than every app rolling their own and getting it subtly
> different enough that strange things happen with different
> compositors.

For atomic drivers, and atomic userspace this really doesn't matter
anymore. Because userspace just assembles an overall update, and the
kernel applies that update no matter in which order userspace listed
the property/value/object triples.

It does somewhat matter for legacy kms (but not from a driver
validation pov, anything legacy can do can also be done as a legit
request through atomic), but I really can't care about that one much.
Imo better to just cut everyone over to atomic. The only thing that
might make sense is the fake atomic support, where userspace tries to
not be too dumb about a transition on drivers without atomic (i.e.
shut down crtcs first, then light up the new ones, to avoid in-between
state that oversubscribes available hw resources). But that's really a
niche thing.

> While we are on the topic, it would be nice to have a central place
> for robustness/context lost handling for compositors so we can
> properly handle GPU resets.  Not sure that is really possible though.

I think this blows up the scope too much and will break the project.
In the past there's been attempts at a libcompositor (and you need
that much to recover from context loss), and that never got anywhere
at all. I think the modular helpers approach has a much bigger chance
at success.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] drm/virtio: Export resource handles via DMA-buf API

2019-10-08 Thread Daniel Vetter
On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote:
> Hi Daniel, Gerd,
> 
> On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter  wrote:
> >
> > On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote:
> > > This patch is an early RFC to judge the direction we are following in
> > > our virtualization efforts in Chrome OS. The purpose is to start a
> > > discussion on how to handle buffer sharing between multiple virtio
> > > devices.
> > >
> > > On a side note, we are also working on a virtio video decoder interface
> > > and implementation, with a V4L2 driver for Linux. Those will be posted
> > > for review in the near future as well.
> > >
> > > Any feedback will be appreciated! Thanks in advance.
> > >
> > > ===
> > >
> > > With the range of use cases for virtualization expanding, there is going
> > > to be more virtio devices added to the ecosystem. Devices such as video
> > > decoders, encoders, cameras, etc. typically work together with the
> > > display and GPU in a pipeline manner, which can only be implemented
> > > efficiently by sharing the buffers between producers and consumers.
> > >
> > > Existing buffer management framework in Linux, such as the videobuf2
> > > framework in V4L2, implements all the DMA-buf handling inside generic
> > > code and do not expose any low level information about the buffers to
> > > the drivers.
> > >
> > > To seamlessly enable buffer sharing with drivers using such frameworks,
> > > make the virtio-gpu driver expose the resource handle as the DMA address
> > > of the buffer returned from the DMA-buf mapping operation. Arguably, the
> > > resource handle is a kind of DMA address already, as it is the buffer
> > > identifier that the device needs to access the backing memory, which is
> > > exactly the same role a DMA address provides for native devices.
> > >
> > > A virtio driver that does memory management fully on its own would have
> > > code similar to following. The code is identical to what a regular
> > > driver for real hardware would do to import a DMA-buf.
> > >
> > > static int virtio_foo_get_resource_handle(struct virtio_foo *foo,
> > > struct dma_buf *dma_buf, u32 *id)
> > > {
> > >   struct dma_buf_attachment *attach;
> > >   struct sg_table *sgt;
> > >   int ret = 0;
> > >
> > >   attach = dma_buf_attach(dma_buf, foo->dev);
> > >   if (IS_ERR(attach))
> > >   return PTR_ERR(attach);
> > >
> > >   sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
> > >   if (IS_ERR(sgt)) {
> > >   ret = PTR_ERR(sgt);
> > >   goto err_detach;
> > >   }
> > >
> > >   if (sgt->nents != 1) {
> > >   ret = -EINVAL;
> > >   goto err_unmap;
> > >   }
> > >
> > >   *id = sg_dma_address(sgt->sgl);
> >
> > I agree with Gerd, this looks pretty horrible to me.
> >
> > The usual way we've done these kind of special dma-bufs is:
> >
> > - They all get allocated at the same place, through some library or
> >   whatever.
> >
> > - You add a dma_buf_is_virtio(dma_buf) function, or maybe something that
> >   also upcasts or returns NULL, which checks for dma_buf->ops.
> >
> 
> Thanks for a lot of valuable feedback and sorry for the late reply.
> 
> While I agree that stuffing the resource ID in sg_dma_address() is
> quite ugly (for example, the regular address arithmetic doesn't work),
> I still believe we need to convey information about these buffers
> using regular kernel interfaces.
> 
> Drivers in some subsystems like DRM tend to open code any buffer
> management and then it wouldn't be any problem to do what you
> suggested. However, other subsystems have generic frameworks for
> buffer management, like videobuf2 for V4L2. Those assume regular
> DMA-bufs that can be handled with regular dma_buf_() API and described
> using sgtables and/or pfn vectors and/or DMA addresses.

"other subsystem sucks" doesn't sound like a good design paradigm to me.
Forced midlayers are a bad design decision isn't really new at all ...

> > - Once you've upcasted at runtime by checking for ->ops, you can add
> >   whatever fancy interfaces you want. Including a real interface to
> >   get at whatever underlying id you need to for real buffer sharing
> >

Re: [PATCH v2 1/3] drm/fb-helper: Synchronize dirty worker with vblank

2019-10-08 Thread Daniel Vetter
On Fri, Sep 27, 2019 at 10:41:43AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 17.09.19 um 15:06 schrieb Daniel Vetter:
> > On Thu, Sep 12, 2019 at 08:42:28AM +0200, Thomas Zimmermann wrote:
> > > Before updating the display from the console's shadow buffer, the dirty
> > > worker now waits for vblank. This allows several screen updates to pile
> > > up and acts as a rate limiter.
> > > 
> > > v2:
> > >   * don't hold helper->lock while waiting for vblank
> > > 
> > > Signed-off-by: Thomas Zimmermann 
> > > ---
> > >   drivers/gpu/drm/drm_fb_helper.c | 10 ++
> > >   1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index a7ba5b4902d6..d0cb1fa4f909 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -402,8 +402,18 @@ static void drm_fb_helper_dirty_work(struct 
> > > work_struct *work)
> > >   dirty_work);
> > >   struct drm_clip_rect *clip = >dirty_clip;
> > >   struct drm_clip_rect clip_copy;
> > > + struct drm_crtc *crtc;
> > >   unsigned long flags;
> > >   void *vaddr;
> > > + int ret;
> > > +
> > > + /* rate-limit update frequency */
> > > + crtc = helper->client.modesets[0].crtc;
> > > + ret = drm_crtc_vblank_get(crtc);
> > > + if (!ret) {
> > > + drm_crtc_wait_one_vblank(crtc);
> > 
> > Without the locking (specifically, preventing other masters) this can go
> > boom since it again calls drm_vblank_get. If someone turned of the display
> > meanwhile that will fail, and result in an unsightly WARN backtrace.
> > 
> > I think we need a __drm_crtc_wait_one_vblank(crtc); which requires that
> > callers hold a full vblank reference already. The other issue is that we
> > might race with the disabling and hit the timeout, which again gives us an
> > unsightly WARNING backtrace. Both can happen without locks (that's why the
> > ioctl path needs them), but we need to avoid.
> 
> Here's a status update: I've been working on this patch for a while, but the
> worker still cannot wait reliable for vblanks. When the worker runs, the
> display could be off and hence no vblank events occur. That's especially a
> problem during boot. The worker warns about missed vblanks because the
> console's video mode is still being programmed.

This sounds like a driver bug to me. If drm_crtc_vblank_get returns
successfully, vblanks are supposed to work. If that's not the case at load
time, then something with the vblank init has gone wrong somewhere (or
fbdev is set up too early).
-Daniel

> 

> Best regards
> Thomas
> 
> > -Daniel
> > > + drm_crtc_vblank_put(crtc);
> > > + }
> > >   spin_lock_irqsave(>dirty_lock, flags);
> > >   clip_copy = *clip;
> > > -- 
> > > 2.23.0
> > > 
> > 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
> HRB 21284 (AG Nürnberg)

-- 
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: [v4] drm: two planes with the same zpos have undefined ordering

2019-10-08 Thread Daniel Vetter
On Mon, Sep 30, 2019 at 10:07:07AM +0300, Pekka Paalanen wrote:
> On Sun, 29 Sep 2019 20:30:44 +
> Simon Ser  wrote:
> 
> > Hi,
> > 
> > > On Mon, Sep 23, 2019 at 12:39:20PM +, Simon Ser wrote:  
> > > > Currently the property docs don't specify whether it's okay for two 
> > > > planes to
> > > > have the same zpos value and what user-space should expect in this case.
> > > >
> > > > The rule mentionned in the past was to disambiguate with object IDs. 
> > > > However
> > > > some drivers break this rule (that's why the ordering is documented as
> > > > unspecified in case the zpos property is missing). Additionally it 
> > > > doesn't
> > > > really make sense for a driver to user identical zpos values if it 
> > > > knows their
> > > > relative position: the driver can just pick different values instead.
> > > >
> > > > So two solutions would make sense: either disallow completely identical 
> > > > zpos
> > > > values for two different planes, either make the ordering unspecified. 
> > > > To allow
> > > > drivers that don't know the relative ordering between two planes to 
> > > > still
> > > > expose the zpos property, choose the latter solution.  
> > >
> > > Some Arm's usage cases about two planes with same zpos.
> > >
> > > - "Smart layer"
> > > which can accepts 4 different fbs with different src/display rect,
> > > but this smart layer has one restriction:
> > >
> > > 4 display rects must have no overlaps in V direction
> > > (A optimization for android window like Toolbar/Navigation bar)
> > >
> > > So when map this Smart-layer to drm world, it might be 4 different
> > > drm-planes, but with same zorder to indicate that these 4 planes are
> > > smart-laye planes.
> > >
> > > - "VR-Layer"
> > > One VR-layer comprises two different viewports which can be configured
> > > with totoally different fbs, src/display rect.
> > > we use two differernt drm-planes to drive on HW "VR-Layer", and these
> > > two drm-planes must be configured with same zpos.  
> > 
> > Thanks a lot for your feedback James, that's exactly what I was looking for.
> > Both of these use-cases make sense to me.
> > 
> > I think user-space should be prepared to handle identical immutable zpos 
> > values.
> > Pekka and Daniel, thoughts?
> 
> Hi,
> 
> given those explained use cases, sure, I agree.
> 
> > In any case, this doesn't change the patch itself. Probably something worth
> > mentionning in the commit message.
> 
> Yes, recording these use cases would be very nice.

There's a lot more hw that does the same tricks (qualcom is one for sure).
Imo before we encode this we should make sure that:
a) everyone is happy with this new uapi
b) drivers are consistent
c) maybe even testcases in igt
d) definitely an open source user
e) no breaking of existing userspace

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

Re: [PATCH] drm: atomic helper: fix W=1 warnings

2019-10-08 Thread Daniel Vetter
ector_state *old_conn_state, *new_conn_state;
> > > > >   struct drm_crtc *crtc;
> > > > >   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > > > > @@ -1173,7 +1173,7 @@ crtc_set_mode(struct drm_device *dev, struct 
> > > > > drm_atomic_state *old_state)
> > > > >  {
> > > > >   struct drm_crtc *crtc;
> > > > >   struct drm_crtc_state *new_crtc_state;
> > > > > - struct drm_connector *connector;
> > > > > + struct drm_connector __maybe_unused *connector;
> > > > >   struct drm_connector_state *new_conn_state;
> > > > >   int i;
> > > > >
> > > > > @@ -1294,7 +1294,7 @@ void 
> > > > > drm_atomic_helper_commit_modeset_enables(struct drm_device *dev,
> > > > >   struct drm_crtc *crtc;
> > > > >   struct drm_crtc_state *old_crtc_state;
> > > > >   struct drm_crtc_state *new_crtc_state;
> > > > > - struct drm_connector *connector;
> > > > > + struct drm_connector __maybe_unused *connector;
> > > > >   struct drm_connector_state *new_conn_state;
> > > > >   int i;
> > > > >
> > > > > @@ -1384,7 +1384,7 @@ int drm_atomic_helper_wait_for_fences(struct 
> > > > > drm_device *dev,
> > > > > struct drm_atomic_state *state,
> > > > > bool pre_swap)
> > > > >  {
> > > > > - struct drm_plane *plane;
> > > > > + struct drm_plane __maybe_unused *plane;
> > > > >   struct drm_plane_state *new_plane_state;
> > > > >   int i, ret;
> > > > >
> > > > > @@ -1431,7 +1431,7 @@ drm_atomic_helper_wait_for_vblanks(struct 
> > > > > drm_device *dev,
> > > > >   struct drm_atomic_state *old_state)
> > > > >  {
> > > > >   struct drm_crtc *crtc;
> > > > > - struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > > > > + struct drm_crtc_state __maybe_unused *old_crtc_state, 
> > > > > *new_crtc_state;
> > > > >   int i, ret;
> > > > >   unsigned crtc_mask = 0;
> > > > >
> > > > > @@ -1621,7 +1621,7 @@ static void commit_work(struct work_struct 
> > > > > *work)
> > > > >  int drm_atomic_helper_async_check(struct drm_device *dev,
> > > > >  struct drm_atomic_state *state)
> > > > >  {
> > > > > - struct drm_crtc *crtc;
> > > > > + struct drm_crtc __maybe_unused *crtc;
> > > > >   struct drm_crtc_state *crtc_state;
> > > > >   struct drm_plane *plane = NULL;
> > > > >   struct drm_plane_state *old_plane_state = NULL;
> > > > > @@ -1982,9 +1982,9 @@ int drm_atomic_helper_setup_commit(struct 
> > > > > drm_atomic_state *state,
> > > > >  {
> > > > >   struct drm_crtc *crtc;
> > > > >   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > > > > - struct drm_connector *conn;
> > > > > + struct drm_connector __maybe_unused *conn;
> > > > >   struct drm_connector_state *old_conn_state, *new_conn_state;
> > > > > - struct drm_plane *plane;
> > > > > + struct drm_plane __maybe_unused *plane;
> > > > >   struct drm_plane_state *old_plane_state, *new_plane_state;
> > > > >   struct drm_crtc_commit *commit;
> > > > >   int i, ret;
> > > > > @@ -2214,7 +2214,7 @@ EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
> > > > >   */
> > > > >  void drm_atomic_helper_commit_hw_done(struct drm_atomic_state 
> > > > > *old_state)
> > > > >  {
> > > > > - struct drm_crtc *crtc;
> > > > > + struct drm_crtc __maybe_unused *crtc;
> > > > >   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> > > > >   struct drm_crtc_commit *commit;
> > > > >   int i;
> > > > > @@ -2300,7 +2300,7 @@ 
> > > > > EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
> > > > >  int drm_atomic_helper_prepare_planes(struct drm_device *dev,
> > > > >struct drm_atomic_state *state)
> > > > >  {
> > > > > - struct drm_connector *connector;
> > > > > + struct drm_connector __maybe_unused *connector;
> > > > >   struct drm_connector_state *new_conn_state;
> > > > >   struct drm_plane *plane;
> > > > >   struct drm_plane_state *new_plane_state;
> > > > > @@ -2953,9 +2953,9 @@ int drm_atomic_helper_disable_all(struct 
> > > > > drm_device *dev,
> > > > >  {
> > > > >   struct drm_atomic_state *state;
> > > > >   struct drm_connector_state *conn_state;
> > > > > - struct drm_connector *conn;
> > > > > + struct drm_connector __maybe_unused *conn;
> > > > >   struct drm_plane_state *plane_state;
> > > > > - struct drm_plane *plane;
> > > > > + struct drm_plane __maybe_unused *plane;
> > > > >   struct drm_crtc_state *crtc_state;
> > > > >   struct drm_crtc *crtc;
> > > > >   int ret, i;
> > > > > @@ -3199,11 +3199,11 @@ int 
> > > > > drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state 
> > > > > *state,
> > > > >  {
> > > > >   int i, ret;
> > > > >   struct drm_plane *plane;
> > > > > - struct drm_plane_state *new_plane_state;
> > > > > + struct drm_plane_state __maybe_unused *new_plane_state;
> > > > >   struct drm_connector *connector;
> > > > > - struct drm_connector_state *new_conn_state;
> > > > > + struct drm_connector_state __maybe_unused *new_conn_state;
> > > > >   struct drm_crtc *crtc;
> > > > > - struct drm_crtc_state *new_crtc_state;
> > > > > + struct drm_crtc_state __maybe_unused *new_crtc_state;
> > > > >
> > > > >   state->acquire_ctx = ctx;
> > > > >
> > > > > --
> > > > > 2.15.0
> > > > >
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> >
> > --
> > Ville Syrjälä
> > Intel

-- 
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] drm: damage_helper: Fix race checking plane->state->fb

2019-10-08 Thread Daniel Vetter
On Thu, Sep 19, 2019 at 11:04:01AM -0400, Sean Paul wrote:
> On Thu, Sep 05, 2019 at 12:41:27PM +0200, Daniel Vetter wrote:
> > On Wed, Sep 4, 2019 at 10:29 PM Sean Paul  wrote:
> > >
> > > From: Sean Paul 
> > >
> > > Since the dirtyfb ioctl doesn't give us any hints as to which plane is
> > > scanning out the fb it's marking as damaged, we need to loop through
> > > planes to find it.
> > >
> > > Currently we just reach into plane state and check, but that can race
> > > with another commit changing the fb out from under us. This patch locks
> > > the plane before checking the fb and will release the lock if the plane
> > > is not displaying the dirty fb.
> > >
> > > Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb")
> > > Cc: Rob Clark 
> > > Cc: Deepak Rawat 
> > > Cc: Daniel Vetter 
> > > Cc: Thomas Hellstrom 
> > > Cc: Maarten Lankhorst 
> > > Cc: Maxime Ripard 
> > > Cc: Sean Paul 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc:  # v5.0+
> > > Reported-by: Daniel Vetter 
> > > Signed-off-by: Sean Paul 
> > > ---
> > >  drivers/gpu/drm/drm_damage_helper.c | 8 +++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_damage_helper.c 
> > > b/drivers/gpu/drm/drm_damage_helper.c
> > > index 8230dac01a89..3a4126dc2520 100644
> > > --- a/drivers/gpu/drm/drm_damage_helper.c
> > > +++ b/drivers/gpu/drm/drm_damage_helper.c
> > > @@ -212,8 +212,14 @@ int drm_atomic_helper_dirtyfb(struct drm_framebuffer 
> > > *fb,
> > > drm_for_each_plane(plane, fb->dev) {
> > > struct drm_plane_state *plane_state;
> > >
> > > -   if (plane->state->fb != fb)
> > > +   ret = drm_modeset_lock(>mutex, state->acquire_ctx);
> > > +   if (ret)
> > 
> > I think for paranoid safety we should have a WARN_ON(ret == -EALREADY)
> > here. It should be impossible, but if it's not for some oddball
> > reason, we'll blow up.
> 
> drm_modeset_lock eats EALREADY and returns 0 for that case, so I guess it
> depends _how_ paranoid you want to be here :-)

Ah silly me, r-b as-is then.
-Daniel

> 
> > 
> > With that: Reviewed-by: Daniel Vetter 
> > 
> > But please give this a spin with some workloads and the ww_mutex
> > slowpath debugging enabled, just to makre sure.
> 
> Ok, had a chance to run through some tests this morning with
> CONFIG_DEBUG_WW_MUTEX_SLOWPATH and things lgtm
> 
> Sean
> 
> > -Daniel
> > 
> > > +   goto out;
> > > +
> > > +   if (plane->state->fb != fb) {
> > > +   drm_modeset_unlock(>mutex);
> > > continue;
> > > +   }
> > >
> > > plane_state = drm_atomic_get_plane_state(state, plane);
> > > if (IS_ERR(plane_state)) {
> > > --
> > > Sean Paul, Software Engineer, Google / Chromium OS
> > >
> > 
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH v2 03/27] drm/dp_mst: Destroy MSTBs asynchronously

2019-10-08 Thread Daniel Vetter
On Fri, Sep 27, 2019 at 09:31:07AM -0400, Sean Paul wrote:
> On Wed, Sep 25, 2019 at 04:08:22PM -0400, Lyude Paul wrote:
> > On Wed, 2019-09-25 at 14:16 -0400, Sean Paul wrote:
> > > On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote:
> > > > When reprobing an MST topology during resume, we have to account for the
> > > > fact that while we were suspended it's possible that mstbs may have been
> > > > removed from any ports in the topology. Since iterating downwards in the
> > > > topology requires that we hold >lock, destroying MSTBs from this
> > > > context would result in attempting to lock >lock a second time and
> > > > deadlocking.
> > > > 
> > > > So, fix this by first moving destruction of MSTBs into
> > > > destroy_connector_work, then rename destroy_connector_work and friends
> > > > to reflect that they now destroy both ports and mstbs.
> > > > 
> > > > Changes since v1:
> > > > * s/destroy_connector_list/destroy_port_list/
> > > >   s/connector_destroy_lock/delayed_destroy_lock/
> > > >   s/connector_destroy_work/delayed_destroy_work/
> > > >   s/drm_dp_finish_destroy_branch_device/drm_dp_delayed_destroy_mstb/
> > > >   s/drm_dp_finish_destroy_port/drm_dp_delayed_destroy_port/
> > > >   - danvet
> > > > * Use two loops in drm_dp_delayed_destroy_work() - danvet
> > > > * Better explain why we need to do this - danvet
> > > > * Use cancel_work_sync() instead of flush_work() - flush_work() doesn't
> > > >   account for work requeing
> > > > 
> > > > Cc: Juston Li 
> > > > Cc: Imre Deak 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Harry Wentland 
> > > > Cc: Daniel Vetter 
> > > > Signed-off-by: Lyude Paul 
> > > 
> > > Took me a while to grok this, and I'm still not 100% confident my mental
> > > model
> > > is correct, so please bear with me while I ask silly questions :)
> > > 
> > > Now that the destroy is delayed, and the port remains in the topology, is 
> > > it
> > > possible we will underflow the topology kref by calling put_mstb multiple
> > > times?
> > > It looks like that would result in a WARN from refcount.c, and wouldn't 
> > > call
> > > the
> > > destroy function multiple times, so that's nice :)
> > > 
> > > Similarly, is there any defense against calling get_mstb() between 
> > > destroy()
> > > and
> > > the delayed destroy worker running?
> > > 
> > Good question! There's only one instance where we unconditionally grab an 
> > MSTB
> > ref, drm_dp_mst_topology_mgr_set_mst(), and in that location we're 
> > guaranteed
> > to be the only one with access to that mstb until we drop >lock.
> > Everywhere else we use drm_dp_mst_topology_try_get_mstb(), which uses
> > kref_get_unless_zero() to protect against that kind of situation (and forces
> > the caller to check with __must_check)

Imo would be good to add this to the commit message when merging as a Q,
just for the record. At least I like to do that with the
silly-but-no-so-silly questions that come up in review.
-Daniel

> 
> Awesome, thanks for the breakdown!
> 
> 
> Reviewed-by: Sean Paul 
> 
> 
> > 
> > > Sean
> > > 
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 162 +-
> > > >  include/drm/drm_dp_mst_helper.h   |  26 +++--
> > > >  2 files changed, 127 insertions(+), 61 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index 3054ec622506..738f260d4b15 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -1113,34 +1113,17 @@ static void
> > > > drm_dp_destroy_mst_branch_device(struct kref *kref)
> > > > struct drm_dp_mst_branch *mstb =
> > > > container_of(kref, struct drm_dp_mst_branch, 
> > > > topology_kref);
> > > > struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> > > > -   struct drm_dp_mst_port *port, *tmp;
> > > > -   bool wake_tx = false;
> > > >  
> > > > -   mutex_lock(>lock);
> > > > -   list_for_each_entry_safe(port, tmp, >ports, next) {
> > > > -   list_

Re: [PATCH v2 00/21] drm/dp: Various helper improvements and cleanups

2019-10-08 Thread Daniel Vetter
t; > 
> > Again, if you've got all of this implemented in i915 (or any of the
> > other "big" drivers), you probably want to stay away from these. But
> > does that mean everyone else has to go and figure all of this out from
> > scratch? Shouldn't we at least attempt to write common code? Or should
> > we all go and write our own DP stacks like the big drivers? I don't see
> > any advantage in that.
> > 
> > > If we get a confirmation from our drm overlords that drivers doing
> > > things the way they see fit in this regard is fine, then I'm okay with
> > > this. But I'm definitely not committing to switching to using the
> > > drm_dp_link structures and helpers in i915, quite the opposite actually.
> > 
> > I don't think anyone's going to force you to convert to the drm_dp_link
> > helpers if you don't want to. It's definitely not my intention to make
> > this "The One And Only Way To Do DP in DRM". The goal here is to create
> > helpers that can simplify adding DP support.
> > 
> > Now, if everyone else thinks the drm_dp_link helpers are a bad idea, I
> > will get over it and move this into Tegra code. But since we're being
> > blunt, I'd like to get a third (and ideally fourth) opinion on whether
> > we really want this stuff to be reinvented in every driver or whether
> > we want to try and come up with something that works for more than one
> > driver.
> > 
> > Thierry
> > 
> > > BR,
> > > Jani.
> > > 
> > > 
> > > (*) Please don't read too much into "small" and "big", just two groups
> > > of drivers handling things differently.
> 
> Dave, Daniel,
> 
> how can we make progress on this? Is it okay to go forward with this
> series if we agree that it's not going to be required for drivers to
> adopt it if they already have a working DP implementation?
> 
> If we can't agree on the struct drm_dp_link helpers, perhaps I should go
> and at least merge the additional DPCD parsing helpers. Those are very
> much in line with existing helpers. I could then move the drm_dp_link
> helpers into the Tegra driver and add replacement code to the other
> drivers that already use struct drm_dp_link. It'd be a shame to
> duplicate the code, but I'm willing to invest that additional work so
> that I can finally make progress on this series and the Tegra DP support
> that depends on this.

I ... don't know.

In general I think helpers are totally ok with being optional (that's the
point after all), but not for color choice reasons. And from very much
afar this feels a bit like that.

I also think that if we want smaller helpers for simpler drivers, it's
better to build that on top of the full-featured helpers and dumb them
down. This worked very well for simple display pipe (built on top of
atomic helpers) and simple vram support (built on top of ttm). Having two
distinct set of helpers for small and big drivers seems wrong.

I also think that the functions/control-flow/callbacks are the important
part of helpers, not really the data structures. Just having common
data structures gives you as much a mess as having a pile of
distinct implementations.

Aside from all these generic thoughts on helpers, for dp specifically I
think the proof of the pudding is in how it integrates with mst. If we
have dp helpers that work for mst (the mst vs sst case decision and
transitions are especially nasty in all drivers), then we can dumb it down
for simple drivers and modularize it for special cases like we do with
other helpers. Without that I fear we're just ending up in a dead-end (but
won't realize it until it's too late).

Finally I'm ok with no helpers in areas where we haven't figured out a
good solution yet. Bunch of copypasta is imo better than going the wrong
way collectively (since it prevents the experiments that might shine a
light on better solutions).

tldr; Still don't know.

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

Re: [PATCH 2/4] drm/ttm: use the parent resv for ghost objects v2

2019-10-08 Thread Daniel Vetter
On Thu, Aug 29, 2019 at 04:29:15PM +0200, Christian König wrote:
> This way we can even pipeline imported BO evictions.
> 
> v2: Limit this to only cases when the parent object uses a separate
> reservation object as well. This fixes another OOM problem.
> 
> Signed-off-by: Christian König 

Since I read quite a bit of ttm I figured I'll review this too, but I'm
totally lost. And git blame gives me at best commits with one-liner commit
messages, and the docs aren't explaining much at all either (and generally
they didn't get updated at all with all the changes in the past years). 

I have a vague idea of what you're doing here, but not enough to do review
with any confidence. And from other ttm patches from amd it feels a lot
like we have essentially a bus factor of 1 for all things ttm :-/
-Daniel

> ---
>  drivers/gpu/drm/ttm/ttm_bo_util.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index fe81c565e7ef..2ebe9fe7f6c8 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -517,7 +517,9 @@ static int ttm_buffer_object_transfer(struct 
> ttm_buffer_object *bo,
>   kref_init(>base.kref);
>   fbo->base.destroy = _transfered_destroy;
>   fbo->base.acc_size = 0;
> - fbo->base.base.resv = >base.base._resv;
> + if (bo->base.resv == >base._resv)
> + fbo->base.base.resv = >base.base._resv;
> +
>   dma_resv_init(fbo->base.base.resv);
>   ret = dma_resv_trylock(fbo->base.base.resv);
>   WARN_ON(!ret);
> @@ -716,7 +718,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object 
> *bo,
>   if (ret)
>   return ret;
>  
> - dma_resv_add_excl_fence(ghost_obj->base.resv, fence);
> + dma_resv_add_excl_fence(_obj->base._resv, fence);
>  
>   /**
>* If we're not moving to fixed memory, the TTM object
> @@ -729,7 +731,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object 
> *bo,
>   else
>   bo->ttm = NULL;
>  
> - ttm_bo_unreserve(ghost_obj);
> + dma_resv_unlock(_obj->base._resv);
>   ttm_bo_put(ghost_obj);
>   }
>  
> @@ -772,7 +774,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
>   if (ret)
>   return ret;
>  
> - dma_resv_add_excl_fence(ghost_obj->base.resv, fence);
> + dma_resv_add_excl_fence(_obj->base._resv, fence);
>  
>   /**
>* If we're not moving to fixed memory, the TTM object
> @@ -785,7 +787,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
>   else
>   bo->ttm = NULL;
>  
> - ttm_bo_unreserve(ghost_obj);
> + dma_resv_unlock(_obj->base._resv);
>   ttm_bo_put(ghost_obj);
>  
>   } else if (from->flags & TTM_MEMTYPE_FLAG_FIXED) {
> @@ -841,7 +843,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
>   if (ret)
>   return ret;
>  
> - ret = dma_resv_copy_fences(ghost->base.resv, bo->base.resv);
> + ret = dma_resv_copy_fences(>base._resv, bo->base.resv);
>   /* Last resort, wait for the BO to be idle when we are OOM */
>   if (ret)
>   ttm_bo_wait(bo, false, false);
> @@ -850,7 +852,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
>   bo->mem.mem_type = TTM_PL_SYSTEM;
>   bo->ttm = NULL;
>  
> - ttm_bo_unreserve(ghost);
> + dma_resv_unlock(>base._resv);
>   ttm_bo_put(ghost);
>  
>   return 0;
> -- 
> 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/4] dma-buf: change DMA-buf locking convention

2019-10-08 Thread Daniel Vetter
On Wed, Oct 02, 2019 at 08:37:50AM +, Koenig, Christian wrote:
> Hi Daniel,
> 
> once more a ping on this. Any more comments or can we get it comitted?

Sorry got a bit smashed past weeks, but should be resurrected now back
from xdc.
-Daniel
> 
> Thanks,
> Christian.
> 
> Am 24.09.19 um 11:50 schrieb Christian König:
> > Am 17.09.19 um 16:56 schrieb Daniel Vetter:
> >> [SNIP]
> >>>>>>>>>>>>   +    /* When either the importer or the exporter 
> >>>>>>>>>>>> can't handle dynamic
> >>>>>>>>>>>> + * mappings we cache the mapping here to avoid issues 
> >>>>>>>>>>>> with the
> >>>>>>>>>>>> + * reservation object lock.
> >>>>>>>>>>>> + */
> >>>>>>>>>>>> +    if (dma_buf_attachment_is_dynamic(attach) !=
> >>>>>>>>>>>> +    dma_buf_is_dynamic(dmabuf)) {
> >>>>>>>>>>>> +    struct sg_table *sgt;
> >>>>>>>>>>>> +
> >>>>>>>>>>>> +    if (dma_buf_is_dynamic(attach->dmabuf))
> >>>>>>>>>>>> + dma_resv_lock(attach->dmabuf->resv, NULL);
> >>>>>>>>>>>> +
> >>>>>>>>>>>> +    sgt = dmabuf->ops->map_dma_buf(attach, 
> >>>>>>>>>>>> DMA_BIDIRECTIONAL);
> >>>>>>>>>>> Now we're back to enforcing DMA_BIDI, which works nicely 
> >>>>>>>>>>> around the
> >>>>>>>>>>> locking pain, but apparently upsets the arm-soc folks who 
> >>>>>>>>>>> want to
> >>>>>>>>>>> control
> >>>>>>>>>>> this better.
> >>>>>>>>>> Take another look at dma_buf_map_attachment(), we still try 
> >>>>>>>>>> to get the
> >>>>>>>>>> caching there for ARM.
> >>>>>>>>>>
> >>>>>>>>>> What we do here is to bidirectionally map the buffer to avoid 
> >>>>>>>>>> the
> >>>>>>>>>> locking hydra when importer and exporter disagree on locking.
> >>>>>>>>>>
> >>>>>>>>>> So the ARM folks can easily avoid that by switching to 
> >>>>>>>>>> dynamic locking
> >>>>>>>>>> for both.
> >>>>>>>> So you still break the contract between importer and exporter, 
> >>>>>>>> except not
> >>>>>>>> for anything that's run in intel-gfx-ci so all is good?
> >>>>>>> No, the contract between importer and exporter stays exactly the 
> >>>>>>> same it
> >>>>>>> is currently as long as you don't switch to dynamic dma-buf 
> >>>>>>> handling.
> >>>>>>>
> >>>>>>> There is no functional change for the ARM folks here. The only 
> >>>>>>> change
> >>>>>>> which takes effect is between i915 and amdgpu and that is perfectly
> >>>>>>> covered by intel-gfx-ci.
> >>>>>> There's people who want to run amdgpu on ARM?
> >>>>> Sure there are, we even recently fixed some bugs for this.
> >>>>>
> >>>>> But as far as I know there is no one currently which is affect by 
> >>>>> this
> >>>>> change on ARM with amdgpu.
> >>>> But don't you break them with this now?
> >>> No, we see the bidirectional attachment as compatible with the other 
> >>> ones.
> >>>
> >>>> amdgpu will soon set the dynamic flag on exports, which forces the 
> >>>> caching
> >>>> at create time (to avoid the locking fun), which will then result in a
> >>>> EBUSY at map_attachment time because we have a cached mapping, but 
> >>>> it's
> >>>> the wrong type.
> >>> See the check in dma_buf_map_attachment():
> >>>
> >>>   if (attach->dir != direction && attach->dir != DMA_BIDIRECTIONAL)
> >>>   return ERR_PTR(-EBUSY);
> >> Hm, I misread this. So yeah should work, +/- the issue that we might
> >> not flush enough. But I guess that can be fixed whenever, it's not
> >> like dma-api semantics are a great fit for us. Maybe a fixme comment
> >> would be useful here ... I'll look at this tomorrow or so because atm
> >> brain is slow, I'm down with the usual post-conference cold it seems
> >> :-/
> >
> > Hope your are feeling better now, adding a comment is of course not a 
> > problem.
> >
> > With that fixed can I get an reviewed-by or at least and acked-by?
> >
> > I want to land at least some parts of those changes now.
> >
> > Regards,
> > Christian.
> >
> >> -Daniel
> >>
> >
> 

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

Re: [PATCH 1/4] dma-buf: change DMA-buf locking convention

2019-10-08 Thread Daniel Vetter
  */

Please add a note that this is an cache_sgt_mapping are exlusive.

> + bool dynamic_mapping;
> +
>   /**
>* @attach:
>*
> @@ -109,6 +120,9 @@ struct dma_buf_ops {
>* any other kind of sharing that the exporter might wish to make
>* available to buffer-users.
>*
> +  * This is always called with the dmabuf->resv object locked when
> +  * the dynamic_mapping flag is true.
> +  *
>* Returns:
>*
>* A _table scatter list of or the backing storage of the DMA buffer,
> @@ -327,6 +341,8 @@ struct dma_buf {
>   * @sgt: cached mapping.
>   * @dir: direction of cached mapping.
>   * @priv: exporter specific attachment data.
> + * @dynamic_mapping: true if dma_buf_map/unmap_attachment() is called with 
> the
> + * dma_resv lock held.
>   *
>   * This structure holds the attachment information between the dma_buf buffer
>   * and its user device(s). The list contains one attachment struct per device
> @@ -343,6 +359,7 @@ struct dma_buf_attachment {
>   struct list_head node;
>   struct sg_table *sgt;
>   enum dma_data_direction dir;
> + bool dynamic_mapping;
>   void *priv;
>  };
>  
> @@ -394,10 +411,39 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
>   get_file(dmabuf->file);
>  }
>  
> +/**
> + * dma_buf_is_dynamic - check if a DMA-buf uses dynamic mappings.
> + * @dmabuf: the DMA-buf to check
> + *
> + * Returns true if a DMA-buf exporter wants to be called with the dma_resv
> + * locked, false if it doesn't wants to be called with the lock held.
> + */
> +static inline bool dma_buf_is_dynamic(struct dma_buf *dmabuf)
> +{
> + return dmabuf->ops->dynamic_mapping;
> +}
> +
> +/**
> + * dma_buf_attachment_is_dynamic - check if a DMA-buf attachment uses dynamic
> + * mappinsg
> + * @attach: the DMA-buf attachment to check
> + *
> + * Returns true if a DMA-buf importer wants to call the map/unmap functions 
> with
> + * the dma_resv lock held.
> + */
> +static inline bool
> +dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach)
> +{
> + return attach->dynamic_mapping;
> +}
> +
>  struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> -     struct device *dev);
> +   struct device *dev);
> +struct dma_buf_attachment *
> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> +bool dynamic_mapping);
>  void dma_buf_detach(struct dma_buf *dmabuf,
> - struct dma_buf_attachment *dmabuf_attach);
> + struct dma_buf_attachment *attach);
>  
>  struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info);
>  
> @@ -409,6 +455,7 @@ struct sg_table *dma_buf_map_attachment(struct 
> dma_buf_attachment *,
>   enum dma_data_direction);
>  void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
>   enum dma_data_direction);
> +void dma_buf_move_notify(struct dma_buf *dma_buf);
>  int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
>enum dma_data_direction dir);
>  int dma_buf_end_cpu_access(struct dma_buf *dma_buf,

Aside from the nits here I think this is ok, count me convinced on
principle.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: DRM_MODE_CONNECTOR_PANEL? [Was: drm/panel: Add and fill drm_panel type field]

2019-10-08 Thread Daniel Vetter
On Fri, Sep 27, 2019 at 05:28:03PM +0300, Tomi Valkeinen wrote:
> On 27/09/2019 15:44, Daniel Stone wrote:
> > Hi Linus,
> > 
> > On Fri, 27 Sep 2019 at 13:37, Linus Walleij  
> > wrote:
> > > Also the ILI9322 can actually set up gamma correction which is
> > > very nice for professional applications. I haven't seen any way for
> > > DRM to do gamma correction properly or any framework for it
> > > to adjust and propagate gamma to/from userspace (seems like
> > > another enormous task), but I am pretty sure it will be there one
> > > of these days so I put in some comments and placeholders.
> > 
> > Gamma correction has been supported since approximately the dawn of
> > time with a 3x8-bit LUT.
> 
> But, afaik, only in the display controller side. I don't think we have means
> to have any properties for the panels or bridges.

I guess would need some semi-elaborate negotiation dance to make sure you
only correct in either the bridge/panel or in the crtc, but should be
doable. I don't think we need a new property or change anything with the
uapi here, just kernel internals.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-misc-fixes

2019-10-07 Thread Daniel Vetter
On Thu, Oct 3, 2019 at 9:26 AM Maxime Ripard  wrote:
>
> Hi,
>
> On Wed, Oct 02, 2019 at 10:06:04PM +0200, Maxime Ripard wrote:
> > Hi Dave, Daniel,
> >
> > I hope that you enjoy XDC if you could make it this year :)
> >
> > Here's the first round of fixes for drm-misc
> >
> > Maxime
> >
> > drm-misc-fixes-2019-10-02:
> >  - One include fix for tilcdc
> >  - A memory leak fix for Komeda
> >  - Some fixes for resources cleanups with writeback
>
> So it turns out that while that tag was pushed, I forgot to push the
> branch first, and now we have a conflict.
>
> Let's drop this PR, I'll do another one.

Hm, does dim not check for that? Can I volunteer you for a patch?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf/resv: fix exclusive fence get

2019-09-30 Thread Daniel Vetter
On Sun, Sep 22, 2019 at 2:08 PM Qiang Yu  wrote:
>
> This causes kernel crash when testing lima driver.
>
> Cc: Christian König 
> Fixes: b8c036dfc66f ("dma-buf: simplify reservation_object_get_fences_rcu a 
> bit")
> Signed-off-by: Qiang Yu 

Selftest for this would be lovely, now that the basic infrastructure
is in place ...
-Daniel

> ---
>  drivers/dma-buf/dma-resv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 42a8f3f11681..709002515550 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -471,7 +471,7 @@ int dma_resv_get_fences_rcu(struct dma_resv *obj,
> if (pfence_excl)
> *pfence_excl = fence_excl;
> else if (fence_excl)
> -   shared[++shared_count] = fence_excl;
> +   shared[shared_count++] = fence_excl;
>
> if (!shared_count) {
> kfree(shared);
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Re: [PATCH 01/36] drm/fourcc: Add 2 plane YCbCr 10bit format support

2019-09-25 Thread Daniel Vetter
On Tue, Sep 24, 2019 at 8:46 AM sandy.huang  wrote:
>
>
> 在 2019/9/23 下午9:06, Daniel Vetter 写道:
> > On Mon, Sep 23, 2019 at 2:40 PM Sandy Huang  wrote:
> >> The drm_format_info.cpp[3] unit is BytePerPlane, when we add define
> >> 10bit YUV format, here have some problem.
> >> So we change cpp to bpp, use unit BitPerPlane to describe the data
> >> format.
> >>
> >> Signed-off-by: Sandy Huang 
> > Whatever the layout you have for these (it's not really defined in
> > your patch here down to the level of detail we want) I think this
> > should be described with the block_h/w and char_per_block
> > functionality. Not by extending the legacy and depcrecated cpp
> > somehow.
> > -Daniel
>
> Hi Daniel,
>
> It seems the char_per_block and block_h/w can't describing the following
> data format:
>
> /*
>   * 2x2 subsampled Cr:Cb plane 10 bits per channel
>   * index 0 = Y plane, [9:0]
>   * index 1 = Cr:Cb plane, [19:0] Cr:x:Cb:x [19:0]
>   */

We can't allocate individual bits, buffers are always at least byte
aligned. And once you have that, you can actually do that.

Or maybe this is a lot more funnier format, which has aven
non-byte-aligned strides. Which would be rather surprising.

Anyway either needs a lot more comments, or just need to use the
infrastructure we have already. E.g. for your case: 4 pixels with 10
bits each gives you 5*8 = 40 bits of 5 bytes. So you very much can
describe this format accurately with the block layout stuff, with a
block size of 4 pixels wide and 1 pixel height and a byte size per
block of 5 bytes. Similar for the others.
-Daniel

>
> >> ---
> >>   drivers/gpu/drm/drm_client.c|   4 +-
> >>   drivers/gpu/drm/drm_fb_helper.c |   8 +-
> >>   drivers/gpu/drm/drm_format_helper.c |   4 +-
> >>   drivers/gpu/drm/drm_fourcc.c| 172 
> >> +++-
> >>   drivers/gpu/drm/drm_framebuffer.c   |   2 +-
> >>   include/drm/drm_fourcc.h|   4 +-
> >>   include/uapi/drm/drm_fourcc.h   |  15 
> >>   7 files changed, 115 insertions(+), 94 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> >> index d9a2e36..a36ffbe 100644
> >> --- a/drivers/gpu/drm/drm_client.c
> >> +++ b/drivers/gpu/drm/drm_client.c
> >> @@ -263,7 +263,7 @@ drm_client_buffer_create(struct drm_client_dev 
> >> *client, u32 width, u32 height, u
> >>
> >>  dumb_args.width = width;
> >>  dumb_args.height = height;
> >> -   dumb_args.bpp = info->cpp[0] * 8;
> >> +   dumb_args.bpp = info->bpp[0];
> >>  ret = drm_mode_create_dumb(dev, _args, client->file);
> >>  if (ret)
> >>  goto err_delete;
> >> @@ -366,7 +366,7 @@ static int drm_client_buffer_addfb(struct 
> >> drm_client_buffer *buffer,
> >>  int ret;
> >>
> >>  info = drm_format_info(format);
> >> -   fb_req.bpp = info->cpp[0] * 8;
> >> +   fb_req.bpp = info->bpp[0];
> >>  fb_req.depth = info->depth;
> >>  fb_req.width = width;
> >>  fb_req.height = height;
> >> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> >> b/drivers/gpu/drm/drm_fb_helper.c
> >> index a7ba5b4..b30e782 100644
> >> --- a/drivers/gpu/drm/drm_fb_helper.c
> >> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >> @@ -382,7 +382,7 @@ static void drm_fb_helper_dirty_blit_real(struct 
> >> drm_fb_helper *fb_helper,
> >>struct drm_clip_rect *clip)
> >>   {
> >>  struct drm_framebuffer *fb = fb_helper->fb;
> >> -   unsigned int cpp = fb->format->cpp[0];
> >> +   unsigned int cpp = fb->format->bpp[0] / 8;
> >>  size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
> >>  void *src = fb_helper->fbdev->screen_buffer + offset;
> >>  void *dst = fb_helper->buffer->vaddr + offset;
> >> @@ -1320,14 +1320,14 @@ int drm_fb_helper_check_var(struct 
> >> fb_var_screeninfo *var,
> >>   * Changes struct fb_var_screeninfo are currently not pushed back
> >>   * to KMS, hence fail if different settings are requested.
> >>   */
> >> -   if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
> >> +   if (var->bits_per_pixel != fb->format->bpp[0] ||
> >>  var->xres > fb->widt

Re: [PATCH 1/3] drm: Add some new format DRM_FORMAT_NVXX_10

2019-09-25 Thread Daniel Vetter
On Wed, Sep 25, 2019 at 10:07 AM Sandy Huang  wrote:
>
> These new format is supported by some rockchip socs:
>
> DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
> DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
> DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
>
> Signed-off-by: Sandy Huang 

Again, please use the block formats to describe these, plus proper
comments as Maarten also asked for.
-Daniel

> ---
>  drivers/gpu/drm/drm_fourcc.c  | 18 ++
>  include/uapi/drm/drm_fourcc.h | 14 ++
>  2 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index c630064..f25fa81 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -274,6 +274,24 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
> { .format = DRM_FORMAT_YUV420_10BIT,.depth = 0,
>   .num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
>   .is_yuv = true },
> +   { .format = DRM_FORMAT_NV12_10, .depth = 0,
> + .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
> + .is_yuv = true },
> +   { .format = DRM_FORMAT_NV21_10, .depth = 0,
> + .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
> + .is_yuv = true },
> +   { .format = DRM_FORMAT_NV16_10, .depth = 0,
> + .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 1,
> + .is_yuv = true },
> +   { .format = DRM_FORMAT_NV61_10, .depth = 0,
> + .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 1,
> + .is_yuv = true },
> +   { .format = DRM_FORMAT_NV24_10, .depth = 0,
> + .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 1, .vsub = 1,
> + .is_yuv = true },
> +   { .format = DRM_FORMAT_NV42_10, .depth = 0,
> + .num_planes = 2, .cpp = { 0, 0, 0 }, .hsub = 1, .vsub = 1,
> + .is_yuv = true },
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3..0479f47 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -238,6 +238,20 @@ extern "C" {
>  #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
> non-subsampled Cb:Cr plane */
>
>  /*
> + * 2 plane YCbCr 10bit
> + * index 0 = Y plane, [9:0] Y
> + * index 1 = Cr:Cb plane, [19:0]
> + * or
> + * index 1 = Cb:Cr plane, [19:0]
> + */
> +#define DRM_FORMAT_NV12_10 fourcc_code('N', 'A', '1', '2') /* 2x2 
> subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV21_10 fourcc_code('N', 'A', '2', '1') /* 2x2 
> subsampled Cb:Cr plane */
> +#define DRM_FORMAT_NV16_10 fourcc_code('N', 'A', '1', '6') /* 2x1 
> subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV61_10 fourcc_code('N', 'A', '6', '1') /* 2x1 
> subsampled Cb:Cr plane */
> +#define DRM_FORMAT_NV24_10 fourcc_code('N', 'A', '2', '4') /* 
> non-subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV42_10 fourcc_code('N', 'A', '4', '2') /* 
> non-subsampled Cb:Cr plane */
> +
> +/*
>   * 2 plane YCbCr MSB aligned
>   * index 0 = Y plane, [15:0] Y:x [10:6] little endian
>   * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
> --
> 2.7.4
>
>
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Re: [PATCH] drm/rockchip: Add AFBC support

2019-09-25 Thread Daniel Vetter
IN_SET(vop, win, format, format);
> >   VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
> >   VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
> > @@ -1163,6 +1248,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc 
> > *crtc,
> >
> >   spin_lock(>reg_lock);
> >
> > + VOP_AFBC_SET(vop, enable, vop->afbc_win ? 0x1 : 0);
> >   vop_cfg_done(vop);
> >
> >   spin_unlock(>reg_lock);
> > @@ -1471,7 +1557,8 @@ static int vop_create_crtc(struct vop *vop)
> >  0, _plane_funcs,
> >  win_data->phy->data_formats,
> >  win_data->phy->nformats,
> > -NULL, win_data->type, NULL);
> > +
> > win_data->phy->format_modifiers,
> > +win_data->type, NULL);
> >   if (ret) {
> >   DRM_DEV_ERROR(vop->dev, "failed to init plane %d\n",
> > ret);
> > @@ -1511,7 +1598,8 @@ static int vop_create_crtc(struct vop *vop)
> >  _plane_funcs,
> >  win_data->phy->data_formats,
> >  win_data->phy->nformats,
> > -NULL, win_data->type, NULL);
> > +
> > win_data->phy->format_modifiers,
> > +win_data->type, NULL);
> >   if (ret) {
> >   DRM_DEV_ERROR(vop->dev, "failed to init overlay %d\n",
> > ret);
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > index 2149a889c29d..dc8b12025269 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > @@ -77,6 +77,16 @@ struct vop_misc {
> >   struct vop_reg global_regdone_en;
> >  };
> >
> > +struct vop_afbc {
> > + struct vop_reg enable;
> > + struct vop_reg win_sel;
> > + struct vop_reg format;
> > + struct vop_reg hreg_block_split;
> > + struct vop_reg pic_size;
> > + struct vop_reg hdr_ptr;
> > + struct vop_reg rstn;
> > +};
> > +
> >  struct vop_intr {
> >   const int *intrs;
> >   uint32_t nintrs;
> > @@ -128,6 +138,7 @@ struct vop_win_phy {
> >   const struct vop_scl_regs *scl;
> >   const uint32_t *data_formats;
> >   uint32_t nformats;
> > + const uint64_t *format_modifiers;
> >
> >   struct vop_reg enable;
> >   struct vop_reg gate;
> > @@ -169,6 +180,7 @@ struct vop_data {
> >   const struct vop_output *output;
> >   const struct vop_win_yuv2yuv_data *win_yuv2yuv;
> >   const struct vop_win_data *win;
> > + const struct vop_afbc *afbc;
> >   unsigned int win_size;
> >
> >  #define VOP_FEATURE_OUTPUT_RGB10 BIT(0)
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
> > b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> > index 7b9c74750f6d..e9ff0c43c396 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> > @@ -30,6 +30,12 @@
> >  #define VOP_REG_MASK_SYNC(off, _mask, _shift) \
> >   _VOP_REG(off, _mask, _shift, true, false)
> >
> > +static const uint64_t format_modifiers_afbc[] = {
> > + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP),
> > + DRM_FORMAT_MOD_LINEAR,
> > + DRM_FORMAT_MOD_INVALID
> > +};
> > +
> >  static const uint32_t formats_win_full[] = {
> >   DRM_FORMAT_XRGB,
> >   DRM_FORMAT_ARGB,
> > @@ -667,6 +673,7 @@ static const struct vop_win_phy rk3368_win01_data = {
> >   .scl = _win_full_scl,
> >   .data_formats = formats_win_full,
> >   .nformats = ARRAY_SIZE(formats_win_full),
> > + .format_modifiers = format_modifiers_afbc,
> >   .enable = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 0),
> >   .format = VOP_REG(RK3368_WIN0_CTRL0, 0x7, 1),
> >   .rb_swap = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 12),
> > @@ -758,6 +765,16 @@ static const struct vop_data rk3366_vop = {
> >   .win_size = ARRAY_SIZE(rk3368_vop_win_data),
> >  };
> >
> > +static const struct vop_afbc rk3399_afbc = {
> > + .rstn = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 3),
> > + .enable = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 0),
> > + .win_sel = VOP_REG(RK3399_AFBCD0_CTRL, 0x3, 1),
> > + .format = VOP_REG(RK3399_AFBCD0_CTRL, 0x1f, 16),
> > + .hreg_block_split = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 21),
> > + .hdr_ptr = VOP_REG(RK3399_AFBCD0_HDR_PTR, 0x, 0),
> > + .pic_size = VOP_REG(RK3399_AFBCD0_PIC_SIZE, 0x, 0),
> > +};
> > +
> >  static const struct vop_output rk3399_output = {
> >   .dp_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 16),
> >   .rgb_pin_pol = VOP_REG(RK3368_DSP_CTRL1, 0xf, 16),
> > @@ -808,6 +825,7 @@ static const struct vop_data rk3399_vop_big = {
> >   .modeset = _modeset,
> >   .output = _output,
> >   .misc = _misc,
> > + .afbc = _afbc,
> >   .win = rk3368_vop_win_data,
> >   .win_size = ARRAY_SIZE(rk3368_vop_win_data),
> >   .win_yuv2yuv = rk3399_vop_big_win_yuv2yuv_data,
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 3feeaa3f987a..ba6caf06c824 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -742,6 +742,9 @@ extern "C" {
> >   */
> >  #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
> >
> > +#define AFBC_FORMAT_MOD_ROCKCHIP \
> > + (AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE)
> > +
> >  /*
> >   * Allwinner tiled modifier
> >   *
> > --
> > 2.17.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



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Re: [PATCH 01/36] drm/fourcc: Add 2 plane YCbCr 10bit format support

2019-09-23 Thread Daniel Vetter
, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_NV61_10, .depth = 0,  
> .num_planes = 2, .cpp = { 10, 20, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_NV24_10, .depth = 0,  
> .num_planes = 2, .cpp = { 10, 20, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_NV42_10, .depth = 0,  
> .num_planes = 2, .cpp = { 10, 20, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_YUYV,.depth = 0,  
> .num_planes = 1, .cpp = { 16, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_YVYU,.depth = 0,  
> .num_planes = 1, .cpp = { 16, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_UYVY,.depth = 0,  
> .num_planes = 1, .cpp = { 16, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_VYUY,.depth = 0,  
> .num_planes = 1, .cpp = { 16, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_XYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 32, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_VUY888,  .depth = 0,  
> .num_planes = 1, .cpp = { 24, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_AYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 32, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> true, .is_yuv = true },
> +   { .format = DRM_FORMAT_Y210,.depth = 0,  
> .num_planes = 1, .cpp = { 32, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_Y212,.depth = 0,  
> .num_planes = 1, .cpp = { 32, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_Y216,.depth = 0,  
> .num_planes = 1, .cpp = { 32, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_Y410,.depth = 0,  
> .num_planes = 1, .cpp = { 32, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> true, .is_yuv = true },
> +   { .format = DRM_FORMAT_Y412,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 },  .hsub = 1, .vsub = 1, .has_alpha = 
> true, .is_yuv = true },
> +   { .format = DRM_FORMAT_Y416,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 },  .hsub = 1, .vsub = 1, .has_alpha = 
> true, .is_yuv = true },
> +   { .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
> .num_planes = 1, .cpp = { 32, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_XVYU12_16161616, .depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 },  .hsub = 1, .vsub = 1, .is_yuv = true },
> +   { .format = DRM_FORMAT_XVYU16161616,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 },  .hsub = 1, .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_Y0L0,.depth = 0,  
> .num_planes = 1,
>   .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 }, 
> .block_h = { 2, 0, 0 },
>   .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index 0b72468..7b29e97 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -530,7 +530,7 @@ int drm_mode_getfb(struct drm_device *dev,
> r->height = fb->height;
> r->width = fb->width;
> r->depth = fb->format->depth;
> -   r->bpp = fb->format->cpp[0] * 8;
> +   r->bpp = fb->format->bpp[0];
> r->pitch = fb->pitches[0];
>
> /* GET_FB() is an unprivileged ioctl so we must not return a
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 306d1ef..021358d 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -73,12 +73,12 @@ struct drm_format_info {
> /**
>  * @cpp:
>  *
> -* Number of bytes per pixel (per plane), this is aliased with
> +* Number of bits per pixel (per plane), this is aliased with
>  * @char_per_block. It is deprecated in favour of using the
>  * triplet @char_per_block, @block_w, @block_h for better
>  * describing the pixel format.
>  */
> -   u8 cpp[3];
> +   u8 bpp[3];
>
> /**
>  * @char_per_block:
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3..5fe89e9 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -266,6 +266,21 @@ extern "C" {
>  #define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 
> 2x2 subsampled Cr:Cb plane 16 bits per channel */
>
>  /*
> + * 2 plane YCbCr 10bit
> + * index 0 = Y plane, [9:0] Y
> + * index 1 = Cr:Cb plane, [19:0] Cr:Cb little endian
> + * or
> + * index 1 = Cb:Cr plane, [19:0] Cb:Cr little endian
> + */
> +
> +#define DRM_FORMAT_NV12_10 fourcc_code('N', 'A', '1', '2') /* 2x2 
> subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV21_10 fourcc_code('N', 'A', '2', '1') /* 2x2 
> subsampled Cb:Cr plane */
> +#define DRM_FORMAT_NV16_10 fourcc_code('N', 'A', '1', '6') /* 2x1 
> subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV61_10 fourcc_code('N', 'A', '6', '1') /* 2x1 
> subsampled Cb:Cr plane */
> +#define DRM_FORMAT_NV24_10 fourcc_code('N', 'A', '2', '4') /* 
> non-subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV42_10 fourcc_code('N', 'A', '4', '2') /* 
> non-subsampled Cb:Cr plane */
> +
> +/*
>   * 3 plane YCbCr
>   * index 0: Y plane, [7:0] Y
>   * index 1: Cb plane, [7:0] Cb
> --
> 2.7.4
>
>
>


-- 
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 00/36] Add support 10bit yuv format

2019-09-23 Thread Daniel Vetter
 |   6 +-
>  drivers/gpu/drm/gma500/oaktrail_crtc.c |   4 +-
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c |   6 +-
>  drivers/gpu/drm/i915/display/intel_atomic_plane.c  |   2 +-
>  drivers/gpu/drm/i915/display/intel_display.c   |  28 ++--
>  drivers/gpu/drm/i915/display/intel_fbc.c   |   8 +-
>  drivers/gpu/drm/i915/display/intel_fbdev.c |   6 +-
>  drivers/gpu/drm/i915/display/intel_sprite.c|   4 +-
>  drivers/gpu/drm/i915/i915_debugfs.c|   4 +-
>  drivers/gpu/drm/i915/intel_pm.c|  28 ++--
>  drivers/gpu/drm/imx/ipuv3-plane.c  |   8 +-
>  drivers/gpu/drm/ingenic/ingenic-drm.c  |   2 +-
>  drivers/gpu/drm/mcde/mcde_display.c|   4 +-
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c  |   2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c   |   2 +-
>  drivers/gpu/drm/mgag200/mgag200_mode.c |  16 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |   4 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c  |   2 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c   |   2 +-
>  drivers/gpu/drm/msm/msm_fb.c   |   2 +-
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c|   7 +-
>  drivers/gpu/drm/nouveau/dispnv50/base507c.c|   4 +-
>  drivers/gpu/drm/nouveau/dispnv50/ovly507e.c|   2 +-
>  drivers/gpu/drm/omapdrm/omap_fb.c  |   8 +-
>  drivers/gpu/drm/pl111/pl111_display.c  |   2 +-
>  drivers/gpu/drm/qxl/qxl_draw.c |   2 +-
>  drivers/gpu/drm/radeon/atombios_crtc.c |  10 +-
>  drivers/gpu/drm/radeon/r100.c  |   4 +-
>  drivers/gpu/drm/radeon/radeon_display.c|   6 +-
>  drivers/gpu/drm/radeon/radeon_fb.c |   2 +-
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c|  14 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c |   2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c|   4 +-
>  drivers/gpu/drm/sti/sti_gdp.c  |   2 +-
>  drivers/gpu/drm/stm/ltdc.c |   2 +-
>  drivers/gpu/drm/sun4i/sun8i_ui_layer.c |   2 +-
>  drivers/gpu/drm/sun4i/sun8i_vi_layer.c |   2 +-
>  drivers/gpu/drm/tegra/dc.c |   2 +-
>  drivers/gpu/drm/tegra/drm.c|   2 +-
>  drivers/gpu/drm/tegra/fb.c |   2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |   2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_plane.c  |   2 +-
>  drivers/gpu/drm/tve200/tve200_display.c|   2 +-
>  drivers/gpu/drm/udl/udl_fb.c   |   4 +-
>  drivers/gpu/drm/vboxvideo/vbox_mode.c  |   2 +-
>  drivers/gpu/drm/vc4/vc4_plane.c|  10 +-
>  drivers/gpu/drm/vkms/vkms_plane.c  |   2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |   4 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c|   4 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c   |   4 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c   |   2 +-
>  drivers/gpu/drm/xen/xen_drm_front_kms.c|   2 +-
>  drivers/gpu/drm/zte/zx_plane.c     |   4 +-
>  include/drm/drm_fourcc.h   |   4 +-
>  include/uapi/drm/drm_fourcc.h  |  15 ++
>  86 files changed, 299 insertions(+), 277 deletions(-)
>
> --
> 2.7.4
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [PATCH v2] drm: Add high-precision time to vblank trace event

2019-09-23 Thread Daniel Vetter
On Sat, Sep 21, 2019 at 10:33 AM Heinrich Fink  wrote:
>
> On Tue, 3 Sep 2019 at 11:53, Daniel Vetter  wrote:
> >
> > On Tue, Sep 03, 2019 at 11:19:19AM +0200, Heinrich Fink wrote:
> > > On Tue, 3 Sep 2019 at 09:46, Daniel Vetter  wrote:
> > > >
> > > > On Mon, Sep 02, 2019 at 04:24:12PM +0200, Heinrich Fink wrote:
> > > > > Store the timestamp of the current vblank in the new field 'time' of 
> > > > > the
> > > > > vblank trace event. If the timestamp is calculated by a driver that
> > > > > supports high-precision vblank timing, set the field 'high-prec' to
> > > > > 'true'.
> > > > >
> > > > > User space can now access actual hardware vblank times via the tracing
> > > > > infrastructure. Tracing applications (such as GPUVis, see [0] for
> > > > > related discussion), can use the newly added information to conduct a
> > > > > more accurate analysis of display timing.
> > > > >
> > > > > v2 Fix author name (missing last name)
> > > > >
> > > > > [0] https://github.com/mikesart/gpuvis/issues/30
> > > > >
> > > > > Reviewed-by: Daniel Vetter 
> > > > > Signed-off-by: Heinrich Fink 
> > > >
> > > > Applied, thanks.
> > >
> > > thanks! One question: After sending v2, I got an email from patchwork
> > > pointing at some failed style checks (CHECK:PARENTHESIS_ALIGNMENT,
> > > CHECK:COMPARISON_TO_NULL). Just so I know for the future, are these
> > > checks mandatory to be addressed? I haven't had a chance to address
> > > them yet. FWIW, linux-tree/scripts/checkpatch.pl did not complain.
> >
> > It's the same script, but I think CI uses some different options/flags. I
> > generally ignore these, but also generally good to stick to the style.
> >
> > $ dim checkpatch
> >
> > in our maintainer-tools should give you the drm flavoured checkpatch.
> > -Daniel
>
> Apologies if that's a basic question, but at which point is this patch
> landing upstream? I am monitoring the 5.4 merge window and couldn't
> figure out what the stages are for this patch to get there. Is there
> anything that is still left to do from my side?

It missed the 5.4 feature cut-off just barely:

commit 6914f8eb64f9de5308e2968968145cf6eb304025
Author: Heinrich Fink 
Date:   Mon Sep 2 16:24:12 2019 +0200

drm: Add high-precision time to vblank trace event

is your patch. Should land in 5.5 (and will show up in linux-next
after -rc1 is tagged).
-Daniel

>
> Thanks, Heinrich
>
> >
> > >
> > > - Heinrich
> > >
> > > > -Daniel
> > > >
> > > > > ---
> > > > >  drivers/gpu/drm/drm_trace.h  | 14 ++
> > > > >  drivers/gpu/drm/drm_vblank.c |  3 ++-
> > > > >  2 files changed, 12 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
> > > > > index 471eb927474b..11c6dd577e8e 100644
> > > > > --- a/drivers/gpu/drm/drm_trace.h
> > > > > +++ b/drivers/gpu/drm/drm_trace.h
> > > > > @@ -13,17 +13,23 @@ struct drm_file;
> > > > >  #define TRACE_INCLUDE_FILE drm_trace
> > > > >
> > > > >  TRACE_EVENT(drm_vblank_event,
> > > > > - TP_PROTO(int crtc, unsigned int seq),
> > > > > - TP_ARGS(crtc, seq),
> > > > > + TP_PROTO(int crtc, unsigned int seq, ktime_t time, bool 
> > > > > high_prec),
> > > > > + TP_ARGS(crtc, seq, time, high_prec),
> > > > >   TP_STRUCT__entry(
> > > > >   __field(int, crtc)
> > > > >   __field(unsigned int, seq)
> > > > > + __field(ktime_t, time)
> > > > > + __field(bool, high_prec)
> > > > >   ),
> > > > >   TP_fast_assign(
> > > > >   __entry->crtc = crtc;
> > > > >   __entry->seq = seq;
> > > > > - ),
> > > > > - TP_printk("crtc=%d, seq=%u", __entry->crtc, __entry->seq)
> > > > > + __entry->time = time;
> > > > > + __entry->high_prec = high_prec;
> > > > > + ),
> > > > > + TP_printk("crtc

Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903

2019-09-20 Thread Daniel Vetter
 Drop vma_node from ttm_buffer_object, use the gem struct
> (base.vma_node) instead.
>
> Signed-off-by: Gerd Hoffmann 
> Reviewed-by: Christian König 
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/20190805140119.7337-9-kra...@redhat.com
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
>  drivers/gpu/drm/drm_gem_vram_helper.c  | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_display.c  | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_gem.c  | 2 +-
>  drivers/gpu/drm/qxl/qxl_object.h   | 2 +-
>  drivers/gpu/drm/radeon/radeon_object.h | 2 +-
>  drivers/gpu/drm/ttm/ttm_bo.c   | 8 
>  drivers/gpu/drm/ttm/ttm_bo_util.c  | 2 +-
>  drivers/gpu/drm/ttm/ttm_bo_vm.c| 9 +
>  drivers/gpu/drm/virtio/virtgpu_drv.h   | 2 +-
>  drivers/gpu/drm/virtio/virtgpu_prime.c | 3 ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c| 4 ++--
>  include/drm/ttm/ttm_bo_api.h   | 4 
>  14 files changed, 21 insertions(+), 27 deletions(-)
>
> I nominated commit '[1e053b10ba60eae6a3f9de64cbc74bdf6cb0e715] drm/ttm:
> use gem reservation object' as being 'good' initially, based on the
> fact that kernel 5.3.0-rc1-00364-g1e053b10ba60 did boot. But the GUI
> applications displayed black artifacts across the screen.
>
> I then edited the git-bisect log file where I nominated
> commit 1e053b10ba60eae6a3f9de64cbc74bdf6cb0e715 as being
> 'bad' and ran 'git bisect replay' on it. This blamed commit
> 1e053b10ba60eae6a3f9de64cbc74bdf6cb0e715 as the first bad commit.
>
> 1e053b10ba60eae6a3f9de64cbc74bdf6cb0e715 is the first bad commit
> commit 1e053b10ba60eae6a3f9de64cbc74bdf6cb0e715
> Author: Gerd Hoffmann 
> Date:   Mon Aug 5 16:01:09 2019 +0200
>
> drm/ttm: use gem reservation object
>
> Drop ttm_resv from ttm_buffer_object, use the gem reservation object
> (base._resv) instead.
>
> Signed-off-by: Gerd Hoffmann 
> Reviewed-by: Christian König 
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/20190805140119.7337-8-kra...@redhat.com
>
>  drivers/gpu/drm/ttm/ttm_bo.c  | 39 
> +++
>  drivers/gpu/drm/ttm/ttm_bo_util.c |  2 +-
>  include/drm/ttm/ttm_bo_api.h  |  1 -
>  3 files changed, 24 insertions(+), 18 deletions(-)
>
>
> In the process of bisection, I nominated the following kernels as being
> 'bad'. They also booted fine, but the xserver would fail to start. I
> have attached the error messages generated by xorg.
>
> # kernel boots; Xorg won't start. See Xorg_err.log attached.
> 5.3.0-rc3-01537-g6a3068065fa4
> 5.3.0-rc3-00782-gb0383c0653c4
> 5.3.0-rc1-00391-g54fc01b775fe
> 5.3.0-rc1-00366-g2e3c9ec4d151
> 5.3.0-rc1-00365-gb96f3e7c8069
>
> Today, I upgraded the kernel to 5.3.0-next-20190919, which booted fine
> with no Xorg regressions to report.
>
> Just wondering if the earlier kernels would not boot for me because of
> the changes introduced by the 'bad' commits being perhaps incomplete?
>
> Thanks to all of you for the tips on how proceed with bisection.



-- 
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 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx

2019-09-20 Thread Daniel Vetter
On Tue, Dec 12, 2017 at 10:34 AM Roger He  wrote:
>
> on_alloc_stage: is this operation on allocation stage
> resv: reservation bo used of this operation
>
> Change-Id: I01ea482e8c7470014196eb218e2ff8913306eef0
> Signed-off-by: Roger He 

Real commit message (the later patches using this are even sparser)
and/or proper kerneldoc would be massively appreciated in common code.
You guys have done a ton of stuff and special cases just for amdgpu,
and if someone doesn't at least know what you aimed to do it's pretty
much impossible to understand. I don't care much if this is the
standard in drivers, but common code really should bother to explain
what problem it's trying to solve.

(yes I think I figured out what it's doing, but I'm pretty sure most
dri-devel folks hacking on gem/cs/render stuff won't be so lucky)
-Daniel

> ---
>  include/drm/ttm/ttm_bo_api.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 368eb02..25de597 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -263,6 +263,8 @@ struct ttm_bo_kmap_obj {
>   *
>   * @interruptible: Sleep interruptible if sleeping.
>   * @no_wait_gpu: Return immediately if the GPU is busy.
> + * @on_alloc_stage: is this operation on allocation stage
> + * @resv: resvation bo used
>   *
>   * Context for TTM operations like changing buffer placement or general 
> memory
>   * allocation.
> @@ -270,6 +272,8 @@ struct ttm_bo_kmap_obj {
>  struct ttm_operation_ctx {
> bool interruptible;
> bool no_wait_gpu;
> +   bool on_alloc_stage;
> +   struct reservation_object *resv;
> uint64_t bytes_moved;
>  };
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer

2019-09-20 Thread Daniel Vetter
On Thu, Sep 19, 2019 at 5:13 PM Ayan Halder  wrote:
>
> On Thu, Sep 19, 2019 at 04:10:42PM +0200, Daniel Vetter wrote:
> > On Thu, Sep 19, 2019 at 4:03 PM Ayan Halder  wrote:
> > >
> > > On Wed, Sep 18, 2019 at 10:30:12PM +0100, Daniel Stone wrote:
> > >
> > > Hi All,
> > > Thanks for your suggestions.
> > >
> > > > Hi Liviu,
> > > >
> > > > On Wed, 18 Sep 2019 at 13:04, Liviu Dudau  wrote:
> > > > > On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > > > > > I totally agree. Framebuffers aren't about the underlying memory 
> > > > > > they
> > > > > > point to, but about how to _interpret_ that memory: it decorates a
> > > > > > pointer with width, height, stride, format, etc, to allow you to 
> > > > > > make
> > > > > > sense of that memory. I see content protection as being the same as
> > > > > > physical contiguity, which is a property of the underlying memory
> > > > > > itself. Regardless of the width, height, or format, you just cannot
> > > > > > access that memory unless it's under the appropriate ('secure 
> > > > > > enough')
> > > > > > conditions.
> > > > > >
> > > > > > So I think a dmabuf attribute would be most appropriate, since 
> > > > > > that's
> > > > > > where you have to do all your MMU handling, and everything else you
> > > > > > need to do to allow access to that buffer, anyway.
> > > > >
> > > > > Isn't it how AMD currently implements protected buffers as well?
> > > >
> > > > No idea to be honest, I haven't seen anything upstream.
> > > >
> > > > > > There's a lot of complexity beyond just 'it's protected'; for
> > > > > > instance, some CP providers mandate that their content can only be
> > > > > > streamed over HDCP 2.2 Type-1 when going through an external
> > > > > > connection. One way you could do that is to use a secure world
> > > > > > (external controller like Intel's ME, or CPU-internal enclave like 
> > > > > > SGX
> > > > > > or TEE) to examine the display pipe configuration, and only then 
> > > > > > allow
> > > > > > access to the buffers and/or keys. Stuff like that is always going 
> > > > > > to
> > > > > > be out in the realm of vendor & product-policy-specific add-ons, but
> > > > > > it should be possible to agree on at least the basic mechanics and
> > > > > > expectations of a secure path without things like that.
> > > > >
> > > > > I also expect that going through the secure world will be pretty much 
> > > > > transparent for
> > > > > the kernel driver, as the most likely hardware implementations would 
> > > > > enable
> > > > > additional signaling that will get trapped and handled by the secure 
> > > > > OS. I'm not
> > > > > trying to simplify things, just taking the stance that it is 
> > > > > userspace that is
> > > > > coordinating all this, we're trying only to find a common ground on 
> > > > > how to handle
> > > > > this in the kernel.
> > > >
> > > > Yeah, makes sense.
> > > >
> > > > As a strawman, how about a new flag to drmPrimeHandleToFD() which sets
> > > > the 'protected' flag on the resulting dmabuf?
> > >
> > > To be honest, during our internal discussion james.qian.w...@arm.com had a
> > > similar suggestion of adding a new flag to dma_buf but I decided
> > > against it.
> > >
> > > As per my understanding, adding custom dma buf flags (like
> > > AMDGPU_GEM_CREATE_XXX, etc) is possible if we(Arm) had our own allocator. 
> > > We
> > > rely on the dumb allocator and ion allocator for framebuffer creation.
> > >
> > > I was looking at an allocator independent way of userspace
> > > communicating to the drm framework that the framebuffer is protected.
> > >
> > > Thus, it looked to me that framebuffer modifier is the best (or the least
> > > corrupt) way of going forth.
> > >
> > > We use ion and dumb allocator for framebuffer object creation. The way
> > > I see it is as follows :-
> > >
> > > 1. For

Re: [git pull] drm tree for 5.4-rc1

2019-09-20 Thread Daniel Vetter
On Fri, Sep 20, 2019 at 2:11 AM Dave Airlie  wrote:
> > Hmm. My merge isn't identical to that. It's close though. Different
> > order for one #define which might be just from you and me merging
> > different directions.
> >
> > But I also ended up removing the .gem_prime_export initialization to
> > drm_gem_prime_export, because it's the default if none exists. That's
> > the left-over from
> >
> > 3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/import")
> >
> > after the import stayed around because it got turned into an actually
> > non-default one.
> >
> > I think that both of our merges are right - equivalent but just
> > slightly different.
> >
> > But the reason I'm pointing this out is that I also get the feeling
> > that if it needs that dev->dev_private difference from the default
> > function in prime_import(), wouldn't it need the same for prime_export
> > too?
> >
> > I don't know the code, and I don't know the hardware, but just from a
> > "pattern matching" angle I just wanted to check whether maybe there's
> > need for a mtk_drm_gem_prime_export() wrapper that does that same
> > thing with
> >
> > struct mtk_drm_private *private = dev->dev_private;
> >
> > .. use private->dev  instead of dev->dev ..
> >
> > So I'm just asking that somebody that knows that drm/mtk code should
> > double-check that oddity.
>
> I've cc'ed Alexandre who wrote the import half of this code to look into it.
>
> I've looked at the other results and it all seems fine to me.

(pre-coffee, but let's hope the brain is awake enough)

This asymmetry in prime import/export is somewhat common for devices
with funky dma requirements/setup in the dt/soc world.

- on export we need to use the "official" struct device, so that when
we re-import (i.e. userspace just shared a buffer across process
through fd-passing, not across device-drivers) the common helpers
realize "ah this is ours, let me just grab the underlying buffer
object", instead of creating a full new buffer object handle like it
does for a real import of a dma-buf from a different device driver.
Because having 2 buffer object handles pointing at the same underlying
buffer objects tends to not go well.

- on import otoh we need to pass the struct device we actually need
for dma (which for reasons that I don't fully grok isn't the same, I
got it explained once by dt/soc folks and forgot again why exactly),
so that dma_map_sg and friends dtrt.

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

Re: [PATCH 2/2] MAINTAINERS: Add Jernej Škrabec as a reviewer for DE2

2019-09-19 Thread Daniel Vetter
On Thu, Sep 19, 2019 at 7:30 PM Maxime Ripard  wrote:
>
> The newer Allwinner SoCs have a different layers controller than the older
> ones. Jernej wrote that support and has been reviewing patches for a while
> now, so let's make him a formal reviewer.
>
> Signed-off-by: Maxime Ripard 

Haz commit rights already, or do we need to fix that?
-Daniel

> ---
>  MAINTAINERS | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 54e222e1d0d6..fae328f06c17 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5361,6 +5361,15 @@ F:   drivers/gpu/drm/sun4i/
>  F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>  T: git git://anongit.freedesktop.org/drm/drm-misc
>
> +DRM DRIVER FOR ALLWINNER DE2 ENGINE
> +M: Maxime Ripard 
> +M: Chen-Yu Tsai 
> +R: Jernej Škrabec 
> +L: dri-devel@lists.freedesktop.org
> +S: Supported
> +F: drivers/gpu/drm/sun4i/sun8i*
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
>  DRM DRIVERS FOR AMLOGIC SOCS
>  M: Neil Armstrong 
>  L: dri-devel@lists.freedesktop.org
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [PATCH 1/2] MAINTAINERS: Update Allwinner DRM drivers entry

2019-09-19 Thread Daniel Vetter
On Thu, Sep 19, 2019 at 7:36 PM Chen-Yu Tsai  wrote:
>
> On Fri, Sep 20, 2019 at 1:30 AM Maxime Ripard  wrote:
> >
> > The DRM drivers are more than about the A10 now, so let's make the entry
> > name a bit more generic.
> >
> > Also, Chen-Yu has been a de-facto maintainer for the DRM driver for a
> > while, is a maintainer of the Allwinner platform for an even longer time,
> > and has drm-misc commit access. Let's make it formal and add him as a
>
> Although I have an account, I haven't actually tried if I have commit access.
> I also don't think my account was properly migrated over to GitLab, as I
> had to re-create one.

The git repo is still on legacy git fd.o servers, it's not yet
migrated over to gitlab.
-Daniel

>
> > maintainer.
> >
> > Signed-off-by: Maxime Ripard 
>
> Acked-by: Chen-Yu Tsai 
>
> > ---
> >  MAINTAINERS | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index b2326dece28e..54e222e1d0d6 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -5352,8 +5352,9 @@ F:include/drm/drm*
> >  F: include/uapi/drm/drm*
> >  F: include/linux/vga*
> >
> > -DRM DRIVERS FOR ALLWINNER A10
> > +DRM DRIVERS FOR ALLWINNER SOCS
> >  M: Maxime Ripard 
> > +M: Chen-Yu Tsai 
> >  L: dri-devel@lists.freedesktop.org
> >  S: Supported
> >  F: drivers/gpu/drm/sun4i/
> > --
> > 2.21.0
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [Intel-gfx] [PATCH] dma-buf: Implement simple read/write vfs ops

2019-09-19 Thread Daniel Vetter
On Thu, Sep 19, 2019 at 5:53 PM Chris Wilson  wrote:
>
> Quoting Daniel Vetter (2019-09-19 16:28:41)
> > On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson  
> > wrote:
> > >
> > > It is expected that processes will pass dma-buf fd between drivers, and
> > > only using the fd themselves for mmaping and synchronisation ioctls.
> > > However, it may be convenient for an application to read/write into the
> > > dma-buf, for instance a test case to check the internal
> > > dma_buf->ops->kmap interface. There may also be a small advantage to
> > > avoiding the mmap() for very simple/small operations.
> > >
> > > Note in particular, synchronisation with the device is left to the
> > > caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly
> > > inside the read/write, so that the user can avoid synchronisation if
> > > they so choose.
> > >
> > > "It is easier to add synchronisation later, than it is to take it away."
> >
> > Hm for mmap I think the explicit sync makes sense (we might even want
> > to do it in userspace). Not so sure it's a great idea for read/write
> > ... I guess we'd need to see what people have/had in mind for the
> > userspace for this to decide.
>
> There's an O_SYNC flag for open(2):
>
>O_SYNC Write operations on the file will complete according to the
>   requirements of synchronized I/O file integrity completion (by
>   contrast with the synchronized I/O data integrity completion
>   provided by O_DSYNC.)
>
>   By the time write(2) (or similar) returns, the output data and
>   associated file metadata have been transferred to the underly‐
>   ing hardware (i.e., as though each write(2) was followed by a
>   call to fsync(2)).
>
> That seems applicable here?

Hm yeah, sounds like a neat idea to use O_SYNC to decide whether
writes/reads flushes or not. It's a bit a stretch since !O_SYNC would
also give you un-coherent reads (or could at least).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf: Implement simple read/write vfs ops

2019-09-19 Thread Daniel Vetter
On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson  wrote:
>
> It is expected that processes will pass dma-buf fd between drivers, and
> only using the fd themselves for mmaping and synchronisation ioctls.
> However, it may be convenient for an application to read/write into the
> dma-buf, for instance a test case to check the internal
> dma_buf->ops->kmap interface. There may also be a small advantage to
> avoiding the mmap() for very simple/small operations.
>
> Note in particular, synchronisation with the device is left to the
> caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly
> inside the read/write, so that the user can avoid synchronisation if
> they so choose.
>
> "It is easier to add synchronisation later, than it is to take it away."

Hm for mmap I think the explicit sync makes sense (we might even want
to do it in userspace). Not so sure it's a great idea for read/write
... I guess we'd need to see what people have/had in mind for the
userspace for this to decide.

Only other thought I have on this is that many dma-buf exporters don't
bother with the kmap/kunmap interface (probably fewer than those who
bother with kernel vmap and mmap), maybe we want at least a vmap
fallback for this. Or maybe just use that as an excuse to get more
people to wire up the kmap stuff :-)
-Daniel

> v2: Lots of little fixes, plus a real llseek() implements so that the
> first basic little test cases work!
>
> Testcase: igt/prime_rw
> Signed-off-by: Chris Wilson 
> Cc: Laura Abbott 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> Cc: Sean Paul 
> Cc: Janusz Krzysztofik 
> Tested-by: Laura Abbott 
> ---
> Dusting this off again as it would be nice as a user to operate on dmabuf
> agnostic to the underyling driver. We have mmap, so naturally we would
> like to have read/write as well!
>
> ---
>  drivers/dma-buf/dma-buf.c | 108 --
>  1 file changed, 93 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 433d91d710e4..a19fc881a99c 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -135,28 +135,104 @@ static int dma_buf_mmap_internal(struct file *file, 
> struct vm_area_struct *vma)
>
>  static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
>  {
> -   struct dma_buf *dmabuf;
> -   loff_t base;
> +   struct dma_buf *dmabuf = file->private_data;
>
> if (!is_dma_buf_file(file))
> return -EBADF;
>
> -   dmabuf = file->private_data;
> +   return fixed_size_llseek(file, offset, whence, dmabuf->size);
> +}
>
> -   /* only support discovering the end of the buffer,
> -  but also allow SEEK_SET to maintain the idiomatic
> -  SEEK_END(0), SEEK_CUR(0) pattern */
> -   if (whence == SEEK_END)
> -   base = dmabuf->size;
> -   else if (whence == SEEK_SET)
> -   base = 0;
> -   else
> -   return -EINVAL;
> +static ssize_t dma_buf_read(struct file *file,
> +   char __user *ubuf, size_t remain,
> +   loff_t *offset)
> +{
> +   struct dma_buf *dmabuf = file->private_data;
> +   unsigned long idx;
> +   unsigned int start;
> +   size_t total;
>
> -   if (offset != 0)
> -   return -EINVAL;
> +   if (!is_dma_buf_file(file))
> +   return -EBADF;
> +
> +   total = 0;
> +   idx = *offset >> PAGE_SHIFT;
> +   start = offset_in_page(*offset);
> +   while (remain) {
> +   unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
> +   unsigned int copied;
> +   void *vaddr;
> +
> +   if (*offset >= dmabuf->size)
> +   return total;
> +
> +   vaddr = dma_buf_kmap(dmabuf, idx);
> +   if (!vaddr)
> +   return total ?: -EIO;
> +
> +   copied = copy_to_user(ubuf, vaddr + start, len);
> +   dma_buf_kunmap(dmabuf, idx, vaddr);
> +
> +   total += copied ?: len;
> +   if (copied) {
> +   *offset += copied;
> +   return total ?: -EFAULT;
> +   }
> +
> +   remain -= len;
> +   *offset += len;
> +   ubuf += len;
> +   start = 0;
> +   idx++;
> +   }
> +
> +   return total;
> +}
> +
> +static ssize_t dma_buf_write(struct file *file,
> +const char __user *ubuf, size_t remain,
> +   

Re: [RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer

2019-09-19 Thread Daniel Vetter
ld be a property of the underlying buffer (like a
contiguous buffer). All we need are two things:
- make sure secure buffers can only be imported by secure-buffer aware drivers
- some way for such drivers to figure out whether they deal with a
secure buffer or not.

There's no need for any flags anywhere else with the ion/secure
dma-buf heap solution. E.g. for contig buffer we also dont pass around
a DRM_FORMAT_MOD_PHYSICALLY_CONTIG for addfb2.

> 2. For dumb allocator :-
> I am curious to know if we can add 'IS_PROTECTED' flag to
> drm_mode_create_dumb.flags. This can/might be used to set dma_buf
> flags. Let me know if this is an incorrect/forbidden path.

dumb is dumb, this definitely feels like the wrong interface to me.

> In a nutshell, my objective is to figure out if the userspace is able
> to communicate to the drm core about the 'protection' status of the
> buffer without introducing Arm specific buffer allocator.

Why does userspace need to communicate this again? What's the issue
with using an ARM specific allocator for this?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Re: [PATCH] drm: two planes with the same zpos have undefined ordering

2019-09-19 Thread Daniel Vetter
On Thu, Sep 19, 2019 at 11:02 AM Pekka Paalanen  wrote:
>
> On Thu, 19 Sep 2019 10:18:04 +0200
> Daniel Vetter  wrote:
>
> > On Thu, Sep 19, 2019 at 9:18 AM Pekka Paalanen  wrote:
> > >
>
> ...
>
> > > Right, and we are suffering from that confusion already. Should
> > > userspace use ID order if zpos property is not there or not? I have no
> > > idea.
> >
> > Nope. I think the only options for this case are:
> > - file bug against upstream driver so they add zpos
> > - you magically know how planes work on that hw
> > - you don't overlap planes at all
> > - cursor is above primary, that much we can guarantee
> >
> > Yes it's kinda uapi fail we didn't add zpos from the start :-/
>
> Good. Weston does the last two. The confusion did not last long
> enough to let us add code using the object ID to infer stacking order.
>
> Although, Weston does have the assumption that overlays are in unknown
> order between primary and cursor, which now seems false.

I think cursor is always on top, but some of the overlays can be underlays.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: two planes with the same zpos have undefined ordering

2019-09-19 Thread Daniel Vetter
gt; > then I'm very confused. What's the difference?
> > >
> > > The text you are changing was specifically added to explain uAPI
> > > behaviour, that is, what the userspace sees and does with the zpos
> > > property in uAPI.
> > >
> > > Having two conflicting pieces of documentation is confusing, especially
> > > when it is not absolutely clear which one is for driver implementors
> > > and which one for uAPI consumers, or that one must ignore the other doc
> > > depending on who you are.
> >
> > Yes, I agree that this is confusing.
> >
> > To be completely honest, I don't really care what the outcome of this
> > discussion is, as long as there are no conflicting documentation comments.
>
> Hi,
>
> that is exactly what I want too.
>
> > So, my interpretation of the docs is that there are:
> >
> > 1. Some documentation for KMS properties, that is, what is exposed to
> >user-space via DRM ioctls. This is the KMS uAPI.
> > 2. Some documentation for kernel drivers, that is, internal DRM state that 
> > can
> >be set by kernel developers. This includes helper functions and common
> >structs.
> >
> > Obviously as user-space developers we only care about (1).
>
> Theoretically yes, but the problem is that one cannot make that
> distinction. I'm pretty sure both categories of comments are not
> complete, and answers to some questions in one must be dug up from the
> other, if documented at all.
>
> So you cannot use wording that looks conflicting between the two. If
> the wording is correct nevertheless, it needs more explaining on how it
> doesn't actually conflict, so that people randomly reading just one
> side or the other don't get the wrong idea.
>
> > Now, back to zpos' case: there are two doc comments about zpos.
> >
> > The first one is [1], the one this patch changes:
> >
> > > zpos:
> > > Z position is set up with drm_plane_create_zpos_immutable_property() and
> > > drm_plane_create_zpos_property(). It controls the visibility of 
> > > overlapping
> > > planes. Without this property the primary plane is always below the cursor
> > > plane, and ordering between all other planes is undefined. The positive Z
> > > axis points towards the user, i.e. planes with lower Z position values are
> > > underneath planes with higher Z position values. Note that the Z position
> > > value can also be immutable, to inform userspace about the hard-coded
> > > stacking of overlay planes, see 
> > > drm_plane_create_zpos_immutable_property().
> >
> > This is in the "Plane Composition Properties". I believe this paragraph
> > documents the standard plane properties (standard as in not 
> > driver-specific).
> > So I'd say this documents the KMS uAPI.
> >
> > The second one is [2], the one you've quoted:
> >
> > > zpos
> > >
> > > Priority of the given plane on crtc (optional).
> > >
> > > Note that multiple active planes on the same crtc can have an identical 
> > > zpos
> > > value. The rule to solving the conflict is to compare the plane object 
> > > IDs;
> > > the plane with a higher ID must be stacked on top of a plane with a lower 
> > > ID.
> > >
> > > See drm_plane_create_zpos_property() and
> > > drm_plane_create_zpos_immutable_property() for more details.
> >
> > This is in the "Plane Functions Reference" section, more precisely in the
> > "struct drm_plane_state" docs. I believe this is really just about the 
> > common
> > DRM struct that can be used by all drivers. This struct isn't exposed to
> > user-space. It's just an implementation detail of DRM.
> >
> > (We can see that even without this patch, these two comments already
> > kind of conflict. The first one says that without zpos ordering is
> > undefined. The second one says that two identical zpos values means the
> > plane ID should be used. However drm_plane_state is zero-filled, so a
> > driver not supporting zpos would have all drm_plane_state.zpos fields
> > set to zero? Since they are all equal, is the object ID ordering rule
> > relevant?)
>
> Right, and we are suffering from that confusion already. Should
> userspace use ID order if zpos property is not there or not? I have no
> idea.

Nope. I think the only options for this case are:
- file bug against upstream driver so they add zpos
- you magically know how planes work on that hw
- you don't overlap planes at all
- cursor is above primary, that much we can guarantee

Yes it's kinda uapi fail we didn't add zpos from the start :-/
-Daniel

>
> > [1]: 
> > https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-composition-properties
> > [2]: 
> > https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#plane-functions-reference
>
>
> Thanks,
> pq



-- 
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 v2 3/3] drm: Add self_refresh_state debugfs entry

2019-09-18 Thread Daniel Vetter
On Wed, Sep 18, 2019 at 10:07 PM Sean Paul  wrote:
>
> From: Sean Paul 
>
> This patch adds a debugfs entry to surface the entry and exit times as
> well as the calculated delay.
>
> Suggested-by: Daniel Vetter 
> Signed-off-by: Sean Paul 
>
> Changes in v2:
> - Added to the set
> ---
>
> Wasn't too sure how to initialize this, as calling the helper function
> from drm_debugfs.c seemed... wrong. However there weren't any other
> compelling solutions, so I figured I'd post this and learn something
> new.

Won't build, because drm.ko can't depend upon stuff in
drm-kms-helper.ko, since that already depends upon the former.

I think we need a drm_self_refresh_helper_register which drivers can
call from their crtc->late_register callback. I think Noralf was
working on some infrastructure to make this neater, but it didn't land
yet.
-Daniel
>
>
>
>  drivers/gpu/drm/drm_debugfs.c | 10 +
>  drivers/gpu/drm/drm_self_refresh_helper.c | 55 ++-
>  include/drm/drm_self_refresh_helper.h |  6 +++
>  3 files changed, 69 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index eab0f2687cd6..175c2451ae72 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -38,6 +38,9 @@
>  #include 
>  #include 
>  #include 
> +#if defined(CONFIG_DRM_KMS_HELPER)
> +#include 
> +#endif
>
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -231,6 +234,13 @@ int drm_debugfs_init(struct drm_minor *minor, int 
> minor_id,
> DRM_ERROR("Failed to create atomic debugfs files\n");
> return ret;
> }
> +#if defined(CONFIG_DRM_KMS_HELPER)
> +   ret = drm_self_refresh_debugfs_init(minor);
> +   if (ret) {
> +   DRM_ERROR("Failed to init self refresh debugfs\n");
> +   return ret;
> +   }
> +#endif
> }
>
> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c 
> b/drivers/gpu/drm/drm_self_refresh_helper.c
> index 68f4765a5896..e7544ae1e47b 100644
> --- a/drivers/gpu/drm/drm_self_refresh_helper.c
> +++ b/drivers/gpu/drm/drm_self_refresh_helper.c
> @@ -14,7 +14,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -167,6 +169,16 @@ void drm_self_refresh_helper_update_avg_times(struct 
> drm_atomic_state *state,
>  }
>  EXPORT_SYMBOL(drm_self_refresh_helper_update_avg_times);
>
> +static unsigned int
> +drm_self_refresh_calc_idle_delay(struct drm_self_refresh_data *sr_data)
> +{
> +   if (WARN_ON(!mutex_is_locked(_data->avg_mutex)))
> +   return SELF_REFRESH_AVG_SEED_MS * 4;
> +
> +   return (ewma_psr_time_read(_data->entry_avg_ms) +
> +   ewma_psr_time_read(_data->exit_avg_ms)) * 2;
> +}
> +
>  /**
>   * drm_self_refresh_helper_alter_state - Alters the atomic state for SR exit
>   * @state: the state currently being checked
> @@ -209,8 +221,7 @@ void drm_self_refresh_helper_alter_state(struct 
> drm_atomic_state *state)
> continue;
>
> mutex_lock(_data->avg_mutex);
> -   delay = (ewma_psr_time_read(_data->entry_avg_ms) +
> -ewma_psr_time_read(_data->exit_avg_ms)) * 2;
> +   delay = drm_self_refresh_calc_idle_delay(sr_data);
> mutex_unlock(_data->avg_mutex);
>
> mod_delayed_work(system_wq, _data->entry_work,
> @@ -275,3 +286,43 @@ void drm_self_refresh_helper_cleanup(struct drm_crtc 
> *crtc)
> kfree(sr_data);
>  }
>  EXPORT_SYMBOL(drm_self_refresh_helper_cleanup);
> +
> +#ifdef CONFIG_DEBUG_FS
> +
> +static int drm_self_refresh_debugfs_state(struct seq_file *m, void *data)
> +{
> +   struct drm_info_node *node = (struct drm_info_node *) m->private;
> +   struct drm_device *dev = node->minor->dev;
> +   struct drm_printer p = drm_seq_file_printer(m);
> +   struct drm_crtc *crtc;
> +
> +   drm_for_each_crtc(crtc, dev) {
> +   struct drm_self_refresh_data *sr_data = 
> crtc->self_refresh_data;
> +   if (!sr_data)
> +   continue;
> +
> +   mutex_lock(_data->avg_mutex);
> +   drm_printf(, "crtc[%u]: %s\n", crtc->base.id, crtc->name);
> +   drm_printf(, "\tentry_avg_ms=%lu\n",
> +  ew

  1   2   3   4   5   6   7   8   9   10   >