Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

[Daniel Vetter]

On Fri, Feb 23, 2018 at 09:25:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> While we want to potentially support multiple different gamma/degamma
> LUT sizes we can (and should) at least check that the blob length
> is a multiple of the LUT entry size.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_atomic.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 8945357212ba..933edec0299d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -413,6 +413,7 @@ drm_atomic_replace_property_blob_from_id(struct 
> drm_device *dev,
>struct drm_property_blob **blob,
>uint64_t blob_id,
>ssize_t expected_size,
> +  ssize_t expected_size_mod,

Needs kerneldoc, and I'm not sure it's the most descriptive name. Maybe
expected_array_element_size?

With or without the bikeshed, but with the kerneldoc fixed:

Reviewed-by: Daniel Vetter 

Up to this patch in the series.
-Daniel

>bool *replaced)
>  {
>   struct drm_property_blob *new_blob = NULL;
> @@ -422,7 +423,13 @@ drm_atomic_replace_property_blob_from_id(struct 
> drm_device *dev,
>   if (new_blob == NULL)
>   return -EINVAL;
>  
> - if (expected_size > 0 && expected_size != new_blob->length) {
> + if (expected_size > 0 &&
> + new_blob->length != expected_size) {
> + drm_property_blob_put(new_blob);
> + return -EINVAL;
> + }
> + if (expected_size_mod > 0 &&
> + new_blob->length % expected_size_mod != 0) {
>   drm_property_blob_put(new_blob);
>   return -EINVAL;
>   }
> @@ -470,7 +477,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   ret = drm_atomic_replace_property_blob_from_id(dev,
>   >degamma_lut,
>   val,
> - -1,
> + -1, sizeof(struct drm_color_lut),
>   );
>   state->color_mgmt_changed |= replaced;
>   return ret;
> @@ -478,7 +485,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   ret = drm_atomic_replace_property_blob_from_id(dev,
>   >ctm,
>   val,
> - sizeof(struct drm_color_ctm),
> + sizeof(struct drm_color_ctm), -1,
>   );
>   state->color_mgmt_changed |= replaced;
>   return ret;
> @@ -486,7 +493,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   ret = drm_atomic_replace_property_blob_from_id(dev,
>   >gamma_lut,
>   val,
> - -1,
> + -1, sizeof(struct drm_color_lut),
>   );
>   state->color_mgmt_changed |= replaced;
>   return ret;
> -- 
> 2.13.6
> 
> ___
> 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: [Intel-gfx] [PATCH 4/6] drm: Introduce drm_color_lut_size()

[Daniel Vetter]

On Fri, Feb 23, 2018 at 09:25:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Provide a small helper to convert the blob length in bytes
> to the number of LUT entries.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  include/drm/drm_color_mgmt.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 03a59cbce621..7ddf4457f3c1 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -37,4 +37,9 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>  int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>int gamma_size);
>  

Add a bit of kerneldoc and you get my

Reviewed-by: Daniel Vetter 

for this and all remaining patches.
-Daniel

> +static inline int drm_color_lut_size(const struct drm_property_blob *blob)
> +{
> + return blob->length / sizeof(struct drm_color_lut);
> +}
> +
>  #endif
> -- 
> 2.13.6
> 
> ___
> 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: [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

[Daniel Vetter]

On Fri, Feb 23, 2018 at 11:26:41AM -0500, Harry Wentland wrote:
> On 2018-02-22 04:42 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > The documentation for the ctm matrix suggests a two's complement
> > format, but at least the i915 implementation is using sign-magnitude
> > instead. And looks like malidp is doing the same. Change the docs
> > to match the current implementation, and change the type from __s64
> > to __u64 to drive the point home.
> > 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Mihail Atanassov 
> > Cc: Liviu Dudau 
> > Cc: Brian Starkey 
> > Cc: Mali DP Maintainers 
> > Cc: Johnson Lin 
> > Cc: Uma Shankar 
> > Cc: Shashank Sharma 
> > Signed-off-by: Ville Syrjälä 
> 
> Good clarification. Our new CTM implementation (1) actually assumed
> two's complement but nobody's using it yet, so we'll patch it to
> convert.

Another reason to start looking into igt and the tests there? That would
have caught this too ...
-Daniel

> 
> Reviewed-by: Harry Wentland 
> 
> (1) https://patchwork.freedesktop.org/patch/204005/
> 
> Harry
> 
> > ---
> >  include/uapi/drm/drm_mode.h | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 2c575794fb52..b5d7d9e0eff5 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
> >  };
> >  
> >  struct drm_color_ctm {
> > -   /* Conversion matrix in S31.32 format. */
> > -   __s64 matrix[9];
> > +   /*
> > +* Conversion matrix in S31.32 sign-magnitude
> > +* (not two's complement!) format.
> > +*/
> > +   __u64 matrix[9];
> >  };
> >  
> >  struct drm_color_lut {
> > 
> ___
> 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 0/4] drm/tilcdc: Add DRM panel support and use it for am335x-evm

[Daniel Vetter]

On Mon, Mar 05, 2018 at 02:12:16PM +0200, Jyri Sarha wrote:
> On 05/03/18 11:29, Jyri Sarha wrote:
> >> Since panel drivers are in drm-misc probably simplest if we push these all
> >> through that tree? Want commit rights for that?
> >> -Daniel
> >>
> > Sure. However, I already sent a pull request for tilcdc patches. But I
> > can send another for the panel patch to drm misc.
> > 
> > There is no direct dependency and I the dts patch can wait until the
> > next release, just to be sure that there is no breakage.
> > 
> 
> Oh... I was hasty in replying. But yes can push the panel patch to
> drm-misc if you give me the rights. I guess you need my ssh public key
> (attached) for that.

You need a fd.o account, please follow the procedure here:

https://www.freedesktop.org/wiki/AccountRequests/

btw if we go this way there's also the question whether you want to
maintain tilcdc in drm-misc, but that's up to you.

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: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

[Daniel Vetter]

On Thu, Feb 22, 2018 at 04:54:08AM +0100, Stefan Schake wrote:
> Android assumes an implicit black background layer is always present
> behind all layers it specifies for composition. drm_hwcomposer currently
> punts responsibility for this to the kernel/DRM platform and puts layers
> with per-pixel alpha content on the primary plane when requested.
> 
> On some platforms (e.g. VC4) a background color fill has a cycle cost for
> the hardware composer and is not enabled by default. Instead, userland can
> request a background color through a CRTC property. Use this property to
> specify the implicit black background Android expects.
> 
> Signed-off-by: Stefan Schake 
> ---
> Kernel changes for this (background_color) are available here:
> 
> https://github.com/stschake/linux/commits/background-upstream
> 
> Sending as RFC because I'm not entirely clear on whose responsibility
> this should be, on most DRM drivers it seems to be implicit. I think
> a case could also be made that VC4 should not accept alpha formats on
> the lowest layer or enable background color fill when given one anyway.
> On the other hand, userland control over background color seems desirable
> regardless and is a feature of multiple hardware composers (i915, vc4, omap).

I see you've already typed vc4 patches to address, just wanted to clarify
this here: The assumption is that all drivers already have a background
color of black/0. The background color property would be to set a
different background color than black.

If the driver has undefined behaviour for instead of an assumed background
color of black, then I think that's a driver bug.

See 
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties

"(e.g. for the background color, which currently is not exposed and
assumed to be black)"

I'm still hoping for some artist to create a nice svg that explains the
kms composition model with a nice graphic ...

Cheers, Daniel

> 
>  drmcrtc.cpp  | 11 +++
>  drmcrtc.h|  2 ++
>  drmdisplaycompositor.cpp | 15 +++
>  3 files changed, 28 insertions(+)
> 
> diff --git a/drmcrtc.cpp b/drmcrtc.cpp
> index 1b354fe..d7bcd7a 100644
> --- a/drmcrtc.cpp
> +++ b/drmcrtc.cpp
> @@ -52,6 +52,13 @@ int DrmCrtc::Init() {
>  ALOGE("Failed to get OUT_FENCE_PTR property");
>  return ret;
>}
> +
> +  ret = drm_->GetCrtcProperty(*this, "background_color",
> +  _color_property_);
> +  if (ret) {
> +ALOGI("Failed to get background_color property");
> +// This is an optional property
> +  }
>return 0;
>  }
>  
> @@ -86,4 +93,8 @@ const DrmProperty ::mode_property() const {
>  const DrmProperty ::out_fence_ptr_property() const {
>return out_fence_ptr_property_;
>  }
> +
> +const DrmProperty ::background_color_property() const {
> +  return background_color_property_;
> +}
>  }
> diff --git a/drmcrtc.h b/drmcrtc.h
> index c5a5599..704573a 100644
> --- a/drmcrtc.h
> +++ b/drmcrtc.h
> @@ -46,6 +46,7 @@ class DrmCrtc {
>const DrmProperty _property() const;
>const DrmProperty _property() const;
>const DrmProperty _fence_ptr_property() const;
> +  const DrmProperty _color_property() const;
>  
>   private:
>DrmResources *drm_;
> @@ -59,6 +60,7 @@ class DrmCrtc {
>DrmProperty active_property_;
>DrmProperty mode_property_;
>DrmProperty out_fence_ptr_property_;
> +  DrmProperty background_color_property_;
>  };
>  }
>  
> diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> index e556e86..69c52dd 100644
> --- a/drmdisplaycompositor.cpp
> +++ b/drmdisplaycompositor.cpp
> @@ -527,6 +527,21 @@ int 
> DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
>return ret;
>  }
>  
> +if (crtc->background_color_property().id() != 0) {
> +  // Background color is specified as a 16 bit per channel RGBA value.
> +  // Set a fully opaque black background as Android HWC expects.
> +  const uint64_t background_color = 0x;
> +
> +  ret = drmModeAtomicAddProperty(pset, crtc->id(),
> + crtc->background_color_property().id(),
> + background_color) < 0;
> +  if (ret) {
> +ALOGE("Failed to add CRTC background_color to pset: %d", ret);
> +drmModeAtomicFree(pset);
> +return ret;
> +  }
> +}
> +
>  ret = drmModeAtomicAddProperty(pset, crtc->id(), 
> crtc->mode_property().id(),
> mode_.blob_id) < 0 ||
>drmModeAtomicAddProperty(pset, connector->id(),
> -- 
> 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
http://blog.ffwll.ch
___
dri-devel mailing list

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

[Oleksandr Andrushchenko]

On 03/06/2018 09:26 AM, Daniel Vetter wrote:

On Mon, Mar 05, 2018 at 03:46:07PM +0200, Oleksandr Andrushchenko wrote:

On 03/05/2018 11:32 AM, Daniel Vetter wrote:

On Wed, Feb 21, 2018 at 10:03:41AM +0200, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment, namely
requirements dictated by the accompanying DRM/(v)GPU drivers running in both
host and guest environments, number of operating modes of para-virtualized
display driver are supported:
   - display buffers can be allocated by either frontend driver or backend
   - display buffers can be allocated to be contiguous in memory or not

Note! Frontend driver itself has no dependency on contiguous memory for
its operation.

1. Buffers allocated by the frontend driver.

The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.

1.1. Front driver configured to use GEM CMA helpers
   This use-case is useful when used with accompanying DRM/vGPU driver in
   guest domain which was designed to only work with contiguous buffers,
   e.g. DRM driver based on GEM CMA helpers: such drivers can only import
   contiguous PRIME buffers, thus requiring frontend driver to provide
   such. In order to implement this mode of operation para-virtualized
   frontend driver can be configured to use GEM CMA helpers.

1.2. Front driver doesn't use GEM CMA
   If accompanying drivers can cope with non-contiguous memory then, to
   lower pressure on CMA subsystem of the kernel, driver can allocate
   buffers from system memory.

Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.

2. Buffers allocated by the backend

This mode of operation is run-time configured via guest domain configuration
through XenStore entries.

For systems which do not provide IOMMU support, but having specific
requirements for display buffers it is possible to allocate such buffers
at backend side and share those with the frontend.
For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
physically contiguous memory, this allows implementing zero-copying
use-cases.

Note! Configuration options 1.1 (contiguous display buffers) and 2 (backend
allocated buffers) are not supported at the same time.

Signed-off-by: Oleksandr Andrushchenko 

Some suggestions below for some larger cleanup work.
-Daniel


---
   drivers/gpu/drm/xen/Kconfig |  13 +
   drivers/gpu/drm/xen/Makefile|   6 +
   drivers/gpu/drm/xen/xen_drm_front.h |  74 ++
   drivers/gpu/drm/xen/xen_drm_front_drv.c |  80 ++-
   drivers/gpu/drm/xen/xen_drm_front_drv.h |   1 +
   drivers/gpu/drm/xen/xen_drm_front_gem.c | 360 

   drivers/gpu/drm/xen/xen_drm_front_gem.h |  46 
   drivers/gpu/drm/xen/xen_drm_front_gem_cma.c |  93 +++
   8 files changed, 667 insertions(+), 6 deletions(-)
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.c
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.h
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c

diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig
index 4cca160782ab..4f4abc91f3b6 100644
--- a/drivers/gpu/drm/xen/Kconfig
+++ b/drivers/gpu/drm/xen/Kconfig
@@ -15,3 +15,16 @@ config DRM_XEN_FRONTEND
help
  Choose this option if you want to enable a para-virtualized
  frontend DRM/KMS driver for Xen guest OSes.
+
+config DRM_XEN_FRONTEND_CMA
+   bool "Use DRM CMA to allocate dumb buffers"
+   depends on DRM_XEN_FRONTEND
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   help
+ Use DRM CMA helpers to allocate display buffers.
+ This is useful for the use-cases when guest driver needs to
+ share or export buffers to other drivers which only expect
+ contiguous buffers.
+ Note: in this mode driver cannot use buffers allocated
+ by the backend.
diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
index 4fcb0da1a9c5..12376ec78fbc 100644
--- a/drivers/gpu/drm/xen/Makefile
+++ b/drivers/gpu/drm/xen/Makefile
@@ -8,4 +8,10 @@ drm_xen_front-objs := xen_drm_front.o \
  xen_drm_front_shbuf.o \
  xen_drm_front_cfg.o
+ifeq ($(CONFIG_DRM_XEN_FRONTEND_CMA),y)
+   drm_xen_front-objs += xen_drm_front_gem_cma.o
+else
+   drm_xen_front-objs += xen_drm_front_gem.o
+endif
+
   obj-$(CONFIG_DRM_XEN_FRONTEND) += drm_xen_front.o
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h 
b/drivers/gpu/drm/xen/xen_drm_front.h
index 

Re: [PATCH 2/3] drm/sun4i: rgb: Fix potential division by zero

[Chen-Yu Tsai]

On Wed, Feb 21, 2018 at 8:57 PM, Maxime Ripard
 wrote:
> In the case where mode_valid callback of our RGB connector was called
> before mode_set was being called, the range of dividers would not be set,
> resulting in a division by zero later on in the clk_round_rate logic.
>
> Set the range of dividers before calling clk_round_rate to fix this.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/sun4i: crtc: Call drm_crtc_vblank_on / drm_crtc_vblank_off

[Chen-Yu Tsai]

On Wed, Feb 21, 2018 at 8:57 PM, Maxime Ripard
 wrote:
> Make sure that the CRTC code will call the enable/disable_vblank hooks.
>
> Otherwise, since the refcounting will be off, we might end up in a
> situation where the vblank management functions are called while the CRTC
> is off.
>
> Signed-off-by: Maxime Ripard 

Reviewed-by: Chen-Yu Tsai 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Daniel Vetter]

On Tue, Mar 06, 2018 at 08:29:20AM +0100, Daniel Vetter wrote:
> On Wed, Feb 21, 2018 at 04:19:40PM +0100, Maarten Lankhorst wrote:
> > Hey,
> > 
> > Op 21-02-18 om 15:37 schreef Rob Clark:
> > > Follow the same pattern of locking as with other state objects.  This
> > > avoids boilerplate in the driver.
> > I'm afraid this will prohibit any uses of this on i915, since it still uses 
> > legacy lock_all().
> > 
> > Oh well, afaict nothing in i915 uses private objects, so I don't think it's 
> > harmful. :)
> 
> We do use private objects, as part of dp mst helpers. But I also thought
> that the only users left of lock_all are in the debugfs code, where this
> really doesn't matter all that much.

Correction, we use it in other places than debugfs. But thanks to Ville's
private state obj refactoring we now have drm_atomic_private_obj_init(),
so it's easy to add all the private state objects to a new list in
drm_dev->mode_config.private_states or so, and use that list in
drm_modeset_lock_all_ctx to also take driver private locks.

I think that would actually be useful in other places, just in case.
-Daniel

> 
> > Could you cc intel-gfx just in case?
> 
> Yeah, best to double-check with CI.
> 
> > > Signed-off-by: Rob Clark 
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c | 9 -
> > >  include/drm/drm_atomic.h | 5 +
> > >  2 files changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index fc8c4da409ff..004e621ab307 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct drm_private_obj 
> > > *obj,
> > >  {
> > >   memset(obj, 0, sizeof(*obj));
> > >  
> > > + drm_modeset_lock_init(>lock);
> > > +
> > >   obj->state = state;
> > >   obj->funcs = funcs;
> > >  }
> > > @@ -1093,6 +1095,7 @@ void
> > >  drm_atomic_private_obj_fini(struct drm_private_obj *obj)
> > >  {
> > >   obj->funcs->atomic_destroy_state(obj, obj->state);
> > > + drm_modeset_lock_fini(>lock);
> > >  }
> > >  EXPORT_SYMBOL(drm_atomic_private_obj_fini);
> > >  
> > > @@ -1113,7 +1116,7 @@ struct drm_private_state *
> > >  drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
> > >struct drm_private_obj *obj)
> > >  {
> > > - int index, num_objs, i;
> > > + int index, num_objs, i, ret;
> > >   size_t size;
> > >   struct __drm_private_objs_state *arr;
> > >   struct drm_private_state *obj_state;
> > > @@ -1122,6 +1125,10 @@ drm_atomic_get_private_obj_state(struct 
> > > drm_atomic_state *state,
> > >   if (obj == state->private_objs[i].ptr)
> > >   return state->private_objs[i].state;
> > >  
> > > + ret = drm_modeset_lock(>lock, state->acquire_ctx);
> > > + if (ret)
> > > + return ERR_PTR(ret);
> > > +
> > >   num_objs = state->num_private_objs + 1;
> > >   size = sizeof(*state->private_objs) * num_objs;
> > >   arr = krealloc(state->private_objs, size, GFP_KERNEL);
> > > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> > > index 09076a625637..9ae53b73c9d2 100644
> > > --- a/include/drm/drm_atomic.h
> > > +++ b/include/drm/drm_atomic.h
> > > @@ -218,6 +218,11 @@ struct drm_private_state_funcs {
> > >   * _modeset_lock is required to duplicate and update this object's 
> > > state.
> > >   */
> > >  struct drm_private_obj {
> > > + /**
> > > +  * @lock: Modeset lock to protect the state object.
> > > +  */
> > > + struct drm_modeset_lock lock;
> > > +
> > >   /**
> > >* @state: Current atomic state for this driver private object.
> > >*/
> > 
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
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] drm/sun4i: tcon: Reduce the scope of the LVDS error a bit

[Chen-Yu Tsai]

On Wed, Feb 21, 2018 at 8:57 PM, Maxime Ripard
 wrote:
> The current logic to deal with old DT missing the LVDS properties doesn't
> take into account whether the LVDS output is supported in the first place,
> resulting in spurious error messages on SoCs where it doesn't even matter.
>
> Introduce a new TCON flag to list if LVDS is supported at all to prevent
> this from happening.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 86 
> --
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |  1 +
>  2 files changed, 46 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 3c15cf24b503..6ff0e2e84e81 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -870,52 +870,56 @@ static int sun4i_tcon_bind(struct device *dev, struct 
> device *master,
> return ret;
> }
>
> -   /*
> -* This can only be made optional since we've had DT nodes
> -* without the LVDS reset properties.
> -*
> -* If the property is missing, just disable LVDS, and print a
> -* warning.
> -*/
> -   tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
> -   if (IS_ERR(tcon->lvds_rst)) {
> -   dev_err(dev, "Couldn't get our reset line\n");
> -   return PTR_ERR(tcon->lvds_rst);
> -   } else if (tcon->lvds_rst) {
> -   has_lvds_rst = true;
> -   reset_control_reset(tcon->lvds_rst);
> -   } else {
> -   has_lvds_rst = false;
> -   }
> +   if (tcon->quirks->supports_lvds) {
> +   /*
> +* This can only be made optional since we've had DT
> +* nodes without the LVDS reset properties.
> +*
> +* If the property is missing, just disable LVDS, and
> +* print a warning.
> +*/
> +   tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
> +   if (IS_ERR(tcon->lvds_rst)) {
> +   dev_err(dev, "Couldn't get our reset line\n");
> +   return PTR_ERR(tcon->lvds_rst);
> +   } else if (tcon->lvds_rst) {
> +   has_lvds_rst = true;
> +   reset_control_reset(tcon->lvds_rst);
> +   } else {
> +   has_lvds_rst = false;
> +   }
>
> -   /*
> -* This can only be made optional since we've had DT nodes
> -* without the LVDS reset properties.
> -*
> -* If the property is missing, just disable LVDS, and print a
> -* warning.
> -*/
> -   if (tcon->quirks->has_lvds_alt) {
> -   tcon->lvds_pll = devm_clk_get(dev, "lvds-alt");
> -   if (IS_ERR(tcon->lvds_pll)) {
> -   if (PTR_ERR(tcon->lvds_pll) == -ENOENT) {
> -   has_lvds_alt = false;
> +   /*
> +* This can only be made optional since we've had DT
> +* nodes without the LVDS reset properties.

This comment doesn't match the code following it. Otherwise,

Reviewed-by: Chen-Yu Tsai 

> +*
> +* If the property is missing, just disable LVDS, and
> +* print a warning.
> +*/
> +   if (tcon->quirks->has_lvds_alt) {
> +   tcon->lvds_pll = devm_clk_get(dev, "lvds-alt");
> +   if (IS_ERR(tcon->lvds_pll)) {
> +   if (PTR_ERR(tcon->lvds_pll) == -ENOENT) {
> +   has_lvds_alt = false;
> +   } else {
> +   dev_err(dev, "Couldn't get the LVDS 
> PLL\n");
> +   return PTR_ERR(tcon->lvds_pll);
> +   }
> } else {
> -   dev_err(dev, "Couldn't get the LVDS PLL\n");
> -   return PTR_ERR(tcon->lvds_pll);
> +   has_lvds_alt = true;
> }
> -   } else {
> -   has_lvds_alt = true;
> }
> -   }
>
> -   if (!has_lvds_rst || (tcon->quirks->has_lvds_alt && !has_lvds_alt)) {
> -   dev_warn(dev,
> -"Missing LVDS properties, Please upgrade your DT\n");
> -   dev_warn(dev, "LVDS output disabled\n");
> +   if (!has_lvds_rst ||
> +   (tcon->quirks->has_lvds_alt && !has_lvds_alt)) {
> +   dev_warn(dev, "Missing LVDS properties, Please 
> upgrade your DT\n");
> +   dev_warn(dev, "LVDS output disabled\n");
> +   

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Daniel Vetter]

On Wed, Feb 21, 2018 at 06:36:54PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 21, 2018 at 11:17:21AM -0500, Rob Clark wrote:
> > On Wed, Feb 21, 2018 at 10:54 AM, Ville Syrjälä
> >  wrote:
> > > On Wed, Feb 21, 2018 at 10:36:06AM -0500, Rob Clark wrote:
> > >> On Wed, Feb 21, 2018 at 10:27 AM, Ville Syrjälä
> > >>  wrote:
> > >> > On Wed, Feb 21, 2018 at 10:20:03AM -0500, Rob Clark wrote:
> > >> >> On Wed, Feb 21, 2018 at 10:07 AM, Ville Syrjälä
> > >> >>  wrote:
> > >> >> > On Wed, Feb 21, 2018 at 09:54:49AM -0500, Rob Clark wrote:
> > >> >> >> On Wed, Feb 21, 2018 at 9:49 AM, Ville Syrjälä
> > >> >> >>  wrote:
> > >> >> >> > On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote:
> > >> >> >> >> Follow the same pattern of locking as with other state objects. 
> > >> >> >> >>  This
> > >> >> >> >> avoids boilerplate in the driver.
> > >> >> >> >
> > >> >> >> > I'm not sure we really want to do this. What if the driver wants 
> > >> >> >> > a
> > >> >> >> > custom locking scheme for this state?
> > >> >> >>
> > >> >> >> That seems like something we want to discourage, ie. all the more
> > >> >> >> reason for this patch.
> > >> >> >>
> > >> >> >> There is no reason drivers could not split their global state into
> > >> >> >> multiple private objs's, each with their own lock, for more fine
> > >> >> >> grained locking.  That is basically the only valid reason I can 
> > >> >> >> think
> > >> >> >> of for "custom locking".
> > >> >> >
> > >> >> > In i915 we have at least one case that would want something close 
> > >> >> > to an
> > >> >> > rwlock. Any crtc lock is enough for read, need all of them for 
> > >> >> > write.
> > >> >> > Though if we wanted to use private objs for that we might need to
> > >> >> > actually make the states refcounted as well, otherwise I can imagine
> > >> >> > we might land in some use-after-free issues once again.
> > >> >> >
> > >> >> > Maybe we could duplicate the state into per-crtc and global copies, 
> > >> >> > but
> > >> >> > then we have to keep all of those in sync somehow which doesn't 
> > >> >> > sound
> > >> >> > particularly pleasant.
> > >> >>
> > >> >> Or just keep your own driver lock for read, and use that plus the core
> > >> >> modeset lock for write?
> > >> >
> > >> > If we can't add the private obj to the state we can't really use it.
> > >> >
> > >>
> > >> I'm not sure why that is strictly true (that you need to add it to the
> > >> state if for read-only), since you'd be guarding it with your own
> > >> driver read-lock you can just priv->foo_state->bar.
> > >>
> > >> Since it is read-only access, there is no roll-back to worry about for
> > >> test-only or failed atomic_check()s..
> > >
> > > That would be super ugly. We want to access the information the same
> > > way whether it has been modified or not.
> > 
> > Well, I mean the whole idea of what you want to do seems a bit super-ugly 
> > ;-)
> > 
> > I mean, in mdp5 the assigned global resources go in plane/crtc state,
> > and tracking of what is assigned to which plane/crtc is in global
> > state, so it fits nicely in the current locking model.  For i915, I'm
> > not quite sure what is the global state you are concerned about, so it
> > is a bit hard to talk about the best solution in the abstract.  Maybe
> > the better option is to teach modeset-lock how to be a rwlock instead?
> 
> The thing I'm thinking is the core display clock (cdclk) frequency which
> we need to consult whenever computing plane states and whatnot. We don't
> want a modeset on one crtc to block a plane update on another crtc
> unless we actually have to bump the cdclk (which would generally require
> all crtcs to undergo a full modeset). Seems like a generally useful
> pattern to me.

The usual way to fix that is to have read-only copies of the state in the
plane or crtc states. And for writing (or if the requirement changes) you
have to lock all the objects. Essentially what Rob's doing for his
plane/crtc assignment stuff.

What we do in i915 is kinda not what I've been recommending to everyone
else, because it is a rather tricky and complicated way to get things
done. Sure there's a tradeoff between duplicating data and complicated
locking schemes, but I think for the kms case having to explicitly type
code that reflects the depencies in computation (instead of having that
embedded implicitly in the locking scheme) is a feature, not a bug.
-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 v4 15/38] drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the panel

[Marek Szyprowski]

Hi All,

This is the patch, which introduces the issue I've pointed here:

https://lists.freedesktop.org/archives/dri-devel/2018-March/167794.html

On 2018-03-05 23:23, Enric Balletbo i Serra wrote:

From: Lin Huang 

When panel is shut down, we should make sure edp can be disabled to avoid
undefined behavior.

Cc: Stéphane Marchesin 
Signed-off-by: Lin Huang 
Signed-off-by: zain wang 
Signed-off-by: Sean Paul 
Signed-off-by: Thierry Escande 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Enric Balletbo i Serra 
---

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 92fb9a072cb6..9b7d530ad24c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1160,6 +1160,12 @@ static int analogix_dp_set_bridge(struct 
analogix_dp_device *dp)
  
  	pm_runtime_get_sync(dp->dev);
  
+	ret = clk_prepare_enable(dp->clock);

+   if (ret < 0) {
+   DRM_ERROR("Failed to prepare_enable the clock clk [%d]\n", ret);
+   goto out_dp_clk_pre;
+   }
+
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
  
@@ -1191,6 +1197,8 @@ static int analogix_dp_set_bridge(struct analogix_dp_device *dp)

phy_power_off(dp->phy);
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
+   clk_disable_unprepare(dp->clock);
+out_dp_clk_pre:
pm_runtime_put_sync(dp->dev);
  
  	return ret;

@@ -1234,10 +1242,13 @@ static void analogix_dp_bridge_disable(struct 
drm_bridge *bridge)
  
  	disable_irq(dp->irq);

phy_power_off(dp->phy);
+   analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);


In case of Exynos DP, external PHY is used to power the DP block, so no
register access should be performed after phy_power_off(). Please move
analogix_dp_set_analog_power_down() before phy_power_off().

  
  	if (dp->plat_data->power_off)

dp->plat_data->power_off(dp->plat_data);
  
+	clk_disable_unprepare(dp->clock);

+
pm_runtime_put_sync(dp->dev);
  
  	ret = analogix_dp_prepare_panel(dp, false, true);


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

[Daniel Vetter]

On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote:
> Follow the same pattern of locking as with other state objects.  This
> avoids boilerplate in the driver.
> 
> Signed-off-by: Rob Clark 

Please also adjust the kernel doc, and I think we can remove the locking
WARN_ON in drm_atomic_get_mst_topology_state after this patch (plus again
adjust the kerneldoc for that please).

Otherwise I think this makes sense, and ecnourages reasonable semantics
for driver private state objects.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic.c | 9 -
>  include/drm/drm_atomic.h | 5 +
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index fc8c4da409ff..004e621ab307 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct drm_private_obj *obj,
>  {
>   memset(obj, 0, sizeof(*obj));
>  
> + drm_modeset_lock_init(>lock);
> +
>   obj->state = state;
>   obj->funcs = funcs;
>  }
> @@ -1093,6 +1095,7 @@ void
>  drm_atomic_private_obj_fini(struct drm_private_obj *obj)
>  {
>   obj->funcs->atomic_destroy_state(obj, obj->state);
> + drm_modeset_lock_fini(>lock);
>  }
>  EXPORT_SYMBOL(drm_atomic_private_obj_fini);
>  
> @@ -1113,7 +1116,7 @@ struct drm_private_state *
>  drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
>struct drm_private_obj *obj)
>  {
> - int index, num_objs, i;
> + int index, num_objs, i, ret;
>   size_t size;
>   struct __drm_private_objs_state *arr;
>   struct drm_private_state *obj_state;
> @@ -1122,6 +1125,10 @@ drm_atomic_get_private_obj_state(struct 
> drm_atomic_state *state,
>   if (obj == state->private_objs[i].ptr)
>   return state->private_objs[i].state;
>  
> + ret = drm_modeset_lock(>lock, state->acquire_ctx);
> + if (ret)
> + return ERR_PTR(ret);
> +
>   num_objs = state->num_private_objs + 1;
>   size = sizeof(*state->private_objs) * num_objs;
>   arr = krealloc(state->private_objs, size, GFP_KERNEL);
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 09076a625637..9ae53b73c9d2 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -218,6 +218,11 @@ struct drm_private_state_funcs {
>   * _modeset_lock is required to duplicate and update this object's state.
>   */
>  struct drm_private_obj {
> + /**
> +  * @lock: Modeset lock to protect the state object.
> +  */
> + struct drm_modeset_lock lock;
> +
>   /**
>* @state: Current atomic state for this driver private object.
>*/
> -- 
> 2.14.3
> 
> ___
> 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/4] drm/atomic: integrate modeset lock with private objects

[Daniel Vetter]

On Wed, Feb 21, 2018 at 04:19:40PM +0100, Maarten Lankhorst wrote:
> Hey,
> 
> Op 21-02-18 om 15:37 schreef Rob Clark:
> > Follow the same pattern of locking as with other state objects.  This
> > avoids boilerplate in the driver.
> I'm afraid this will prohibit any uses of this on i915, since it still uses 
> legacy lock_all().
> 
> Oh well, afaict nothing in i915 uses private objects, so I don't think it's 
> harmful. :)

We do use private objects, as part of dp mst helpers. But I also thought
that the only users left of lock_all are in the debugfs code, where this
really doesn't matter all that much.

> Could you cc intel-gfx just in case?

Yeah, best to double-check with CI.

> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 9 -
> >  include/drm/drm_atomic.h | 5 +
> >  2 files changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index fc8c4da409ff..004e621ab307 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1078,6 +1078,8 @@ drm_atomic_private_obj_init(struct drm_private_obj 
> > *obj,
> >  {
> > memset(obj, 0, sizeof(*obj));
> >  
> > +   drm_modeset_lock_init(>lock);
> > +
> > obj->state = state;
> > obj->funcs = funcs;
> >  }
> > @@ -1093,6 +1095,7 @@ void
> >  drm_atomic_private_obj_fini(struct drm_private_obj *obj)
> >  {
> > obj->funcs->atomic_destroy_state(obj, obj->state);
> > +   drm_modeset_lock_fini(>lock);
> >  }
> >  EXPORT_SYMBOL(drm_atomic_private_obj_fini);
> >  
> > @@ -1113,7 +1116,7 @@ struct drm_private_state *
> >  drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
> >  struct drm_private_obj *obj)
> >  {
> > -   int index, num_objs, i;
> > +   int index, num_objs, i, ret;
> > size_t size;
> > struct __drm_private_objs_state *arr;
> > struct drm_private_state *obj_state;
> > @@ -1122,6 +1125,10 @@ drm_atomic_get_private_obj_state(struct 
> > drm_atomic_state *state,
> > if (obj == state->private_objs[i].ptr)
> > return state->private_objs[i].state;
> >  
> > +   ret = drm_modeset_lock(>lock, state->acquire_ctx);
> > +   if (ret)
> > +   return ERR_PTR(ret);
> > +
> > num_objs = state->num_private_objs + 1;
> > size = sizeof(*state->private_objs) * num_objs;
> > arr = krealloc(state->private_objs, size, GFP_KERNEL);
> > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> > index 09076a625637..9ae53b73c9d2 100644
> > --- a/include/drm/drm_atomic.h
> > +++ b/include/drm/drm_atomic.h
> > @@ -218,6 +218,11 @@ struct drm_private_state_funcs {
> >   * _modeset_lock is required to duplicate and update this object's 
> > state.
> >   */
> >  struct drm_private_obj {
> > +   /**
> > +* @lock: Modeset lock to protect the state object.
> > +*/
> > +   struct drm_modeset_lock lock;
> > +
> > /**
> >  * @state: Current atomic state for this driver private object.
> >  */
> 
> 

-- 
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 7/9] drm/xen-front: Implement KMS/connector handling

[Oleksandr Andrushchenko]

On 03/06/2018 09:22 AM, Daniel Vetter wrote:

On Mon, Mar 05, 2018 at 02:59:23PM +0200, Oleksandr Andrushchenko wrote:

On 03/05/2018 11:23 AM, Daniel Vetter wrote:

On Wed, Feb 21, 2018 at 10:03:40AM +0200, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:

- implement KMS part of the driver with the help of DRM
simple pipepline helper which is possible due to the fact
that the para-virtualized driver only supports a single
(primary) plane:
- initialize connectors according to XenStore configuration
- handle frame done events from the backend
- generate vblank events
- create and destroy frame buffers and propagate those
  to the backend
- propagate set/reset mode configuration to the backend on display
  enable/disable callbacks
- send page flip request to the backend and implement logic for
  reporting backend IO errors on prepare fb callback

- implement virtual connector handling:
- support only pixel formats suitable for single plane modes
- make sure the connector is always connected
- support a single video mode as per para-virtualized driver
  configuration

Signed-off-by: Oleksandr Andrushchenko 

I think once you've removed the midlayer in the previous patch it would
makes sense to merge the 2 patches into 1.

ok, will squash the two

Bunch more comments below.
-Daniel


---
   drivers/gpu/drm/xen/Makefile |   2 +
   drivers/gpu/drm/xen/xen_drm_front_conn.c | 125 +
   drivers/gpu/drm/xen/xen_drm_front_conn.h |  35 
   drivers/gpu/drm/xen/xen_drm_front_drv.c  |  15 ++
   drivers/gpu/drm/xen/xen_drm_front_drv.h  |  12 ++
   drivers/gpu/drm/xen/xen_drm_front_kms.c  | 299 
+++
   drivers/gpu/drm/xen/xen_drm_front_kms.h  |  30 
   7 files changed, 518 insertions(+)
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.c
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.h
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.c
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.h

diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
index d3068202590f..4fcb0da1a9c5 100644
--- a/drivers/gpu/drm/xen/Makefile
+++ b/drivers/gpu/drm/xen/Makefile
@@ -2,6 +2,8 @@
   drm_xen_front-objs := xen_drm_front.o \
  xen_drm_front_drv.o \
+ xen_drm_front_kms.o \
+ xen_drm_front_conn.o \
  xen_drm_front_evtchnl.o \
  xen_drm_front_shbuf.o \
  xen_drm_front_cfg.o
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c 
b/drivers/gpu/drm/xen/xen_drm_front_conn.c
new file mode 100644
index ..d9986a2e1a3b
--- /dev/null
+++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
@@ -0,0 +1,125 @@
+/*
+ *  Xen para-virtual DRM device
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 2 of the License, or
+ *   (at your option) any later version.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details.
+ *
+ * Copyright (C) 2016-2018 EPAM Systems Inc.
+ *
+ * Author: Oleksandr Andrushchenko 
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "xen_drm_front_conn.h"
+#include "xen_drm_front_drv.h"
+
+static struct xen_drm_front_drm_pipeline *
+to_xen_drm_pipeline(struct drm_connector *connector)
+{
+   return container_of(connector, struct xen_drm_front_drm_pipeline, conn);
+}
+
+static const uint32_t plane_formats[] = {
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_RGB888,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_ARGB1555,
+};
+
+const uint32_t *xen_drm_front_conn_get_formats(int *format_count)
+{
+   *format_count = ARRAY_SIZE(plane_formats);
+   return plane_formats;
+}
+
+static enum drm_connector_status connector_detect(
+   struct drm_connector *connector, bool force)
+{
+   if (drm_dev_is_unplugged(connector->dev))
+   return connector_status_disconnected;
+
+   return connector_status_connected;
+}
+
+#define XEN_DRM_NUM_VIDEO_MODES1
+#define XEN_DRM_CRTC_VREFRESH_HZ   60
+
+static int connector_get_modes(struct drm_connector *connector)
+{
+   struct xen_drm_front_drm_pipeline *pipeline =
+   to_xen_drm_pipeline(connector);
+   struct drm_display_mode *mode;
+   struct 

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

[Daniel Vetter]

On Mon, Mar 05, 2018 at 03:46:07PM +0200, Oleksandr Andrushchenko wrote:
> On 03/05/2018 11:32 AM, Daniel Vetter wrote:
> > On Wed, Feb 21, 2018 at 10:03:41AM +0200, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko 
> > > 
> > > Implement GEM handling depending on driver mode of operation:
> > > depending on the requirements for the para-virtualized environment, namely
> > > requirements dictated by the accompanying DRM/(v)GPU drivers running in 
> > > both
> > > host and guest environments, number of operating modes of para-virtualized
> > > display driver are supported:
> > >   - display buffers can be allocated by either frontend driver or backend
> > >   - display buffers can be allocated to be contiguous in memory or not
> > > 
> > > Note! Frontend driver itself has no dependency on contiguous memory for
> > > its operation.
> > > 
> > > 1. Buffers allocated by the frontend driver.
> > > 
> > > The below modes of operation are configured at compile-time via
> > > frontend driver's kernel configuration.
> > > 
> > > 1.1. Front driver configured to use GEM CMA helpers
> > >   This use-case is useful when used with accompanying DRM/vGPU driver 
> > > in
> > >   guest domain which was designed to only work with contiguous 
> > > buffers,
> > >   e.g. DRM driver based on GEM CMA helpers: such drivers can only 
> > > import
> > >   contiguous PRIME buffers, thus requiring frontend driver to provide
> > >   such. In order to implement this mode of operation para-virtualized
> > >   frontend driver can be configured to use GEM CMA helpers.
> > > 
> > > 1.2. Front driver doesn't use GEM CMA
> > >   If accompanying drivers can cope with non-contiguous memory then, to
> > >   lower pressure on CMA subsystem of the kernel, driver can allocate
> > >   buffers from system memory.
> > > 
> > > Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
> > > may require IOMMU support on the platform, so accompanying DRM/vGPU
> > > hardware can still reach display buffer memory while importing PRIME
> > > buffers from the frontend driver.
> > > 
> > > 2. Buffers allocated by the backend
> > > 
> > > This mode of operation is run-time configured via guest domain 
> > > configuration
> > > through XenStore entries.
> > > 
> > > For systems which do not provide IOMMU support, but having specific
> > > requirements for display buffers it is possible to allocate such buffers
> > > at backend side and share those with the frontend.
> > > For example, if host domain is 1:1 mapped and has DRM/GPU hardware 
> > > expecting
> > > physically contiguous memory, this allows implementing zero-copying
> > > use-cases.
> > > 
> > > Note! Configuration options 1.1 (contiguous display buffers) and 2 
> > > (backend
> > > allocated buffers) are not supported at the same time.
> > > 
> > > Signed-off-by: Oleksandr Andrushchenko 
> > Some suggestions below for some larger cleanup work.
> > -Daniel
> > 
> > > ---
> > >   drivers/gpu/drm/xen/Kconfig |  13 +
> > >   drivers/gpu/drm/xen/Makefile|   6 +
> > >   drivers/gpu/drm/xen/xen_drm_front.h |  74 ++
> > >   drivers/gpu/drm/xen/xen_drm_front_drv.c |  80 ++-
> > >   drivers/gpu/drm/xen/xen_drm_front_drv.h |   1 +
> > >   drivers/gpu/drm/xen/xen_drm_front_gem.c | 360 
> > > 
> > >   drivers/gpu/drm/xen/xen_drm_front_gem.h |  46 
> > >   drivers/gpu/drm/xen/xen_drm_front_gem_cma.c |  93 +++
> > >   8 files changed, 667 insertions(+), 6 deletions(-)
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.c
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.h
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c
> > > 
> > > diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig
> > > index 4cca160782ab..4f4abc91f3b6 100644
> > > --- a/drivers/gpu/drm/xen/Kconfig
> > > +++ b/drivers/gpu/drm/xen/Kconfig
> > > @@ -15,3 +15,16 @@ config DRM_XEN_FRONTEND
> > >   help
> > > Choose this option if you want to enable a para-virtualized
> > > frontend DRM/KMS driver for Xen guest OSes.
> > > +
> > > +config DRM_XEN_FRONTEND_CMA
> > > + bool "Use DRM CMA to allocate dumb buffers"
> > > + depends on DRM_XEN_FRONTEND
> > > + select DRM_KMS_CMA_HELPER
> > > + select DRM_GEM_CMA_HELPER
> > > + help
> > > +   Use DRM CMA helpers to allocate display buffers.
> > > +   This is useful for the use-cases when guest driver needs to
> > > +   share or export buffers to other drivers which only expect
> > > +   contiguous buffers.
> > > +   Note: in this mode driver cannot use buffers allocated
> > > +   by the backend.
> > > diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
> > > index 4fcb0da1a9c5..12376ec78fbc 100644
> > > --- a/drivers/gpu/drm/xen/Makefile
> > > +++ 

Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane

[Thomas Hellstrom]

On 03/06/2018 08:08 AM, Daniel Vetter wrote:

On Mon, Mar 05, 2018 at 11:01:42AM +0100, Thomas Hellstrom wrote:

On 03/05/2018 10:39 AM, Daniel Vetter wrote:

On Mon, Mar 05, 2018 at 10:22:09AM +0100, Thomas Hellstrom wrote:

On 03/05/2018 09:37 AM, Daniel Vetter wrote:

On Wed, Feb 28, 2018 at 09:10:46PM +, Deepak Singh Rawat wrote:

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
Of Daniel Vetter
Sent: Thursday, December 21, 2017 5:11 AM
To: Ville Syrjälä 
Cc: airl...@linux.ie; daniel.vet...@intel.com; dri-
de...@lists.freedesktop.org; Lukasz Spintzyk

Subject: Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for
drm_plane

On Thu, Dec 21, 2017 at 02:46:55PM +0200, Ville Syrjälä wrote:

On Thu, Dec 21, 2017 at 12:10:08PM +0100, Lukasz Spintzyk wrote:

Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
Signed-off-by: Lukasz Spintzyk 
---
drivers/gpu/drm/drm_atomic.c  | 10 ++
drivers/gpu/drm/drm_mode_config.c |  6 ++
drivers/gpu/drm/drm_plane.c   |  1 +
include/drm/drm_mode_config.h |  5 +
include/drm/drm_plane.h   |  3 +++
5 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c

b/drivers/gpu/drm/drm_atomic.c

index b76d49218cf1..cd3b4ed7b04c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -759,6 +759,14 @@ static int drm_atomic_plane_set_property(struct

drm_plane *plane,

state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+   } else if (property == config->dirty_rects_property) {
+   bool replaced = false;
+   int ret = drm_atomic_replace_property_blob_from_id(dev,
+   >dirty_blob,
+   val,
+   -1,
+   );
+   return ret;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct

drm_plane *plane,

*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+   } else if (property == config->dirty_rects_property) {
+   *val = (state->dirty_blob) ? state->dirty_blob->base.id : 0;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,

property, val);

} else {
diff --git a/drivers/gpu/drm/drm_mode_config.c

b/drivers/gpu/drm/drm_mode_config.c

index bc5c46306b3d..d5f1021c6ece 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -293,6 +293,12 @@ static int

drm_mode_create_standard_properties(struct drm_device *dev)

return -ENOMEM;
dev->mode_config.prop_crtc_id = prop;

+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+   "DIRTY_RECTS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.dirty_rects_property = prop;
+
prop = drm_property_create_bool(dev,

DRM_MODE_PROP_ATOMIC,

"ACTIVE");
if (!prop)
diff --git a/drivers/gpu/drm/drm_plane.c

b/drivers/gpu/drm/drm_plane.c

index 37a93cdffb4a..add110f025e5 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device

*dev, struct drm_plane *plane,

drm_object_attach_property(>base, config-

prop_src_y, 0);

drm_object_attach_property(>base, config-

prop_src_w, 0);

drm_object_attach_property(>base, config-

prop_src_h, 0);

+   drm_object_attach_property(>base, config-

dirty_rects_property, 0);

}

if (config->allow_fb_modifiers)
diff --git a/include/drm/drm_mode_config.h

b/include/drm/drm_mode_config.h

index e5f3b43014e1..65f64eb04c0c 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -599,6 +599,11 @@ struct drm_mode_config {
 * _crtc.
 */
struct drm_property *prop_crtc_id;
+   /**
+* @dirty_rects_property: Optional plane property to mark damaged
+* regions on the plane framebuffer.

What exactly would the blob contain?

The comment seems to be implying these are in fb coordiantes as
opposed to plane crtc coordinates? Not sure which would be more
convenient. At least if they're fb coordinates then you probably
want some helpers to translate/rotate/scale those rects to the
crtc coordinates. Actual use depends on the driver/hw I suppose.

Yeah I think we also should add a decoded state to the 

Re: [PATCH 7/9] drm/xen-front: Implement KMS/connector handling

[Daniel Vetter]

On Mon, Mar 05, 2018 at 02:59:23PM +0200, Oleksandr Andrushchenko wrote:
> On 03/05/2018 11:23 AM, Daniel Vetter wrote:
> > On Wed, Feb 21, 2018 at 10:03:40AM +0200, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko 
> > > 
> > > Implement kernel modesetiing/connector handling using
> > > DRM simple KMS helper pipeline:
> > > 
> > > - implement KMS part of the driver with the help of DRM
> > >simple pipepline helper which is possible due to the fact
> > >that the para-virtualized driver only supports a single
> > >(primary) plane:
> > >- initialize connectors according to XenStore configuration
> > >- handle frame done events from the backend
> > >- generate vblank events
> > >- create and destroy frame buffers and propagate those
> > >  to the backend
> > >- propagate set/reset mode configuration to the backend on display
> > >  enable/disable callbacks
> > >- send page flip request to the backend and implement logic for
> > >  reporting backend IO errors on prepare fb callback
> > > 
> > > - implement virtual connector handling:
> > >- support only pixel formats suitable for single plane modes
> > >- make sure the connector is always connected
> > >- support a single video mode as per para-virtualized driver
> > >  configuration
> > > 
> > > Signed-off-by: Oleksandr Andrushchenko 
> > I think once you've removed the midlayer in the previous patch it would
> > makes sense to merge the 2 patches into 1.
> ok, will squash the two
> > 
> > Bunch more comments below.
> > -Daniel
> > 
> > > ---
> > >   drivers/gpu/drm/xen/Makefile |   2 +
> > >   drivers/gpu/drm/xen/xen_drm_front_conn.c | 125 +
> > >   drivers/gpu/drm/xen/xen_drm_front_conn.h |  35 
> > >   drivers/gpu/drm/xen/xen_drm_front_drv.c  |  15 ++
> > >   drivers/gpu/drm/xen/xen_drm_front_drv.h  |  12 ++
> > >   drivers/gpu/drm/xen/xen_drm_front_kms.c  | 299 
> > > +++
> > >   drivers/gpu/drm/xen/xen_drm_front_kms.h  |  30 
> > >   7 files changed, 518 insertions(+)
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.c
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.h
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.c
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.h
> > > 
> > > diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
> > > index d3068202590f..4fcb0da1a9c5 100644
> > > --- a/drivers/gpu/drm/xen/Makefile
> > > +++ b/drivers/gpu/drm/xen/Makefile
> > > @@ -2,6 +2,8 @@
> > >   drm_xen_front-objs := xen_drm_front.o \
> > > xen_drm_front_drv.o \
> > > +   xen_drm_front_kms.o \
> > > +   xen_drm_front_conn.o \
> > > xen_drm_front_evtchnl.o \
> > > xen_drm_front_shbuf.o \
> > > xen_drm_front_cfg.o
> > > diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c 
> > > b/drivers/gpu/drm/xen/xen_drm_front_conn.c
> > > new file mode 100644
> > > index ..d9986a2e1a3b
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
> > > @@ -0,0 +1,125 @@
> > > +/*
> > > + *  Xen para-virtual DRM device
> > > + *
> > > + *   This program is free software; you can redistribute it and/or modify
> > > + *   it under the terms of the GNU General Public License as published by
> > > + *   the Free Software Foundation; either version 2 of the License, or
> > > + *   (at your option) any later version.
> > > + *
> > > + *   This program is distributed in the hope that it will be useful,
> > > + *   but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + *   GNU General Public License for more details.
> > > + *
> > > + * Copyright (C) 2016-2018 EPAM Systems Inc.
> > > + *
> > > + * Author: Oleksandr Andrushchenko 
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +
> > > +#include "xen_drm_front_conn.h"
> > > +#include "xen_drm_front_drv.h"
> > > +
> > > +static struct xen_drm_front_drm_pipeline *
> > > +to_xen_drm_pipeline(struct drm_connector *connector)
> > > +{
> > > + return container_of(connector, struct xen_drm_front_drm_pipeline, conn);
> > > +}
> > > +
> > > +static const uint32_t plane_formats[] = {
> > > + DRM_FORMAT_RGB565,
> > > + DRM_FORMAT_RGB888,
> > > + DRM_FORMAT_XRGB,
> > > + DRM_FORMAT_ARGB,
> > > + DRM_FORMAT_XRGB,
> > > + DRM_FORMAT_ARGB,
> > > + DRM_FORMAT_XRGB1555,
> > > + DRM_FORMAT_ARGB1555,
> > > +};
> > > +
> > > +const uint32_t *xen_drm_front_conn_get_formats(int *format_count)
> > > +{
> > > + *format_count = ARRAY_SIZE(plane_formats);
> > > + return plane_formats;
> > > +}
> > > +
> > > +static enum drm_connector_status 

RE: [PATCH] dma-buf/reservation: should keep later one in add fence(v3)

[Zhou, David(ChunMing)]

Patch looks ok to me, Reviewed-by: Chunming Zhou , and 
it’s better to get others RB as well.

Regards,
David Zhou
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Monk Liu
Sent: Tuesday, March 06, 2018 3:01 PM
To: dri-de...@freedesktop.org
Cc: Liu, Monk 
Subject: [PATCH] dma-buf/reservation: should keep later one in add fence(v3)

v2:
still check context first to avoid warning from dma_fence_is_later apply this 
fix in add_shared_replace as well

v3:
use a bool falg to indict if fence is need to insert to new slot and ignore it 
if it is an eld fence compared with the one with the same context in old->shared

Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
Signed-off-by: Monk Liu 
---
 drivers/dma-buf/reservation.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c 
index 314eb10..a7d0598 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -118,7 +118,8 @@ reservation_object_add_shared_inplace(struct 
reservation_object *obj,
old_fence = rcu_dereference_protected(fobj->shared[i],
reservation_object_held(obj));
 
-   if (old_fence->context == fence->context) {
+   if (old_fence->context == fence->context &&
+   dma_fence_is_later(fence, old_fence)) {
/* memory barrier is added by write_seqcount_begin */
RCU_INIT_POINTER(fobj->shared[i], fence);
write_seqcount_end(>seq);
@@ -158,6 +159,7 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,
  struct dma_fence *fence)
 {
unsigned i, j, k;
+   bool wrong_fence = false;
 
dma_fence_get(fence);
 
@@ -179,15 +181,29 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,
check = rcu_dereference_protected(old->shared[i],
reservation_object_held(obj));
 
-   if (check->context == fence->context ||
-   dma_fence_is_signaled(check))
+   if (dma_fence_is_signaled(check)) {
+   /* put check to tail of fobj if signaled */
RCU_INIT_POINTER(fobj->shared[--k], check);
-   else
+   } else if (check->context == fence->context) {
+   if (dma_fence_is_later(fence, check)) {
+   /* put check to tail of fobj if it is 
deprecated */
+   RCU_INIT_POINTER(fobj->shared[--k], check);
+   } else {
+   /* this is a wrong operation that add an eld 
fence */
+   wrong_fence = true;
+   RCU_INIT_POINTER(fobj->shared[j++], check);
+   }
+   } else {
+   /* add fence to new slot */
RCU_INIT_POINTER(fobj->shared[j++], check);
+   }
}
+
fobj->shared_count = j;
-   RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
-   fobj->shared_count++;
+   if (!wrong_fence) {
+   RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
+   fobj->shared_count++;
+   }
 
 done:
preempt_disable();
--
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

Re: [PATCH v3 0/2] Parfait changes

[Daniel Vetter]

On Mon, Mar 05, 2018 at 11:14:11AM -0500, Joe Moriarty wrote:
> On 2/20/2018 2:11 PM, Joe Moriarty wrote:
> > The following patch(s) are bugs found by the static compiler
> > 'Parfait'.  Care was taken to make sure false positive results
> > were removed from this patchset.
> > 
> > Parfait Overview
> > 
> > 
> > https://labs.oracle.com/pls/apex/f?p=labs:49:P49_PROJECT_ID:13
> > 
> > v1:
> > Initial release
> > 
> > v2:
> > - Split original v1 patch into 4 separate patches per request
> > from Jani Nikula
> > - Fixed system hang during boot up on test machine.
> > 
> > v3:
> > - Made changes requested by Daniel Vetter.
> > 
> > Joe Moriarty (2):
> >drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
> >drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
> > 
> >   drivers/gpu/drm/drm_drv.c| 2 +-
> >   drivers/gpu/drm/drm_vblank.c | 9 +
> >   2 files changed, 10 insertions(+), 1 deletion(-)
> > 
> Ping, Waiting on review/addition of these 2 patches to drm-misc-next.

I was on vacation, and I guess no one else cared. Btw, minor process nit:
Including internal review tags is fairly pointless, since generally I have
no idea about how it happened (there's no public record), nor do I know
the experience level of your reviewer. That makes the r-b tag fairly
value-less in this case. If you want to included it's much better to do
that review on the m-l, after submission.

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

[PATCH] dma-buf/reservation: should keep later one in add fence(v3)

[Monk Liu]

v2:
still check context first to avoid warning from dma_fence_is_later
apply this fix in add_shared_replace as well

v3:
use a bool falg to indict if fence is need to insert to new slot
and ignore it if it is an eld fence compared with the one with
the same context in old->shared

Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
Signed-off-by: Monk Liu 
---
 drivers/dma-buf/reservation.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 314eb10..a7d0598 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -118,7 +118,8 @@ reservation_object_add_shared_inplace(struct 
reservation_object *obj,
old_fence = rcu_dereference_protected(fobj->shared[i],
reservation_object_held(obj));
 
-   if (old_fence->context == fence->context) {
+   if (old_fence->context == fence->context &&
+   dma_fence_is_later(fence, old_fence)) {
/* memory barrier is added by write_seqcount_begin */
RCU_INIT_POINTER(fobj->shared[i], fence);
write_seqcount_end(>seq);
@@ -158,6 +159,7 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,
  struct dma_fence *fence)
 {
unsigned i, j, k;
+   bool wrong_fence = false;
 
dma_fence_get(fence);
 
@@ -179,15 +181,29 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,
check = rcu_dereference_protected(old->shared[i],
reservation_object_held(obj));
 
-   if (check->context == fence->context ||
-   dma_fence_is_signaled(check))
+   if (dma_fence_is_signaled(check)) {
+   /* put check to tail of fobj if signaled */
RCU_INIT_POINTER(fobj->shared[--k], check);
-   else
+   } else if (check->context == fence->context) {
+   if (dma_fence_is_later(fence, check)) {
+   /* put check to tail of fobj if it is 
deprecated */
+   RCU_INIT_POINTER(fobj->shared[--k], check);
+   } else {
+   /* this is a wrong operation that add an eld 
fence */
+   wrong_fence = true;
+   RCU_INIT_POINTER(fobj->shared[j++], check);
+   }
+   } else {
+   /* add fence to new slot */
RCU_INIT_POINTER(fobj->shared[j++], check);
+   }
}
+
fobj->shared_count = j;
-   RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
-   fobj->shared_count++;
+   if (!wrong_fence) {
+   RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
+   fobj->shared_count++;
+   }
 
 done:
preempt_disable();
-- 
2.7.4

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

Re: [PATCH v3 1/8] drm/blend: Add a generic alpha property

[Daniel Vetter]

On Mon, Mar 05, 2018 at 12:08:12PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Monday, 5 March 2018 10:58:41 EET Daniel Vetter wrote:
> > On Wed, Feb 21, 2018 at 02:07:57PM +0100, Maxime Ripard wrote:
> > > On Mon, Feb 19, 2018 at 10:58:40PM +0100, Daniel Vetter wrote:
> > >> On Mon, Feb 19, 2018 at 9:19 PM, Laurent Pinchart wrote:
> > >>> On Friday, 16 February 2018 20:20:41 EET Ville Syrjälä wrote:
> >  On Fri, Feb 16, 2018 at 06:39:29PM +0100, Maxime Ripard wrote:
> > > Some drivers duplicate the logic to create a property to store a
> > > per-plane alpha.
> > > 
> > > This is especially useful if we ever want to support extra
> > > protocols for Wayland like:
> > > https://lists.freedesktop.org/archives/wayland-devel/2017-August/03
> > > 4741.html
> > > 
> > > Let's create a helper in order to move that to the core.
> > > 
> > > Cc: Laurent Pinchart 
> > > Reviewed-by: Boris Brezillon 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > > 
> > >  Documentation/gpu/kms-properties.csv |  2 +-
> > >  drivers/gpu/drm/drm_atomic.c |  4 -
> > >  drivers/gpu/drm/drm_atomic_helper.c  |  4 -
> > >  drivers/gpu/drm/drm_blend.c  | 32 +++-
> > >  include/drm/drm_blend.h  |  1 +-
> > >  include/drm/drm_plane.h  |  6 +-
> > >  6 files changed, 48 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/Documentation/gpu/kms-properties.csv
> > > b/Documentation/gpu/kms-properties.csv index
> > > 927b65e14219..25ad3503d663
> > > 100644
> > > --- a/Documentation/gpu/kms-properties.csv
> > > +++ b/Documentation/gpu/kms-properties.csv
> > > @@ -99,5 +99,5 @@ radeon,DVI-I,“coherent”,RANGE,"Min=0,
> > > Max=1",Connector,TBD>
> > > 
> > >  ,,"""underscan vborder""",RANGE,"Min=0, Max=128",Connector,TBD
> > >  ,Audio,“audio”,ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
> > >  ,FMT Dithering,“dither”,ENUM,"{ ""off"", ""on"" }",Connector,TBD
> > > 
> > > -rcar-du,Generic,"""alpha""",RANGE,"Min=0, Max=255",Plane,TBD
> > > +,,"""alpha""",RANGE,"Min=0, Max=Driver dependant",Plane,Opacity of
> > > the plane from transparent (0) to fully opaque (MAX). If this
> > > property is set to a value different than max, and that the pixel
> > > will define an alpha component, the property will have precendance
> > > and the pixel value will be ignored.
> > >> 
> > >> Please don't document new properties in that csv file, it's an
> > >> unreadable mess. Instead follow how we document standardized
> > >> properties nowadays in full-blown sections. For plane blending we
> > >> have:
> > >> 
> > >> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition->
> > >>  >> properties
> > > 
> > > Ack
> > > 
> > > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > > index 8185e3468a23..5a6f29524f12 100644
> > > --- a/include/drm/drm_plane.h
> > > +++ b/include/drm/drm_plane.h
> > > @@ -42,6 +42,7 @@ struct drm_modeset_acquire_ctx;
> > >   * plane (in 16.16)
> > >   * @src_w: width of visible portion of plane (in 16.16)
> > >   * @src_h: height of visible portion of plane (in 16.16)
> > > + * @alpha: opacity of the plane
> > >   * @rotation: rotation of the plane
> > >   * @zpos: priority of the given plane on crtc (optional)
> > >   * Note that multiple active planes on the same crtc can have an
> > >   identical
> > > @@ -105,6 +106,9 @@ struct drm_plane_state {
> > > uint32_t src_x, src_y;
> > > uint32_t src_h, src_w;
> > > 
> > > +   /* Plane opacity */
> > > +   u8 alpha;
> >  
> >  We may want to make that u16. The general we expect 16bpc for most
> >  color related things, but since this is a range prop I suppose we
> >  should just expose the actual hardware range. But making it u16 might
> >  avoid some head scratching for the first person to have hardware with
> >  higher precision. Either that or we should make the prop creation
> >  fail if the driver asks for more bits than we have in the state.
> > >>> 
> > >>> I'm tempted to go one step further and always make the alpha property
> > >>> 16-bits wide for new users (we can't do so for existing users as it
> > >>> could break userspace), and let drivers convert that internally to
> > >>> the range they need. There could however be drawbacks I don't
> > >>> foresee.
> > >> 
> > >> I think scaling the range to match the hw is the most sensible (yes
> > >> I'm flip-flopping around here). And once someone needs more than u8,
> > >> we can extend the internal representation easily. The external
> > >> representation in the property is an u64, that /should/ be enough for
> > >> the next few years :-)
> > > 
> > > Just 

RE: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

[Liu, Monk]

Make sense, will give v3

-Original Message-
From: Zhou, David(ChunMing) 
Sent: 2018年3月6日 14:08
To: Liu, Monk ; Zhou, David(ChunMing) ; 
dri-de...@freedesktop.org
Subject: Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)



On 2018年03月06日 13:59, Liu, Monk wrote:
>>
>> -if (check->context == fence->context ||
>> +if ((check->context == fence->context &&
>> +dma_fence_is_later(fence, check)) ||
> We still need do more for !dma_fence_is_later(fence, check)   case, in which, 
> we will don't need add new fence to resv slot.
>
> if ((check->context == fence->context) && dma_fence_is_later(fence, check))
>   fobj->shared_count = j;
>   RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
>   fobj->shared_count++;
> } else {
>   dma_fence_put(fence);
> }
>
> No you cannot do that, check is changed and not the one you want, 
> Besides, we don't need to consider the case you mentioned, take only one 
> fence in obj->staged for example:
>
> You add a fence whose context is equal to this fence (check), so 
> current logic will put this check into fobj->shared[++j],
Yes, if !dma_fence_is_later(fence, check), then 'check' will be put to 
fobj->shared[++j], so we don't need add new fence to resv slot, don't we?

Regards,
David Zhou
> so in the end
> Obj->fence will point to fobj, and original old would be rcu_kfree()
>
> No additional action actually needed...
>
> /Monk
>
> -Original Message-
> From: Zhou, David(ChunMing)
> Sent: 2018年3月6日 12:25
> To: Liu, Monk ; dri-de...@freedesktop.org
> Subject: Re: [PATCH] dma-buf/reservation: should keep later one in add 
> fence(v2)
>
>
>
> On 2018年03月06日 11:53, Monk Liu wrote:
>> v2:
>> still check context first to avoid warning from dma_fence_is_later 
>> apply this fix in add_shared_replace as well
>>
>> Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
>> Signed-off-by: Monk Liu 
>> ---
>>drivers/dma-buf/reservation.c | 6 --
>>1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma-buf/reservation.c 
>> b/drivers/dma-buf/reservation.c index 314eb10..c6e3c86 100644
>> --- a/drivers/dma-buf/reservation.c
>> +++ b/drivers/dma-buf/reservation.c
>> @@ -118,7 +118,8 @@ reservation_object_add_shared_inplace(struct 
>> reservation_object *obj,
>>  old_fence = rcu_dereference_protected(fobj->shared[i],
>>  reservation_object_held(obj));
>>
>> -if (old_fence->context == fence->context) {
>> +if (old_fence->context == fence->context &&
>> +dma_fence_is_later(fence, old_fence)) {
>>  /* memory barrier is added by write_seqcount_begin */
>>  RCU_INIT_POINTER(fobj->shared[i], fence);
>>  write_seqcount_end(>seq);
>> @@ -179,7 +180,8 @@ reservation_object_add_shared_replace(struct 
>> reservation_object *obj,
>>  check = rcu_dereference_protected(old->shared[i],
>>  reservation_object_held(obj));
>>
>> -if (check->context == fence->context ||
>> +if ((check->context == fence->context &&
>> +dma_fence_is_later(fence, check)) ||
> We still need do more for !dma_fence_is_later(fence, check)   case, in which, 
> we will don't need add new fence to resv slot.
>
> if ((check->context == fence->context) && dma_fence_is_later(fence, check))
>       fobj->shared_count = j;
>       RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
>       fobj->shared_count++;
> } else {
>       dma_fence_put(fence);
> }
>
>
> Regards,
> David Zhou
>>  dma_fence_is_signaled(check))
>>  RCU_INIT_POINTER(fobj->shared[--k], check);
>>  else

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

Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane

[Daniel Vetter]

On Mon, Mar 05, 2018 at 11:01:42AM +0100, Thomas Hellstrom wrote:
> On 03/05/2018 10:39 AM, Daniel Vetter wrote:
> > On Mon, Mar 05, 2018 at 10:22:09AM +0100, Thomas Hellstrom wrote:
> > > On 03/05/2018 09:37 AM, Daniel Vetter wrote:
> > > > On Wed, Feb 28, 2018 at 09:10:46PM +, Deepak Singh Rawat wrote:
> > > > > > -Original Message-
> > > > > > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On 
> > > > > > Behalf
> > > > > > Of Daniel Vetter
> > > > > > Sent: Thursday, December 21, 2017 5:11 AM
> > > > > > To: Ville Syrjälä 
> > > > > > Cc: airl...@linux.ie; daniel.vet...@intel.com; dri-
> > > > > > de...@lists.freedesktop.org; Lukasz Spintzyk
> > > > > > 
> > > > > > Subject: Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property 
> > > > > > for
> > > > > > drm_plane
> > > > > > 
> > > > > > On Thu, Dec 21, 2017 at 02:46:55PM +0200, Ville Syrjälä wrote:
> > > > > > > On Thu, Dec 21, 2017 at 12:10:08PM +0100, Lukasz Spintzyk wrote:
> > > > > > > > Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
> > > > > > > > Signed-off-by: Lukasz Spintzyk 
> > > > > > > > ---
> > > > > > > >drivers/gpu/drm/drm_atomic.c  | 10 ++
> > > > > > > >drivers/gpu/drm/drm_mode_config.c |  6 ++
> > > > > > > >drivers/gpu/drm/drm_plane.c   |  1 +
> > > > > > > >include/drm/drm_mode_config.h |  5 +
> > > > > > > >include/drm/drm_plane.h   |  3 +++
> > > > > > > >5 files changed, 25 insertions(+)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > > > > index b76d49218cf1..cd3b4ed7b04c 100644
> > > > > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > > > > @@ -759,6 +759,14 @@ static int 
> > > > > > > > drm_atomic_plane_set_property(struct
> > > > > > drm_plane *plane,
> > > > > > > > state->rotation = val;
> > > > > > > > } else if (property == plane->zpos_property) {
> > > > > > > > state->zpos = val;
> > > > > > > > +   } else if (property == config->dirty_rects_property) {
> > > > > > > > +   bool replaced = false;
> > > > > > > > +   int ret = 
> > > > > > > > drm_atomic_replace_property_blob_from_id(dev,
> > > > > > > > +   >dirty_blob,
> > > > > > > > +   val,
> > > > > > > > +   -1,
> > > > > > > > +   );
> > > > > > > > +   return ret;
> > > > > > > > } else if (plane->funcs->atomic_set_property) {
> > > > > > > > return plane->funcs->atomic_set_property(plane, 
> > > > > > > > state,
> > > > > > > > property, val);
> > > > > > > > @@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct
> > > > > > drm_plane *plane,
> > > > > > > > *val = state->rotation;
> > > > > > > > } else if (property == plane->zpos_property) {
> > > > > > > > *val = state->zpos;
> > > > > > > > +   } else if (property == config->dirty_rects_property) {
> > > > > > > > +   *val = (state->dirty_blob) ? 
> > > > > > > > state->dirty_blob->base.id : 0;
> > > > > > > > } else if (plane->funcs->atomic_get_property) {
> > > > > > > > return plane->funcs->atomic_get_property(plane, 
> > > > > > > > state,
> > > > > > property, val);
> > > > > > > > } else {
> > > > > > > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > > > > b/drivers/gpu/drm/drm_mode_config.c
> > > > > > > > index bc5c46306b3d..d5f1021c6ece 100644
> > > > > > > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > > > > > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > > > > > > @@ -293,6 +293,12 @@ static int
> > > > > > drm_mode_create_standard_properties(struct drm_device *dev)
> > > > > > > > return -ENOMEM;
> > > > > > > > dev->mode_config.prop_crtc_id = prop;
> > > > > > > > 
> > > > > > > > +   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> > > > > > > > +   "DIRTY_RECTS", 0);
> > > > > > > > +   if (!prop)
> > > > > > > > +   return -ENOMEM;
> > > > > > > > +   dev->mode_config.dirty_rects_property = prop;
> > > > > > > > +
> > > > > > > > prop = drm_property_create_bool(dev,
> > > > > > DRM_MODE_PROP_ATOMIC,
> > > > > > > > "ACTIVE");
> > > > > > > > if (!prop)
> > > > > > > > diff --git a/drivers/gpu/drm/drm_plane.c
> > > > > > b/drivers/gpu/drm/drm_plane.c
> > > > > > > > index 37a93cdffb4a..add110f025e5 100644
> > > > > > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > > > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > > > > > @@ -258,6 +258,7 @@ int drm_universal_plane_init(struct 
> > 

Re: [PULL] drm-misc-next

[Daniel Vetter]

On Tue, Mar 6, 2018 at 12:20 AM, Sean Paul  wrote:
> On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter  wrote:
>> On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote:
>>> On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul  wrote:
>>> >
>>> > Hi Dave,
>>> > Here's this weeks pull, relatively small when you pull out the trivial 
>>> > fixes.
>>> >
>>> > drm-misc-next-2018-02-28:
>>> > drm-misc-next for 4.17:
>>> >
>>> > UAPI Changes:
>>> >  Fix drm_color_ctm matrix docs to match usage and change the type to
>>> >  __u64 make it obvious (Ville)
>>>
>>> Hi Dave,
>>> Could you please hold off on pulling this? I'd like to sort out this
>>> change a bit more. We're already using the __s64 in chrome, and not
>>> explicitly sign-magnitude. I think it would be prudent to hash this
>>> out a little more.
>>>
>>> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?l=161
>>
>> That code seems to be doing the exact same fun s.u63 math. This all looks
>> consistent to me.
>
> Hmm, yeah, I skimmed too quickly last week.
>
>>
>> Now in hindsight ofc we've screwed up the uapi, but well can't fix that
>> now again ...
>
> Yeah, I'm not convinced we should be changing the type. It's great to
> clarify the documentation to let userspace know it's sign-magnitude,
> but changing the type in-flight with users seems wrong.

But everyone must do unsigned bit ops to get this right, the s64 is
completely meaningless at best, and very likely will confuse someone.
What do we benefit by not changing it? We know all the users and have
the source, so we know that we won't hit another undefined corner of
C, which is about the only real issue I can even imagine. UAPI isn't
cast in stone, we simply have to make sure nothing breaks when we
clarify/update/remove/whatever it.
-Daniel

>
> Sean
>
>> -Daniel
>>
>>>
>>> Sean
>>>
>>> >
>>> > Core Changes:
>>> >  Check modifier with format when checking if a plane state is supported 
>>> > (Ville)
>>> >
>>> > Driver Changes:
>>> >  sun4i: Improve hw plane utilization (Maxime)
>>> >  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>>> >  virtio: Whitespace + checkpatch changes (Rodrigo)
>>> >
>>> > Cc: Maxime Ripard 
>>> > Cc: Oleksandr Andrushchenko 
>>> > Cc: Ville Syrjälä 
>>> > Cc: Rodrigo Siqueira 
>>> >
>>> > Cheers, Sean
>>> >
>>> >
>>> > The following changes since commit 
>>> > 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:
>>> >
>>> >   drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)
>>> >
>>> > are available in the Git repository at:
>>> >
>>> >   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-02-28
>>> >
>>> > for you to fetch changes up to 7628166d5e2883e4cdd142b99863d29d411a81b2:
>>> >
>>> >   tinydrm: add backlight dependency (2018-02-28 15:08:56 -0500)
>>> >
>>> > 
>>> > drm-misc-next for 4.17:
>>> >
>>> > UAPI Changes:
>>> >  Fix drm_color_ctm matrix docs to match usage and change the type to
>>> >  __u64 make it obvious (Ville)
>>> >
>>> > Core Changes:
>>> >  Check modifier with format when checking if a plane state is supported 
>>> > (Ville)
>>> >
>>> > Driver Changes:
>>> >  sun4i: Improve hw plane utilization (Maxime)
>>> >  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>>> >  virtio: Whitespace + checkpatch changes (Rodrigo)
>>> >
>>> > Cc: Maxime Ripard 
>>> > Cc: Oleksandr Andrushchenko 
>>> > Cc: Ville Syrjälä 
>>> > Cc: Rodrigo Siqueira 
>>> >
>>> > 
>>> > Arnd Bergmann (2):
>>> >   drm: fix drm_get_max_iomem type mismatch
>>> >   tinydrm: add backlight dependency
>>> >
>>> > Benjamin Gaignard (1):
>>> >   drm/stm: check pitch and size calculations even if !CONFIG_MMU
>>> >
>>> > Chris Wilson (1):
>>> >   drm/mm: Fix caching of leftmost node in the interval tree
>>> >
>>> > Linus Walleij (1):
>>> >   drm/panel: Fix ARM Versatile panel clocks
>>> >
>>> > Maxime Ripard (4):
>>> >   drm/sun4i: backend: Assign the pipes automatically
>>> >   drm/sun4i: Remove the plane description structure
>>> >   drm/sun4i: backend: Make zpos configurable
>>> >   drm/sun4i: backend: Remove ARGB spoofing
>>> >
>>> > Oleksandr Andrushchenko (5):
>>> >   drm/simple_kms_helper: Fix NULL pointer dereference with no active 
>>> > CRTC
>>> >   drm/simple_kms_helper: Add {enable|disable}_vblank callback support
>>> >   drm/mxsfb: Do not use deprecated drm_driver.{enable|disable)_vblank
>>> >   drm/tve200: Do not use deprecated drm_driver.{enable|disable)_vblank
>>> >   drm/pl111: Do not use deprecated 

[Bug 105355] [BAT] igt@kms_cursor_legacy@* - fail - general protection ip:7f6678e12d13 sp:7ffd689de6e0 error:0 in ld-2.26.so[7f6678e06000+27000]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105355

Marta Löfstedt  changed:

   What|Removed |Added

 Whiteboard||ReadyForDev

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

[Bug 105355] [BAT] igt@kms_cursor_legacy@* - fail - general protection ip:7f6678e12d13 sp:7ffd689de6e0 error:0 in ld-2.26.so[7f6678e06000+27000]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105355

Bug ID: 105355
   Summary: [BAT] igt@kms_cursor_legacy@* - fail - general
protection ip:7f6678e12d13 sp:7ffd689de6e0 error:0 in
ld-2.26.so[7f6678e06000+27000]
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: marta.lofst...@intel.com

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3873/fi-cfl-u/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3873/fi-cfl-u/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3873/fi-cfl-u/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3873/fi-cfl-u/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3873/fi-cfl-u/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3873/fi-cfl-u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3873/fi-cfl-u/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3873/fi-cfl-u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html

<7>[  298.714307] [IGT] kms_chamelium: exiting, ret=77
<6>[  298.826843] traps: kms_cursor_lega[3793] general protection
ip:7f6678e12d13 sp:7ffd689de6e0 error:0 in ld-2.26.so[7f6678e06000+27000]
<6>[  299.142836] traps: kms_cursor_lega[3798] general protection
ip:7f9d74521d13 sp:7fff08debeb0 error:0 in ld-2.26.so[7f9d74515000+27000]
<6>[  299.422554] traps: kms_cursor_lega[3802] general protection
ip:7f261d821d13 sp:7fff06bc7030 error:0 in ld-2.26.so[7f261d815000+27000]
<6>[  299.680435] traps: kms_cursor_lega[3806] general protection
ip:7f1357f67d13 sp:7ffc2fd3a7a0 error:0 in ld-2.26.so[7f1357f5b000+27000]
<6>[  299.928278] traps: kms_cursor_lega[3810] general protection
ip:7f9d0a09cd13 sp:7fff9cd39070 error:0 in ld-2.26.so[7f9d0a09+27000]
<7>[  300.070236] [drm:edp_panel_vdd_off_sync [i915]] Turning eDP port A VDD
off
<7>[  300.070432] [drm:edp_panel_vdd_off_sync [i915]] PP_STATUS: 0x8008
PP_CONTROL: 0x0067
<7>[  300.070470] [drm:intel_power_well_disable [i915]] disabling DC off
<7>[  300.070508] [drm:skl_enable_dc6 [i915]] Enabling DC6
<7>[  300.070541] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02
<6>[  300.159901] traps: kms_cursor_lega[3814] general protection
ip:7f26e6ba5d13 sp:7ffec98a99a0 error:0 in ld-2.26.so[7f26e6b99000+27000]
<6>[  300.412466] traps: kms_cursor_lega[3818] general protection
ip:7fb641caad13 sp:7fffacd1dfb0 error:0 in ld-2.26.so[7fb641c9e000+27000]
<6>[  300.638778] traps: kms_cursor_lega[3822] general protection
ip:7f7d7a375d13 sp:7ffe10215890 error:0 in ld-2.26.so[7f7d7a369000+27000]
<7>[  300.904849] [IGT] kms_flip: executing
<7>[  300.933379] [drm:drm_helper_probe_singl

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

[radeon-alex:drm-next-4.17-wip 458/469] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:897:6: error: implicit declaration of function 'amdgpu_acpi_is_pcie_performance_request_supported'; did yo

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head:   7f462340284582c0180384c046ddd6dda03888b1
commit: e1deba285156fb4023bb48f22068de5b60e34e15 [458/469] drm/amd/pp: Use 
amdgpu acpi helper functions in powerplay
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout e1deba285156fb4023bb48f22068de5b60e34e15
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c: In function 
'hwmgr_init_default_caps':
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:897:6: error: implicit 
>> declaration of function 'amdgpu_acpi_is_pcie_performance_request_supported'; 
>> did you mean 'amdgpu_dpm_force_performance_level'? 
>> [-Werror=implicit-function-declaration]
 if (amdgpu_acpi_is_pcie_performance_request_supported(hwmgr->adev))
 ^
 amdgpu_dpm_force_performance_level
   cc1: some warnings being treated as errors
--
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c: In function 
'smu7_request_link_speed_change_before_state_change':
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:3617:13: error: 
>> implicit declaration of function 'amdgpu_acpi_pcie_performance_request'; did 
>> you mean 'smu7_pcie_performance_request'? 
>> [-Werror=implicit-function-declaration]
   if (0 == amdgpu_acpi_pcie_performance_request(hwmgr->adev, 
PCIE_PERF_REQ_GEN3, false))
^~~~
smu7_pcie_performance_request
   cc1: some warnings being treated as errors

vim +897 drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c

   889  
   890  void hwmgr_init_default_caps(struct pp_hwmgr *hwmgr)
   891  {
   892  phm_cap_unset(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_PCIEPerformanceRequest);
   893  
   894  phm_cap_set(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_UVDDPM);
   895  phm_cap_set(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_VCEDPM);
   896  
 > 897  if 
 > (amdgpu_acpi_is_pcie_performance_request_supported(hwmgr->adev))
   898  phm_cap_set(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_PCIEPerformanceRequest);
   899  
   900  phm_cap_set(hwmgr->platform_descriptor.platformCaps,
   901  PHM_PlatformCaps_DynamicPatchPowerState);
   902  
   903  phm_cap_set(hwmgr->platform_descriptor.platformCaps,
   904  PHM_PlatformCaps_EnableSMU7ThermalManagement);
   905  
   906  phm_cap_set(hwmgr->platform_descriptor.platformCaps,
   907  PHM_PlatformCaps_DynamicPowerManagement);
   908  
   909  phm_cap_set(hwmgr->platform_descriptor.platformCaps,
   910  PHM_PlatformCaps_SMC);
   911  
   912  phm_cap_set(hwmgr->platform_descriptor.platformCaps,
   913  
PHM_PlatformCaps_DynamicUVDState);
   914  
   915  phm_cap_set(hwmgr->platform_descriptor.platformCaps,
   916  
PHM_PlatformCaps_FanSpeedInTableIsRPM);
   917  return;
   918  }
   919  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

[zhoucm1]

On 2018年03月06日 13:59, Liu, Monk wrote:
   
-		if (check->context == fence->context ||

+   if ((check->context == fence->context &&
+   dma_fence_is_later(fence, check)) ||

We still need do more for !dma_fence_is_later(fence, check)   case, in which, 
we will don't need add new fence to resv slot.

if ((check->context == fence->context) && dma_fence_is_later(fence, check))
  fobj->shared_count = j;
  RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
  fobj->shared_count++;
} else {
  dma_fence_put(fence);
}

No you cannot do that, check is changed and not the one you want,
Besides, we don't need to consider the case you mentioned, take only one fence in 
obj->staged for example:

You add a fence whose context is equal to this fence (check), so current logic 
will put this check into fobj->shared[++j],
Yes, if !dma_fence_is_later(fence, check), then 'check' will be put to 
fobj->shared[++j], so we don't need add new fence to resv slot, don't we?


Regards,
David Zhou

so in the end
Obj->fence will point to fobj, and original old would be rcu_kfree()

No additional action actually needed...

/Monk

-Original Message-
From: Zhou, David(ChunMing)
Sent: 2018年3月6日 12:25
To: Liu, Monk ; dri-de...@freedesktop.org
Subject: Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)



On 2018年03月06日 11:53, Monk Liu wrote:

v2:
still check context first to avoid warning from dma_fence_is_later
apply this fix in add_shared_replace as well

Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
Signed-off-by: Monk Liu 
---
   drivers/dma-buf/reservation.c | 6 --
   1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c
b/drivers/dma-buf/reservation.c index 314eb10..c6e3c86 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -118,7 +118,8 @@ reservation_object_add_shared_inplace(struct 
reservation_object *obj,
old_fence = rcu_dereference_protected(fobj->shared[i],
reservation_object_held(obj));
   
-		if (old_fence->context == fence->context) {

+   if (old_fence->context == fence->context &&
+   dma_fence_is_later(fence, old_fence)) {
/* memory barrier is added by write_seqcount_begin */
RCU_INIT_POINTER(fobj->shared[i], fence);
write_seqcount_end(>seq);
@@ -179,7 +180,8 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,
check = rcu_dereference_protected(old->shared[i],
reservation_object_held(obj));
   
-		if (check->context == fence->context ||

+   if ((check->context == fence->context &&
+   dma_fence_is_later(fence, check)) ||

We still need do more for !dma_fence_is_later(fence, check)   case, in which, 
we will don't need add new fence to resv slot.

if ((check->context == fence->context) && dma_fence_is_later(fence, check))
      fobj->shared_count = j;
      RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
      fobj->shared_count++;
} else {
      dma_fence_put(fence);
}


Regards,
David Zhou

dma_fence_is_signaled(check))
RCU_INIT_POINTER(fobj->shared[--k], check);
else


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

RE: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

[Liu, Monk]

>   
> - if (check->context == fence->context ||
> + if ((check->context == fence->context &&
> + dma_fence_is_later(fence, check)) ||
We still need do more for !dma_fence_is_later(fence, check)   case, in which, 
we will don't need add new fence to resv slot.

if ((check->context == fence->context) && dma_fence_is_later(fence, check))
 fobj->shared_count = j;
 RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
 fobj->shared_count++;
} else {
 dma_fence_put(fence);
}

No you cannot do that, check is changed and not the one you want,
Besides, we don't need to consider the case you mentioned, take only one fence 
in obj->staged for example:

You add a fence whose context is equal to this fence (check), so current logic 
will put this check into fobj->shared[++j], so in the end
Obj->fence will point to fobj, and original old would be rcu_kfree() 

No additional action actually needed...

/Monk

-Original Message-
From: Zhou, David(ChunMing) 
Sent: 2018年3月6日 12:25
To: Liu, Monk ; dri-de...@freedesktop.org
Subject: Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)



On 2018年03月06日 11:53, Monk Liu wrote:
> v2:
> still check context first to avoid warning from dma_fence_is_later 
> apply this fix in add_shared_replace as well
>
> Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
> Signed-off-by: Monk Liu 
> ---
>   drivers/dma-buf/reservation.c | 6 --
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/reservation.c 
> b/drivers/dma-buf/reservation.c index 314eb10..c6e3c86 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -118,7 +118,8 @@ reservation_object_add_shared_inplace(struct 
> reservation_object *obj,
>   old_fence = rcu_dereference_protected(fobj->shared[i],
>   reservation_object_held(obj));
>   
> - if (old_fence->context == fence->context) {
> + if (old_fence->context == fence->context &&
> + dma_fence_is_later(fence, old_fence)) {
>   /* memory barrier is added by write_seqcount_begin */
>   RCU_INIT_POINTER(fobj->shared[i], fence);
>   write_seqcount_end(>seq);
> @@ -179,7 +180,8 @@ reservation_object_add_shared_replace(struct 
> reservation_object *obj,
>   check = rcu_dereference_protected(old->shared[i],
>   reservation_object_held(obj));
>   
> - if (check->context == fence->context ||
> + if ((check->context == fence->context &&
> + dma_fence_is_later(fence, check)) ||
We still need do more for !dma_fence_is_later(fence, check)   case, in which, 
we will don't need add new fence to resv slot.

if ((check->context == fence->context) && dma_fence_is_later(fence, check))
     fobj->shared_count = j;
     RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
     fobj->shared_count++;
} else {
     dma_fence_put(fence);
}


Regards,
David Zhou
>   dma_fence_is_signaled(check))
>   RCU_INIT_POINTER(fobj->shared[--k], check);
>   else

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

Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

[zhoucm1]

On 2018年03月06日 11:53, Monk Liu wrote:

v2:
still check context first to avoid warning from dma_fence_is_later
apply this fix in add_shared_replace as well

Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
Signed-off-by: Monk Liu 
---
  drivers/dma-buf/reservation.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 314eb10..c6e3c86 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -118,7 +118,8 @@ reservation_object_add_shared_inplace(struct 
reservation_object *obj,
old_fence = rcu_dereference_protected(fobj->shared[i],
reservation_object_held(obj));
  
-		if (old_fence->context == fence->context) {

+   if (old_fence->context == fence->context &&
+   dma_fence_is_later(fence, old_fence)) {
/* memory barrier is added by write_seqcount_begin */
RCU_INIT_POINTER(fobj->shared[i], fence);
write_seqcount_end(>seq);
@@ -179,7 +180,8 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,
check = rcu_dereference_protected(old->shared[i],
reservation_object_held(obj));
  
-		if (check->context == fence->context ||

+   if ((check->context == fence->context &&
+   dma_fence_is_later(fence, check)) ||
We still need do more for !dma_fence_is_later(fence, check)   case, in 
which, we will don't need add new fence to resv slot.


if ((check->context == fence->context) && dma_fence_is_later(fence, check))
    fobj->shared_count = j;
    RCU_INIT_POINTER(fobj->shared[fobj->shared_count], fence);
    fobj->shared_count++;
} else {
    dma_fence_put(fence);
}


Regards,
David Zhou

dma_fence_is_signaled(check))
RCU_INIT_POINTER(fobj->shared[--k], check);
else


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

[Bug 105354] RIP: dm_update_crtcs_state+0x36b/0x3f0 [amdgpu]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105354

--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 137811
  --> https://bugs.freedesktop.org/attachment.cgi?id=137811=edit
dmesg

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

[PATCH] dma-buf/reservation: should keep later one in add fence(v2)

[Monk Liu]

v2:
still check context first to avoid warning from dma_fence_is_later
apply this fix in add_shared_replace as well

Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
Signed-off-by: Monk Liu 
---
 drivers/dma-buf/reservation.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 314eb10..c6e3c86 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -118,7 +118,8 @@ reservation_object_add_shared_inplace(struct 
reservation_object *obj,
old_fence = rcu_dereference_protected(fobj->shared[i],
reservation_object_held(obj));
 
-   if (old_fence->context == fence->context) {
+   if (old_fence->context == fence->context &&
+   dma_fence_is_later(fence, old_fence)) {
/* memory barrier is added by write_seqcount_begin */
RCU_INIT_POINTER(fobj->shared[i], fence);
write_seqcount_end(>seq);
@@ -179,7 +180,8 @@ reservation_object_add_shared_replace(struct 
reservation_object *obj,
check = rcu_dereference_protected(old->shared[i],
reservation_object_held(obj));
 
-   if (check->context == fence->context ||
+   if ((check->context == fence->context &&
+   dma_fence_is_later(fence, check)) ||
dma_fence_is_signaled(check))
RCU_INIT_POINTER(fobj->shared[--k], check);
else
-- 
2.7.4

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

[Bug 105354] RIP: dm_update_crtcs_state+0x36b/0x3f0 [amdgpu]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105354

Bug ID: 105354
   Summary: RIP: dm_update_crtcs_state+0x36b/0x3f0 [amdgpu]
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mikhail.v.gavri...@gmail.com

kernel: 4.16.0-rc1-git63e5921e856b
mesa: 18.1.0-0.4.git56dc9f9
llvm: 7.0.0-0.1.r326462

[ 5483.411841] [ cut here ]
[ 5483.411844] kernel BUG at
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4666!
[ 5483.411939] invalid opcode:  [#1] SMP PTI
[ 5483.411942] Modules linked in: nls_utf8 isofs rfcomm fuse
nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge
stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables bnep sunrpc
xfs vfat fat libcrc32c intel_rapl x86_pkg_temp_thermal intel_powerclamp
coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul iTCO_wdt ppdev
iTCO_vendor_support ghash_clmulni_intel intel_cstate snd_hda_codec_realtek
intel_uncore snd_hda_codec_generic snd_hda_codec_hdmi snd_usb_audio
intel_rapl_perf
[ 5483.412017]  snd_hda_intel snd_hda_codec snd_usbmidi_lib btusb snd_rawmidi
btrtl btbcm snd_hda_core btintel bluetooth snd_hwdep snd_seq huawei_cdc_ncm
gspca_zc3xx snd_seq_device gspca_main cdc_wdm snd_pcm v4l2_common option
cdc_ncm usb_wwan videodev ecdh_generic mei_me cdc_ether snd_timer joydev media
rfkill usbnet snd pcspkr soundcore i2c_i801 shpchp lpc_ich mei parport_pc
parport video binfmt_misc hid_logitech_hidpp hid_logitech_dj amdgpu uas
usb_storage chash i2c_algo_bit gpu_sched drm_kms_helper ttm drm crc32c_intel
r8169 mii
[ 5483.412080] CPU: 6 PID: 2564 Comm: gnome-shell Tainted: GW   
4.16.0-rc1-amd-vega+ #2
[ 5483.412083] Hardware name: Gigabyte Technology Co., Ltd. Z87M-D3H/Z87M-D3H,
BIOS F11 08/12/2014
[ 5483.412132] RIP: 0010:dm_update_crtcs_state+0x36b/0x3f0 [amdgpu]
[ 5483.412135] RSP: 0018:b97e49477ad0 EFLAGS: 00010246
[ 5483.412138] RAX: 0020 RBX: 9b76a0058000 RCX:
000e4719
[ 5483.412141] RDX: 000e4718 RSI: 9b76be3e7160 RDI:
001e7160
[ 5483.412144] RBP: 9b76a1317000 R08: 0001 R09:

[ 5483.412146] R10:  R11:  R12:

[ 5483.412149] R13: 9b7502ed4000 R14: 9b70cd9aa800 R15:
9b7501b7d300
[ 5483.412152] FS:  7fc04ba63ac0() GS:9b76be20()
knlGS:
[ 5483.412154] CS:  0010 DS:  ES:  CR0: 80050033
[ 5483.412157] CR2: 7fc024109d80 CR3: 0007a798e001 CR4:
001606e0
[ 5483.412159] Call Trace:
[ 5483.412197]  amdgpu_dm_atomic_check+0x1b5/0x420 [amdgpu]
[ 5483.412216]  drm_atomic_check_only+0x370/0x570 [drm]
[ 5483.412221]  ? refcount_inc+0x5/0x30
[ 5483.412232]  ? drm_property_blob_get+0xe/0x20 [drm]
[ 5483.412243]  drm_atomic_commit+0x13/0x50 [drm]
[ 5483.412252]  drm_atomic_helper_legacy_gamma_set+0x112/0x160 [drm_kms_helper]
[ 5483.412263]  drm_mode_gamma_set_ioctl+0x183/0x1f0 [drm]
[ 5483.412278]  ? drm_mode_crtc_set_gamma_size+0xa0/0xa0 [drm]
[ 5483.412287]  drm_ioctl_kernel+0x5b/0xb0 [drm]
[ 5483.412297]  drm_ioctl+0x2e2/0x380 [drm]
[ 5483.412308]  ? drm_mode_crtc_set_gamma_size+0xa0/0xa0 [drm]
[ 5483.412314]  ? __pm_runtime_resume+0x54/0x90
[ 5483.412319]  ? trace_hardirqs_on_caller+0xed/0x180
[ 5483.412344]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[ 5483.412350]  do_vfs_ioctl+0xa5/0x6e0
[ 5483.412356]  SyS_ioctl+0x74/0x80
[ 5483.412361]  do_syscall_64+0x7a/0x220
[ 5483.412366]  entry_SYSCALL_64_after_hwframe+0x26/0x9b
[ 5483.412370] RIP: 0033:0x7fc048b13b87
[ 5483.412372] RSP: 002b:7ffdf4ae48a8 EFLAGS: 0246 ORIG_RAX:
0010
[ 5483.412376] RAX: ffda RBX: 55c00eba4080 RCX:
7fc048b13b87
[ 5483.412378] RDX: 7ffdf4ae48e0 RSI: c02064a5 RDI:
0008
[ 5483.412381] RBP: 7ffdf4ae48e0 R08: 7fc0240a5ca0 R09:
7fc024109d60
[ 5483.412384] R10: 55c00eba4080 R11: 0246 R12:
c02064a5
[ 5483.412386] R13: 0008 R14: 7fc024308380 R15:
7fc0243094f0
[ 5483.412394] Code: 44 24 18 c6 00 01 0f 84 cd fd ff ff e9 bf fd ff ff 41 0f
b6 45 0a a8 0e 0f 84 36 fd ff ff 48 c7 04 24 00 00 00 00 e9 ee fd ff ff <0f> 0b
48 83 bb e0 14 00 00 00 0f 84 01 ff ff ff 48 83 3c 24 00 
[ 5483.412496] RIP: dm_update_crtcs_state+0x36b/0x3f0 [amdgpu] RSP:
b97e49477ad0
[ 5483.412514] ---[ end trace 9b840e1ed652b6a1 ]---

-- 
You are receiving this mail because:
You are the 

RE: [PATCH] dma-buf/reservation: should keep the new fence in add_shared_inplace

[Liu, Monk]

Yeah, right 

-Original Message-
From: Zhou, David(ChunMing) 
Sent: 2018年3月6日 11:38
To: Liu, Monk ; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] dma-buf/reservation: should keep the new fence in 
add_shared_inplace



On 2018年03月06日 11:09, Monk Liu wrote:
> Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
> Signed-off-by: Monk Liu 
> ---
>   drivers/dma-buf/reservation.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/reservation.c 
> b/drivers/dma-buf/reservation.c index 314eb10..29b7e45 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -118,7 +118,7 @@ reservation_object_add_shared_inplace(struct 
> reservation_object *obj,
>   old_fence = rcu_dereference_protected(fobj->shared[i],
>   reservation_object_held(obj));
>   
> - if (old_fence->context == fence->context) {
> + if (dma_fence_is_later(fence, old_fence)) {
OK, good catch, to avoid warning of different context, which should be "if 
((old_fence->context == fence->context) && dma_fence_is_later(fence,
old_fence)) { "
and reservation_object_add_shared_replace need this fix as well.

Regards,
David Zhou
>   /* memory barrier is added by write_seqcount_begin */
>   RCU_INIT_POINTER(fobj->shared[i], fence);
>   write_seqcount_end(>seq);

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

Re: [PATCH] dma-buf/reservation: should keep the new fence in add_shared_inplace

[zhoucm1]

On 2018年03月06日 11:09, Monk Liu wrote:

Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
Signed-off-by: Monk Liu 
---
  drivers/dma-buf/reservation.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 314eb10..29b7e45 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -118,7 +118,7 @@ reservation_object_add_shared_inplace(struct 
reservation_object *obj,
old_fence = rcu_dereference_protected(fobj->shared[i],
reservation_object_held(obj));
  
-		if (old_fence->context == fence->context) {

+   if (dma_fence_is_later(fence, old_fence)) {
OK, good catch, to avoid warning of different context, which should be 
"if ((old_fence->context == fence->context) && dma_fence_is_later(fence, 
old_fence)) { "

and reservation_object_add_shared_replace need this fix as well.

Regards,
David Zhou

/* memory barrier is added by write_seqcount_begin */
RCU_INIT_POINTER(fobj->shared[i], fence);
write_seqcount_end(>seq);


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

[PATCH] dma-buf/reservation: should keep the new fence in add_shared_inplace

[Monk Liu]

Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
Signed-off-by: Monk Liu 
---
 drivers/dma-buf/reservation.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 314eb10..29b7e45 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -118,7 +118,7 @@ reservation_object_add_shared_inplace(struct 
reservation_object *obj,
old_fence = rcu_dereference_protected(fobj->shared[i],
reservation_object_held(obj));
 
-   if (old_fence->context == fence->context) {
+   if (dma_fence_is_later(fence, old_fence)) {
/* memory barrier is added by write_seqcount_begin */
RCU_INIT_POINTER(fobj->shared[i], fence);
write_seqcount_end(>seq);
-- 
2.7.4

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

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

[Stefan Schake]

On Mon, Mar 5, 2018 at 10:15 PM, Eric Anholt  wrote:
> Stefan Schake  writes:
>
>> We allow alpha formats on the primary plane but a partially transparent
>> framebuffer will cause a corrupted display. With this change black pixels
>> are output instead, in line with the behavior for other DRM drivers.
>>
>> Signed-off-by: Stefan Schake 
>> ---
>> Test program is available at https://github.com/stschake/vc4-alpha-test
>
> How about this as a suggestion for a patch series:
>
> vc4_plane_mode_set() sets ALPHA_PREMULT (POS2 bit 29) if alpha is
> enabled.
>
> vc4_plane_mode_set() sets a new vc4_plane->needs_bg_fill boolean to
> (format->has_alpha || !covers_screen) where covers_screenis the
> can_position logic from drm_atomic_helper.c
>
> vc4_crtc_atomic_flush() updates DISPBKGND to enable background fill
> (before vc4_crtc_update_dlist()) if the first plane has needs_bg_fill
> set.
>
> vc4_plane_mode_set() strips off the alpha blend bits if
> !vc4_plane->needs_bg_fill.
>
> This lets us keep avoiding the background fill cost in the normal case,
> and fixes the case where the "primary" plane doesn't cover the screen.
> It doesn't get the background fill turned back off if you transition
> away from primary not covering the screen, but that seems unlikely and
> harder to handle (since you would need to wait for the flip to be done
> before disabling).

I've sent out the series:

https://patchwork.freedesktop.org/series/39411/

I don't think we need the final change since

!needs_bg_fill <=> !(has_alpha||!covers_screen) <=> covers_screen && !has_alpha

so we shouldn't be setting the alpha blend bits in the first place.

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

Re: [DPU PATCH 05/11] drm/msm: Mark the crtc->state->event consumed

[Jeykumar Sankaran]

On 2018-02-28 11:19, Sean Paul wrote:

Don't leave the event != NULL once it's consumed, this is used a signal
to the atomic helpers that the event will be handled by the driver.

Change-Id: Ib934fb2e97bacbb4a1f9c780cc7369c2bb98ed50
Signed-off-by: Sean Paul 


Reviewed-by: Jeykumar Sankaran 


---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 2 ++
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 +
 3 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 94fab2dcca5b..a261021e5deb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -2714,6 +2714,7 @@ static void dpu_crtc_atomic_begin(struct drm_crtc
*crtc,
} else {
spin_lock_irqsave(>event_lock, flags);
dpu_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);
}

@@ -2798,6 +2799,7 @@ static void dpu_crtc_atomic_flush(struct drm_crtc
*crtc,
} else {
spin_lock_irqsave(>event_lock, flags);
dpu_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);
}

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
index 6e5e1aa54ce1..b001699297c4 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
@@ -351,6 +351,7 @@ static void mdp4_crtc_atomic_flush(struct drm_crtc
*crtc,

spin_lock_irqsave(>event_lock, flags);
mdp4_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);

blend_setup(crtc);
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 8c5ed0b59e46..5cb490a58f20 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -704,6 +704,7 @@ static void mdp5_crtc_atomic_flush(struct drm_crtc
*crtc,

spin_lock_irqsave(>event_lock, flags);
mdp5_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(>event_lock, flags);

/*


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

RE: [PATCH 4/5] drm/ttm: add ttm_sg_tt_init

[He, Roger]

Patch 1: Acked-by: Roger He 

Patch 2~5: Reviewed-by: Roger He 

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Monday, March 05, 2018 8:07 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Ben Skeggs 
; Ilia Mirkin ; nouveau 

Subject: Re: [PATCH 4/5] drm/ttm: add ttm_sg_tt_init

Ping?

Am 27.02.2018 um 13:07 schrieb Christian König:
> Hi guys,
>
> at least on amdgpu and radeon the page array allocated by 
> ttm_dma_tt_init is completely unused in the case of DMA-buf sharing.
> So I'm trying to get rid of that by only allocating the DMA address 
> array.
>
> Now the only other user of DMA-buf together with ttm_dma_tt_init is 
> Nouveau. So my question is are you guys using the page array anywhere 
> in your kernel driver in case of a DMA-buf sharing?
>
> If no then I could just make this the default behavior for all drivers 
> and save quite a bit of memory for everybody.
>
> Thanks,
> Christian.
>
> Am 27.02.2018 um 12:49 schrieb Christian König:
>> This allows drivers to only allocate dma addresses, but not a page 
>> array.
>>
>> Signed-off-by: Christian König 
>> ---
>>   drivers/gpu/drm/ttm/ttm_tt.c | 54
>> 
>>   include/drm/ttm/ttm_tt.h |  2 ++
>>   2 files changed, 47 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c 
>> b/drivers/gpu/drm/ttm/ttm_tt.c index 8e0b525cda00..971133106ec2 
>> 100644
>> --- a/drivers/gpu/drm/ttm/ttm_tt.c
>> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
>> @@ -108,6 +108,16 @@ static int
>> ttm_dma_tt_alloc_page_directory(struct ttm_dma_tt *ttm)
>>   return 0;
>>   }
>>   +static int ttm_sg_tt_alloc_page_directory(struct ttm_dma_tt *ttm)
>> +{
>> +    ttm->dma_address = kvmalloc_array(ttm->ttm.num_pages,
>> +  sizeof(*ttm->dma_address),
>> +  GFP_KERNEL | __GFP_ZERO);
>> +    if (!ttm->dma_address)
>> +    return -ENOMEM;
>> +    return 0;
>> +}
>> +
>>   #ifdef CONFIG_X86
>>   static inline int ttm_tt_set_page_caching(struct page *p,
>>     enum ttm_caching_state c_old, @@ -227,8 
>> +237,8 @@ void ttm_tt_destroy(struct ttm_tt *ttm)
>>   ttm->func->destroy(ttm);
>>   }
>>   -int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
>> -    unsigned long size, uint32_t page_flags)
>> +void ttm_tt_init_fields(struct ttm_tt *ttm, struct ttm_bo_device 
>> +*bdev,
>> +    unsigned long size, uint32_t page_flags)
>>   {
>>   ttm->bdev = bdev;
>>   ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT; @@ 
>> -236,6 +246,12 @@ int ttm_tt_init(struct ttm_tt *ttm, struct 
>> ttm_bo_device *bdev,
>>   ttm->page_flags = page_flags;
>>   ttm->state = tt_unpopulated;
>>   ttm->swap_storage = NULL;
>> +}
>> +
>> +int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
>> +    unsigned long size, uint32_t page_flags) {
>> +    ttm_tt_init_fields(ttm, bdev, size, page_flags);
>>     if (ttm_tt_alloc_page_directory(ttm)) {
>>   ttm_tt_destroy(ttm);
>> @@ -258,12 +274,7 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, 
>> struct ttm_bo_device *bdev,
>>   {
>>   struct ttm_tt *ttm = _dma->ttm;
>>   -    ttm->bdev = bdev;
>> -    ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
>> -    ttm->caching_state = tt_cached;
>> -    ttm->page_flags = page_flags;
>> -    ttm->state = tt_unpopulated;
>> -    ttm->swap_storage = NULL;
>> +    ttm_tt_init_fields(ttm, bdev, size, page_flags);
>>     INIT_LIST_HEAD(_dma->pages_list);
>>   if (ttm_dma_tt_alloc_page_directory(ttm_dma)) { @@ -275,11 
>> +286,36 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct 
>> ttm_bo_device *bdev,
>>   }
>>   EXPORT_SYMBOL(ttm_dma_tt_init);
>>   +int ttm_sg_tt_init(struct ttm_dma_tt *ttm_dma, struct 
>> ttm_bo_device *bdev,
>> +   unsigned long size, uint32_t page_flags) {
>> +    struct ttm_tt *ttm = _dma->ttm;
>> +    int ret;
>> +
>> +    ttm_tt_init_fields(ttm, bdev, size, page_flags);
>> +
>> +    INIT_LIST_HEAD(_dma->pages_list);
>> +    if (page_flags & TTM_PAGE_FLAG_SG)
>> +    ret = ttm_sg_tt_alloc_page_directory(ttm_dma);
>> +    else
>> +    ret = ttm_dma_tt_alloc_page_directory(ttm_dma);
>> +    if (ret) {
>> +    ttm_tt_destroy(ttm);
>> +    pr_err("Failed allocating page table\n");
>> +    return -ENOMEM;
>> +    }
>> +    return 0;
>> +}
>> +EXPORT_SYMBOL(ttm_sg_tt_init);
>> +
>>   void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
>>   {
>>   struct ttm_tt *ttm = _dma->ttm;
>>   -    kvfree(ttm->pages);
>> +    if (ttm->pages)
>> +    kvfree(ttm->pages);
>> +    else
>> +    kvfree(ttm_dma->dma_address);
>>   ttm->pages = NULL;
>>   ttm_dma->dma_address = NULL;
>>   }
>> diff --git 

[PATCH 0/3] drm/vc4: Improve alpha format plane support

[Stefan Schake]

This series improves the handling of alpha formats with the VC4 HVS
compositor. Alpha formats are marked as premultiplied as is standard
for DRM. Further fix a display corruption issue when planes with
per-pixel alpha try blending from the (nonexistent) background by
selectively enabling a black background color fill.

This series follows the changes suggested by Eric Anholt in a previous
patch discussion:

https://patchwork.freedesktop.org/patch/207667/

A simple test program for the display corruption issue is available:

https://github.com/stschake/vc4-alpha-test

Stefan Schake (3):
  drm/vc4: Set premultiplied for alpha formats
  drm/vc4: Check if plane requires background fill
  drm/vc4: Enable background color fill when necessary

 drivers/gpu/drm/vc4/vc4_crtc.c  | 22 ++
 drivers/gpu/drm/vc4/vc4_drv.h   |  6 ++
 drivers/gpu/drm/vc4/vc4_plane.c | 16 +++-
 drivers/gpu/drm/vc4/vc4_regs.h  |  1 +
 4 files changed, 44 insertions(+), 1 deletion(-)

-- 
2.7.4

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

[PATCH 3/3] drm/vc4: Enable background color fill when necessary

[Stefan Schake]

Using the hint from the plane state, we turn on the background color
to avoid display corruption from planes blending with the background.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index ce1e3b9..728845f 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -643,9 +643,11 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
 {
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
struct drm_plane *plane;
bool debug_dump_regs = false;
+   bool enable_bg_fill = false;
u32 __iomem *dlist_start = vc4->hvs->dlist + vc4_state->mm.start;
u32 __iomem *dlist_next = dlist_start;
 
@@ -656,6 +658,18 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
 
/* Copy all the active planes' dlist contents to the hardware dlist. */
drm_atomic_crtc_for_each_plane(plane, crtc) {
+   /* Is this the first active plane? */
+   if (dlist_next == dlist_start)
+   /* We need to enable background fill when a plane
+* could be alpha blending from the background, i.e.
+* where no other plane is underneath. It suffices to
+* consider the first active plane here since we set
+* needs_bg_fill such that either the first plane
+* already needs it or all planes on top blend from
+* the first or a lower plane.
+*/
+   enable_bg_fill = to_vc4_plane(plane)->needs_bg_fill;
+
dlist_next += vc4_plane_write_dlist(plane, dlist_next);
}
 
@@ -664,6 +678,14 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
 
WARN_ON_ONCE(dlist_next - dlist_start != vc4_state->mm.size);
 
+   if (enable_bg_fill)
+   /* This sets a black background color fill, as is the case
+* with other DRM drivers.
+*/
+   HVS_WRITE(SCALER_DISPBKGNDX(vc4_crtc->channel),
+ HVS_READ(SCALER_DISPBKGNDX(vc4_crtc->channel)) |
+ SCALER_DISPBKGND_FILL);
+
/* Only update DISPLIST if the CRTC was already running and is not
 * being disabled.
 * vc4_crtc_enable() takes care of updating the dlist just after
-- 
2.7.4

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

[PATCH 2/3] drm/vc4: Check if plane requires background fill

[Stefan Schake]

Considering a single plane only, we have to enable background color
when the plane has an alpha format and could be blending from the
background or when it doesn't cover the entire screen.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_drv.h   |  6 ++
 drivers/gpu/drm/vc4/vc4_plane.c | 15 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index fefa166..7cc6390 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -302,6 +302,12 @@ struct vc4_hvs {
 
 struct vc4_plane {
struct drm_plane base;
+
+   /* Set when the plane has per-pixel alpha content or does not cover
+* the entire screen. This is a hint to the CRTC that it might need
+* to enable background color fill.
+*/
+   bool needs_bg_fill;
 };
 
 static inline struct vc4_plane *
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 3d0c8a2..c299e29 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -517,10 +517,12 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
 {
struct vc4_dev *vc4 = to_vc4_dev(plane->dev);
struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
+   struct vc4_plane *vc4_plane = to_vc4_plane(plane);
struct drm_framebuffer *fb = state->fb;
u32 ctl0_offset = vc4_state->dlist_count;
const struct hvs_format *format = 
vc4_get_hvs_format(fb->format->format);
int num_planes = drm_format_num_planes(format->drm);
+   bool covers_screen;
u32 scl0, scl1, pitch0;
u32 lbm_size, tiling;
unsigned long irqflags;
@@ -625,7 +627,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
  SCALER_POS2_ALPHA_MODE_PIPELINE :
  SCALER_POS2_ALPHA_MODE_FIXED,
  SCALER_POS2_ALPHA_MODE) |
-   (format->has_alpha ? SCALER_POS2_ALPHA_PREMULT : 0) |
+   (fb->format->has_alpha ? SCALER_POS2_ALPHA_PREMULT : 0) 
|
VC4_SET_FIELD(vc4_state->src_w[0], SCALER_POS2_WIDTH) |
VC4_SET_FIELD(vc4_state->src_h[0], SCALER_POS2_HEIGHT));
 
@@ -701,6 +703,17 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
vc4_state->dlist[ctl0_offset] |=
VC4_SET_FIELD(vc4_state->dlist_count, SCALER_CTL0_SIZE);
 
+   /* crtc_* are already clipped coordinates. */
+   covers_screen = vc4_state->crtc_x == 0 && vc4_state->crtc_y == 0 &&
+   vc4_state->crtc_w == state->crtc->mode.hdisplay &&
+   vc4_state->crtc_h == state->crtc->mode.vdisplay;
+   /* Background fill might be necessary when the plane has per-pixel
+* alpha content and blends from the background or does not cover
+* the entire screen.
+*/
+   vc4_plane->needs_bg_fill = fb->format->has_alpha || !covers_screen;
+
+
return 0;
 }
 
-- 
2.7.4

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

[PATCH 1/3] drm/vc4: Set premultiplied for alpha formats

[Stefan Schake]

Alpha formats in DRM are assumed to be premultiplied, so we should be
setting the PREMULT bit in the plane configuration for HVS.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 3 ++-
 drivers/gpu/drm/vc4/vc4_regs.h  | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index c4c7af1..3d0c8a2 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -618,13 +618,14 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
  SCALER_POS1_SCL_HEIGHT));
}
 
-   /* Position Word 2: Source Image Size, Alpha Mode */
+   /* Position Word 2: Source Image Size, Alpha */
vc4_state->pos2_offset = vc4_state->dlist_count;
vc4_dlist_write(vc4_state,
VC4_SET_FIELD(fb->format->has_alpha ?
  SCALER_POS2_ALPHA_MODE_PIPELINE :
  SCALER_POS2_ALPHA_MODE_FIXED,
  SCALER_POS2_ALPHA_MODE) |
+   (format->has_alpha ? SCALER_POS2_ALPHA_PREMULT : 0) |
VC4_SET_FIELD(vc4_state->src_w[0], SCALER_POS2_WIDTH) |
VC4_SET_FIELD(vc4_state->src_h[0], SCALER_POS2_HEIGHT));
 
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index b9749cb..a141496 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -848,6 +848,7 @@ enum hvs_pixel_format {
 #define SCALER_POS2_ALPHA_MODE_FIXED   1
 #define SCALER_POS2_ALPHA_MODE_FIXED_NONZERO   2
 #define SCALER_POS2_ALPHA_MODE_FIXED_OVER_0x07 3
+#define SCALER_POS2_ALPHA_PREMULT  BIT(29)
 
 #define SCALER_POS2_HEIGHT_MASKVC4_MASK(27, 16)
 #define SCALER_POS2_HEIGHT_SHIFT   16
-- 
2.7.4

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

Re: [PATCH 3/4] drm/pl111: Handle the RealView variant separately

[Eric Anholt]

Linus Walleij  writes:

> We want to cut down the default bpp to 16 on the RealView so
> we can have a 1024x768 framebuffer console by default. The
> memory bandwidth limitations makes this not work with the
> PL111 default of 32bpp.
>
> This builds on top of the earlier patches making the
> framebuffer default bpp a per-variant variable.
>
> Signed-off-by: Linus Walleij 

Reviewed-by: Eric Anholt 


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

Re: [PATCH 2/4] drm/pl111: Use max memory bandwidth for resolution

[Eric Anholt]

Linus Walleij  writes:

> We were previously selecting 1024x768 and 32BPP as the default
> set-up for the PL111 consumers.
>
> This does not work on elder systems: the device tree bindings
> support a property "max-memory-bandwidth" in bytes/second that
> states that if you exceed this the memory bus will saturate.
> The result is flickering and unstable images.
>
> Parse the "max-memory-bandwidth" and respect it when
> intializing the driver. On the RealView PB11MP, Versatile and
> Integrator/CP we get a nice console as default with this code.
>
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v2->v3:
> - Account for the case where there is no bandwidth limitation
>   so priv->memory_bw is zero. Then just accept any modes.
> ChangeLog v1->v2:
> - Exploit the new .mode_valid() callback we added to the
>   simple KMS helper.
> - Use the hardcoded bits per pixel per variant instead of
>   trying to be heuristic about this setting for now.
> ---
>  drivers/gpu/drm/pl111/pl111_display.c | 36 
> +++
>  drivers/gpu/drm/pl111/pl111_drm.h |  1 +
>  drivers/gpu/drm/pl111/pl111_drv.c |  6 ++
>  3 files changed, 43 insertions(+)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
> b/drivers/gpu/drm/pl111/pl111_display.c
> index d75923896609..577e61950e16 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -50,6 +50,41 @@ irqreturn_t pl111_irq(int irq, void *data)
>   return status;
>  }
>  
> +static enum drm_mode_status
> +pl111_mode_valid(struct drm_crtc *crtc,
> +  const struct drm_display_mode *mode)
> +{
> + struct drm_device *drm = crtc->dev;
> + struct pl111_drm_dev_private *priv = drm->dev_private;
> + u32 cpp = priv->variant->fb_bpp / 8;
> + u64 bw;
> +
> + /*
> +  * We use the pixelclock to also account for interlaced modes, the
> +  * resulting bandwidth is in bytes per second.
> +  */
> + bw = mode->clock * 1000; /* In Hz */
> + bw = bw * mode->hdisplay * mode->vdisplay * cpp;
> + bw = div_u64(bw, mode->htotal * mode->vtotal);
> +
> + /*
> +  * If no bandwidth constraints, anything goes, else
> +  * check if we are too fast.
> +  */
> + if (priv->memory_bw && (bw > priv->memory_bw)) {
> + DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu too fast\n",
> +  mode->hdisplay, mode->vdisplay,
> +  mode->clock * 1000, cpp, bw);
> +
> + return MODE_BAD;
> + }
> + DRM_INFO("%d x %d @ %d Hz, %d cpp, bw %llu bytes/s OK\n",
> +  mode->hdisplay, mode->vdisplay,
> +  mode->clock * 1000, cpp, bw);

I think the DRM_INFO should be DRM_DEBUG_KMS.  With that,

Reviewed-by: Eric Anholt 


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

linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Stephen Rothwell]

Hi Liviu,

Today's linux-next merge of the mali-dp tree got a conflict in:

  drivers/gpu/drm/arm/malidp_planes.c

between commit:

  81af63a4af82 ("drm: Don't pass clip to drm_atomic_helper_check_plane_state()")

from the drm-misc tree and commit:

  4968211e7b8f ("drm: mali-dp: Uninitialized variable in 
malidp_se_check_scaling()")

from the mali-dp tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/arm/malidp_planes.c
index ee32361c87ac,b2d11df6b5e1..
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@@ -147,7 -147,13 +146,9 @@@ static int malidp_se_check_scaling(stru
if (!crtc_state)
return -EINVAL;
  
 -  if (crtc_state->enable)
 -  drm_mode_get_hv_timing(_state->mode,
 - , );
 -
+   mc = to_malidp_crtc_state(crtc_state);
+ 
 -  ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
 +  ret = drm_atomic_helper_check_plane_state(state, crtc_state,
  0, INT_MAX, true, true);
if (ret)
return ret;


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

[Bug 98974] Can't see borders/empires in Stellaris

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98974

--- Comment #21 from John  ---
I now see borders with versions:

Stellaris v2.0.1

Linux 4.15.6
mesa 17.3.6
xorg 1.19.6

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

Re: [PULL] drm-misc-next

[Sean Paul]

On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter  wrote:
> On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote:
>> On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul  wrote:
>> >
>> > Hi Dave,
>> > Here's this weeks pull, relatively small when you pull out the trivial 
>> > fixes.
>> >
>> > drm-misc-next-2018-02-28:
>> > drm-misc-next for 4.17:
>> >
>> > UAPI Changes:
>> >  Fix drm_color_ctm matrix docs to match usage and change the type to
>> >  __u64 make it obvious (Ville)
>>
>> Hi Dave,
>> Could you please hold off on pulling this? I'd like to sort out this
>> change a bit more. We're already using the __s64 in chrome, and not
>> explicitly sign-magnitude. I think it would be prudent to hash this
>> out a little more.
>>
>> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?l=161
>
> That code seems to be doing the exact same fun s.u63 math. This all looks
> consistent to me.

Hmm, yeah, I skimmed too quickly last week.

>
> Now in hindsight ofc we've screwed up the uapi, but well can't fix that
> now again ...

Yeah, I'm not convinced we should be changing the type. It's great to
clarify the documentation to let userspace know it's sign-magnitude,
but changing the type in-flight with users seems wrong.

Sean

> -Daniel
>
>>
>> Sean
>>
>> >
>> > Core Changes:
>> >  Check modifier with format when checking if a plane state is supported 
>> > (Ville)
>> >
>> > Driver Changes:
>> >  sun4i: Improve hw plane utilization (Maxime)
>> >  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>> >  virtio: Whitespace + checkpatch changes (Rodrigo)
>> >
>> > Cc: Maxime Ripard 
>> > Cc: Oleksandr Andrushchenko 
>> > Cc: Ville Syrjälä 
>> > Cc: Rodrigo Siqueira 
>> >
>> > Cheers, Sean
>> >
>> >
>> > The following changes since commit 
>> > 2b91e3c43b4f3d3cd4d84a31cfbe6b165d89b70e:
>> >
>> >   drm/omapdrm: Use of_find_backlight helper (2018-02-20 11:07:22 -0500)
>> >
>> > are available in the Git repository at:
>> >
>> >   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-02-28
>> >
>> > for you to fetch changes up to 7628166d5e2883e4cdd142b99863d29d411a81b2:
>> >
>> >   tinydrm: add backlight dependency (2018-02-28 15:08:56 -0500)
>> >
>> > 
>> > drm-misc-next for 4.17:
>> >
>> > UAPI Changes:
>> >  Fix drm_color_ctm matrix docs to match usage and change the type to
>> >  __u64 make it obvious (Ville)
>> >
>> > Core Changes:
>> >  Check modifier with format when checking if a plane state is supported 
>> > (Ville)
>> >
>> > Driver Changes:
>> >  sun4i: Improve hw plane utilization (Maxime)
>> >  simple: Add per-pipe enable/disable vblank functions (Oleksandr)
>> >  virtio: Whitespace + checkpatch changes (Rodrigo)
>> >
>> > Cc: Maxime Ripard 
>> > Cc: Oleksandr Andrushchenko 
>> > Cc: Ville Syrjälä 
>> > Cc: Rodrigo Siqueira 
>> >
>> > 
>> > Arnd Bergmann (2):
>> >   drm: fix drm_get_max_iomem type mismatch
>> >   tinydrm: add backlight dependency
>> >
>> > Benjamin Gaignard (1):
>> >   drm/stm: check pitch and size calculations even if !CONFIG_MMU
>> >
>> > Chris Wilson (1):
>> >   drm/mm: Fix caching of leftmost node in the interval tree
>> >
>> > Linus Walleij (1):
>> >   drm/panel: Fix ARM Versatile panel clocks
>> >
>> > Maxime Ripard (4):
>> >   drm/sun4i: backend: Assign the pipes automatically
>> >   drm/sun4i: Remove the plane description structure
>> >   drm/sun4i: backend: Make zpos configurable
>> >   drm/sun4i: backend: Remove ARGB spoofing
>> >
>> > Oleksandr Andrushchenko (5):
>> >   drm/simple_kms_helper: Fix NULL pointer dereference with no active 
>> > CRTC
>> >   drm/simple_kms_helper: Add {enable|disable}_vblank callback support
>> >   drm/mxsfb: Do not use deprecated drm_driver.{enable|disable)_vblank
>> >   drm/tve200: Do not use deprecated drm_driver.{enable|disable)_vblank
>> >   drm/pl111: Do not use deprecated drm_driver.{enable|disable)_vblank
>> >
>> > Rodrigo Siqueira (7):
>> >   drm/virtio: Add tabs at the start of a line
>> >   drm/virtio: Add blank line after variable declarations
>> >   drm/virtio: Add */ in block comments to separate line
>> >   drm/virtio: Remove return from void function
>> >   drm/virtio: Replace 'unsigned' for 'unsigned int'
>> >   drm/virtio: Remove multiple blank lines
>> >   drm/virtio: Add spaces around operators
>> >
>> > Thierry Reding (1):
>> >   drm/pl111: Remove reverse dependency on DRM_DUMB_VGA_DAC
>> >
>> > Ville Syrjälä (4):
>> >   drm: Check that the plane supports the request format+modifier combo
>> 

Re: [PATCH libdrm] intel/intel_chipset.h: Sync Cannonlake IDs.

[Rodrigo Vivi]

On Mon, Mar 05, 2018 at 02:51:46PM -0800, Rafael Antognolli wrote:
> This is matching both the kernel and the spec.
> 
> Reviewed-by: Rafael Antognolli .

pushed, thanks

> 
> On Wed, Feb 14, 2018 at 05:42:24PM -0800, Rodrigo Vivi wrote:
> > Let's sync CNL ids with Spec and kernel.
> > 
> > Sync with kernel commit '3f43031b1693 ("drm/i915/cnl:
> > Add Cannonlake PCI IDs for another SKU.")' and
> > commit 'e3890d05b342 ("drm/i915/cnl: Sync PCI ID with Spec.")'
> > 
> > Cc: James Ausmus 
> > Cc: Lucas De Marchi 
> > Cc: Paulo Zanoni 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  intel/intel_chipset.h | 52 
> > +++
> >  1 file changed, 28 insertions(+), 24 deletions(-)
> > 
> > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > index 3818e71e..01d250e8 100644
> > --- a/intel/intel_chipset.h
> > +++ b/intel/intel_chipset.h
> > @@ -241,16 +241,20 @@
> >  #define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
> >  #define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
> >  
> > -#define PCI_CHIP_CANNONLAKE_U_GT2_00x5A52
> > -#define PCI_CHIP_CANNONLAKE_U_GT2_10x5A5A
> > -#define PCI_CHIP_CANNONLAKE_U_GT2_20x5A42
> > -#define PCI_CHIP_CANNONLAKE_U_GT2_30x5A4A
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_00x5A51
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_10x5A59
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_20x5A41
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_30x5A49
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_40x5A71
> > -#define PCI_CHIP_CANNONLAKE_Y_GT2_50x5A79
> > +#define PCI_CHIP_CANNONLAKE_0  0x5A51
> > +#define PCI_CHIP_CANNONLAKE_1  0x5A59
> > +#define PCI_CHIP_CANNONLAKE_2  0x5A41
> > +#define PCI_CHIP_CANNONLAKE_3  0x5A49
> > +#define PCI_CHIP_CANNONLAKE_4  0x5A52
> > +#define PCI_CHIP_CANNONLAKE_5  0x5A5A
> > +#define PCI_CHIP_CANNONLAKE_6  0x5A42
> > +#define PCI_CHIP_CANNONLAKE_7  0x5A4A
> > +#define PCI_CHIP_CANNONLAKE_8  0x5A50
> > +#define PCI_CHIP_CANNONLAKE_9  0x5A40
> > +#define PCI_CHIP_CANNONLAKE_10 0x5A54
> > +#define PCI_CHIP_CANNONLAKE_11 0x5A5C
> > +#define PCI_CHIP_CANNONLAKE_12 0x5A44
> > +#define PCI_CHIP_CANNONLAKE_13 0x5A4C
> >  
> >  #define IS_MOBILE(devid)   ((devid) == PCI_CHIP_I855_GM || \
> >  (devid) == PCI_CHIP_I915_GM || \
> > @@ -515,20 +519,20 @@
> >  IS_GEMINILAKE(devid) || \
> >  IS_COFFEELAKE(devid))
> >  
> > -#define IS_CNL_Y(devid)((devid) == PCI_CHIP_CANNONLAKE_Y_GT2_0 
> > || \
> > -(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_3 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_4 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_5)
> > -
> > -#define IS_CNL_U(devid)((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0 
> > || \
> > -(devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
> > -(devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
> > -
> > -#define IS_CANNONLAKE(devid)   (IS_CNL_U(devid) || \
> > -IS_CNL_Y(devid))
> > +#define IS_CANNONLAKE(devid)   ((devid) == PCI_CHIP_CANNONLAKE_0 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_1 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_2 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_3 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_4 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_5 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_6 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_7 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_8 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_9 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_10 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_11 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_12 || \
> > +(devid) == PCI_CHIP_CANNONLAKE_13)
> >  
> >  #define IS_GEN10(devid)(IS_CANNONLAKE(devid))
> >  
> > -- 
> > 2.13.6
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___

[Bug 105352] [r600g] OpenGL ES fails to start on RV730

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105352

Eugene  changed:

   What|Removed |Added

 CC||ken20...@ukr.net
   Priority|medium  |high

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

[Bug 105352] [r600g] OpenGL ES fails to start on RV730

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105352

Bug ID: 105352
   Summary: [r600g] OpenGL ES fails to start on RV730
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ken20...@ukr.net
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 137804
  --> https://bugs.freedesktop.org/attachment.cgi?id=137804=edit
full glxinfo output

After upgrading to Kubuntu 18.04 (dev branch) I found OpenGL ES fails to start:

$ KWIN_COMPOSE=O2ES kwin_x11 --replace
QPainter::begin: Paint device returned engine == 0, type: 3
QPainter::setRenderHint: Painter must be active to set rendering hints
QPainter::setWindow: Painter not active
QPainter::setClipRect: Painter not active
QPainter::save: Painter not active
QPainter::setRenderHint: Painter must be active to set rendering hints
QPainter::setPen: Painter not active
QPainter::setBrush: Painter not active
QPainter::setClipRect: Painter not active
QPainter::drawRects: Painter not active
QPainter::restore: Unbalanced save/restore
QPainter::save: Painter not active
QPainter::setRenderHint: Painter must be active to set rendering hints
QPainter::setBrush: Painter not active
QPainter::setPen: Painter not active
QPainter::drawRects: Painter not active
QPainter::restore: Unbalanced save/restore
OpenGL vendor string:   X.Org
OpenGL renderer string: AMD RV730 (DRM 2.50.0 /
4.15.0-10-generic, LLVM 5.0.1)
OpenGL version string:  OpenGL ES 3.0 Mesa 18.0.0-rc4
OpenGL shading language version string: OpenGL ES GLSL ES 3.00
Driver: R600G
GPU class:  Unknown
OpenGL version: 3.0
GLSL version:   3.0
Mesa version:   18.0
X server version:   1.19.6
Linux kernel version:   4.15
Requires strict binding:no
GLSL shaders:   yes
Texture NPOT support:   yes
Virtual Machine:no
kf5.kcoreaddons.desktopparser: Property type "Url" is not a known QVariant
type. Found while parsing property definition for "X-KWin-Video-Url" in
"/usr/share/kservicetypes5/kwineffect.desktop"
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1757, resource id: 0,
major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1759, resource id: 0,
major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1760, resource id: 0,
major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1761, resource id: 0,
major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1762, resource id: 0,
major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1763, resource id: 0,
major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1767, resource id: 0,
major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 1797, resource id:
65011748, major code: 3 (GetWindowAttributes), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1798, resource id:
65011748, major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 1815, resource id:
52428850, major code: 18 (ChangeProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 1817, resource id:
52428850, major code: 3 (GetWindowAttributes), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1818, resource id:
52428850, major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 8 (BadMatch), sequence: 1825, resource id: 46137350,
major code: 42 (SetInputFocus), minor code: 0
QXcbConnection: XCB error: 8 (BadMatch), sequence: 2384, resource id: 46137350,
major code: 42 (SetInputFocus), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 2452, resource id:
52428854, major code: 18 (ChangeProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 2454, resource id:
52428854, major code: 3 (GetWindowAttributes), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 2455, resource id:
52428854, major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 4657, resource id:
65011772, major code: 18 (ChangeProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 4725, resource id:
65011776, major code: 18 (ChangeProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 4752, resource id:
65011780, major code: 18 

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Eric Anholt]

Ville Syrjälä  writes:

> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
>> Ville Syrjala  writes:
>> 
>> > From: Ville Syrjälä 
>> >
>> > To make life easier for drivers, let's have the core check that the
>> > requested pixel format is supported by at least one plane when creating
>> > a new framebuffer.
>> >
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/drm_framebuffer.c | 26 ++
>> >  1 file changed, 26 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>> > b/drivers/gpu/drm/drm_framebuffer.c
>> > index c0530a1af5e3..155b21e579c4 100644
>> > --- a/drivers/gpu/drm/drm_framebuffer.c
>> > +++ b/drivers/gpu/drm/drm_framebuffer.c
>> > @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
>> >return DIV_ROUND_UP(height, format->vsub);
>> >  }
>> >  
>> > +static bool planes_have_format(struct drm_device *dev, u32 format)
>> > +{
>> > +  struct drm_plane *plane;
>> > +
>> > +  /* TODO: maybe maintain a device level format list? */
>> > +  drm_for_each_plane(plane, dev) {
>> > +  int i;
>> > +
>> > +  for (i = 0; i < plane->format_count; i++) {
>> > +  if (plane->format_types[i] == format)
>> > +  return true;
>> > +  }
>> > +  }
>> > +
>> > +  return false;
>> > +}
>> > +
>> >  static int framebuffer_check(struct drm_device *dev,
>> > const struct drm_mode_fb_cmd2 *r)
>> >  {
>> > @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
>> >return -EINVAL;
>> >}
>> >  
>> > +  if (!planes_have_format(dev, r->pixel_format)) {
>> > +  struct drm_format_name_buf format_name;
>> > +
>> > +  DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
>> > +drm_get_format_name(r->pixel_format,
>> > +_name));
>> > +  return -EINVAL;
>> > +  }
>> > +
>> 
>> Won't this break KMS on things like the radeon driver, which doesn't do
>> planes?  Maybe check if any universal planes have been registered and
>> only do the check in that case?
>
> Hmm. I thought we add the implicit planes always. Apparently
> drm_crtc_init() adds a primary with X/ARGB, but no more. So
> this would break all other formats, which is probably a bit too
> aggressive.
>
> I guess I could just skip the check in case any plane has
> plane->format_default set. That should be indicating that the driver
> doesn't do planes fully. Oh, why exactly is amggpu setting that flag?
> Harry?
>
>> 
>> Also, "any_planes_have_format()" might be slightly more descriptive.
>
> Or any_plane_has_format()? Is that more englishy? :)

I like it.


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

[PATCH v8 4/4] drm: rcar-du: Convert LVDS encoder code to bridge driver

[Laurent Pinchart]

The LVDS encoders used to be described in DT as part of the DU. They now
have their own DT node, linked to the DU using the OF graph bindings.
This allows moving internal LVDS encoder support to a separate driver
modelled as a DRM bridge. Backward compatibility is retained as legacy
DT is patched live to move to the new bindings.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Niklas Söderlund 
---
Changes since v1:

- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Update to the -lvds compatible string format
---
 drivers/gpu/drm/rcar-du/Kconfig   |   4 +-
 drivers/gpu/drm/rcar-du/Makefile  |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  93 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |  24 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 238 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |  64 
 drivers/gpu/drm/rcar-du/rcar_lvds.c   | 524 ++
 12 files changed, 561 insertions(+), 616 deletions(-)
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 3f83352a7313..edde8d4b87a3 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -19,8 +19,8 @@ config DRM_RCAR_DW_HDMI
  Enable support for R-Car Gen3 internal HDMI encoder.
 
 config DRM_RCAR_LVDS
-   bool "R-Car DU LVDS Encoder Support"
-   depends on DRM_RCAR_DU
+   tristate "R-Car DU LVDS Encoder Support"
+   depends on DRM && DRM_BRIDGE && OF
select DRM_PANEL
select OF_FLATTREE
select OF_OVERLAY
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 86b337b4be5d..3e58ed93d5b1 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,10 +4,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_encoder.o \
 rcar_du_group.o \
 rcar_du_kms.o \
-rcar_du_lvdscon.o \
 rcar_du_plane.o
 
-rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
   rcar_du_of_lvds_r8a7790.dtb.o \
   rcar_du_of_lvds_r8a7791.dtb.o \
@@ -18,3 +16,4 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP)+= rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
 obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
+obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 6e02c762a557..06a3fbdd728a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -29,6 +29,7 @@
 
 #include "rcar_du_drv.h"
 #include "rcar_du_kms.h"
+#include "rcar_du_of.h"
 #include "rcar_du_regs.h"
 
 /* 
-
@@ -74,7 +75,6 @@ static const struct rcar_du_device_info rzg1_du_r8a7745_info 
= {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7779_info = {
@@ -95,14 +95,13 @@ static const struct rcar_du_device_info 
rcar_du_r8a7779_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
-   .quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
+   .quirks = RCAR_DU_QUIRK_ALIGN_128B,
.num_crtcs = 3,
.routes = {
/*
@@ -164,7 +163,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7792_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7794_info = {
@@ -186,7 +184,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7794_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7795_info = {
@@ -434,7 +431,19 @@ static struct platform_driver rcar_du_platform_driver = {
},
 };
 

[PATCH v8 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.

Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Niklas Söderlund 
Reviewed-by: Frank Rowand 
---
Changes since v7:

- Make the LVDS name array 22 characters long
- Drop attribution comment in *.dts files as they have been completely
  rewritten
- Rebase on top of of_overlay_fdt_apply() change from Frank Rowand

Changes since v6:

- Don't free data used by the applied overlay

Changes since v5:

- Use a private copy of rcar_du_of_changeset_add_property()

Changes since v3:

- Use the OF changeset API
- Use of_graph_get_endpoint_by_regs()
- Replace hardcoded constants by sizeof()

Changes since v2:

- Update the SPDX headers to use C-style comments in header files
- Removed the manually created __local_fixups__ node
- Perform manual fixups on live DT instead of overlay

Changes since v1:

- Select OF_FLATTREE
- Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
- Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
- Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
- Pass void begin and end pointers to rcar_du_of_get_overlay()
- Use of_get_parent() instead of accessing the parent pointer directly
- Find the LVDS endpoints nodes based on the LVDS node instead of the
  root of the overlay
- Update to the -lvds compatible string format
---
 drivers/gpu/drm/rcar-du/Kconfig|   2 +
 drivers/gpu/drm/rcar-du/Makefile   |   7 +-
 drivers/gpu/drm/rcar-du/rcar_du_of.c   | 322 +
 drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  76 +
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  50 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  50 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  50 
 .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  50 
 9 files changed, 626 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 5d0b4b7119af..3f83352a7313 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -22,6 +22,8 @@ config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
select DRM_PANEL
+   select OF_FLATTREE
+   select OF_OVERLAY
help
  Enable support for the R-Car Display Unit embedded LVDS encoders.
 
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 0cf5c11030e8..86b337b4be5d 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -8,7 +8,12 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_plane.o
 
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
-
+rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
+  rcar_du_of_lvds_r8a7790.dtb.o \
+  rcar_du_of_lvds_r8a7791.dtb.o \
+  rcar_du_of_lvds_r8a7793.dtb.o \
+  rcar_du_of_lvds_r8a7795.dtb.o \
+  rcar_du_of_lvds_r8a7796.dtb.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
new file mode 100644
index ..68a0b82cb17e
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -0,0 +1,322 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * rcar_du_of.c - Legacy DT bindings compatibility
+ *
+ * Copyright (C) 2018 Laurent Pinchart 
+ *
+ * Based on work from Jyri Sarha 
+ * Copyright (C) 2015 Texas Instruments
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rcar_du_crtc.h"
+#include "rcar_du_drv.h"
+
+/* 
-
+ * Generic Overlay Handling
+ */
+
+struct rcar_du_of_overlay {
+   const char *compatible;
+   void *begin;
+   void 

[PATCH v8 2/4] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings, representing
them as part of the DU is deprecated.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
Reviewed-by: Niklas Söderlund 
---
Changes since v1:

- Remove the LVDS reg range from the example
- Remove the reg-names property
---
 .../devicetree/bindings/display/renesas,du.txt | 31 --
 1 file changed, 11 insertions(+), 20 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index cd48aba3bc8c..e79cf9b0ad38 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -14,12 +14,7 @@ Required Properties:
 - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
 - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
 
-  - reg: A list of base address and length of each memory resource, one for
-each entry in the reg-names property.
-  - reg-names: Name of the memory resources. The DU requires one memory
-resource for the DU core (named "du") and one memory resource for each
-LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical
-index).
+  - reg: the memory-mapped I/O registers base address and length
 
   - interrupt-parent: phandle of the parent interrupt controller.
   - interrupts: Interrupt specifiers for the DU interrupts.
@@ -29,14 +24,13 @@ Required Properties:
   - clock-names: Name of the clocks. This property is model-dependent.
 - R8A7779 uses a single functional clock. The clock doesn't need to be
   named.
-- All other DU instances use one functional clock per channel and one
-  clock per LVDS encoder (if available). The functional clocks must be
-  named "du.x" with "x" being the channel numerical index. The LVDS clocks
-  must be named "lvds.x" with "x" being the LVDS encoder numerical index.
-- In addition to the functional and encoder clocks, all DU versions also
-  support externally supplied pixel clocks. Those clocks are optional.
-  When supplied they must be named "dclkin.x" with "x" being the input
-  clock numerical index.
+- All other DU instances use one functional clock per channel The
+  functional clocks must be named "du.x" with "x" being the channel
+  numerical index.
+- In addition to the functional clocks, all DU versions also support
+  externally supplied pixel clocks. Those clocks are optional. When
+  supplied they must be named "dclkin.x" with "x" being the input clock
+  numerical index.
 
   - vsps: A list of phandle and channel index tuples to the VSPs that handle
 the memory interfaces for the DU channels. The phandle identifies the VSP
@@ -69,9 +63,7 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
 
du: display@feb0 {
compatible = "renesas,du-r8a7795";
-   reg = <0 0xfeb0 0 0x8>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x8>;
interrupts = ,
 ,
 ,
@@ -79,9 +71,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 721>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
+< CPG_MOD 721>;
+   clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = < 0>, < 0>, < 0>, < 1>;
 
ports {
-- 
Regards,

Laurent Pinchart

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

[PATCH v8 0/4] R-Car DU: Convert LVDS code to bridge driver

[Laurent Pinchart]

Hello,

This patch series addresses a design mistake that dates back from the initial
DU support. Support for the LVDS encoders, which are IP cores separate from
the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
described through a single DT node.

To fix the, patches 1/4 and 2/4 define new DT bindings for the LVDS
encoders, and deprecate their description inside the DU bindings. To retain
backward compatibility with existing DT, patch 3/4 then patch the device tree
at runtime to convert the legacy bindings to the new ones.

With the DT side addressed, patch 4/4 converts the LVDS support code to a
separate bridge driver.

I decided to go for live DT patching in patch 3/4 because implementing
support for both the legacy and new bindings in the driver would have been
very intrusive, and prevented further cleanups. This version relies more
heavily on overlays to avoid touching the internals of the OF core compared to
v2, even if manual fixes to the device tree are still needed.

The patches and their dependencies are available from

git://linuxtv.org/pinchartl/media.git drm/next/du

I plan to send a pull request tomorrow if no new issue is discovered.

Compared to v7, the series has been rebased on top of Frank Rowand's
"[PATCH v7 0/5] of: change overlay apply input data from unflattened"
patches. Patch 3/4 now uses of_overlay_fdt_apply() instead of
of_overlay_apply().

Compared to v6, patch 3/4 now exists in two variants, to accommodate Frank's
"[PATCH v4 0/4] of: change overlay apply input data from unflattened" patch
series. If that series can't make it to v4.17, patch 3/4 variant 1 will be
used. Otherwise I will go with variant 2.

Compared to v5, I've dropped the OF changeset halpers series as Frank raised
concerns about hidding it in the middle of a driver patch series. I've thus
copied the implementation of of_changeset_add_property_copy() in the driver to
avoid blocking this series. The function arguments are identical, so when the
OF changeset helpers will land it will be very easy to drop the private copy
and use the of_changeset_add_property_copy() helper.

Compared to v4, the patch "of: changeset: Add of_changeset_node_move method"
has been dropped as it's not needed. The patches that update the DT sources to
the new DU and LVDS bindings have been dropped as well to avoid spamming the
lists as they depend on the driver changes going in first to avoid
regressions and haven't been changed.

Compared to v3, this series uses the OF changeset API to update properties
instead of accessing the internals of the property structure. This removes the
local implementation of functions to look up nodes by path and update
properties. In order to do this, I pulled in Pantelis' patch series titled
"[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's request, and
rebased it while taking two small review comments into account.

Rob, I'd like this series to be merged in v4.17. As the changeset helpers are
now a dependency, I'd need you to merge them early (ideally on top of
v4.16-rc1) and provide a stable branch, or get your ack to merge them through
Dave's tree if they don't conflict with what you have and will queue for
v4.17.

This version also drops the small fix to the Porter board device tree that has
been queued for v4.17 already.

Compared to v2, the biggest change is in patch 3/4. Following Rob's and
Frank's reviews it was clear that modifying the unflattened DT structure of
the overlay before applying it wasn't popular. I have thus decided to use one
overlay source per SoC to move as much of the DT changes to the overlay as
possible, and only perform manual modifications (that are still needed as some
of the information is board-specific) on the system DT after applying the
overlay. As a result the overlay is parsed and applied without being modified.

Compared to v1, this series update the r8a7792 and r8a7794 device tree sources
and incorporate review feedback as described by the changelogs of individual
patches.

Laurent Pinchart (4):
  dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
  dt-bindings: display: renesas: Deprecate LVDS support in the DU
bindings
  drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
  drm: rcar-du: Convert LVDS encoder code to bridge driver

 .../bindings/display/bridge/renesas,lvds.txt   |  56 +++
 .../devicetree/bindings/display/renesas,du.txt |  31 +-
 MAINTAINERS|   1 +
 drivers/gpu/drm/rcar-du/Kconfig|   6 +-
 drivers/gpu/drm/rcar-du/Makefile   |  10 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  | 175 +--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h  |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  93 
 

[PATCH v8 1/4] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Laurent Pinchart]

The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
corresponding device tree bindings.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
Reviewed-by: Niklas Söderlund 
---
Changes since v6:

- Fixed typo in SoC name

Changes since v1:

- Move the SoC name before the IP name in compatible strings
- Rename parallel input to parallel RGB input
- Fixed "renesas,r8a7743-lvds" description
- Document the resets property
- Fixed typo
---
 .../bindings/display/bridge/renesas,lvds.txt   | 56 ++
 MAINTAINERS|  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt 
b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
new file mode 100644
index ..af45ba9d8f90
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -0,0 +1,56 @@
+Renesas R-Car LVDS Encoder
+==
+
+These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
+Gen2, R-Car Gen3 and RZ/G SoCs.
+
+Required properties:
+
+- compatible : Shall contain one of
+  - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
+  - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
+  - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders
+  - "renesas,r8a7793-lvds" for R8A7793 (R-Car M2-N) compatible LVDS encoders
+  - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
+  - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
+
+- reg: Base address and length for the memory-mapped registers
+- clocks: A phandle + clock-specifier pair for the functional clock
+- resets: A phandle + reset specifier for the module reset
+
+Required nodes:
+
+The LVDS encoder has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 corresponds to the parallel RGB input
+- Video port 1 corresponds to the LVDS output
+
+Each port shall have a single endpoint.
+
+
+Example:
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,r8a7790-lvds";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   resets = < 726>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
+   };
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2afba909724c..13c8ec11135a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4744,6 +4744,7 @@ F:drivers/gpu/drm/rcar-du/
 F: drivers/gpu/drm/shmobile/
 F: include/linux/platform_data/shmob_drm.h
 F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
 F: Documentation/devicetree/bindings/display/renesas,du.txt
 
 DRM DRIVERS FOR ROCKCHIP
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH libdrm] intel/intel_chipset.h: Sync Cannonlake IDs.

[Rafael Antognolli]

This is matching both the kernel and the spec.

Reviewed-by: Rafael Antognolli .

On Wed, Feb 14, 2018 at 05:42:24PM -0800, Rodrigo Vivi wrote:
> Let's sync CNL ids with Spec and kernel.
> 
> Sync with kernel commit '3f43031b1693 ("drm/i915/cnl:
> Add Cannonlake PCI IDs for another SKU.")' and
> commit 'e3890d05b342 ("drm/i915/cnl: Sync PCI ID with Spec.")'
> 
> Cc: James Ausmus 
> Cc: Lucas De Marchi 
> Cc: Paulo Zanoni 
> Signed-off-by: Rodrigo Vivi 
> ---
>  intel/intel_chipset.h | 52 
> +++
>  1 file changed, 28 insertions(+), 24 deletions(-)
> 
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 3818e71e..01d250e8 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -241,16 +241,20 @@
>  #define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
>  #define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
>  
> -#define PCI_CHIP_CANNONLAKE_U_GT2_0  0x5A52
> -#define PCI_CHIP_CANNONLAKE_U_GT2_1  0x5A5A
> -#define PCI_CHIP_CANNONLAKE_U_GT2_2  0x5A42
> -#define PCI_CHIP_CANNONLAKE_U_GT2_3  0x5A4A
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_0  0x5A51
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_1  0x5A59
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_2  0x5A41
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_3  0x5A49
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_4  0x5A71
> -#define PCI_CHIP_CANNONLAKE_Y_GT2_5  0x5A79
> +#define PCI_CHIP_CANNONLAKE_00x5A51
> +#define PCI_CHIP_CANNONLAKE_10x5A59
> +#define PCI_CHIP_CANNONLAKE_20x5A41
> +#define PCI_CHIP_CANNONLAKE_30x5A49
> +#define PCI_CHIP_CANNONLAKE_40x5A52
> +#define PCI_CHIP_CANNONLAKE_50x5A5A
> +#define PCI_CHIP_CANNONLAKE_60x5A42
> +#define PCI_CHIP_CANNONLAKE_70x5A4A
> +#define PCI_CHIP_CANNONLAKE_80x5A50
> +#define PCI_CHIP_CANNONLAKE_90x5A40
> +#define PCI_CHIP_CANNONLAKE_10   0x5A54
> +#define PCI_CHIP_CANNONLAKE_11   0x5A5C
> +#define PCI_CHIP_CANNONLAKE_12   0x5A44
> +#define PCI_CHIP_CANNONLAKE_13   0x5A4C
>  
>  #define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
>(devid) == PCI_CHIP_I915_GM || \
> @@ -515,20 +519,20 @@
>IS_GEMINILAKE(devid) || \
>IS_COFFEELAKE(devid))
>  
> -#define IS_CNL_Y(devid)  ((devid) == PCI_CHIP_CANNONLAKE_Y_GT2_0 
> || \
> -  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_3 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_4 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_5)
> -
> -#define IS_CNL_U(devid)  ((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0 
> || \
> -  (devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
> -  (devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
> -
> -#define IS_CANNONLAKE(devid) (IS_CNL_U(devid) || \
> -  IS_CNL_Y(devid))
> +#define IS_CANNONLAKE(devid) ((devid) == PCI_CHIP_CANNONLAKE_0 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_1 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_2 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_3 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_4 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_5 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_6 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_7 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_8 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_9 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_10 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_11 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_12 || \
> +  (devid) == PCI_CHIP_CANNONLAKE_13)
>  
>  #define IS_GEN10(devid)  (IS_CANNONLAKE(devid))
>  
> -- 
> 2.13.6
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Harry Wentland]

On 2018-03-05 04:33 PM, Alex Deucher wrote:
> On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä
>  wrote:
>> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
>>> Ville Syrjala  writes:
>>>
 From: Ville Syrjälä 

 To make life easier for drivers, let's have the core check that the
 requested pixel format is supported by at least one plane when creating
 a new framebuffer.

 Signed-off-by: Ville Syrjälä 
 ---
  drivers/gpu/drm/drm_framebuffer.c | 26 ++
  1 file changed, 26 insertions(+)

 diff --git a/drivers/gpu/drm/drm_framebuffer.c 
 b/drivers/gpu/drm/drm_framebuffer.c
 index c0530a1af5e3..155b21e579c4 100644
 --- a/drivers/gpu/drm/drm_framebuffer.c
 +++ b/drivers/gpu/drm/drm_framebuffer.c
 @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
 return DIV_ROUND_UP(height, format->vsub);
  }

 +static bool planes_have_format(struct drm_device *dev, u32 format)
 +{
 +   struct drm_plane *plane;
 +
 +   /* TODO: maybe maintain a device level format list? */
 +   drm_for_each_plane(plane, dev) {
 +   int i;
 +
 +   for (i = 0; i < plane->format_count; i++) {
 +   if (plane->format_types[i] == format)
 +   return true;
 +   }
 +   }
 +
 +   return false;
 +}
 +
  static int framebuffer_check(struct drm_device *dev,
  const struct drm_mode_fb_cmd2 *r)
  {
 @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
 return -EINVAL;
 }

 +   if (!planes_have_format(dev, r->pixel_format)) {
 +   struct drm_format_name_buf format_name;
 +
 +   DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
 + drm_get_format_name(r->pixel_format,
 + _name));
 +   return -EINVAL;
 +   }
 +
>>>
>>> Won't this break KMS on things like the radeon driver, which doesn't do
>>> planes?  Maybe check if any universal planes have been registered and
>>> only do the check in that case?
>>
>> Hmm. I thought we add the implicit planes always. Apparently
>> drm_crtc_init() adds a primary with X/ARGB, but no more. So
>> this would break all other formats, which is probably a bit too
>> aggressive.
>>
>> I guess I could just skip the check in case any plane has
>> plane->format_default set. That should be indicating that the driver
>> doesn't do planes fully. Oh, why exactly is amggpu setting that flag?
>> Harry?
> 
> Probably leftover from DC bringup?

I'm not sure if I'm following. Which flag are we talking about?

Is the concern the DC driver or amdgpu with DC (or radeon)?

DC does not call drm_crtc_init(). It initializes universal planes in 
amdgpu_dm_initialize_drm_device() -> amdgpu_dm_plane_init().

From a quick glance this patch looks fine by me.

Harry

> 
> Alex
> 
>>
>>>
>>> Also, "any_planes_have_format()" might be slightly more descriptive.
>>
>> Or any_plane_has_format()? Is that more englishy? :)
>>
>> --
>> Ville Syrjälä
>> Intel OTC
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/atomic: Add new reverse iterator over all plane state (V2)

[Harry Wentland]

On 2018-03-01 02:56 AM, S, Shirish wrote:
> From: Shirish S 
> 
> Add reverse iterator for_each_oldnew_plane_in_state_reverse to compliment the 
> for_each_oldnew_plane_in_state way or reading plane states.
> 
> The plane states are required to be read in reverse order for amd drivers, 
> cause the z order convention followed in linux is opposite to how the planes 
> are supposed to be presented to DC engine, which is in common to both windows 
> and linux.
> 
> V2: fix compile time errors due to -Werror flag.
> 
> Signed-off-by: Shirish S 
> Signed-off-by: Pratik Vishwakarma 
> ---
>  include/drm/drm_atomic.h | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 
> cf13842..3fe8dde 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -754,6 +754,28 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
> (new_plane_state) = 
> (__state)->planes[__i].new_state, 1))
>  
>  /**
> + * for_each_oldnew_plane_in_state_reverse - iterate over all planes in 
> +an atomic
> + * update in reverse order

Looks good but can you check if docs build and render well with the newline in 
here? To build the docs run
make DOCBOOKS="" htmldocs
and then check that it renders correctly in 
Documentation/output/gpu/drm_kms.html

Harry

> + * @__state:  drm_atomic_state pointer
> + * @plane:  drm_plane iteration cursor
> + * @old_plane_state:  drm_plane_state iteration cursor for the 
> +old state
> + * @new_plane_state:  drm_plane_state iteration cursor for the 
> +new state
> + * @__i: int iteration cursor, for macro-internal use
> + *
> + * This iterates over all planes in an atomic update in reverse order,
> + * tracking both old and  new state. This is useful in places where the
> + * state delta needs to be considered, for example in atomic check functions.
> + */
> +#define for_each_oldnew_plane_in_state_reverse(__state, plane, 
> old_plane_state, new_plane_state, __i) \
> + for ((__i) = ((__state)->dev->mode_config.num_total_plane - 1); \
> +  (__i) >= 0;\
> +  (__i)--)   \
> + for_each_if ((__state)->planes[__i].ptr &&  \
> +  ((plane) = (__state)->planes[__i].ptr, \
> +   (old_plane_state) = 
> (__state)->planes[__i].old_state,\
> +   (new_plane_state) = 
> (__state)->planes[__i].new_state, 1))
> +
> +/**
>   * for_each_old_plane_in_state - iterate over all planes in an atomic update
>   * @__state:  drm_atomic_state pointer
>   * @plane:  drm_plane iteration cursor
> --
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
> These bindings allow to describe most known standard USB connectors
> and it should be possible to extend it if necessary.
> USB connectors, beside USB can be used to route other protocols,
> for example UART, Audio, MHL. In such case every device passing data
> through the connector should have appropriate graph bindings.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> v4:
> - improved 'type' description (Rob),
> - improved description of 2nd example (Rob).
> v3:
> - removed MHL port (samsung connector will have separate bindings),
> - added 2nd example for USB-C,
> - improved formatting.
> v2:
> - moved connector type(A,B,C) to compatible string (Rob),
> - renamed size property to type (Rob),
> - changed type description to be less confusing (Laurent),
> - removed vendor specific compatibles (implied by graph port number),
> - added requirement of connector being a child of IC (Rob),
> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>   by USB Controller in runtime, downside is that device is not able to
>   report its real capabilities, maybe better would be to make it optional(?)),
> - assigned port numbers to data buses (Rob).
> 
> Regards
> Andrzej
> ---
>  .../bindings/connector/usb-connector.txt   | 75 
> ++
>  1 file changed, 75 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/connector/usb-connector.txt

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

[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=102553

--- Comment #6 from Alex Deucher  ---
See if you can find out where it's crashing.  See:
https://stackoverflow.com/questions/13468286/how-to-read-understand-analyze-and-debug-a-linux-kernel-panicand

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

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103234

--- Comment #14 from Roman Gilg  ---
I have a RFC with a potential fix on the mailing list:
https://lists.freedesktop.org/archives/mesa-dev/2018-March/187675.html

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

[PATCH v2 2/3] drm/i915: Eliminate the horrendous format check code

[Ville Syrjala]

From: Ville Syrjälä 

Now that the core makes sure that the pixel format is supported
by at least one plane, we can eliminate the hand rolled code for the
same thing in i915. The way we were doing was extremely inconvenient
because not only did you have to add the format to the plane's format
list, but you also had to come up with the correct platform checks
for this code.

v2: Nuke the modifier checks as well since the core does that too now

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 86 
 1 file changed, 86 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fb08590b4d40..3ed1ef05cb55 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13991,7 +13991,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 {
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = _fb->base;
-   struct drm_format_name_buf format_name;
u32 pitch_limit;
unsigned int tiling, stride;
int ret = -EINVAL;
@@ -14022,37 +14021,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
}
}
 
-   /* Passed in modifier sanity checking. */
-   switch (mode_cmd->modifier[0]) {
-   case I915_FORMAT_MOD_Y_TILED_CCS:
-   case I915_FORMAT_MOD_Yf_TILED_CCS:
-   switch (mode_cmd->pixel_format) {
-   case DRM_FORMAT_XBGR:
-   case DRM_FORMAT_ABGR:
-   case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_ARGB:
-   break;
-   default:
-   DRM_DEBUG_KMS("RC supported only with RGB 
formats\n");
-   goto err;
-   }
-   /* fall through */
-   case I915_FORMAT_MOD_Y_TILED:
-   case I915_FORMAT_MOD_Yf_TILED:
-   if (INTEL_GEN(dev_priv) < 9) {
-   DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
- mode_cmd->modifier[0]);
-   goto err;
-   }
-   case DRM_FORMAT_MOD_LINEAR:
-   case I915_FORMAT_MOD_X_TILED:
-   break;
-   default:
-   DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
- mode_cmd->modifier[0]);
-   goto err;
-   }
-
/*
 * gen2/3 display engine uses the fence if present,
 * so the tiling mode must match the fb modifier exactly.
@@ -14083,60 +14051,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
 
-   /* Reject formats not supported by any plane early. */
-   switch (mode_cmd->pixel_format) {
-   case DRM_FORMAT_C8:
-   case DRM_FORMAT_RGB565:
-   case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_ARGB:
-   break;
-   case DRM_FORMAT_XRGB1555:
-   if (INTEL_GEN(dev_priv) > 3) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_ABGR:
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
-   INTEL_GEN(dev_priv) < 9) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_XBGR:
-   case DRM_FORMAT_XRGB2101010:
-   case DRM_FORMAT_XBGR2101010:
-   if (INTEL_GEN(dev_priv) < 4) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_ABGR2101010:
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_YUYV:
-   case DRM_FORMAT_UYVY:
-   case DRM_FORMAT_YVYU:
-   case DRM_FORMAT_VYUY:
-   if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   default:
-

[PATCH v2 1/3] drm: Make sure at least one plane supports the fb format

[Ville Syrjala]

From: Ville Syrjälä 

To make life easier for drivers, let's have the core check that the
requested pixel format is supported by at least one plane when creating
a new framebuffer.

v2: Accept anyformat if the driver doesn't do planes (Eric)
s/planes_have_format/any_plane_has_format/ (Eric)
Check the modifier as well since we already have a function
that does both

Cc: Eric Anholt 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_framebuffer.c | 43 +++
 1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index c0530a1af5e3..b9a33e3f13e9 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -152,12 +152,37 @@ static int fb_plane_height(int height,
return DIV_ROUND_UP(height, format->vsub);
 }
 
+static bool any_plane_has_format(struct drm_device *dev,
+u32 format, u64 modifier)
+{
+   struct drm_plane *plane;
+
+   /* TODO: maybe maintain a device level format list? */
+   drm_for_each_plane(plane, dev) {
+   /*
+* In case the driver doesn't really do
+* planes we have to accept any format here.
+*/
+   if (plane->format_default)
+   return true;
+
+   if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
+   return true;
+   }
+
+   return false;
+}
+
 static int framebuffer_check(struct drm_device *dev,
 const struct drm_mode_fb_cmd2 *r)
 {
const struct drm_format_info *info;
+   u64 modifier = 0;
int i;
 
+   if (r->flags & DRM_MODE_FB_MODIFIERS)
+   modifier = r->modifier[0];
+
/* check if the format is supported at all */
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
@@ -168,6 +193,15 @@ static int framebuffer_check(struct drm_device *dev,
return -EINVAL;
}
 
+   if (!any_plane_has_format(dev, r->pixel_format, modifier)) {
+   struct drm_format_name_buf format_name;
+
+   DRM_DEBUG_KMS("unsupported pixel format %s, modifier 0x%llx\n",
+ drm_get_format_name(r->pixel_format, 
_name),
+ modifier);
+   return -EINVAL;
+   }
+
/* now let the driver pick its own format info */
info = drm_get_format_info(dev, r);
 
@@ -202,14 +236,7 @@ static int framebuffer_check(struct drm_device *dev,
return -EINVAL;
}
 
-   if (r->modifier[i] && !(r->flags & DRM_MODE_FB_MODIFIERS)) {
-   DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
- r->modifier[i], i);
-   return -EINVAL;
-   }
-
-   if (r->flags & DRM_MODE_FB_MODIFIERS &&
-   r->modifier[i] != r->modifier[0]) {
+   if (r->modifier[i] != modifier) {
DRM_DEBUG_KMS("bad fb modifier %llu for plane %d\n",
  r->modifier[i], i);
return -EINVAL;
-- 
2.16.1

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

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Alex Deucher]

On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä
 wrote:
> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
>> Ville Syrjala  writes:
>>
>> > From: Ville Syrjälä 
>> >
>> > To make life easier for drivers, let's have the core check that the
>> > requested pixel format is supported by at least one plane when creating
>> > a new framebuffer.
>> >
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/drm_framebuffer.c | 26 ++
>> >  1 file changed, 26 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>> > b/drivers/gpu/drm/drm_framebuffer.c
>> > index c0530a1af5e3..155b21e579c4 100644
>> > --- a/drivers/gpu/drm/drm_framebuffer.c
>> > +++ b/drivers/gpu/drm/drm_framebuffer.c
>> > @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
>> > return DIV_ROUND_UP(height, format->vsub);
>> >  }
>> >
>> > +static bool planes_have_format(struct drm_device *dev, u32 format)
>> > +{
>> > +   struct drm_plane *plane;
>> > +
>> > +   /* TODO: maybe maintain a device level format list? */
>> > +   drm_for_each_plane(plane, dev) {
>> > +   int i;
>> > +
>> > +   for (i = 0; i < plane->format_count; i++) {
>> > +   if (plane->format_types[i] == format)
>> > +   return true;
>> > +   }
>> > +   }
>> > +
>> > +   return false;
>> > +}
>> > +
>> >  static int framebuffer_check(struct drm_device *dev,
>> >  const struct drm_mode_fb_cmd2 *r)
>> >  {
>> > @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
>> > return -EINVAL;
>> > }
>> >
>> > +   if (!planes_have_format(dev, r->pixel_format)) {
>> > +   struct drm_format_name_buf format_name;
>> > +
>> > +   DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
>> > + drm_get_format_name(r->pixel_format,
>> > + _name));
>> > +   return -EINVAL;
>> > +   }
>> > +
>>
>> Won't this break KMS on things like the radeon driver, which doesn't do
>> planes?  Maybe check if any universal planes have been registered and
>> only do the check in that case?
>
> Hmm. I thought we add the implicit planes always. Apparently
> drm_crtc_init() adds a primary with X/ARGB, but no more. So
> this would break all other formats, which is probably a bit too
> aggressive.
>
> I guess I could just skip the check in case any plane has
> plane->format_default set. That should be indicating that the driver
> doesn't do planes fully. Oh, why exactly is amggpu setting that flag?
> Harry?

Probably leftover from DC bringup?

Alex

>
>>
>> Also, "any_planes_have_format()" might be slightly more descriptive.
>
> Or any_plane_has_format()? Is that more englishy? :)
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> 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

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #30 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Using UMR please provide following data:

sudo umr -O many,bits  -r *.gfx80.mmGRBM_STATUS
sudo umr -O many,bits  -r *.gfx80.HEADER_DUMP
sudo umr -O many,bits  -r *.gfx80.CP_EOP

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

Re: [PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA

[Peter Wu]

Hi Lukas,

Sorry for the delay, I finally found some time to reviewd and test the
patches and found some issues (some of them might already be present in
v4.15 without your patches though, I did not try).

Test environment:
- Branch switcheroo_devlink_v2 (commit v4.15-20-gb33d50c5c6ad)
- Laptop: Clevo P651RA (nouveau uses PR3), lspci:
  00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th 
Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 07)
  01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204M [GeForce 
GTX 965M] [10de:13d9] (rev a1)
  01:00.1 Audio device [0403]: NVIDIA Corporation GM204 High Definition Audio 
Controller [10de:0fbb] (rev a1)
- Distribution: Arch Linux x86_64
- Tested from (1) console and (2) Xorg 1.19.3-2 (Openbox)
- Booted with HDMI cable connected and nouveau/snd-hda-intel unloaded.

To check the runtime PM status, I used this "rpm-status" script:

grep --color . 
/sys/bus/pci/devices/:00:01.0/{:01:00.0/,:01:00.1/,}power/control
grep --color . 
/sys/bus/pci/devices/:00:01.0/{:01:00.0/,:01:00.1/,}power/runtime_{enabled,usage,active_kids,status}


To test audio output (via HDMI; DP port does not seem to support audio):

speaker-test -Dhdmi:CARD=NVidia,DEV=0 -c2

Below I first list some issues, then some good news.

Issue 1 - GPU does not suspend on text console.
When present at the text console and an external monitor is connected
through HDMI or DP, the RPM counter is 1. Only when the cable is removed
(or when "echo off > /sys/class/drm/card1-HDMI-A-1/status"), the RPM
count drops to 0 and the GPU device suspends. When Xorg is started
(startx), the RPM counter also drops to 0 though.

Issue 2 - RPM counter for audio function drops below 0 on system sleep.
When both nouveau and snd-hda-intel are loaded and a HDMI (or DP?) cable
is connected, the RPM counter becomes one after suspend/resume. This
happens both with text console and Xorg.

Issue 3 - invalid PCI config reads to audio device if disconnected.
When no HDMI/DP cable is connected, the HDMI audio function will be
inaccessible after runtime/system resume. Assume nouveau loaded before
s/r, then loading snd-hda-intel will fail with:

0]: pam_unix(sudo:session): session closed for user root
hdaudio hdaudioC1D0: no AFG or MFG node found
hdaudio hdaudioC1D1: no AFG or MFG node found
hdaudio hdaudioC1D2: no AFG or MFG node found
hdaudio hdaudioC1D3: no AFG or MFG node found
hdaudio hdaudioC1D4: no AFG or MFG node found
hdaudio hdaudioC1D5: no AFG or MFG node found
hdaudio hdaudioC1D6: no AFG or MFG node found
hdaudio hdaudioC1D7: no AFG or MFG node found
snd_hda_intel :01:00.1: no codecs initialized

After rmmod snd-hda-intel and system suspend/resume:

pci :01:00.1: restoring config space at offset 0x3c (was 0x, 
writing 0x200)
pci :01:00.1: restoring config space at offset 0x38 (was 0x, 
writing 0x0)
pci :01:00.1: restoring config space at offset 0x34 (was 0x, 
writing 0x60)

This persists until removing both PCI devices and rescanning the root
port. (When no HDMI/DP cable is connected, the audio function will not
appear; remove+rescan is required to recover.)

Issue 4 - runtime_active_kids leak with audio function.
After the above issue, the audio device never entered the suspended
state even though the runtime_usage counter reached 0. It turned out
that runtime_active_kids was 4. Every time snd-hda-intel is loaded (and
fails to initialize due to the above issue), this counter is increased.

Issue 5 - audio breaks after system sleep or stopping Xorg.
When Xorg is stopped or the system sleep/resumes while speaker-test is
active (e.g. in GNU screen), audio stops playing and speaker-test exits.

Issue 6 - wrong pin status reported / no audio
(Possibly "working as expected" since audio is tied to GPU function.)
Scenario: HDMI cable is connected but GPU is unused
("echo off > /sys/class/drm/card1-HDMI-1-1/status" from console or
with "xrandr --output HDMI-A-1 --off"). hdajacksensetest reports no
HDMI pin presence even if connected, dmesg reports:

nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1

Using "speaker-test", the program does not fail but no sound can be
heard either.

Issue 7 - nouveau: warning after unloading after stopping Xorg
(Issue in nouveau, likely not related to this patch set.)
After "xrandr --output HDMI-1-1 --mode 2560x1440" in Xorg, stopping Xorg
(and possibly "echo off > /sys/class/drm/card1-HDMI-A-1/status"),
removing nouveau triggered:

WARNING: CPU: 7 PID: 5475 at drivers/gpu/drm/drm_mode_config.c:439 
drm_mode_config_cleanup+0x1fa/0x260
CPU: 7 PID: 5475 Comm: rmmod Not tainted 4.15.0testing-00020-gb33d50c5c6ad 
#55
RIP: 0010:drm_mode_config_cleanup+0x1fa/0x260
[..]
Call Trace:
 nouveau_display_destroy+0x41/0x80 [nouveau]
 nouveau_drm_unload+0x6b/0xd0 [nouveau]
 

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

[Eric Anholt]

Stefan Schake  writes:

> We allow alpha formats on the primary plane but a partially transparent
> framebuffer will cause a corrupted display. With this change black pixels
> are output instead, in line with the behavior for other DRM drivers.
>
> Signed-off-by: Stefan Schake 
> ---
> Test program is available at https://github.com/stschake/vc4-alpha-test

How about this as a suggestion for a patch series:

vc4_plane_mode_set() sets ALPHA_PREMULT (POS2 bit 29) if alpha is
enabled.

vc4_plane_mode_set() sets a new vc4_plane->needs_bg_fill boolean to
(format->has_alpha || !covers_screen) where covers_screenis the
can_position logic from drm_atomic_helper.c

vc4_crtc_atomic_flush() updates DISPBKGND to enable background fill
(before vc4_crtc_update_dlist()) if the first plane has needs_bg_fill
set.

vc4_plane_mode_set() strips off the alpha blend bits if
!vc4_plane->needs_bg_fill.

This lets us keep avoiding the background fill cost in the normal case,
and fixes the case where the "primary" plane doesn't cover the screen.
It doesn't get the background fill turned back off if you transition
away from primary not covering the screen, but that seems unlikely and
harder to handle (since you would need to wait for the flip to be done
before disabling).


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

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Ville Syrjälä]

On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote:
> Ville Syrjala  writes:
> 
> > From: Ville Syrjälä 
> >
> > To make life easier for drivers, let's have the core check that the
> > requested pixel format is supported by at least one plane when creating
> > a new framebuffer.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_framebuffer.c | 26 ++
> >  1 file changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index c0530a1af5e3..155b21e579c4 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
> > return DIV_ROUND_UP(height, format->vsub);
> >  }
> >  
> > +static bool planes_have_format(struct drm_device *dev, u32 format)
> > +{
> > +   struct drm_plane *plane;
> > +
> > +   /* TODO: maybe maintain a device level format list? */
> > +   drm_for_each_plane(plane, dev) {
> > +   int i;
> > +
> > +   for (i = 0; i < plane->format_count; i++) {
> > +   if (plane->format_types[i] == format)
> > +   return true;
> > +   }
> > +   }
> > +
> > +   return false;
> > +}
> > +
> >  static int framebuffer_check(struct drm_device *dev,
> >  const struct drm_mode_fb_cmd2 *r)
> >  {
> > @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
> > return -EINVAL;
> > }
> >  
> > +   if (!planes_have_format(dev, r->pixel_format)) {
> > +   struct drm_format_name_buf format_name;
> > +
> > +   DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
> > + drm_get_format_name(r->pixel_format,
> > + _name));
> > +   return -EINVAL;
> > +   }
> > +
> 
> Won't this break KMS on things like the radeon driver, which doesn't do
> planes?  Maybe check if any universal planes have been registered and
> only do the check in that case?

Hmm. I thought we add the implicit planes always. Apparently
drm_crtc_init() adds a primary with X/ARGB, but no more. So
this would break all other formats, which is probably a bit too
aggressive.

I guess I could just skip the check in case any plane has
plane->format_default set. That should be indicating that the driver
doesn't do planes fully. Oh, why exactly is amggpu setting that flag?
Harry?

> 
> Also, "any_planes_have_format()" might be slightly more descriptive.

Or any_plane_has_format()? Is that more englishy? :)

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

[ANNOUNCE] libdrm 2.4.91

[robdclark]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Andrey Grodzovsky (1):
  amdgpu: Fix mistake in initial hole size calculation.

Christian König (3):
  amdgpu: mostly revert "use the high VA range if possible v2"
  amdgpu: add AMDGPU_VA_RANGE_HIGH
  amdgpu: fix "add AMDGPU_VA_RANGE_HIGH"

Chunming Zhou (1):
  test/amdgpu: disable bo eviction test by default

Eric Engestrom (1):
  meson: add configuration summary

Heiko Becker (1):
  *-symbol-check: Don't hard-code nm executable

Igor Gnatenko (1):
  meson: do not use cairo/valgrind if disabled

Jonathan Gray (1):
  meson/configure.ac: pthread-stubs not present on OpenBSD

Marek Olšák (2):
  meson: bump the version number
  RELEASING: mention meson

Michel Dänzer (1):
  tests/amdgpu: Fix misspellings of "suite"

Rob Clark (2):
  freedreno: add interface to get buffer address
  bump version for release

Rob Herring (4):
  android: revert making handle magic and version members const
  android: fix mis-named alloc_handle_t
  android: add helper to convert buffer_handle_t to gralloc_handle_t ptr
  android: fix gralloc_handle_create() problems

Thierry Reding (2):
  drm/fourcc: Fix fourcc_mod_code() definition
  drm/tegra: Sanitize format modifiers

git tag: libdrm-2.4.91

https://dri.freedesktop.org/libdrm/libdrm-2.4.91.tar.bz2
MD5:  23d87cda92700b710a37d9b8edaa9f54  libdrm-2.4.91.tar.bz2
SHA1: 44e42ce3cd41666e343ba393c73f6f1ad9fe1e74  libdrm-2.4.91.tar.bz2
SHA256: 634a0ed0cc1eff06f48674b1da81aafa661a9f001e7a4f43dde81076886dc800  
libdrm-2.4.91.tar.bz2
SHA512: 
07578c00c121ba37033db7172590e26d1545f81c242bbce2cfb7fb904bde504822c275d6468e5c5d20360d0046ae73d9b058aa0459ba35eb11927141cc998772
  libdrm-2.4.91.tar.bz2
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.91.tar.bz2.sig

https://dri.freedesktop.org/libdrm/libdrm-2.4.91.tar.gz
MD5:  d31468ede12851d48f77d9c0eb030411  libdrm-2.4.91.tar.gz
SHA1: 8b894394361e83ed6b39487d3172643bb5b0dbb4  libdrm-2.4.91.tar.gz
SHA256: c8ea3343d5bfc356550f0b5632403359d050fa09cf05d61e96e73adba0c407a9  
libdrm-2.4.91.tar.gz
SHA512: 
276cb0e0a6542a00ce5b9addc64b322bd25ceabdae2d86dda733bfe5d346bfbfc2a113d630c1a12761d31c7d4bda850bf3c26ed4b141f14e37fc8afbde6dbfc9
  libdrm-2.4.91.tar.gz
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.91.tar.gz.sig

-BEGIN PGP SIGNATURE-

iQIcBAEBAgAGBQJanbM5AAoJEBkcm5BVIrBFZqkP/icJEATztkiu8gjpdxqo9wzv
zG5c1PPbOeWaUKWToNDS2eMO0bq0d7qecqQ2L3W3zJ89z0jE85u0TCfJo0SAwsot
w1QXONMODMBlhWJrOAptrqTNkLsNMTFlbT5aOLxDbZzHs96dHu9agQ+ksYCvPswM
uMaBRAPOwHveyA1ZuqRkSnaO6vmQxUT5QZm2Z6kpYJaucYIewmsusWVfCSDmI1ck
0xng1taOa5XNexhlNs6WVxNjzbsmqmYNVMJjcdbJdaCI6MXKTGn3Ond3xjYq03o9
hFemDYLpXUaA6AR2PnN376VzCHsoM80qk4ZLy7YAUbpQ2vgs7N7rM01ovLszjGB/
k4EcTlNYCdPmMlZSTpTXJyDsDRm/5w+cgjtvfmmXYCyi4e5x8gFUx25bzx9DG/tb
yc/aSACJ734U+j5rJnHOJz9+dMP/ORhtaZfUr4Ba5H6xAZUROUNXQ06+f5yx+PDw
Ctu4k7oS9SMc0fyPFOfVYJnSiHPrNLPJe1YIKIDRTEha7YAX5sF0CTbJDn+JQONV
Gcsg4rupza1HZPy3qvzgnRGr1bBi3DNvQ2I8Y97DQB9DSi9jW+a5Uy6PDWsrkIEL
lED8+c2h1rmWdztkLTb15+ZQpUcKoeOaBscEql5chceduITOnwZ9ClHdt3WW4Dcg
5T6PkgZVB3eZhRbzvNp1
=LiFX
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Eric Anholt]

Ville Syrjala  writes:

> From: Ville Syrjälä 
>
> To make life easier for drivers, let's have the core check that the
> requested pixel format is supported by at least one plane when creating
> a new framebuffer.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_framebuffer.c | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index c0530a1af5e3..155b21e579c4 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -152,6 +152,23 @@ static int fb_plane_height(int height,
>   return DIV_ROUND_UP(height, format->vsub);
>  }
>  
> +static bool planes_have_format(struct drm_device *dev, u32 format)
> +{
> + struct drm_plane *plane;
> +
> + /* TODO: maybe maintain a device level format list? */
> + drm_for_each_plane(plane, dev) {
> + int i;
> +
> + for (i = 0; i < plane->format_count; i++) {
> + if (plane->format_types[i] == format)
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
>  static int framebuffer_check(struct drm_device *dev,
>const struct drm_mode_fb_cmd2 *r)
>  {
> @@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
>   return -EINVAL;
>   }
>  
> + if (!planes_have_format(dev, r->pixel_format)) {
> + struct drm_format_name_buf format_name;
> +
> + DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
> +   drm_get_format_name(r->pixel_format,
> +   _name));
> + return -EINVAL;
> + }
> +

Won't this break KMS on things like the radeon driver, which doesn't do
planes?  Maybe check if any universal planes have been registered and
only do the check in that case?

Also, "any_planes_have_format()" might be slightly more descriptive.


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

Re: [PATCH 4/5] drm/ttm: add ttm_sg_tt_init

[Ben Skeggs]

On Mon, Mar 5, 2018 at 10:06 PM, Christian König
 wrote:
> Ping?
On a quick look, it looks like both are used sometimes.  I believe
this had something to do with the addition of Tegra support, but I'll
need some time to look into the details of why/how these things are
used again.

Ben.

>
>
> Am 27.02.2018 um 13:07 schrieb Christian König:
>>
>> Hi guys,
>>
>> at least on amdgpu and radeon the page array allocated by ttm_dma_tt_init
>> is completely unused in the case of DMA-buf sharing. So I'm trying to get
>> rid of that by only allocating the DMA address array.
>>
>> Now the only other user of DMA-buf together with ttm_dma_tt_init is
>> Nouveau. So my question is are you guys using the page array anywhere in
>> your kernel driver in case of a DMA-buf sharing?
>>
>> If no then I could just make this the default behavior for all drivers and
>> save quite a bit of memory for everybody.
>>
>> Thanks,
>> Christian.
>>
>> Am 27.02.2018 um 12:49 schrieb Christian König:
>>>
>>> This allows drivers to only allocate dma addresses, but not a page
>>> array.
>>>
>>> Signed-off-by: Christian König 
>>> ---
>>>   drivers/gpu/drm/ttm/ttm_tt.c | 54
>>> 
>>>   include/drm/ttm/ttm_tt.h |  2 ++
>>>   2 files changed, 47 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
>>> index 8e0b525cda00..971133106ec2 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_tt.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
>>> @@ -108,6 +108,16 @@ static int ttm_dma_tt_alloc_page_directory(struct
>>> ttm_dma_tt *ttm)
>>>   return 0;
>>>   }
>>>   +static int ttm_sg_tt_alloc_page_directory(struct ttm_dma_tt *ttm)
>>> +{
>>> +ttm->dma_address = kvmalloc_array(ttm->ttm.num_pages,
>>> +  sizeof(*ttm->dma_address),
>>> +  GFP_KERNEL | __GFP_ZERO);
>>> +if (!ttm->dma_address)
>>> +return -ENOMEM;
>>> +return 0;
>>> +}
>>> +
>>>   #ifdef CONFIG_X86
>>>   static inline int ttm_tt_set_page_caching(struct page *p,
>>> enum ttm_caching_state c_old,
>>> @@ -227,8 +237,8 @@ void ttm_tt_destroy(struct ttm_tt *ttm)
>>>   ttm->func->destroy(ttm);
>>>   }
>>>   -int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
>>> -unsigned long size, uint32_t page_flags)
>>> +void ttm_tt_init_fields(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
>>> +unsigned long size, uint32_t page_flags)
>>>   {
>>>   ttm->bdev = bdev;
>>>   ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
>>> @@ -236,6 +246,12 @@ int ttm_tt_init(struct ttm_tt *ttm, struct
>>> ttm_bo_device *bdev,
>>>   ttm->page_flags = page_flags;
>>>   ttm->state = tt_unpopulated;
>>>   ttm->swap_storage = NULL;
>>> +}
>>> +
>>> +int ttm_tt_init(struct ttm_tt *ttm, struct ttm_bo_device *bdev,
>>> +unsigned long size, uint32_t page_flags)
>>> +{
>>> +ttm_tt_init_fields(ttm, bdev, size, page_flags);
>>> if (ttm_tt_alloc_page_directory(ttm)) {
>>>   ttm_tt_destroy(ttm);
>>> @@ -258,12 +274,7 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma,
>>> struct ttm_bo_device *bdev,
>>>   {
>>>   struct ttm_tt *ttm = _dma->ttm;
>>>   -ttm->bdev = bdev;
>>> -ttm->num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
>>> -ttm->caching_state = tt_cached;
>>> -ttm->page_flags = page_flags;
>>> -ttm->state = tt_unpopulated;
>>> -ttm->swap_storage = NULL;
>>> +ttm_tt_init_fields(ttm, bdev, size, page_flags);
>>> INIT_LIST_HEAD(_dma->pages_list);
>>>   if (ttm_dma_tt_alloc_page_directory(ttm_dma)) {
>>> @@ -275,11 +286,36 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma,
>>> struct ttm_bo_device *bdev,
>>>   }
>>>   EXPORT_SYMBOL(ttm_dma_tt_init);
>>>   +int ttm_sg_tt_init(struct ttm_dma_tt *ttm_dma, struct ttm_bo_device
>>> *bdev,
>>> +   unsigned long size, uint32_t page_flags)
>>> +{
>>> +struct ttm_tt *ttm = _dma->ttm;
>>> +int ret;
>>> +
>>> +ttm_tt_init_fields(ttm, bdev, size, page_flags);
>>> +
>>> +INIT_LIST_HEAD(_dma->pages_list);
>>> +if (page_flags & TTM_PAGE_FLAG_SG)
>>> +ret = ttm_sg_tt_alloc_page_directory(ttm_dma);
>>> +else
>>> +ret = ttm_dma_tt_alloc_page_directory(ttm_dma);
>>> +if (ret) {
>>> +ttm_tt_destroy(ttm);
>>> +pr_err("Failed allocating page table\n");
>>> +return -ENOMEM;
>>> +}
>>> +return 0;
>>> +}
>>> +EXPORT_SYMBOL(ttm_sg_tt_init);
>>> +
>>>   void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
>>>   {
>>>   struct ttm_tt *ttm = _dma->ttm;
>>>   -kvfree(ttm->pages);
>>> +if (ttm->pages)
>>> +kvfree(ttm->pages);
>>> +else
>>> +kvfree(ttm_dma->dma_address);
>>>   ttm->pages = NULL;
>>>   ttm_dma->dma_address = NULL;
>>>   }
>>> diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
>>> index 

[Bug 105083] Random blinking display

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105083

--- Comment #14 from denisgolo...@yandex.ru ---
(In reply to Harry Wentland from comment #13)
> (In reply to denisgolovan from comment #11)
> > (In reply to Harry Wentland from comment #10)
> > Some areas just
> > stay not affected as if gamma change specifically disabled for them.
> 
> Do you have a picture?

See https://www.youtube.com/watch?v=6MQrgemv-yQ
White color on github page is completely unaffected when I switch Redshift
on/off.

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

Re: [PATCH 1/2] dt-bindings: Document qcom,adreno-gmu

[Rob Herring]

On Fri, Mar 2, 2018 at 3:56 PM, Jordan Crouse  wrote:
> Document the device tree bindings for the Adreno GMU device
> available on Adreno a6xx targets.
>
> Change-Id: I3cfd5fb35ab0045e39905ff12393006e60f1a124

Gerrit!

> Signed-off-by: Jordan Crouse 
> ---
>  .../devicetree/bindings/display/msm/gmu.txt| 54 
> ++
>  .../devicetree/bindings/display/msm/gpu.txt| 10 +++-
>  2 files changed, 62 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt
>
> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt 
> b/Documentation/devicetree/bindings/display/msm/gmu.txt
> new file mode 100644
> index ..f65bb49fff36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> @@ -0,0 +1,54 @@
> +Qualcomm adreno/snapdragon GMU (Graphics management unit)
> +
> +The GMU is a programmable power controller for the GPU. the CPU controls the
> +GMU which in turn handles power controls for the GPU.
> +
> +Required properties:
> +- compatible:
> +  * "qcom,adreno-gmu"

Kind of generic. All the features are discoverable?

> +- reg: Physical base address and length of the GMU registers.
> +- reg-names: Matching names for the register regions
> +  * "gmu"
> +  * "gmu_pdc"
> +- interrupts: The interrupt signals from the GMU.
> +- interrupt-names: Matching names for the interrupts
> +  * "hfi"
> +  * "gmu"
> +- clocks: phandles to the device clocks
> +- clock-names: Matching names for the clocks
> +   * "gmu"
> +   * "cxo"
> +   * "axi"
> +   * "mnoc"
> +- power-domains: should be <_gpucc GPU_CX_GDSC>
> +- iommus: phandle to the adreno iommu
> +- operating-points-v2: phandle to the OPP operating points
> +
> +Example:
> +
> +/ {
> +   ...
> +
> +   gmu: gmu@506a000 {
> +   compatible="qcom,adreno-gmu";
> +
> +   reg = <0x506a000 0x3>,
> +   <0xb20 0x30>;
> +   reg-names = "gmu", "gmu_pdc";
> +
> +   interrupts = ,
> +   ;
> +   interrupt-names = "hfi", "gmu";
> +
> +   clocks = <_gpucc GPU_CC_CX_GMU_CLK>,
> +   <_gpucc GPU_CC_CXO_CLK>,
> +   <_gcc GCC_DDRSS_GPU_AXI_CLK>,
> +   <_gcc GCC_GPU_MEMNOC_GFX_CLK>;
> +   clock-names = "gmu", "cxo", "axi", "memnoc";
> +
> +   power-domains = <_gpucc GPU_CX_GDSC>;
> +   iommus = <_smmu 5>;
> +
> +   i   operating-points-v2 = <_opp_table>;
> +   };
> +};
> diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
> b/Documentation/devicetree/bindings/display/msm/gpu.txt
> index 43fac0fe09bb..0e207498edd3 100644
> --- a/Documentation/devicetree/bindings/display/msm/gpu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
> @@ -8,12 +8,18 @@ Required properties:
>with the chip-id.
>  - reg: Physical base address and length of the controller's registers.
>  - interrupts: The interrupt signal from the gpu.
> -- clocks: device clocks
> +
> +Optional properties.
> +- clocks: device clocks. Required for a3xx, a4xx and a5xx targets. a6xx and
> +  newer with a GMU attached do not have direct clock control from the CPU and
> +  do not need to provide clock properties.
>See ../clocks/clock-bindings.txt for details.
> -- clock-names: the following clocks are required:
> +- clock-names: the following clocks can be provided:
>* "core"
>* "iface"
>* "mem_iface"
> +- gmu: For a6xx and newer targets a phandle to the GMU device that will

qcom,gmu

> +  control the power for the GPU
>
>  Example:
>
> --
> 2.16.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re:

[Noralf Trønnes]

Den 05.03.2018 18.06, skrev Meghana Madhyastha:

linux-...@vger.kernel.org,Noralf Trønnes ,Sean Paul 
,ker...@martin.sperl.org
Cc:
Bcc:
Subject: Re: [PATCH v2 0/2] Chunk splitting of spi transfers
Reply-To:
In-Reply-To: 

On Sun, Mar 04, 2018 at 06:38:42PM +0100, Noralf Trønnes wrote:

Den 02.03.2018 12.11, skrev Meghana Madhyastha:

On Sun, Feb 25, 2018 at 02:19:10PM +0100, Lukas Wunner wrote:

[cc += linux-rpi-ker...@lists.infradead.org]

On Sat, Feb 24, 2018 at 06:15:59PM +, Meghana Madhyastha wrote:

I've added bcm2835_spi_transfer_one_message in spi-bcm2835. This calls
spi_split_transfers_maxsize to split large chunks for spi dma transfers.
I then removed chunk splitting in the tinydrm spi helper (as now the core
is handling the chunk splitting). However, although the SPI HW should be
able to accomodate up to 65535 bytes for dma transfers, the splitting of
chunks to 65535 bytes results in a dma transfer time out error. However,
when the chunks are split to < 64 bytes it seems to work fine.

Hm, that is really odd, how did you test this exactly, what did you
use as SPI slave?  It contradicts our own experience, we're using
Micrel KSZ8851 Ethernet chips as SPI slave on spi0 of a BCM2837
and can send/receive messages via DMA to the tune of several hundred
bytes without any issues.  In fact, for messages < 96 bytes, DMA is
not used at all, so you've probably been using interrupt mode,
see the BCM2835_SPI_DMA_MIN_LENGTH macro in spi-bcm2835.c.

Hi Lukas,

I think you are right. I checked it and its not using the DMA mode which
is why its working with 64 bytes.
Noralf, that leaves us back to the
initial time out problem. I've tried doing the message splitting in
spi_sync as well as spi_pump_messages. Martin had explained that DMA
will wait for
the SPI HW to set the send_more_data line, but the SPI-HW itself will
stop triggering it when SPI_LEN is 0 causing DMA to wait forever. I
thought if we split it before itself, the SPI_LEN will not go to zero
thus preventing this problem, however it didn't work and started
hanging. So I'm a little uncertain as to how to proceed and debug what
exactly has caused the time out due to the asynchronous methods.

I did a quick test and at least this is working:

int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
              struct spi_transfer *header, u8 bpw, const void *buf,
              size_t len)
{
     struct spi_transfer tr = {
         .bits_per_word = bpw,
         .speed_hz = speed_hz,
         .tx_buf = buf,
         .len = len,
     };
     struct spi_message m;
     size_t maxsize;
     int ret;

     maxsize = tinydrm_spi_max_transfer_size(spi, 0);

     if (drm_debug & DRM_UT_DRIVER)
         pr_debug("[drm:%s] bpw=%u, maxsize=%zu, transfers:\n",
              __func__, bpw, maxsize);

     spi_message_init();
     m.spi = spi;
     if (header)
         spi_message_add_tail(header, );
     spi_message_add_tail(, );

     ret = spi_split_transfers_maxsize(spi->controller, , maxsize,
GFP_KERNEL);
     if (ret)
         return ret;

     tinydrm_dbg_spi_message(spi, );

     return spi_sync(spi, );
}
EXPORT_SYMBOL(tinydrm_spi_transfer);


Log:
[   39.015644] [drm:mipi_dbi_fb_dirty [mipi_dbi]] Flushing [FB:36] x1=0,
x2=320, y1=0, y2=240

[   39.018079] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2a, par=00 00 01
3f
[   39.018129] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
[   39.018152] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2a]
[   39.018231] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
[   39.018248] tr(0): speed=10MHz, bpw=8, len=4, tx_buf=[00 00 01 3f]

[   39.018330] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2b, par=00 00 00
ef
[   39.018347] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
[   39.018362] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2b]
[   39.018396] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
[   39.018428] tr(0): speed=10MHz, bpw=8, len=4, tx_buf=[00 00 00 ef]

[   39.018487] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2c, len=153600
[   39.018502] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
[   39.018517] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2c]
[   39.018565] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
[   39.018594] tr(0): speed=48MHz, bpw=8, len=65532, tx_buf=[c6 18 c6 18
c6 18 c6 18 c6 18 c6 18 c6 18 c6 18 ...]
[   39.018608] tr(1): speed=48MHz, bpw=8, len=65532, tx_buf=[06 18 06 18
06 18 06 18 06 18 06 18 06 18 06 18 ...]
[   39.018621] tr(2): speed=48MHz, bpw=8, len=22536, tx_buf=[10 82 10 82
10 82 10 82 10 82 10 82 18 e3 18 e3 ...]

Hi Noralf,

Yes this works but splitting in the spi subsystem doesn't seem to work.
So this means that spi_split_transfers_maxsize is working.
Should I just send in a patch with splitting done here in tinydrm? (I
had thought we wanted to avoid splitting in the 

[Bug 105262] [R600] [BISECTED] ttf fonts are invisible in many programs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105262

Roland Scheidegger  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #14 from Roland Scheidegger  ---
Fixed by 434523cf2a6738b0250de2a0e36e93b13f88832a.
Thanks for bisecting!

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

Re: [PATCH 4/5] drm/armada: Use drm_mode_get_hv_timing() to populate plane clip rectangle

[Ville Syrjälä]

On Mon, Mar 05, 2018 at 09:41:43AM +0100, Daniel Vetter wrote:
> On Tue, Jan 23, 2018 at 07:08:56PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
> > 
> > Since armada isn't atomic we'll use crtc->enabled and crtc->mode instead
> > of the stuff under crtc_state.
> > 
> > Once everyone agrees on how the clip rectangle gets set up we can
> > move the code into drm_atomic_helper_check_plane_state().
> > 
> > Cc: Dave Airlie 
> > Cc: Russell King 
> > Signed-off-by: Ville Syrjälä 
> 
> For patches 3&4: Reviewed-by: Daniel Vetter 
> 
> In case they do unexpectly break armada we can always just copypaste the
> previous version of the non-atomic helper into armada code to fix any
> regressions cropping up, so I don't see any big risks here. And I'd like
> to get this cleanup merged, just stumbled over it again.
> 
> I pinged Dave Airlie on irc, and he's fine with that approach too.
> 
> Acked-by: Dave Airlie 
> 
> for the same two patches.

Cool. Thank you both.

Remainder of the series pushed to drm-misc-next.

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

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101900

--- Comment #32 from Direx  ---
(In reply to Andrew Nelson from comment #31)
> I have been running into the same issue. The problem seems to be that AMDGPU
> is reporting that it supports 7 speakers instead of 8 in the EID. HBR
> formats work with 5.1 encoded audio, but not 7.1. For some reason, the
> driver is configured to subtract 1 from the channel count before passing it
> into the EID. I have removed this and confirmed that 7.1 HBR audio works.

Jackpot, this is it. Just tried your patch and now all audio formats are
working. I can confirm that the following formats can now be played back
correctly on my RX480:

- PCM 2.0
- PCM 5.1
- PCM 7.1
- Dolby Digital@5.1
- DTS@5.1
- Dolby TrueHD@7.1
- DTS HD-MA@7.1
- Dolby Atmos

Excellent job. Can we please get this patch into drm-fixes, as it is cleary a
bug fix and not a new feature.

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

Re: [PATCH] drm: vc4_hdmi: Replace long udelay with usleep_range

[Eric Anholt]

Stefan Wahren  writes:

> Since we aren't in atomic context replace this long udelay with a
> usleep_range.

Reviewed and pushed to drm-misc-next. Thanks!


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

Re: [PATCH v2] drm/vc4: Advertise supported modifiers for planes

[Eric Anholt]

Daniel Stone  writes:

> The IN_FORMATS blob allows the kernel to advertise to userspace which
> format/modifier combinations are supported, per plane. Use this to
> advertise that we support both T_TILED and linear.
>
> v2:
>   - Only advertise T_TILED for RGB (Eric)
>   - Actually turn on allow_fb_modifiers (Eric)
>
> Signed-off-by: Daniel Stone 

Reviewed and pushed to drm-misc-next. Thanks!


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

[PATCH v3] drm/mali-dp: Fix malidp_atomic_commit_hw_done() for event sending.

[Liviu Dudau]

Mali DP hardware has a 'go' bit (config_valid) for making the new scene
parameters active at the next page flip. The problem with the current
code is that the driver first sets this bit and then proceeds to wait
for confirmation from the hardware that the configuration has been
updated before arming the vblank event. As config_valid is actually
asserted by the hardware after the vblank event, during the prefetch
phase, when we get to arming the vblank event we are going to send it
at the next vblank, in effect halving the vblank rate from the userspace
perspective.

Fix it by sending the userspace event from the IRQ handler, when we
handle the config_valid interrupt, which syncs with the time when the
hardware is active with the new parameters.

v2: Brian reminded me that interrupts won't fire when CRTC is off,
so we need to do the sending ourselves.

v3: crtc->enabled is the wrong flag to use here, as when we get an
atomic commit that turns off the CRTC it will still be enabled until
after the commit is done. Use the crtc->state->active for test.

Reported-by: Alexandru-Cosmin Gheorghe 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_drv.c | 32 +---
 drivers/gpu/drm/arm/malidp_drv.h |  1 +
 drivers/gpu/drm/arm/malidp_hw.c  | 12 +---
 3 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index d88a3b9d59cc..3c628e43bf25 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -185,25 +185,29 @@ static int malidp_set_and_wait_config_valid(struct 
drm_device *drm)
 
 static void malidp_atomic_commit_hw_done(struct drm_atomic_state *state)
 {
-   struct drm_pending_vblank_event *event;
struct drm_device *drm = state->dev;
struct malidp_drm *malidp = drm->dev_private;
 
-   if (malidp->crtc.enabled) {
-   /* only set config_valid if the CRTC is enabled */
-   if (malidp_set_and_wait_config_valid(drm))
-   DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
-   }
+   malidp->event = malidp->crtc.state->event;
+   malidp->crtc.state->event = NULL;
 
-   event = malidp->crtc.state->event;
-   if (event) {
-   malidp->crtc.state->event = NULL;
+   if (malidp->crtc.state->active) {
+   /*
+* if we have an event to deliver to userspace, make sure
+* the vblank is enabled as we are sending it from the IRQ
+* handler.
+*/
+   if (malidp->event)
+   drm_crtc_vblank_get(>crtc);
 
+   /* only set config_valid if the CRTC is enabled */
+   if (malidp_set_and_wait_config_valid(drm) < 0)
+   DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
+   } else if (malidp->event) {
+   /* CRTC inactive means vblank IRQ is disabled, send event 
directly */
spin_lock_irq(>event_lock);
-   if (drm_crtc_vblank_get(>crtc) == 0)
-   drm_crtc_arm_vblank_event(>crtc, event);
-   else
-   drm_crtc_send_vblank_event(>crtc, event);
+   drm_crtc_send_vblank_event(>crtc, malidp->event);
+   malidp->event = NULL;
spin_unlock_irq(>event_lock);
}
drm_atomic_helper_commit_hw_done(state);
@@ -232,8 +236,6 @@ static void malidp_atomic_commit_tail(struct 
drm_atomic_state *state)
 
malidp_atomic_commit_hw_done(state);
 
-   drm_atomic_helper_wait_for_vblanks(drm, state);
-
pm_runtime_put(drm->dev);
 
drm_atomic_helper_cleanup_planes(drm, state);
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index e0d12c9fc6b8..c2375bb49619 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -22,6 +22,7 @@ struct malidp_drm {
struct malidp_hw_device *dev;
struct drm_crtc crtc;
wait_queue_head_t wq;
+   struct drm_pending_vblank_event *event;
atomic_t config_valid;
u32 core_id;
 };
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 2bfb542135ac..8abd335ec313 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -782,9 +782,15 @@ static irqreturn_t malidp_de_irq(int irq, void *arg)
/* first handle the config valid IRQ */
dc_status = malidp_hw_read(hwdev, hw->map.dc_base + MALIDP_REG_STATUS);
if (dc_status & hw->map.dc_irq_map.vsync_irq) {
-   /* we have a page flip event */
-   atomic_set(>config_valid, 1);
malidp_hw_clear_irq(hwdev, MALIDP_DC_BLOCK, dc_status);
+   /* do we have a page flip event? */
+   if (malidp->event != NULL) {
+   

Re: [PATCHv2 0/7] cec: add error injection support

[Wolfram Sang]

Hans,

> Special thanks go to Wolfram Sang since his i2c error injection
> presentation at the Embedded Linux Conference Europe 2017 inspired
> me to switch to debugfs for this instead of using ioctls.

You are very welcome! I am glad the presentation did inspire you.

Happy hacking,

   Wolfram



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

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #29 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Thanks for the logs, just to clear things out, you keep saying 'crash', but you
actually mean hang, right ? Or do observe actual Xorg process crash ? To answer
for sure check if Xorg is still running when you run 'ps' or 'top'and
/var/log/Xorg.log.

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

Re: [PATCH v2 2/2] drm: rcar-du: lvds: add R8A77970 support

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Thursday, 1 March 2018 20:10:16 EET Sergei Shtylyov wrote:
> Add support for the R-Car V3M (R8A77970) SoC to the LVDS encoder driver.
> Note that there are some differences with the other R-Car gen3 SoCs, e.g.
> LVDPLLCR has the same layout as in the R-Car gen2 SoCs...
> 
> Signed-off-by: Sergei Shtylyov 

Reviewed-by: Laurent Pinchart 

and applied to my tree.

> ---
> Changes in version 2:
> - shortened the comment to #define RCAR_LVDS_QUIRK_GEN2_PLLCR and applied
> this quitk to all R-Car gen2 SoCs, thus simplifying the check for the gen2
> LVDPLLCR layout;
> - renamed RCAR_LVDS_QUIRK_PHY to RCAR_LVDS_QUIRK_GEN3_LVEN, reworded the
> comment to this #define;
> - removed the 'quirks' variable from rcar_lvds_enable();
> - resolved rejects atop of the recent version of the LVDS driver.
> 
>  drivers/gpu/drm/rcar-du/rcar_lvds.c |   20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> Index: linux/drivers/gpu/drm/rcar-du/rcar_lvds.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -32,6 +32,9 @@ enum rcar_lvds_mode {
>  };
> 
>  #define RCAR_LVDS_QUIRK_LANES(1 << 0)/* LVDS lanes 1 and 3 
> inverted */
> +#define RCAR_LVDS_QUIRK_GEN2_PLLCR (1 << 1)  /* LVDPLLCR has gen2 layout */
> +#define RCAR_LVDS_QUIRK_GEN3_LVEN (1 << 2)   /* LVEN bit needs to be set */
> + /* on R8A77970/R8A7799x */
> 
>  struct rcar_lvds_device_info {
>   unsigned int gen;
> @@ -191,7 +194,7 @@ static void rcar_lvds_enable(struct drm_
>   rcar_lvds_write(lvds, LVDCHCR, lvdhcr);
> 
>   /* PLL clock configuration. */
> - if (lvds->info->gen < 3)
> + if (lvds->info->quirks & RCAR_LVDS_QUIRK_GEN2_PLLCR)
>   lvdpllcr = rcar_lvds_lvdpllcr_gen2(mode->clock);
>   else
>   lvdpllcr = rcar_lvds_lvdpllcr_gen3(mode->clock);
> @@ -224,6 +227,12 @@ static void rcar_lvds_enable(struct drm_
>   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
>   }
> 
> + if (lvds->info->quirks & RCAR_LVDS_QUIRK_GEN3_LVEN) {
> + /* Turn on the LVDS PHY. */
> + lvdcr0 |= LVDCR0_LVEN;
> + rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> + }
> +
>   /* Wait for the startup delay. */
>   usleep_range(100, 150);
> 
> @@ -485,17 +494,23 @@ static int rcar_lvds_remove(struct platf
> 
>  static const struct rcar_lvds_device_info rcar_lvds_gen2_info = {
>   .gen = 2,
> + .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR,
>  };
> 
>  static const struct rcar_lvds_device_info rcar_lvds_r8a7790_info = {
>   .gen = 2,
> - .quirks = RCAR_LVDS_QUIRK_LANES,
> + .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_LANES,
>  };
> 
>  static const struct rcar_lvds_device_info rcar_lvds_gen3_info = {
>   .gen = 3,
>  };
> 
> +static const struct rcar_lvds_device_info rcar_lvds_r8a77970_info = {
> + .gen = 3,
> + .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR | RCAR_LVDS_QUIRK_GEN3_LVEN,
> +};
> +
>  static const struct of_device_id rcar_lvds_of_table[] = {
>   { .compatible = "renesas,r8a7743-lvds", .data = _lvds_gen2_info },
>   { .compatible = "renesas,r8a7790-lvds", .data = _lvds_r8a7790_info 
> },
> @@ -503,6 +518,7 @@ static const struct of_device_id rcar_lv
>   { .compatible = "renesas,r8a7793-lvds", .data = _lvds_gen2_info },
>   { .compatible = "renesas,r8a7795-lvds", .data = _lvds_gen3_info },
>   { .compatible = "renesas,r8a7796-lvds", .data = _lvds_gen3_info },
> + { .compatible = "renesas,r8a77970-lvds", .data = 
> _lvds_r8a77970_info
> }, { }
>  };

-- 
Regards,

Laurent Pinchart

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

[Bug 104608] [r600, RV635] Removing radeon module results in BUG: unable to handle kernel NULL pointer dereference at 0000000000000258

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104608

Vedran Miletić  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Vedran Miletić  ---
Confirmed on 4.15.7-300.fc27.x86_64

[   59.965382] [drm] radeon: finishing device.
[   59.976804] [TTM] Finalizing pool allocator
[   59.976813] [TTM] Finalizing DMA pool allocator
[   59.977327] [TTM] Zone  kernel: Used memory at exit: 0 kiB
[   59.977330] [drm] radeon: ttm finalized

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

[no subject]

[Meghana Madhyastha]

linux-...@vger.kernel.org,Noralf Trønnes ,Sean Paul 
,ker...@martin.sperl.org
Cc: 
Bcc: 
Subject: Re: [PATCH v2 0/2] Chunk splitting of spi transfers
Reply-To: 
In-Reply-To: 

On Sun, Mar 04, 2018 at 06:38:42PM +0100, Noralf Trønnes wrote:
> 
> Den 02.03.2018 12.11, skrev Meghana Madhyastha:
> >On Sun, Feb 25, 2018 at 02:19:10PM +0100, Lukas Wunner wrote:
> >>[cc += linux-rpi-ker...@lists.infradead.org]
> >>
> >>On Sat, Feb 24, 2018 at 06:15:59PM +, Meghana Madhyastha wrote:
> >>>I've added bcm2835_spi_transfer_one_message in spi-bcm2835. This calls
> >>>spi_split_transfers_maxsize to split large chunks for spi dma transfers.
> >>>I then removed chunk splitting in the tinydrm spi helper (as now the core
> >>>is handling the chunk splitting). However, although the SPI HW should be
> >>>able to accomodate up to 65535 bytes for dma transfers, the splitting of
> >>>chunks to 65535 bytes results in a dma transfer time out error. However,
> >>>when the chunks are split to < 64 bytes it seems to work fine.
> >>Hm, that is really odd, how did you test this exactly, what did you
> >>use as SPI slave?  It contradicts our own experience, we're using
> >>Micrel KSZ8851 Ethernet chips as SPI slave on spi0 of a BCM2837
> >>and can send/receive messages via DMA to the tune of several hundred
> >>bytes without any issues.  In fact, for messages < 96 bytes, DMA is
> >>not used at all, so you've probably been using interrupt mode,
> >>see the BCM2835_SPI_DMA_MIN_LENGTH macro in spi-bcm2835.c.
> >Hi Lukas,
> >
> >I think you are right. I checked it and its not using the DMA mode which
> >is why its working with 64 bytes.
> >Noralf, that leaves us back to the
> >initial time out problem. I've tried doing the message splitting in
> >spi_sync as well as spi_pump_messages. Martin had explained that DMA
> >will wait for
> >the SPI HW to set the send_more_data line, but the SPI-HW itself will
> >stop triggering it when SPI_LEN is 0 causing DMA to wait forever. I
> >thought if we split it before itself, the SPI_LEN will not go to zero
> >thus preventing this problem, however it didn't work and started
> >hanging. So I'm a little uncertain as to how to proceed and debug what
> >exactly has caused the time out due to the asynchronous methods.
> 
> I did a quick test and at least this is working:
> 
> int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
>              struct spi_transfer *header, u8 bpw, const void *buf,
>              size_t len)
> {
>     struct spi_transfer tr = {
>         .bits_per_word = bpw,
>         .speed_hz = speed_hz,
>         .tx_buf = buf,
>         .len = len,
>     };
>     struct spi_message m;
>     size_t maxsize;
>     int ret;
> 
>     maxsize = tinydrm_spi_max_transfer_size(spi, 0);
> 
>     if (drm_debug & DRM_UT_DRIVER)
>         pr_debug("[drm:%s] bpw=%u, maxsize=%zu, transfers:\n",
>              __func__, bpw, maxsize);
> 
>     spi_message_init();
>     m.spi = spi;
>     if (header)
>         spi_message_add_tail(header, );
>     spi_message_add_tail(, );
> 
>     ret = spi_split_transfers_maxsize(spi->controller, , maxsize,
> GFP_KERNEL);
>     if (ret)
>         return ret;
> 
>     tinydrm_dbg_spi_message(spi, );
> 
>     return spi_sync(spi, );
> }
> EXPORT_SYMBOL(tinydrm_spi_transfer);
> 
> 
> Log:
> [   39.015644] [drm:mipi_dbi_fb_dirty [mipi_dbi]] Flushing [FB:36] x1=0,
> x2=320, y1=0, y2=240
> 
> [   39.018079] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2a, par=00 00 01
> 3f
> [   39.018129] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018152] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2a]
> [   39.018231] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018248] tr(0): speed=10MHz, bpw=8, len=4, tx_buf=[00 00 01 3f]
> 
> [   39.018330] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2b, par=00 00 00
> ef
> [   39.018347] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018362] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2b]
> [   39.018396] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018428] tr(0): speed=10MHz, bpw=8, len=4, tx_buf=[00 00 00 ef]
> 
> [   39.018487] [drm:mipi_dbi_typec3_command [mipi_dbi]] cmd=2c, len=153600
> [   39.018502] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018517] tr(0): speed=10MHz, bpw=8, len=1, tx_buf=[2c]
> [   39.018565] [drm:tinydrm_spi_transfer] bpw=8, maxsize=65532, transfers:
> [   39.018594] tr(0): speed=48MHz, bpw=8, len=65532, tx_buf=[c6 18 c6 18
> c6 18 c6 18 c6 18 c6 18 c6 18 c6 18 ...]
> [   39.018608] tr(1): speed=48MHz, bpw=8, len=65532, tx_buf=[06 18 06 18
> 06 18 06 18 06 18 06 18 06 18 06 18 ...]
> [   39.018621] tr(2): speed=48MHz, bpw=8, len=22536, tx_buf=[10 82 10 82
> 10 82 10 82 10 82 10 82 18 e3 18 e3 ...]
Hi Noralf,

Yes this works but splitting in the spi subsystem doesn't seem to 

[Bug 103953] [DC] Polaris10: Missing modes when enabling DC

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103953

Harry Wentland  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Harry Wentland  ---
Marking this fixed as multiple people confirmed fix is in amd-staging-drm-next.

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

Re: [PATCH v3 0/2] Parfait changes

[Joe Moriarty]

On 2/20/2018 2:11 PM, Joe Moriarty wrote:

The following patch(s) are bugs found by the static compiler
'Parfait'.  Care was taken to make sure false positive results
were removed from this patchset.

Parfait Overview


https://labs.oracle.com/pls/apex/f?p=labs:49:P49_PROJECT_ID:13

v1:
Initial release

v2:
- Split original v1 patch into 4 separate patches per request
from Jani Nikula
- Fixed system hang during boot up on test machine.

v3:
- Made changes requested by Daniel Vetter.

Joe Moriarty (2):
   drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem
   drm: NULL pointer dereference [null-pointer-deref] (CWE 476) problem

  drivers/gpu/drm/drm_drv.c| 2 +-
  drivers/gpu/drm/drm_vblank.c | 9 +
  2 files changed, 10 insertions(+), 1 deletion(-)


Ping, Waiting on review/addition of these 2 patches to drm-misc-next.

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

Re: [PATCH] drm/bridge: sii902x: Retry status read after DDI I2C

[Liviu Dudau]

On Mon, Mar 05, 2018 at 11:17:02AM +0100, Linus Walleij wrote:
> The following happens when connection a DVI output driven
> from the SiI9022 using a DVI-to-VGA adapter plug:
> 
> i2c i2c-0: sendbytes: NAK bailout.
> i2c i2c-0: sendbytes: NAK bailout.
> 
> Then no picture. Apparently the I2C engine inside the SiI9022
> is not smart enough to try to fall back to DDC I2C. Or the
> vendor have not integrated the electronics properly. I don't
> know which one it is.
> 
> After this, the I2C bus seems stalled and the first attempt to
> read the status register fails, and the code returns with
> negative return value, and the display fails to initialized.
> 
> Instead, retry status readout five times and continue even
> if this fails.
> 
> Tested on the ARM Versatile Express with a DVI-to-VGA
> connector, it now gives picture.
> 
> Introduce a helper struct device *dev variable to make
> the code more readable.
> 
> Cc: Ville Syrjälä 
> Cc: Liviu Dudau 

I don't have a suitable configuration to test this, but looks goot to me.

Reviewed-by: Liviu Dudau 

BTW, Linus, could it be that your DVI-to-VGA connector doesn't wire
correctly the EDID pin?

Best regards,
Liviu

> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Found the real problem instead of trying to explicitly
>   shoehorn EDID modes into the error path.
> ---
>  drivers/gpu/drm/bridge/sii902x.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index b1ab4ab09532..60373d7eb220 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -137,7 +137,9 @@ static int sii902x_get_modes(struct drm_connector 
> *connector)
>   struct sii902x *sii902x = connector_to_sii902x(connector);
>   struct regmap *regmap = sii902x->regmap;
>   u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> + struct device *dev = >i2c->dev;
>   unsigned long timeout;
> + unsigned int retries;
>   unsigned int status;
>   struct edid *edid;
>   int num = 0;
> @@ -159,7 +161,7 @@ static int sii902x_get_modes(struct drm_connector 
> *connector)
>time_before(jiffies, timeout));
>  
>   if (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD)) {
> - dev_err(>i2c->dev, "failed to acquire the i2c bus\n");
> + dev_err(dev, "failed to acquire the i2c bus\n");
>   return -ETIMEDOUT;
>   }
>  
> @@ -179,9 +181,19 @@ static int sii902x_get_modes(struct drm_connector 
> *connector)
>   if (ret)
>   return ret;
>  
> - ret = regmap_read(regmap, SII902X_SYS_CTRL_DATA, );
> + /*
> +  * Sometimes the I2C bus can stall after failure to use the
> +  * EDID channel. Retry a few times to see if things clear
> +  * up, else continue anyway.
> +  */
> + retries = 5;
> + do {
> + ret = regmap_read(regmap, SII902X_SYS_CTRL_DATA,
> +   );
> + retries--;
> + } while (ret && retries);
>   if (ret)
> - return ret;
> + dev_err(dev, "failed to read status (%d)\n", ret);
>  
>   ret = regmap_update_bits(regmap, SII902X_SYS_CTRL_DATA,
>SII902X_SYS_CTRL_DDC_BUS_REQ |
> @@ -201,7 +213,7 @@ static int sii902x_get_modes(struct drm_connector 
> *connector)
>  
>   if (status & (SII902X_SYS_CTRL_DDC_BUS_REQ |
> SII902X_SYS_CTRL_DDC_BUS_GRTD)) {
> - dev_err(>i2c->dev, "failed to release the i2c bus\n");
> + dev_err(dev, "failed to release the i2c bus\n");
>   return -ETIMEDOUT;
>   }
>  
> -- 
> 2.14.3
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU

[Jordan Crouse]

On Mon, Mar 05, 2018 at 10:12:21AM +0530, Viresh Kumar wrote:
> On 02-03-18, 14:56, Jordan Crouse wrote:
> > Add the nodes and other bits to describe the Adreno GPU and GMU
> > devices.
> > 
> > Change-Id: Ibf4dc0ebb0ac03d8b6b8e65747e142c440e70b0a
> 
> Remove it ?

* Shakes fist at Gerrit *

> > Signed-off-by: Jordan Crouse 
> > ---
> >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 120 
> > +++
> >  1 file changed, 120 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index 7b5c16eb63b7..cc6d367ee55e 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -312,5 +312,125 @@
> > status = "disabled";
> > };
> > };
> > +
> > +   adreno_smmu: arm,smmu-adreno@504 {
> > +   compatible = "qcom,msm8996-smmu-v2";
> > +   reg = <0x504 0x1>;
> > +   #iommu-cells = <1>;
> > +   #global-interrupts = <2>;
> > +   interrupts = ,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +,
> > +;
> > +   clocks = <_gcc GCC_GPU_MEMNOC_GFX_CLK>,
> > +<_gcc GCC_GPU_CFG_AHB_CLK>;
> > +   clock-names = "bus", "iface";
> > +
> > +   power-domains = <_gpucc GPU_CX_GDSC>;
> > +   };
> > +
> > +   gpu_opp_table: adreno-opp-table {
> > +   compatible = "operating-points-v2";
> > +
> > +   opp-71000 {
> > +   opp-hz = /bits/ 64 <71000>;
> > +   qcom,arc-level = <416>;
> 
> I am not sure if I saw where this is defined ?

I'm glad you brought this up - I was trying to find a place in the documentation
to put it, but since target specific nodes would be a new trick for OPP I didn't
quite know how to go about doing it. Do we just list them as Optional: or
should we add a target specific section to the documentation and list them out
there instead?

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/msm: Add A6XX device support

[Jordan Crouse]

On Mon, Mar 05, 2018 at 10:09:38AM +0530, Viresh Kumar wrote:
> On 02-03-18, 14:43, Jordan Crouse wrote:
> > +static int a6xx_gmu_build_freq_table(struct device *dev, unsigned long 
> > *freqs,
> > +   u32 size)
> > +{
> > +   int count = dev_pm_opp_get_opp_count(dev);
> > +   struct dev_pm_opp *opp;
> > +   int i, index = 0;
> > +   unsigned long freq = 1;
> > +
> > +   /*
> > +* The OPP table doesn't contain the "off" frequency level so we need to
> > +* add 1 to the table size to account for it
> > +*/
> > +
> > +   if (WARN(count + 1 > size,
> > +   "The GMU frequency table is being truncated\n"))
> > +   count = size - 1;
> > +
> > +   /* Set the "off" frequency */
> > +   freqs[index++] = 0;
> > +
> > +   for (i = 0; i < count; i++) {
> > +   opp = dev_pm_opp_find_freq_ceil(dev, );
> > +   if (IS_ERR(opp))
> > +   break;
> > +
> > +   freqs[index++] = freq++;
> 
>   dev_pm_opp_put(opp) ?
> 

Yes! Thank you for finding that. I'll fix it in the next go-around.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] PM / OPP: Add dev_pm_opp_get_np()

[Jordan Crouse]

On Mon, Mar 05, 2018 at 10:07:08AM +0530, Viresh Kumar wrote:
> On 02-03-18, 14:43, Jordan Crouse wrote:
> > Add a function to return the device node associated with a
> > specific opp which will facilitate detailing with custom
> > properties in client drivers.
> > 
> > Signed-off-by: Jordan Crouse 
> > ---
> >  drivers/opp/of.c   | 20 
> >  include/linux/pm_opp.h |  6 ++
> >  2 files changed, 26 insertions(+)
> 
> I was using a patch for this for quite sometime now, but never posted it. So 
> its
> your patch which should get merged now. But there are few things that you need
> to change/fix. Please update your patch based on mine (pasted below) and 
> repost
> here.

Thanks - I'll make the changes.

> And I am not really sure how should this patch get merged. Maybe I will apply
> the patch and share a branch (which I wouldn't rebase) and you can use that ?

You can go ahead and submit it through your normal process. The a6xx code won't
be merged with Linus until there is a open source user-mode driver component
available. Until then it will hang out in the various integration kernels and
the maintainers will be reminded to take this patch from your repo.

Thanks for the review,
Jordan

> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 21265af55117..b17715bc3c0a 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -736,3 +736,22 @@ struct dev_pm_opp 
> *of_dev_pm_opp_find_required_opp(struct device *dev,
>   return opp;
>  }
>  EXPORT_SYMBOL_GPL(of_dev_pm_opp_find_required_opp);
> +
> +/**
> + * dev_pm_opp_get_of_node() - Gets the DT node corresponding to an opp
> + * @opp: opp for which DT node has to be returned for
> + *
> + * Return: DT node corresponding to the opp, else 0 on success.
> + *
> + * The caller needs to put the node of_node_put() after using it.
> + */
> +struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
> +{
> + if (IS_ERR_OR_NULL(opp)) {
> + pr_err("%s: Invalid parameters\n", __func__);
> + return NULL;
> + }
> +
> + return of_node_get(opp->np);
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node);
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index 528a7d9cf2ef..099b31960dec 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -300,6 +300,7 @@ void dev_pm_opp_of_cpumask_remove_table(const struct 
> cpumask *cpumask);
>  int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask 
> *cpumask);
>  struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
>  struct dev_pm_opp *of_dev_pm_opp_find_required_opp(struct device *dev, 
> struct device_node *np);
> +struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
>  #else
>  static inline int dev_pm_opp_of_add_table(struct device *dev)
>  {
> @@ -338,6 +339,10 @@ static inline struct dev_pm_opp 
> *of_dev_pm_opp_find_required_opp(struct device *
>  {
>   return NULL;
>  }
> +static inline struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp 
> *opp)
> +{
> + return NULL;
> +}
>  #endif
>  
>  #endif   /* __LINUX_OPP_H__ */
> 
> -- 
> viresh

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm: Fix some coding style issues

[Ville Syrjala]

From: Ville Syrjälä 

Put an empty line between the variable declarations and the code, and
use tabs for alignment.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_framebuffer.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 155b21e579c4..6aa86a6549a0 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -179,9 +179,10 @@ static int framebuffer_check(struct drm_device *dev,
info = __drm_format_info(r->pixel_format & ~DRM_FORMAT_BIG_ENDIAN);
if (!info) {
struct drm_format_name_buf format_name;
+
DRM_DEBUG_KMS("bad framebuffer format %s\n",
- drm_get_format_name(r->pixel_format,
- _name));
+ drm_get_format_name(r->pixel_format,
+ _name));
return -EINVAL;
}
 
-- 
2.16.1

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

[PATCH 2/3] drm/i915: Eliminate the horrendous format check code

[Ville Syrjala]

From: Ville Syrjälä 

Now that the core makes sure that the pixel format is supported
by at least one plane, we can eliminate the hand rolled code for the
same thing in i915. The way we were doing was extremely inconvenient
because not only did you have to add the format to the plane's format
list, but you also had to come up with the correct platform checks
for this code.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 55 
 1 file changed, 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fb08590b4d40..9b03d50d2d53 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13991,7 +13991,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 {
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = _fb->base;
-   struct drm_format_name_buf format_name;
u32 pitch_limit;
unsigned int tiling, stride;
int ret = -EINVAL;
@@ -14083,60 +14082,6 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
 
-   /* Reject formats not supported by any plane early. */
-   switch (mode_cmd->pixel_format) {
-   case DRM_FORMAT_C8:
-   case DRM_FORMAT_RGB565:
-   case DRM_FORMAT_XRGB:
-   case DRM_FORMAT_ARGB:
-   break;
-   case DRM_FORMAT_XRGB1555:
-   if (INTEL_GEN(dev_priv) > 3) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_ABGR:
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
-   INTEL_GEN(dev_priv) < 9) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_XBGR:
-   case DRM_FORMAT_XRGB2101010:
-   case DRM_FORMAT_XBGR2101010:
-   if (INTEL_GEN(dev_priv) < 4) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_ABGR2101010:
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   case DRM_FORMAT_YUYV:
-   case DRM_FORMAT_UYVY:
-   case DRM_FORMAT_YVYU:
-   case DRM_FORMAT_VYUY:
-   if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) {
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- 
drm_get_format_name(mode_cmd->pixel_format, _name));
-   goto err;
-   }
-   break;
-   default:
-   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
- drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   goto err;
-   }
-
/* FIXME need to adjust LINOFF/TILEOFF accordingly. */
if (mode_cmd->offsets[0] != 0)
goto err;
-- 
2.16.1

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

[PATCH 1/3] drm: Make sure at least one plane supports the fb format

[Ville Syrjala]

From: Ville Syrjälä 

To make life easier for drivers, let's have the core check that the
requested pixel format is supported by at least one plane when creating
a new framebuffer.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_framebuffer.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index c0530a1af5e3..155b21e579c4 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -152,6 +152,23 @@ static int fb_plane_height(int height,
return DIV_ROUND_UP(height, format->vsub);
 }
 
+static bool planes_have_format(struct drm_device *dev, u32 format)
+{
+   struct drm_plane *plane;
+
+   /* TODO: maybe maintain a device level format list? */
+   drm_for_each_plane(plane, dev) {
+   int i;
+
+   for (i = 0; i < plane->format_count; i++) {
+   if (plane->format_types[i] == format)
+   return true;
+   }
+   }
+
+   return false;
+}
+
 static int framebuffer_check(struct drm_device *dev,
 const struct drm_mode_fb_cmd2 *r)
 {
@@ -168,6 +185,15 @@ static int framebuffer_check(struct drm_device *dev,
return -EINVAL;
}
 
+   if (!planes_have_format(dev, r->pixel_format)) {
+   struct drm_format_name_buf format_name;
+
+   DRM_DEBUG_KMS("unsupported framebuffer format %s\n",
+ drm_get_format_name(r->pixel_format,
+ _name));
+   return -EINVAL;
+   }
+
/* now let the driver pick its own format info */
info = drm_get_format_info(dev, r);
 
-- 
2.16.1

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

[Bug 105083] Random blinking display

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105083

--- Comment #13 from Harry Wentland  ---
(In reply to denisgolovan from comment #11)
> (In reply to Harry Wentland from comment #10)
> Some areas just
> stay not affected as if gamma change specifically disabled for them.

Do you have a picture?

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

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #28 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Here you go!

umr dump 0 is a crash just after starting X

umr dump 1 is a crash after running dmesg inside xterm just after starting X

Thanks!

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

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #27 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Created attachment 274537
  --> https://bugzilla.kernel.org/attachment.cgi?id=274537=edit
umr dump 1

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