date:20170928

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

--- Comment #23 from Shmerl  ---
The Witcher 3 in Wine is affected by a very similar issue:
https://bugs.winehq.org/show_bug.cgi?id=43786

And actually setting glsl_correct_derivatives_after_discard=true helps as well,
though it costs some performance.

-- 
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/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

On Thu, Sep 28, 2017 at 11:38:36AM +0200, Daniel Vetter wrote:
> On Thu, Sep 28, 2017 at 11:27 AM, Meghana Madhyastha
>  wrote:
> > On Thu, Sep 28, 2017 at 09:15:39AM +0200, Daniel Vetter wrote:
> >> On Wed, Sep 27, 2017 at 05:08:07PM +0200, Noralf Trønnes wrote:
> >> >
> >> > Den 27.09.2017 15.54, skrev Meghana Madhyastha:
> >> > > Rename tinydrm_of_find_backlight to drm_of_find_backlight
> >> > > and move it into drm_of.c from tinydrm-helpers.c. This is
> >> > > because other drivers in the drm subsystem might need to call
> >> > > this function. In that case and otherwise, it is better from
> >> > > an organizational point of view to move it into drm_of.c along
> >> > > with the other _of.c functions.
> >> > >
> >> > > Signed-off-by: Meghana Madhyastha 
> >> > > ---
> >> >
> >> > I suggest you split this patch in 2, one to add the function and one to
> >> > use it in tinydrm.
> >>
> >> In general I'd agree to split into 3 phases: 1) add new function 2)
> >> convert drivers 3) remove old one.
> >>
> >> But since there's only 1 caller this seems like overkill.
> >>
> >> > >   drivers/gpu/drm/drm_of.c   | 41 
> >> > > ++
> >> > >   drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 
> >> > > -
> >> > >   drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
> >> > >   include/drm/drm_of.h   |  1 +
> >> > >   include/drm/tinydrm/tinydrm-helpers.h  |  1 -
> >> > >   5 files changed, 44 insertions(+), 42 deletions(-)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> >> > > index 8dafbdf..d8cded3 100644
> >> > > --- a/drivers/gpu/drm/drm_of.c
> >> > > +++ b/drivers/gpu/drm/drm_of.c
> >> > > @@ -1,6 +1,7 @@
> >> > >   #include 
> >> > >   #include 
> >> > >   #include 
> >> > > +#include 
> >> > >   #include 
> >> > >   #include 
> >> > >   #include 
> >> > > @@ -260,3 +261,43 @@ int drm_of_find_panel_or_bridge(const struct 
> >> > > device_node *np,
> >> > >   return ret;
> >> > >   }
> >> > >   EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
> >> > > +
> >> > > +/**
> >> > > + * drm_of_find_backlight - Find backlight device in device-tree
> >> > > + * @dev: Device
> >> > > + *
> >> > > + * This function looks for a DT node pointed to by a property named 
> >> > > 'backlight'
> >> > > + * and uses of_find_backlight_by_node() to get the backlight device.
> >> > > + * Additionally if the brightness property is zero, it is set to
> >> > > + * max_brightness.
> >> >
> >> > Please add a note here about the callers responsibility to call
> >> > put_device() when releasing the resource.
> >> > See the of_find_backlight_by_node() docs.
> >> >
> >> > > + *
> >> > > + * Returns:
> >> > > + * NULL if there's no backlight property.
> >> > > + * Error pointer -EPROBE_DEFER if the DT node is found, but no 
> >> > > backlight device
> >> > > + * is found.
> >> > > + * If the backlight device is found, a pointer to the structure is 
> >> > > returned.
> >> > > + */
> >> > > +struct backlight_device *drm_of_find_backlight(struct device *dev)
> >> > > +{
> >> > > + struct backlight_device *backlight;
> >> > > + struct device_node *np;
> >> > > +
> >> > > + np = of_parse_phandle(dev->of_node, "backlight", 0);
> >> > > + if (!np)
> >> > > + return NULL;
> >> > > +
> >> > > + backlight = of_find_backlight_by_node(np);
> >> > > + of_node_put(np);
> >> > > +
> >> > > + if (!backlight)
> >> > > + return ERR_PTR(-EPROBE_DEFER);
> >> > > +
> >> > > + if (!backlight->props.brightness) {
> >> > > + backlight->props.brightness = 
> >> > > backlight->props.max_brightness;
> >> > > + DRM_DEBUG_KMS("Backlight brightness set to %d\n",
> >> > > +   backlight->props.brightness);
> >> > > + }
> >> > > +
> >> > > + return backlight;
> >> > > +}
> >> > > +EXPORT_SYMBOL(drm_of_find_backlight);
> >> >
> >> > Can you also please add a devm_ version of this function. tinydrm uses
> >> > devres[1] versions of functions for requiring device resources, so it
> >> > would be nice to do this for backlight as well. tinydrm is currently
> >> > broken in this respect, it doesn't put the backlight device.
> >> >
> >> > I had a devm_of_find_backlight() version lying around that I've adjusted
> >> > to give you an idea of what I'm talking about:
> >> >
> >> > static void devm_drm_of_find_backlight_release(void *data)
> >> > {
> >> > put_device(data);
> >> > }
> >> >
> >> > struct backlight_device *devm_drm_of_find_backlight(struct device *dev)
> >> > {
> >> > struct backlight_device *backlight;
> >> > int ret;
> >> >
> >> > backlight = drm_of_find_backlight(dev);
> >> > if (IS_ERR_OR_NULL(backlight))
> >> > return backlight;
> >> >
> >> > ret = devm_add_action(dev, devm_drm_of_find_backlight_release,
> >> >   backlight->dev);
> >> > if (ret) {
> >> > put_device(backlight->dev);
> >> > return ERR_PTR(re

Re: [PATCH v3 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

On Thu, Sep 28, 2017 at 06:02:27PM +0200, Noralf Trønnes wrote:
> 
> Den 28.09.2017 16.08, skrev Daniel Vetter:
> >On Thu, Sep 28, 2017 at 02:44:34PM +0530, Meghana Madhyastha wrote:
> >>Rename tinydrm_of_find_backlight to drm_of_find_backlight
> >>and move it into drm_of.c from tinydrm-helpers.c. This is
> >>because other drivers in the drm subsystem might need to call
> >>this function. In that case and otherwise, it is better from
> >>an organizational point of view to move it into drm_of.c along
> >>with the other _of.c functions.
> >>
> >>Signed-off-by: Meghana Madhyastha 
> >>---
> >>Changes in v3:
> >>-Change it back to a single patch from two patches in v2
> >>
> >>  drivers/gpu/drm/drm_of.c   | 44 
> >> ++
> >>  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 
> >> ---
> >>  drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
> >>  include/drm/drm_of.h   |  1 +
> >>  include/drm/tinydrm/tinydrm-helpers.h  |  1 -
> >>  5 files changed, 47 insertions(+), 42 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> >>index 8dafbdf..d878d3a 100644
> >>--- a/drivers/gpu/drm/drm_of.c
> >>+++ b/drivers/gpu/drm/drm_of.c
> >>@@ -1,6 +1,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >>+#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>@@ -260,3 +261,46 @@ int drm_of_find_panel_or_bridge(const struct 
> >>device_node *np,
> >>return ret;
> >>  }
> >>  EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
> >>+
> >>+/**
> >>+ * drm_of_find_backlight - Find backlight device in device-tree
> >>+ * @dev: Device
> >>+ *
> >>+ * This function looks for a DT node pointed to by a property named 
> >>'backlight'
> >>+ * and uses of_find_backlight_by_node() to get the backlight device.
> >>+ * Additionally if the brightness property is zero, it is set to
> >>+ * max_brightness.
> >>+ *
> >>+ * Note: It is the responsibility of the caller to call put_device() when
> >>+ * releasing the resource.
> >>+ *
> >>+ * Returns:
> >>+ * NULL if there's no backlight property.
> >>+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight 
> >>device
> >>+ * is found.
> >>+ * If the backlight device is found, a pointer to the structure is 
> >>returned.
> >>+ */
> >>+struct backlight_device *drm_of_find_backlight(struct device *dev)
> >>+{
> >>+   struct backlight_device *backlight;
> >>+   struct device_node *np;
> >>+
> >>+   np = of_parse_phandle(dev->of_node, "backlight", 0);
> >>+   if (!np)
> >>+   return NULL;
> >>+
> >>+   backlight = of_find_backlight_by_node(np);
> >>+   of_node_put(np);
> >>+
> >>+   if (!backlight)
> >>+   return ERR_PTR(-EPROBE_DEFER);
> >>+
> >>+   if (!backlight->props.brightness) {
> >>+   backlight->props.brightness = backlight->props.max_brightness;
> >>+   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
> >>+ backlight->props.brightness);
> >>+   }
> >>+
> >>+   return backlight;
> >>+}
> >>+EXPORT_SYMBOL(drm_of_find_backlight);
> >>diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
> >>b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >>index bd6cce0..cd4c6a5 100644
> >>--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >>+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> >>@@ -237,46 +237,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
> >>struct drm_framebuffer *fb,
> >>  EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
> >>  /**
> >>- * tinydrm_of_find_backlight - Find backlight device in device-tree
> >>- * @dev: Device
> >>- *
> >>- * This function looks for a DT node pointed to by a property named 
> >>'backlight'
> >>- * and uses of_find_backlight_by_node() to get the backlight device.
> >>- * Additionally if the brightness property is zero, it is set to
> >>- * max_brightness.
> >>- *
> >>- * Returns:
> >>- * NULL if there's no backlight property.
> >>- * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight 
> >>device
> >>- * is found.
> >>- * If the backlight device is found, a pointer to the structure is 
> >>returned.
> >>- */
> >>-struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
> >>-{
> >>-   struct backlight_device *backlight;
> >>-   struct device_node *np;
> >>-
> >>-   np = of_parse_phandle(dev->of_node, "backlight", 0);
> >>-   if (!np)
> >>-   return NULL;
> >>-
> >>-   backlight = of_find_backlight_by_node(np);
> >>-   of_node_put(np);
> >>-
> >>-   if (!backlight)
> >>-   return ERR_PTR(-EPROBE_DEFER);
> >>-
> >>-   if (!backlight->props.brightness) {
> >>-   backlight->props.brightness = backlight->props.max_brightness;
> >>-   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
> >>- backlight->props.brightness);
> >>-   }
> >>-
> >>-   return backlight;
> >>-}
> >>-EXPORT_SYMBOL(tinydrm_of_find_backlight);
> >>-
> >>-/**
> >>   * tiny

Re: [PATCH v3 2/2] drm/tinydrm: Add devres versions of drm_of_find_backlight

On Thu, Sep 28, 2017 at 06:19:35PM +0200, Noralf Trønnes wrote:
> 
> Den 28.09.2017 11.15, skrev Meghana Madhyastha:
> >Add devm_drm_of_find_backlight and the corresponding release
> >function because some drivers such as tinydrm use devres versions
> >of functions for requiring device resources.
> >
> >Signed-off-by: Meghana Madhyastha 
> >---
> >Changes in v3:
> >-None
> >
> >  drivers/gpu/drm/drm_of.c | 48 
> > 
> >  include/drm/drm_of.h |  2 ++
> >  2 files changed, 50 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> >index d878d3a..238e8e5 100644
> >--- a/drivers/gpu/drm/drm_of.c
> >+++ b/drivers/gpu/drm/drm_of.c
> >@@ -304,3 +304,51 @@ struct backlight_device *drm_of_find_backlight(struct 
> >device *dev)
> > return backlight;
> >  }
> >  EXPORT_SYMBOL(drm_of_find_backlight);
> >+
> >+/**
> >+ * devm_drm_of_find_backlight_release - Release backlight device
> >+ * @dev: Device
> >+ *
> >+ * This is the release function corresponding to the 
> >devm_drm_of_find_backlight.
> >+ * Each devres entry is associated with a release function.
> >+ */
> 
> This is an internal function so no need for docs or exporting. I know
> that some devm_ functions have explicit release functions, but I don't
> think this is necessary since those users can just use
> drm_of_find_backlight() directly instead.

I have a question here. devm_drm_of_find_backlight_release is a
wrapper around put_device which is passed as a parameter to
devm_add_action in devm_drm_of_find_backlight. So isn't the function
useful here ?

> >+static void devm_drm_of_find_backlight_release(void *data)
> >+{
> >+put_device(data);
> >+}
> >+EXPORT_SYMBOL(devm_drm_of_find_backlight_release);
> >+
> >+/**
> >+ * devm_drm_of_find_backlight - Find backlight device in device-tree
> >+ * devres version of the function
> >+ * @dev: Device
> >+ *
> >+ * This is the devres version of the function drm_of_find_backlight.
> >+ * Some drivers such as tinydrm use devres versions of functions for
> 
> No need to mention tinydrm here.
> 
> >+ * requiring device resources.
> >+ *
> >+ * Returns:
> >+ * NULL if there's no backlight property.
> >+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight 
> >device
> >+ * is found.
> >+ * If the backlight device is found, a pointer to the structure is returned.
> >+ */
> >+struct backlight_device *devm_drm_of_find_backlight(struct device *dev)
> >+{
> >+struct backlight_device *backlight;
> >+int ret;
> >+
> >+backlight = drm_of_find_backlight(dev);
> >+if (IS_ERR_OR_NULL(backlight))
> >+return backlight;
> >+
> >+ret = devm_add_action(dev, devm_drm_of_find_backlight_release,
> >+  &backlight->dev);
> >+if (ret) {
> >+put_device(&backlight->dev);
> >+return ERR_PTR(ret);
> >+}
> >+
> >+return backlight;
> >+}
> >+EXPORT_SYMBOL(devm_drm_of_find_backlight);
> >diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> >index e8fba5b..071fb3b 100644
> >--- a/include/drm/drm_of.h
> >+++ b/include/drm/drm_of.h
> >@@ -30,7 +30,9 @@ int drm_of_find_panel_or_bridge(const struct device_node 
> >*np,
> > struct drm_panel **panel,
> > struct drm_bridge **bridge);
> >  struct backlight_device *drm_of_find_backlight(struct device *dev);
> >+struct backlight_device *devm_drm_of_find_backlight(struct device *dev);
> >  #else
> 
> We need a dummy version of devm_drm_of_find_backlight() here that
> returns NULL as in the previous patch.
> 
> >+static void devm_drm_of_find_backlight_release(void *data);
> 
> And this isn't needed as explained above.
> >  static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> >   struct device_node *port)
> >  {
> 
> I'd appreciate if you could also switch mi0283qt over to this helper :-)
> 
> Noralf.
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/syncobj: extract two helpers from drm_syncobj_create

2017-09-28 Thread Chunming Zhou




On 2017年09月13日 04:42, Marek Olšák wrote:

From: Marek Olšák 

For amdgpu.

drm_syncobj_create is renamed to drm_syncobj_create_as_handle, and new
helpers drm_syncobj_create and drm_syncobj_get_handle are added.

Signed-off-by: Marek Olšák 
---
  drivers/gpu/drm/drm_syncobj.c | 49 +++
  include/drm/drm_syncobj.h |  4 
  2 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0422b8c..0bb1741 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -262,8 +262,14 @@ void drm_syncobj_free(struct kref *kref)
  }
  EXPORT_SYMBOL(drm_syncobj_free);
  
-static int drm_syncobj_create(struct drm_file *file_private,

- u32 *handle, uint32_t flags)
You can add a new parameter for passing dma fence, then in patch3, you 
can directly use it for AMDGPU_FENCE_TO HANDLE_GET_SYNCOBJ.


otherwise the set looks good to me.

Regards,
David Zhou


+/**
+ * drm_syncobj_create - create a new syncobj
+ * @out_syncobj: returned syncobj
+ * @flags: DRM_SYNCOBJ_* flags
+ * @fence: if non-NULL, the syncobj will represent this fence
+ */
+int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
+  struct dma_fence *fence)
  {
int ret;
struct drm_syncobj *syncobj;
@@ -284,6 +290,25 @@ static int drm_syncobj_create(struct drm_file 
*file_private,
}
}
  
+	if (fence)

+   drm_syncobj_replace_fence(syncobj, fence);
+
+   *out_syncobj = syncobj;
+   return 0;
+}
+EXPORT_SYMBOL(drm_syncobj_create);
+
+/**
+ * drm_syncobj_get_handle - get a handle from a syncobj
+ */
+int drm_syncobj_get_handle(struct drm_file *file_private,
+  struct drm_syncobj *syncobj, u32 *handle)
+{
+   int ret;
+
+   /* take a reference to put in the idr */
+   drm_syncobj_get(syncobj);
+
idr_preload(GFP_KERNEL);
spin_lock(&file_private->syncobj_table_lock);
ret = idr_alloc(&file_private->syncobj_idr, syncobj, 1, 0, GFP_NOWAIT);
@@ -299,6 +324,22 @@ static int drm_syncobj_create(struct drm_file 
*file_private,
*handle = ret;
return 0;
  }
+EXPORT_SYMBOL(drm_syncobj_get_handle);
+
+static int drm_syncobj_create_as_handle(struct drm_file *file_private,
+   u32 *handle, uint32_t flags)
+{
+   int ret;
+   struct drm_syncobj *syncobj;
+
+   ret = drm_syncobj_create(&syncobj, flags, NULL);
+   if (ret)
+   return ret;
+
+   ret = drm_syncobj_get_handle(file_private, syncobj, handle);
+   drm_syncobj_put(syncobj);
+   return ret;
+}
  
  static int drm_syncobj_destroy(struct drm_file *file_private,

   u32 handle)
@@ -522,8 +563,8 @@ drm_syncobj_create_ioctl(struct drm_device *dev, void *data,
if (args->flags & ~DRM_SYNCOBJ_CREATE_SIGNALED)
return -EINVAL;
  
-	return drm_syncobj_create(file_private,

- &args->handle, args->flags);
+   return drm_syncobj_create_as_handle(file_private,
+   &args->handle, args->flags);
  }
  
  int

diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index c00fee5..e7f0035 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -136,5 +136,9 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
   u32 handle,
   struct dma_fence **fence);
  void drm_syncobj_free(struct kref *kref);
+int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
+  struct dma_fence *fence);
+int drm_syncobj_get_handle(struct drm_file *file_private,
+  struct drm_syncobj *syncobj, u32 *handle);
  
  #endif


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

[Bug 101749] sclk scales badly in war thunder

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

--- Comment #2 from higu...@gmx.net ---
a apitrace link in https://bugs.freedesktop.org/show_bug.cgi?id=101978#c5 may
help test this.

talking with other people, looks like amdgpu and war thunder are performing
badly in several GPUs, if not all of then

-- 
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 101978] [bisected] war thunder performance reduced by ~28%

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

--- Comment #5 from higu...@gmx.net ---
I'm not very familiar with apitrace, so i generated a 2.6GB trace, locate here:
http://motaleite.net/~higuita/warthunder/aces.trace

The replay also look broken, do not know if its some bug or its normal

Anyway, 1 minute after starting you get a long benchmark run where you can
notice in a RX480 (and probably other GPUs of the same family or even in all
amdgpu ) that the GPU load is low (~30% here), sclk also low (~350-450Mhz)

-- 
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 libdrm] modetest: Decode IN_FORMATS plane blob property

2017-09-28 Thread Kristian H. Kristensen

This teaches modetest about the new IN_FORMATS blob and decodes the
blob to show supported formats and modifiers.

Signed-off-by: Kristian H. Kristensen 
---
 tests/modetest/modetest.c | 86 +++
 1 file changed, 86 insertions(+)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index b8891ff5..8ad4766f 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -251,6 +251,89 @@ static void dump_blob(struct device *dev, uint32_t blob_id)
drmModeFreePropertyBlob(blob);
 }
 
+static const char *modifier_to_string(uint64_t modifier)
+{
+   switch (modifier) {
+   case DRM_FORMAT_MOD_INVALID:
+   return "INVALID";
+   case DRM_FORMAT_MOD_LINEAR:
+   return "LINEAR";
+   case I915_FORMAT_MOD_X_TILED:
+   return "X_TILED";
+   case I915_FORMAT_MOD_Y_TILED:
+   return "Y_TILED";
+   case I915_FORMAT_MOD_Yf_TILED:
+   return "Yf_TILED";
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   return "Y_TILED_CCS";
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   return "Yf_TILED_CCS";
+   case DRM_FORMAT_MOD_SAMSUNG_64_32_TILE:
+   return "SAMSUNG_64_32_TILE";
+   case DRM_FORMAT_MOD_VIVANTE_TILED:
+   return "VIVANTE_TILED";
+   case DRM_FORMAT_MOD_VIVANTE_SUPER_TILED:
+   return "VIVANTE_SUPER_TILED";
+   case DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED:
+   return "VIVANTE_SPLIT_TILED";
+   case DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED:
+   return "VIVANTE_SPLIT_SUPER_TILED";
+   case NV_FORMAT_MOD_TEGRA_TILED:
+   return "MOD_TEGRA_TILED";
+   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(0):
+   return "MOD_TEGRA_16BX2_BLOCK(0)";
+   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(1):
+   return "MOD_TEGRA_16BX2_BLOCK(1)";
+   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(2):
+   return "MOD_TEGRA_16BX2_BLOCK(2)";
+   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(3):
+   return "MOD_TEGRA_16BX2_BLOCK(3)";
+   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(4):
+   return "MOD_TEGRA_16BX2_BLOCK(4)";
+   case NV_FORMAT_MOD_TEGRA_16BX2_BLOCK(5):
+   return "MOD_TEGRA_16BX2_BLOCK(5)";
+   case DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED:
+   return "MOD_BROADCOM_VC4_T_TILED";
+   default:
+   return "(UNKNOWN MODIFIER)";
+   }
+}
+
+static void dump_in_formats(struct device *dev, uint32_t blob_id)
+{
+   uint32_t i, j;
+   drmModePropertyBlobPtr blob;
+   struct drm_format_modifier_blob *header;
+   uint32_t *formats;
+   struct drm_format_modifier *modifiers;
+
+   printf("\t\tin_formats blob decoded:\n");
+   blob = drmModeGetPropertyBlob(dev->fd, blob_id);
+   if (!blob) {
+   printf("\n");
+   return;
+   }
+
+   header = blob->data;
+   formats = (uint32_t *) ((char *) header + header->formats_offset);
+   modifiers = (struct drm_format_modifier *)
+   ((char *) header + header->modifiers_offset);
+
+   for (i = 0; i < header->count_formats; i++) {
+   printf("\t\t\t");
+   dump_fourcc(formats[i]);
+   printf(": ");
+   for (j = 0; j < header->count_modifiers; j++) {
+   uint64_t mask = 1ULL << i;
+   if (modifiers[j].formats & mask)
+   printf(" %s", 
modifier_to_string(modifiers[j].modifier));
+   }
+   printf("\n");
+   }
+
+   drmModeFreePropertyBlob(blob);
+}
+
 static void dump_prop(struct device *dev, drmModePropertyPtr prop,
  uint32_t prop_id, uint64_t value)
 {
@@ -328,6 +411,9 @@ static void dump_prop(struct device *dev, 
drmModePropertyPtr prop,
printf(" %"PRId64"\n", value);
else
printf(" %"PRIu64"\n", value);
+
+   if (strcmp(prop->name, "IN_FORMATS") == 0)
+   dump_in_formats(dev, value);
 }
 
 static void dump_connectors(struct device *dev)
-- 
2.14.2.822.g60be5d43e6-goog

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

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

2017-09-28 Thread Dave Airlie

On 29 September 2017 at 06:41, Marek Olšák  wrote:
> Can I get Rb for this series?
>

For the series,

Reviewed-by: Dave Airlie 

Alex, please merge the two drm core precursor with patch 3.

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

[PATCH libdrm 1/1] Add meson build system

2017-09-28 Thread Dylan Baker

This patch adds a meson build system that is equivalent to the autotools
build system with a few exceptions but is about 4x faster than
autotools.

Signed-off-by: Dylan Baker 

---
 amdgpu/meson.build  |  73 ++
 data/meson.build|  24 
 etnaviv/meson.build |  59 +
 exynos/meson.build  |  49 +++
 freedreno/meson.build   |  78 +++
 intel/meson.build   |  85 
 libkms/meson.build  |  71 ++
 man/meson.build |  66 +
 meson.build | 317 
 meson_options.txt   |  38 ++
 nouveau/meson.build |  61 +
 omap/meson.build|  49 +++
 radeon/meson.build  |  61 +
 tegra/meson.build   |  48 +++
 tests/amdgpu/meson.build|  42 ++
 tests/etnaviv/meson.build   |  57 
 tests/exynos/meson.build|  54 
 tests/kms/meson.build   |  54 
 tests/kmstest/meson.build   |  30 +
 tests/meson.build   |  85 
 tests/modeprint/meson.build |  29 
 tests/nouveau/meson.build   |  30 +
 tests/proptest/meson.build  |  30 +
 tests/radeon/meson.build|  27 
 tests/tegra/meson.build |  27 
 tests/util/meson.build  |  37 ++
 tests/vbltest/meson.build   |  28 
 vc4/meson.build |  28 
 28 files changed, 1637 insertions(+)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

diff --git a/amdgpu/meson.build b/amdgpu/meson.build
new file mode 100644
index ..72150f9e
--- /dev/null
+++ b/amdgpu/meson.build
@@ -0,0 +1,73 @@
+# Copyright ?? 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+ids = join_paths(meson.source_root(), 'data/amdgpu.ids')
+
+prog_egrep = find_program('egrep')
+amdgpu_asic_count = run_command(
+  prog_egrep, ['-ci', '\'^[0-9a-f]{4},.*[0-9a-f]+,\'', ids]
+).stdout().strip()
+
+datadir = get_option('datadir')
+
+files_amdgpu = files(
+  'amdgpu_asic_id.c',
+  'amdgpu_bo.c',
+  'amdgpu_cs.c',
+  'amdgpu_device.c',
+  'amdgpu_gpu_info.c',
+  'amdgpu_internal.h',
+  'amdgpu_vamgr.c',
+  'util_hash.c',
+  'util_hash.h',
+  'util_hash_table.c',
+  'util_hash_table.h',
+)
+
+libdrm_amdgpu = shared_library(
+  'drm_amdgpu',
+  [files_amdgpu, config_file],
+  c_args : [c_args,
+   '-DAMDGPU_ASIC_ID_TABLE="@0@"'.format(join_paths(datadir, 'libdrm', 
'amdgpu.ids')),
+   '-DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=@0@'.format(amdgpu_asic_count)],
+  include_directories : [inc_root, inc_drm],
+  link_with : libdrm,
+  dependencies : [dep_pthread_stubs],
+  version : '1.0.0',
+  install : true,
+)
+
+install_headers('amdgpu.h', subdir : 'libdrm')
+
+pkg.generate(
+  name : 'libdrm_amdgpu',
+  libraries : libdrm_amdgpu,
+  subdirs : ['.', 'libdrm'],
+  version : meson

[PATCH libdrm 0/1] Meson, round 2

2017-09-28 Thread Dylan Baker

This is a second go at a meson build system for libdrm. Since we've started
landing meson for mesa as well as other projects in the ecosystem like wayland,
xorg, and IGT, I thought I would send this out again.

Dylan Baker (1):
  Add meson build system

 amdgpu/meson.build  |  73 ++
 data/meson.build|  24 
 etnaviv/meson.build |  59 +
 exynos/meson.build  |  49 +++
 freedreno/meson.build   |  78 +++
 intel/meson.build   |  85 
 libkms/meson.build  |  71 ++
 man/meson.build |  66 +
 meson.build | 317 
 meson_options.txt   |  38 ++
 nouveau/meson.build |  61 +
 omap/meson.build|  49 +++
 radeon/meson.build  |  61 +
 tegra/meson.build   |  48 +++
 tests/amdgpu/meson.build|  42 ++
 tests/etnaviv/meson.build   |  57 
 tests/exynos/meson.build|  54 
 tests/kms/meson.build   |  54 
 tests/kmstest/meson.build   |  30 +
 tests/meson.build   |  85 
 tests/modeprint/meson.build |  29 
 tests/nouveau/meson.build   |  30 +
 tests/proptest/meson.build  |  30 +
 tests/radeon/meson.build|  27 
 tests/tegra/meson.build |  27 
 tests/util/meson.build  |  37 ++
 tests/vbltest/meson.build   |  28 
 vc4/meson.build |  28 
 28 files changed, 1637 insertions(+)
 create mode 100644 amdgpu/meson.build
 create mode 100644 data/meson.build
 create mode 100644 etnaviv/meson.build
 create mode 100644 exynos/meson.build
 create mode 100644 freedreno/meson.build
 create mode 100644 intel/meson.build
 create mode 100644 libkms/meson.build
 create mode 100644 man/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 nouveau/meson.build
 create mode 100644 omap/meson.build
 create mode 100644 radeon/meson.build
 create mode 100644 tegra/meson.build
 create mode 100644 tests/amdgpu/meson.build
 create mode 100644 tests/etnaviv/meson.build
 create mode 100644 tests/exynos/meson.build
 create mode 100644 tests/kms/meson.build
 create mode 100644 tests/kmstest/meson.build
 create mode 100644 tests/meson.build
 create mode 100644 tests/modeprint/meson.build
 create mode 100644 tests/nouveau/meson.build
 create mode 100644 tests/proptest/meson.build
 create mode 100644 tests/radeon/meson.build
 create mode 100644 tests/tegra/meson.build
 create mode 100644 tests/util/meson.build
 create mode 100644 tests/vbltest/meson.build
 create mode 100644 vc4/meson.build

-- 
2.14.1

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

[PATCH] drm/amd/display: Remove DWB

2017-09-28 Thread Harry Wentland

It's not in a good shape and currently completely unused.

Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/core/dc.c   |   9 -
 drivers/gpu/drm/amd/display/dc/dcn10/Makefile  |   2 +-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c   | 365 -
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.h   | 277 
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  |  57 
 drivers/gpu/drm/amd/display/dc/inc/core_types.h|   3 -
 drivers/gpu/drm/amd/display/dc/inc/hw/dwb.h| 193 ---
 7 files changed, 1 insertion(+), 905 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c
 delete mode 100644 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.h
 delete mode 100644 drivers/gpu/drm/amd/display/dc/inc/hw/dwb.h

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index d86d9796e4cc..7fd42fc8bdfa 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -1525,15 +1525,6 @@ struct dc_link *dc_get_link_at_index(struct dc *dc, 
uint32_t link_index)
return dc->links[link_index];
 }
 
-struct dwbc *dc_get_dwb_at_pipe(struct dc *dc, uint32_t pipe)
-{
-   if ((pipe >= dwb_pipe0) && (pipe < dwb_pipe_max_num)) {
-   return dc->res_pool->dwbc[(int)pipe];
-   } else {
-   return NULL;
-   }
-}
-
 const struct graphics_object_id dc_get_link_id_at_index(
struct dc *dc, uint32_t link_index)
 {
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
index e92ac2997a1a..2d6d3a371858 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
@@ -3,7 +3,7 @@
 
 DCN10 = dcn10_resource.o dcn10_ipp.o dcn10_hw_sequencer.o \
dcn10_dpp.o dcn10_opp.o dcn10_timing_generator.o \
-   dcn10_mem_input.o dcn10_mpc.o dcn10_dwb.o \
+   dcn10_mem_input.o dcn10_mpc.o \
dcn10_dpp_dscl.o dcn10_dpp_cm.o dcn10_dpp_cm_helper.o
 
 AMD_DAL_DCN10 = $(addprefix $(AMDDALPATH)/dc/dcn10/,$(DCN10))
diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c 
b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c
deleted file mode 100644
index 4ec5554f0f5b..
--- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c
+++ /dev/null
@@ -1,365 +0,0 @@
-/*
- * Copyright 2012-17 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors: AMD
- *
- */
-
-#if defined(CONFIG_DRM_AMD_DC_DCN1_0)
-
-#include "reg_helper.h"
-#include "resource.h"
-#include "dwb.h"
-#include "dcn10_dwb.h"
-
-
-#define REG(reg)\
-   dwbc10->dwbc_regs->reg
-
-#define CTX \
-   dwbc10->base.ctx
-
-#undef FN
-#define FN(reg_name, field_name) \
-   dwbc10->dwbc_shift->field_name, dwbc10->dwbc_mask->field_name
-
-#define TO_DCN10_DWBC(dwbc_base) \
-   container_of(dwbc_base, struct dcn10_dwbc, base)
-
-static bool get_caps(struct dwbc *dwbc, struct dwb_caps *caps)
-{
-   if (caps) {
-   caps->adapter_id = 0;   /* we only support 1 adapter currently 
*/
-   caps->hw_version = DCN_VERSION_1_0;
-   caps->num_pipes = 2;
-   memset(&caps->reserved, 0, sizeof(caps->reserved));
-   memset(&caps->reserved2, 0, sizeof(caps->reserved2));
-   caps->sw_version = dwb_ver_1_0;
-   caps->caps.support_dwb = true;
-   caps->caps.support_ogam = false;
-   caps->caps.support_wbscl = true;
-   caps->caps.support_ocsc = false;
-   return true;
-   } else {
-   return false;
-   }
-}
-
-static bool enable(struct dwbc *dwbc)
-{
-   struct dcn10_dwbc *dwbc10 = TO_DCN10_DWBC(dwbc);
-
-   /* disable first. */
-   dwbc->funcs->disable(dwbc);
-
-   /* disable power gating */

Re: [PATCH 1/3] drm/syncobj: extract two helpers from drm_syncobj_create

2017-09-28 Thread Marek Olšák

On Thu, Sep 14, 2017 at 10:01 AM, Emil Velikov  wrote:
> On 14 September 2017 at 08:56, Emil Velikov  wrote:
>> Hi Marek,
>>
>> On 12 September 2017 at 21:42, Marek Olšák  wrote:
>>
>>>  include/drm/drm_syncobj.h |  4 
>> Please sync the header as described in
>> https://cgit.freedesktop.org/mesa/drm/tree/include/drm/README#n72
>>
>> Tl;DR: cd .../linux; make headers_install; cp ... .../drm/include/drm;
>> cd .../drm; git commit -sm " $branch $sha1..."
>>
> Seems like I've replied to the wrong patch - silly me.
> This was meant for the libdrm ones - suggestion still applies though.

I actually did that, but I'm on amd-staging-drm-next.

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

Re: [PATCH hwc v2 1/6] drm_hwcomposer: Remove threading

2017-09-28 Thread Rob Herring

On Thu, Sep 28, 2017 at 11:43 AM, Chih-Wei Huang
 wrote:
> 2017-09-27 19:58 GMT+08:00 Robert Foss :
>> From: Sean Paul 
>>
>> Since HWC2 doesn't require the use of threads to implement correct
>> synchronization, remove some of these threads.
>
> May I ask to avoid HWC2 only implementation?
> The main reason is not all GPUs support
> drm_hwcompser (as discussed in another thread).

Which thread? Is that because they don't support explicit fences? Or
something else?

> To continue supporting these GPUs we need to
> keep using HWC1 version of SurfaceFlinger.

I think that is a lot of complexity to keep which will impact future
changes as well. For example, is keeping it going to make removing
sw_sync dependency (A non-stable debugfs interface) more difficult?
drm_hwcomposer is already complex enough IMO with the GL compositing
that removing some complexity would be a good thing.

> So it's better to keep the code compatible with
> HWC1. At least make it be a compile-time option.
>
> Personally I have a patch to make
> HWC1 vs HWC2 a compile-time choice
> of drm_hwcomposer.

Perhaps just leave the current state as a separate branch.

> I can submit it if it's acceptable.
>
>
> --
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

2017-09-28 Thread Marek Olšák

Can I get Rb for this series?

Thanks,
Marek

On Tue, Sep 12, 2017 at 10:42 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> for being able to convert an amdgpu fence into one of the handles.
> Mesa will use this.
>
> Signed-off-by: Marek Olšák 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 61 
> +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  1 +
>  include/uapi/drm/amdgpu_drm.h   | 16 +
>  5 files changed, 82 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index b5c8b90..c15fa93 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1308,6 +1308,8 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void 
> *data,
>  int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
> struct drm_file *filp);
>  int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct drm_file 
> *filp);
> +int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data,
> +   struct drm_file *filp);
>  int amdgpu_cs_wait_ioctl(struct drm_device *dev, void *data, struct drm_file 
> *filp);
>  int amdgpu_cs_wait_fences_ioctl(struct drm_device *dev, void *data,
> struct drm_file *filp);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 7cb8a59..6dd719c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -25,6 +25,7 @@
>   *Jerome Glisse 
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1311,6 +1312,66 @@ static struct dma_fence *amdgpu_cs_get_fence(struct 
> amdgpu_device *adev,
> return fence;
>  }
>
> +int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data,
> +   struct drm_file *filp)
> +{
> +   struct amdgpu_device *adev = dev->dev_private;
> +   struct amdgpu_fpriv *fpriv = filp->driver_priv;
> +   union drm_amdgpu_fence_to_handle *info = data;
> +   struct dma_fence *fence;
> +   struct drm_syncobj *syncobj;
> +   struct sync_file *sync_file;
> +   int fd, r;
> +
> +   if (amdgpu_kms_vram_lost(adev, fpriv))
> +   return -ENODEV;
> +
> +   fence = amdgpu_cs_get_fence(adev, filp, &info->in.fence);
> +   if (IS_ERR(fence))
> +   return PTR_ERR(fence);
> +
> +   switch (info->in.what) {
> +   case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ:
> +   r = drm_syncobj_create(&syncobj, 0, fence);
> +   dma_fence_put(fence);
> +   if (r)
> +   return r;
> +   r = drm_syncobj_get_handle(filp, syncobj, &info->out.handle);
> +   drm_syncobj_put(syncobj);
> +   return r;
> +
> +   case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD:
> +   r = drm_syncobj_create(&syncobj, 0, fence);
> +   dma_fence_put(fence);
> +   if (r)
> +   return r;
> +   r = drm_syncobj_get_fd(syncobj, (int*)&info->out.handle);
> +   drm_syncobj_put(syncobj);
> +   return r;
> +
> +   case AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD:
> +   fd = get_unused_fd_flags(O_CLOEXEC);
> +   if (fd < 0) {
> +   dma_fence_put(fence);
> +   return fd;
> +   }
> +
> +   sync_file = sync_file_create(fence);
> +   dma_fence_put(fence);
> +   if (!sync_file) {
> +   put_unused_fd(fd);
> +   return -ENOMEM;
> +   }
> +
> +   fd_install(fd, sync_file->file);
> +   info->out.handle = fd;
> +   return 0;
> +
> +   default:
> +   return -EINVAL;
> +   }
> +}
> +
>  /**
>   * amdgpu_cs_wait_all_fence - wait on all fences to signal
>   *
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index d01aca6..1e38411 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -70,9 +70,10 @@
>   * - 3.18.0 - Export gpu always on cu bitmap
>   * - 3.19.0 - Add support for UVD MJPEG decode
>   * - 3.20.0 - Add support for local BOs
> + * - 3.21.0 - Add DRM_AMDGPU_FENCE_TO_HANDLE ioctl
>   */
>  #define KMS_DRIVER_MAJOR   3
> -#define KMS_DRIVER_MINOR   20
> +#define KMS_DRIVER_MINOR   21
>  #define KMS_DRIVER_PATCHLEVEL  0
>
>  int amdgpu_vram_limit = 0;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index d31777b..b09d315 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu

RE: [PATCH] drm/amd/display: Remove DWB

2017-09-28 Thread Deucher, Alexander

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Harry Wentland
> Sent: Thursday, September 28, 2017 3:42 PM
> To: amd-...@lists.freedesktop.org
> Cc: Deucher, Alexander; Cheng, Tony; airl...@gmail.com; dri-
> de...@lists.freedesktop.org; Wentland, Harry
> Subject: [PATCH] drm/amd/display: Remove DWB
> 
> It's not in a good shape and currently completely unused.
> 
> Signed-off-by: Harry Wentland 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c   |   9 -
>  drivers/gpu/drm/amd/display/dc/dcn10/Makefile  |   2 +-
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c   | 365 --
> ---
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.h   | 277 
>  .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  |  57 
>  drivers/gpu/drm/amd/display/dc/inc/core_types.h|   3 -
>  drivers/gpu/drm/amd/display/dc/inc/hw/dwb.h| 193 ---
>  7 files changed, 1 insertion(+), 905 deletions(-)
>  delete mode 100644 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c
>  delete mode 100644 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.h
>  delete mode 100644 drivers/gpu/drm/amd/display/dc/inc/hw/dwb.h
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index d86d9796e4cc..7fd42fc8bdfa 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -1525,15 +1525,6 @@ struct dc_link *dc_get_link_at_index(struct dc
> *dc, uint32_t link_index)
>   return dc->links[link_index];
>  }
> 
> -struct dwbc *dc_get_dwb_at_pipe(struct dc *dc, uint32_t pipe)
> -{
> - if ((pipe >= dwb_pipe0) && (pipe < dwb_pipe_max_num)) {
> - return dc->res_pool->dwbc[(int)pipe];
> - } else {
> - return NULL;
> - }
> -}
> -
>  const struct graphics_object_id dc_get_link_id_at_index(
>   struct dc *dc, uint32_t link_index)
>  {
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
> b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
> index e92ac2997a1a..2d6d3a371858 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/Makefile
> @@ -3,7 +3,7 @@
> 
>  DCN10 = dcn10_resource.o dcn10_ipp.o dcn10_hw_sequencer.o \
>   dcn10_dpp.o dcn10_opp.o dcn10_timing_generator.o \
> - dcn10_mem_input.o dcn10_mpc.o dcn10_dwb.o \
> + dcn10_mem_input.o dcn10_mpc.o \
>   dcn10_dpp_dscl.o dcn10_dpp_cm.o
> dcn10_dpp_cm_helper.o
> 
>  AMD_DAL_DCN10 = $(addprefix $(AMDDALPATH)/dc/dcn10/,$(DCN10))
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c
> deleted file mode 100644
> index 4ec5554f0f5b..
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dwb.c
> +++ /dev/null
> @@ -1,365 +0,0 @@
> -/*
> - * Copyright 2012-17 Advanced Micro Devices, Inc.
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the
> "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice shall be included in
> - * all copies or substantial portions of the Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> EVENT SHALL
> - * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> DAMAGES OR
> - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> OTHERWISE,
> - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
> THE USE OR
> - * OTHER DEALINGS IN THE SOFTWARE.
> - *
> - * Authors: AMD
> - *
> - */
> -
> -#if defined(CONFIG_DRM_AMD_DC_DCN1_0)
> -
> -#include "reg_helper.h"
> -#include "resource.h"
> -#include "dwb.h"
> -#include "dcn10_dwb.h"
> -
> -
> -#define REG(reg)\
> - dwbc10->dwbc_regs->reg
> -
> -#define CTX \
> - dwbc10->base.ctx
> -
> -#undef FN
> -#define FN(reg_name, field_name) \
> - dwbc10->dwbc_shift->field_name, dwbc10->dwbc_mask-
> >field_name
> -
> -#define TO_DCN10_DWBC(dwbc_base) \
> - container_of(dwbc_base, struct dcn10_dwbc, base)
> -
> -static bool get_caps(struct dwbc *dwbc, struct dwb_caps *caps)
> -{
> - if (caps) {
> - caps->adapter_id = 0;   /* we only support 1 adapter
> currently */
> - caps->hw_version = DCN_VERSION_1_0;
> - caps->num_pipes = 2;
> - memset(&caps->reserved, 0, sizeof(caps->reserved));
> -

RE: [alsa-devel] [PATCH 0/6 v4] Add ASoC support for AMD Stoney APUs

2017-09-28 Thread Deucher, Alexander

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Thursday, September 28, 2017 3:00 PM
> To: Alex Deucher
> Cc: alsa-de...@alsa-project.org; Takashi Iwai; Liam Girdwood; Maling list -
> DRI developers; rajeev kumar; amd-gfx list; Mukunda, Vijendar; Deucher,
> Alexander; Dave Airlie
> Subject: Re: [alsa-devel] [PATCH 0/6 v4] Add ASoC support for AMD Stoney
> APUs
> 
> On Thu, Sep 14, 2017 at 10:42:28AM -0700, Mark Brown wrote:
> > On Wed, Sep 13, 2017 at 02:49:08PM -0400, Alex Deucher wrote:
> 
> > > I'm not quite sure what you mean by the cross merge.  There are no
> > > dependencies outside this patch set.  The only patches that touch drm
> > > are patches 1 and 2.  Patch 1 touches both audio and drm, patch 2 just
> > > touches drm.  Do you want me to send you a pull request for patches 1
> 
> > I can't see any reason for patch 1 to be a single patch, just have a DRM
> > patch that adds the property and then a separate audio patch that uses
> > it.  Send me a pull request for that and patch 2 then I can handle the
> > audio stuff.
> 
> Any updates with the pull requests?

Sorry travelling last week and swamped this week.  I'm going to try and get it 
done tomorrow, otherwise, probably the week after.

Alex

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

Re: [PATCH][drm-next] drm/amd/powerplay: fix spelling mistake: "dividable" -> "divisible"

2017-09-28 Thread Alex Deucher

On Thu, Sep 28, 2017 at 6:35 AM, Colin King  wrote:
> From: Colin Ian King 
>
> Trivial fix to spelling mistakes in pr_err error message and ASSERT
> messages.
>
> Signed-off-by: Colin Ian King 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c | 2 +-
>  drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c | 2 +-
>  drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c| 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c
> index fcf88b8fc738..9d1086894d2b 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c
> @@ -2332,7 +2332,7 @@ static int ci_load_smc_ucode(struct pp_hwmgr *hwmgr)
> PHM_WRITE_FIELD(hwmgr->device, SMC_IND_ACCESS_CNTL, 
> AUTO_INCREMENT_IND_0, 0);
>
> if (0 != byte_count) {
> -   pr_err("SMC size must be dividable by 4\n");
> +   pr_err("SMC size must be divisible by 4\n");
> return -EINVAL;
> }
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
> index 78aa1122eacc..a778e174ba01 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
> @@ -108,7 +108,7 @@ static int iceland_upload_smc_firmware_data(struct 
> pp_hwmgr *hwmgr,
>
> PHM_WRITE_FIELD(hwmgr->device, SMC_IND_ACCESS_CNTL, 
> AUTO_INCREMENT_IND_0, 0);
>
> -   PP_ASSERT_WITH_CODE((0 == byte_count), "SMC size must be dividable by 
> 4.", return -EINVAL);
> +   PP_ASSERT_WITH_CODE((0 == byte_count), "SMC size must be divisible by 
> 4.", return -EINVAL);
>
> return 0;
>  }
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
> index 2ae05bbdb974..c997117f2461 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
> @@ -513,7 +513,7 @@ static int smu7_upload_smc_firmware_data(struct pp_hwmgr 
> *hwmgr, uint32_t length
>
> PHM_WRITE_FIELD(hwmgr->device, SMC_IND_ACCESS_CNTL, 
> AUTO_INCREMENT_IND_11, 0);
>
> -   PP_ASSERT_WITH_CODE((0 == byte_count), "SMC size must be dividable by 
> 4.", return -EINVAL);
> +   PP_ASSERT_WITH_CODE((0 == byte_count), "SMC size must be divisible by 
> 4.", return -EINVAL);
>
> return 0;
>  }
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [alsa-devel] [PATCH 0/6 v4] Add ASoC support for AMD Stoney APUs

2017-09-28 Thread Mark Brown

On Thu, Sep 14, 2017 at 10:42:28AM -0700, Mark Brown wrote:
> On Wed, Sep 13, 2017 at 02:49:08PM -0400, Alex Deucher wrote:

> > I'm not quite sure what you mean by the cross merge.  There are no
> > dependencies outside this patch set.  The only patches that touch drm
> > are patches 1 and 2.  Patch 1 touches both audio and drm, patch 2 just
> > touches drm.  Do you want me to send you a pull request for patches 1

> I can't see any reason for patch 1 to be a single patch, just have a DRM
> patch that adds the property and then a separate audio patch that uses
> it.  Send me a pull request for that and patch 2 then I can handle the
> audio stuff.

Any updates with the pull requests?


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

[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!

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

taij...@posteo.de changed:

   What|Removed |Added

 Attachment #130826|0   |1
is obsolete||
 Attachment #132567|0   |1
is obsolete||

--- Comment #33 from taij...@posteo.de ---
Created attachment 134553
  --> https://bugs.freedesktop.org/attachment.cgi?id=134553&action=edit
relevant dmesg output with kernel 4.13.3

New dmesg output with kernel 4.13.3 AND a new acpi_osi setting after I
decompiled my DSDT to see just how borked my firmware is for non-W10 OSs.

-- 
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 102468] RX470 powerplay issues on hybrid laptop system (dGPU does not power down)

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

taij...@posteo.de changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #5 from taij...@posteo.de ---
OK, so I finally summoned to courage to decompile my laptop's DSDT and look at
that to debug my ACPI problems - turns out that "Linux" just gets plain shafted
by the firmware. I rebootet with 'acpi_osi=!* acpi_osi="Windows 2015"' and the
problem disappeared. 

So, I'm sorry if I wasted anybody's time. I'll direct the rest of the powerplay
bugs to a different topic.

-- 
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: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl

2017-09-28 Thread Eric Anholt

Daniel Vetter  writes:

> On Wed, Sep 27, 2017 at 11:49:21AM -0700, Eric Anholt wrote:
>> Boris Brezillon  writes:
>> 
>> > This ioctl will allow us to purge inactive userspace buffers when the
>> > system is running out of contiguous memory.
>> >
>> > For now, the purge logic is rather dumb in that it does not try to
>> > release only the amount of BO needed to meet the last CMA alloc request
>> > but instead purges all objects placed in the purgeable pool as soon as
>> > we experience a CMA allocation failure.
>> >
>> > Note that the in-kernel BO cache is always purged before the purgeable
>> > cache because those objects are known to be unused while objects marked
>> > as purgeable by a userspace application/library might have to be
>> > restored when they are marked back as unpurgeable, which can be
>> > expensive.
>> >
>> > Signed-off-by: Boris Brezillon 
>> > ---
>> > Hello,
>> >
>> > Updates to libdrm, mesa and igt making use of this kernel feature can
>> > be found on my github repos [1][2][3].
>> >
>> > There's currently no debugfs hook to manually force a purge, but this
>> > is being discussed and will probably be added in v2.
>> >
>> > Regards,
>> 
>> > diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
>> > index afae87004963..c01b93d453db 100644
>> > --- a/include/uapi/drm/vc4_drm.h
>> > +++ b/include/uapi/drm/vc4_drm.h
>> > @@ -41,6 +41,7 @@ extern "C" {
>> >  #define DRM_VC4_SET_TILING0x08
>> >  #define DRM_VC4_GET_TILING0x09
>> >  #define DRM_VC4_LABEL_BO  0x0a
>> > +#define DRM_VC4_GEM_MADVISE   0x0b
>> >  
>> >  #define DRM_IOCTL_VC4_SUBMIT_CL   DRM_IOWR(DRM_COMMAND_BASE + 
>> > DRM_VC4_SUBMIT_CL, struct drm_vc4_submit_cl)
>> >  #define DRM_IOCTL_VC4_WAIT_SEQNO  DRM_IOWR(DRM_COMMAND_BASE + 
>> > DRM_VC4_WAIT_SEQNO, struct drm_vc4_wait_seqno)
>> > @@ -53,6 +54,7 @@ extern "C" {
>> >  #define DRM_IOCTL_VC4_SET_TILING  DRM_IOWR(DRM_COMMAND_BASE + 
>> > DRM_VC4_SET_TILING, struct drm_vc4_set_tiling)
>> >  #define DRM_IOCTL_VC4_GET_TILING  DRM_IOWR(DRM_COMMAND_BASE + 
>> > DRM_VC4_GET_TILING, struct drm_vc4_get_tiling)
>> >  #define DRM_IOCTL_VC4_LABEL_BODRM_IOWR(DRM_COMMAND_BASE + 
>> > DRM_VC4_LABEL_BO, struct drm_vc4_label_bo)
>> > +#define DRM_IOCTL_VC4_GEM_MADVISE DRM_IOWR(DRM_COMMAND_BASE + 
>> > DRM_VC4_GEM_MADVISE, struct drm_vc4_gem_madvise)
>> >  
>> >  struct drm_vc4_submit_rcl_surface {
>> >__u32 hindex; /* Handle index, or ~0 if not present. */
>> > @@ -333,6 +335,16 @@ struct drm_vc4_label_bo {
>> >__u64 name;
>> >  };
>> >  
>> > +#define VC4_MADV_WILLNEED 0
>> > +#define VC4_MADV_DONTNEED 1
>> > +#define __VC4_MADV_PURGED 2
>> > +
>> > +struct drm_vc4_gem_madvise {
>> > +  __u32 handle;
>> > +  __u32 madv;
>> > +  __u32 retained;
>> > +};
>> 
>> danvet had a note in
>> http://blog.ffwll.ch/2013/11/botching-up-ioctls.html:
>> 
>> Pad the entire struct to a multiple of 64bits - the structure size
>> will otherwise differ on 32bit versus 64bit. Which hurts when
>> passing arrays of structures to the kernel. Or with the ioctl
>> structure size checking that e.g. the drm core does.
>> 
>> I'm surprised that i915's ioctl didn't do this or have compat code to
>> handle it.
>
> This advise is defensive just in case you ever make an array of any of
> your uabi structs, and there's a 64 bit value in there somewhere. It only
> matters for that case really. But since gpus have a few of those ioctls
> (especially command submission) I figured better safe than sorry.

It talked about there being some core ioctl size checking -- does that
not exist any more?  I've had other people comment on size alignment of
my (non-array) ioctl structs based on your post, so some clarification
would be nice.


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

Re: [PATCH v6 1/3] drm/vc4: Move the DSI clock divider workaround closer to the clock call.

2017-09-28 Thread Eric Anholt

Thierry Reding  writes:

> [ Unknown signature status ]
> On Wed, Sep 27, 2017 at 12:36:52PM -0700, Eric Anholt wrote:
>> We want the adjusted_mode->clock to be the actual clock we're
>> expecting to program, so that consumers see the right values for clock
>> and vrefresh.
>> 
>> Signed-off-by: Eric Anholt 
>> ---
>>  drivers/gpu/drm/vc4/vc4_dsi.c | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> Do you want me to apply this to drm-misc-next along with the touchscreen
> panel driver?

drm-misc-next procedure trends toward the submitter applies the patch
once they get review, if they have the commit rights.  However, I'm
happy either way as long as I can get the code in.


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/2] drm/i915/psr: Set frames before SU entry for psr2

2017-09-28 Thread Rodrigo Vivi

On Fri, Sep 22, 2017 at 03:58:36PM +, vathsala nagaraju wrote:
> Set frames before SU entry value for max resync frame count of
> dpcd register 2009, bit field 0:3.
> 
> v2 :
>  - add macro  EDP_PSR2_FRAME_BEFORE_SU (Rodrigo)
>  - remove EDP_FRAMES_BEFORE_SU_ENTRY (Rodrigo)
>  - add check ==1 for dpcd_read call (ville)
> 
> Cc: Rodrigo Vivi 
> CC: Puthikorn Voravootivat 
> Signed-off-by: Vathsala Nagaraju 

Merged both patches to dinq. Thanks for the patches.

I'm anxiously waiting the PSR2 related workaroud(s)! ;)

Thanks,
Rodrigo.

> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  2 +-
>  drivers/gpu/drm/i915/intel_psr.c | 12 ++--
>  2 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 82f36dd..89c5249 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -170,6 +170,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>   (mask) << 16 | (value); })
>  #define _MASKED_BIT_ENABLE(a)({ typeof(a) _a = (a); 
> _MASKED_FIELD(_a, _a); })
>  #define _MASKED_BIT_DISABLE(a)   (_MASKED_FIELD((a), 0))
> +#define EDP_PSR2_FRAME_BEFORE_SU(a) ((a) << EDP_PSR2_FRAME_BEFORE_SU_SHIFT)
>  
>  /* Engine ID */
>  
> @@ -4047,7 +4048,6 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
> -#define   EDP_FRAMES_BEFORE_SU_ENTRY   (1<<4)
>  
>  #define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
>  #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 0a17d1f..e505fa6 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -327,6 +327,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>*/
>   uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
>   uint32_t val;
> + uint8_t sink_latency;
>  
>   val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
> @@ -334,8 +335,15 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
>   val |= EDP_PSR2_ENABLE |
> - EDP_SU_TRACK_ENABLE |
> - EDP_FRAMES_BEFORE_SU_ENTRY;
> + EDP_SU_TRACK_ENABLE;
> +
> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_SYNCHRONIZATION_LATENCY,
> + &sink_latency) == 1) {
> + sink_latency = sink_latency & DP_MAX_RESYNC_FRAME_CNT_MASK;
> + } else {
> + sink_latency = 0;
> + }
> + val |= EDP_PSR2_FRAME_BEFORE_SU(sink_latency + 1);
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v2] drm/amd/display: DC I2C review

2017-09-28 Thread Deucher, Alexander

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Harry Wentland
> Sent: Thursday, September 28, 2017 10:14 AM
> To: amd-...@lists.freedesktop.org
> Cc: daniel.vet...@ffwll.ch; dri-devel@lists.freedesktop.org;
> seanp...@chromium.org; Deucher, Alexander; daniel.vet...@intel.com;
> Wentland, Harry
> Subject: [PATCH v2] drm/amd/display: DC I2C review
> 
> While reviewing I2C in DC identified a few places. Added a couple to the
> TODO list.
> 
> 1) Connector info read
> 
> See get_ext_display_connection_info
> 
> On some boards the connector information has to be read through a
> special I2C channel. This line is only used for this purpose and only on
> driver init.
> 
> 2) SCDC stuff
> 
> This should all be reworked to go through DRM's SCDC code. When this is
> done some unnecessary I2C code can be retired as well.
> 
> 3) Max TMDS clock read
> 
> See dal_ddc_service_i2c_query_dp_dual_mode_adaptor
> 
> This should happen in DRM as well. I haven't checked if there's
> currently functionality in DRM. If not we can propose something.
> 
> 4) HDMI retimer programming
> 
> Some boards have an HDMI retimer that we need to program to pass PHY
> compliance.
> 
> 1 & 3 might be a good exercise if someone is looking for things to do.
> 
> v2: Merge dp_dual_mode_adaptor TODO
> 
> Signed-off-by: Harry Wentland 
> Acked-by: Daniel Vetter 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/display/TODO | 25 ++---
>  1 file changed, 10 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/TODO
> b/drivers/gpu/drm/amd/display/TODO
> index eea645b102a1..46464678f2b3 100644
> --- a/drivers/gpu/drm/amd/display/TODO
> +++ b/drivers/gpu/drm/amd/display/TODO
> @@ -62,20 +62,10 @@ TODOs
>  ~ Daniel Vetter
> 
> 
> -11. Remove existing i2c implementation from DC
> -
> -"Similar story for i2c, it uses the kernel's i2c code now, but there's
> -still a full i2c implementation hidden beneath that in
> -display/dc/i2caux. Kinda not cool, but imo ok if you fix that
> -post-merging (perhaps by not including any of this in the linux DC
> -code in the upstream kernel, but as an aux module in your internal
> -codebase since there you probably need that, same applies to the edid
> -parsing DC still does. For both cases I assume that the minimal shim
> -you need on linux (bit banging and edid parsing isn't rocket since) is
> -a lot less than the glue code to interface with the dc-provided
> -abstraction."
> -~ Daniel Vetter
> -
> +11. Remove dc/i2caux. This folder can be somewhat misleading. It's basically
> an
> +overy complicated HW programming function for sendind and receiving
> i2c/aux
> +commands. We can greatly simplify that and move it into dc/dceXYZ like
> other
> +HW blocks.
> 
>  12. drm_modeset_lock in MST should no longer be needed in recent kernels
>  * Adopt appropriate locking scheme
> @@ -89,7 +79,8 @@ moving all your driver state printing into the various
> atomic_print_state
>  callbacks. There's also plans to expose this stuff in a standard way across 
> all
>  drivers, to make debugging userspace compositors easier across different
> hw.
> 
> -15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c.
> +15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c.
> See
> +dal_ddc_service_i2c_query_dp_dual_mode_adaptor.
> 
>  16. Move to core SCDC helpers (I think those are new since initial DC 
> review).
> 
> @@ -110,3 +101,7 @@ guilty.
>  stuff just isn't up to the challenges either. We need to figure out something
>  that integrates better with DRM and linux debug printing, while not being
>  useless with filtering output. dynamic debug printing might be an option.
> +
> +20. Use kernel i2c device to program HDMI retimer. Some boards have an
> HDMI
> +retimer that we need to program to pass PHY compliance. Currently that's
> +bypassing the i2c device and goes directly to HW. This should be changed.
> --
> 2.11.0
> 
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH hwc v2 1/6] drm_hwcomposer: Remove threading

2017-09-28 Thread Chih-Wei Huang

2017-09-27 19:58 GMT+08:00 Robert Foss :
> From: Sean Paul 
>
> Since HWC2 doesn't require the use of threads to implement correct
> synchronization, remove some of these threads.

May I ask to avoid HWC2 only implementation?
The main reason is not all GPUs support
drm_hwcompser (as discussed in another thread).
To continue supporting these GPUs we need to
keep using HWC1 version of SurfaceFlinger.
So it's better to keep the code compatible with
HWC1. At least make it be a compile-time option.

Personally I have a patch to make
HWC1 vs HWC2 a compile-time choice
of drm_hwcomposer.
I can submit it if it's acceptable.


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH hwc v3 5/6] drm_hwcomposer: Add out-fence support

Add support for out-fences through the OUT_FENCE_PTR property.
Out-fences signal when their associated buffer may be read by a device.

Signed-off-by: Robert Foss 
Reviewed-by: Sean Paul 
---

Changes since v2:
  Sean Paul:
   - Removed dup() and subsequent close() call
   - Added r-b

  Emil Velikov:
   - Moved code around to allow for "Remove threading" patch to be last of 
series

Changes since v1:
  Sergi Granell:
- Set atomic property to be out_fences[crtc->pipe()] not out_fences[0]

 drmdisplaycomposition.h  |  9 +
 drmdisplaycompositor.cpp | 15 +++
 drmhwctwo.cpp|  9 ++---
 3 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/drmdisplaycomposition.h b/drmdisplaycomposition.h
index 13da19d..470bf7e 100644
--- a/drmdisplaycomposition.h
+++ b/drmdisplaycomposition.h
@@ -179,6 +179,14 @@ class DrmDisplayComposition {
 return planner_;
   }
 
+  int take_out_fence() {
+return out_fence_.Release();
+  }
+
+  void set_out_fence(int out_fence) {
+out_fence_.Set(out_fence);
+  }
+
   void Dump(std::ostringstream *out) const;
 
  private:
@@ -205,6 +213,7 @@ class DrmDisplayComposition {
   int timeline_current_ = 0;
   int timeline_squash_done_ = 0;
   int timeline_pre_comp_done_ = 0;
+  UniqueFd out_fence_ = -1;
 
   bool geometry_changed_;
   std::vector layers_;
diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index 75c1a7c..8936d08 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -602,6 +602,7 @@ int DrmDisplayCompositor::CommitFrame(DrmDisplayComposition 
*display_comp,
   display_comp->composition_planes();
   std::vector &pre_comp_regions =
   display_comp->pre_comp_regions();
+  uint64_t out_fences[drm_->crtcs().size()];
 
   DrmConnector *connector = drm_->GetConnectorForDisplay(display_);
   if (!connector) {
@@ -620,6 +621,16 @@ int 
DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
 return -ENOMEM;
   }
 
+  if (crtc->out_fence_ptr_property().id() != 0) {
+ret = drmModeAtomicAddProperty(pset, crtc->id(), 
crtc->out_fence_ptr_property().id(),
+   (uint64_t) &out_fences[crtc->pipe()]);
+if (ret < 0) {
+  ALOGE("Failed to add OUT_FENCE_PTR property to pset: %d", ret);
+  drmModeAtomicFree(pset);
+  return ret;
+}
+  }
+
   if (mode_.needs_modeset) {
 ret = drmModeAtomicAddProperty(pset, crtc->id(), 
crtc->mode_property().id(),
mode_.blob_id) < 0 ||
@@ -818,6 +829,10 @@ out:
 mode_.needs_modeset = false;
   }
 
+  if (crtc->out_fence_ptr_property().id()) {
+display_comp->set_out_fence((int) out_fences[crtc->pipe()]);
+  }
+
   return ret;
 }
 
diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
index 8c853f4..00bedd0 100644
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -557,19 +557,14 @@ HWC2::Error DrmHwcTwo::HwcDisplay::PresentDisplay(int32_t 
*retire_fence) {
 i = overlay_planes.erase(i);
   }
 
+  AddFenceToRetireFence(composition->take_out_fence());
+
   ret = compositor_.QueueComposition(std::move(composition));
   if (ret) {
 ALOGE("Failed to apply the frame composition ret=%d", ret);
 return HWC2::Error::BadParameter;
   }
 
-  // Now that the release fences have been generated by the compositor, make
-  // sure they're managed properly
-  for (std::pair &l : z_map) {
-l.second->manage_release_fence();
-AddFenceToRetireFence(l.second->release_fence());
-  }
-
   // The retire fence returned here is for the last frame, so return it and
   // promote the next retire fence
   *retire_fence = retire_fence_.Release();
-- 
2.11.0

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

[PATCH hwc v3 4/6] drm_hwcomposer: Add crtc() fetcher to DrmResources

This is a fetcher for getting the vector of DrmCrtc objects
in DrmResources.

Signed-off-by: Robert Foss 
Reviewed-by: Sean Paul 
---

Changes since v2:
  Sean Paul:
   - Replaced GetCrtcCount() with crtr()
   - Added r-b

 drmresources.cpp | 4 
 drmresources.h   | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drmresources.cpp b/drmresources.cpp
index 6b8ed03..ea23cce 100644
--- a/drmresources.cpp
+++ b/drmresources.cpp
@@ -245,6 +245,10 @@ DrmPlane *DrmResources::GetPlane(uint32_t id) const {
   return NULL;
 }
 
+const std::vector> & DrmResources::crtcs() const {
+  return crtcs_;
+}
+
 uint32_t DrmResources::next_mode_id() {
   return ++mode_id_;
 }
diff --git a/drmresources.h b/drmresources.h
index 011f87e..5cca11b 100644
--- a/drmresources.h
+++ b/drmresources.h
@@ -68,6 +68,7 @@ class DrmResources {
   int GetConnectorProperty(const DrmConnector &connector, const char 
*prop_name,
DrmProperty *property);
 
+  const std::vector> &crtcs() const;
   uint32_t next_mode_id();
   int SetDisplayActiveMode(int display, const DrmMode &mode);
   int SetDpmsMode(int display, uint64_t mode);
-- 
2.11.0

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

[PATCH hwc v3 6/6] drm_hwcomposer: Remove threading

From: Sean Paul 

Since HWC2 doesn't require the use of threads to implement correct
synchronization, remove some of these threads.

Signed-off-by: Sean Paul 
Signed-off-by: Robert Foss 
---

Changes since v2:

  Emil Velikov:
   - Patch to be last in the series

 Android.mk|   3 -
 drmcomposition.cpp| 166 
 drmcomposition.h  |  79 ---
 drmcompositor.cpp | 106 --
 drmcompositor.h   |  56 --
 drmcompositorworker.h |  41 --
 drmdisplaycomposition.cpp |   1 +
 drmdisplaycomposition.h   |  10 +++
 drmdisplaycompositor.cpp  | 189 --
 drmdisplaycompositor.h|  36 +
 drmeventlistener.cpp  |   3 +
 drmhwctwo.cpp |   6 +-
 drmresources.cpp  |  54 +
 drmresources.h|   5 --
 glworker.cpp  |  52 +++--
 glworker.h|  10 +++
 16 files changed, 93 insertions(+), 724 deletions(-)
 delete mode 100644 drmcomposition.cpp
 delete mode 100644 drmcomposition.h
 delete mode 100644 drmcompositor.cpp
 delete mode 100644 drmcompositor.h
 delete mode 100644 drmcompositorworker.h

diff --git a/Android.mk b/Android.mk
index aa95b44..5d16c2f 100644
--- a/Android.mk
+++ b/Android.mk
@@ -57,9 +57,6 @@ LOCAL_C_INCLUDES := \
 LOCAL_SRC_FILES := \
autolock.cpp \
drmresources.cpp \
-   drmcomposition.cpp \
-   drmcompositor.cpp \
-   drmcompositorworker.cpp \
drmconnector.cpp \
drmcrtc.cpp \
drmdisplaycomposition.cpp \
diff --git a/drmcomposition.cpp b/drmcomposition.cpp
deleted file mode 100644
index 1aaf920..000
--- a/drmcomposition.cpp
+++ /dev/null
@@ -1,166 +0,0 @@
-/*
- * Copyright (C) 2015 The Android Open Source Project
- *
- * Licensed under the Apache License, Version 2.0 (the "License");
- * you may not use this file except in compliance with the License.
- * You may obtain a copy of the License at
- *
- *  http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-
-#define LOG_TAG "hwc-drm-composition"
-
-#include "drmcomposition.h"
-#include "drmcrtc.h"
-#include "drmplane.h"
-#include "drmresources.h"
-#include "platform.h"
-
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-namespace android {
-
-DrmComposition::DrmComposition(DrmResources *drm, Importer *importer,
-   Planner *planner)
-: drm_(drm), importer_(importer), planner_(planner) {
-  char use_overlay_planes_prop[PROPERTY_VALUE_MAX];
-  property_get("hwc.drm.use_overlay_planes", use_overlay_planes_prop, "1");
-  bool use_overlay_planes = atoi(use_overlay_planes_prop);
-
-  for (auto &plane : drm->planes()) {
-if (plane->type() == DRM_PLANE_TYPE_PRIMARY)
-  primary_planes_.push_back(plane.get());
-else if (use_overlay_planes && plane->type() == DRM_PLANE_TYPE_OVERLAY)
-  overlay_planes_.push_back(plane.get());
-  }
-}
-
-int DrmComposition::Init(uint64_t frame_no) {
-  for (auto &conn : drm_->connectors()) {
-int display = conn->display();
-composition_map_[display].reset(new DrmDisplayComposition());
-if (!composition_map_[display]) {
-  ALOGE("Failed to allocate new display composition\n");
-  return -ENOMEM;
-}
-
-// If the display hasn't been modeset yet, this will be NULL
-DrmCrtc *crtc = drm_->GetCrtcForDisplay(display);
-
-int ret = composition_map_[display]->Init(drm_, crtc, importer_, planner_,
-  frame_no);
-if (ret) {
-  ALOGE("Failed to init display composition for %d", display);
-  return ret;
-}
-  }
-  return 0;
-}
-
-int DrmComposition::SetLayers(size_t num_displays,
-  DrmCompositionDisplayLayersMap *maps) {
-  int ret = 0;
-  for (size_t display_index = 0; display_index < num_displays;
-   display_index++) {
-DrmCompositionDisplayLayersMap &map = maps[display_index];
-int display = map.display;
-
-if (!drm_->GetConnectorForDisplay(display)) {
-  ALOGE("Invalid display given to SetLayers %d", display);
-  continue;
-}
-
-ret = composition_map_[display]->SetLayers(
-map.layers.data(), map.layers.size(), map.geometry_changed);
-if (ret)
-  return ret;
-  }
-
-  return 0;
-}
-
-int DrmComposition::SetDpmsMode(int display, uint32_t dpms_mode) {
-  return composition_map_[display]->SetDpmsMode(dpms_mode);
-}
-
-int DrmComposition::SetDisplayMode(int display, const DrmMode &display_mode) {
-  return composition_map_[display]->SetDisplayMode(display_mode);
-}
-
-std::unique_p

[PATCH hwc v3 1/6] drm_hwcomposer: Add support for IN_FENCE_FD property to DrmPlane

Add support for the IN_FENCE_FD property to DrmPlane.

Signed-off-by: Robert Foss 
Reviewed-by: Sean Paul 
---

Changes since v2:
  Sean Paul:
   - Added r-b

 drmplane.cpp | 8 
 drmplane.h   | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/drmplane.cpp b/drmplane.cpp
index c4ea722..1f739ae 100644
--- a/drmplane.cpp
+++ b/drmplane.cpp
@@ -126,6 +126,10 @@ int DrmPlane::Init() {
   if (ret)
 ALOGI("Could not get alpha property");
 
+  ret = drm_->GetPlaneProperty(*this, "IN_FENCE_FD", &in_fence_fd_property_);
+  if (ret)
+ALOGI("Could not get IN_FENCE_FD property");
+
   return 0;
 }
 
@@ -188,4 +192,8 @@ const DrmProperty &DrmPlane::rotation_property() const {
 const DrmProperty &DrmPlane::alpha_property() const {
   return alpha_property_;
 }
+
+const DrmProperty &DrmPlane::in_fence_fd_property() const {
+  return in_fence_fd_property_;
+}
 }
diff --git a/drmplane.h b/drmplane.h
index 2e06986..5b73b08 100644
--- a/drmplane.h
+++ b/drmplane.h
@@ -54,6 +54,7 @@ class DrmPlane {
   const DrmProperty &src_h_property() const;
   const DrmProperty &rotation_property() const;
   const DrmProperty &alpha_property() const;
+  const DrmProperty &in_fence_fd_property() const;
 
  private:
   DrmResources *drm_;
@@ -75,6 +76,7 @@ class DrmPlane {
   DrmProperty src_h_property_;
   DrmProperty rotation_property_;
   DrmProperty alpha_property_;
+  DrmProperty in_fence_fd_property_;
 };
 }
 
-- 
2.11.0

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

[PATCH hwc v3 0/6] Implement fencing

This series removes the old thread-based synchronization utilities and
replaces them with fences.

It has been tested on various platforms, including etnaviv/freedreno/virgl.

Robert Foss (5):
  drm_hwcomposer: Add support for IN_FENCE_FD property to DrmPlane
  drm_hwcomposer: Submit in-fence to DRM
  drm_hwcomposer: Add FENCE_OUT_PTR property to DrmCrtc
  drm_hwcomposer: Add crtc() fetcher to DrmResources
  drm_hwcomposer: Add out-fence support

Sean Paul (1):
  drm_hwcomposer: Remove threading

 Android.mk|   3 -
 drmcomposition.cpp| 166 
 drmcomposition.h  |  79 ---
 drmcompositor.cpp | 106 
 drmcompositor.h   |  56 ---
 drmcompositorworker.h |  41 
 drmcrtc.cpp   |  10 ++
 drmcrtc.h |   2 +
 drmdisplaycomposition.cpp |   1 +
 drmdisplaycomposition.h   |  19 
 drmdisplaycompositor.cpp  | 239 +-
 drmdisplaycompositor.h|  36 +--
 drmeventlistener.cpp  |   3 +
 drmhwctwo.cpp |  15 +--
 drmplane.cpp  |   8 ++
 drmplane.h|   2 +
 drmresources.cpp  |  58 +--
 drmresources.h|   6 +-
 glworker.cpp  |  52 +-
 glworker.h|  10 ++
 20 files changed, 162 insertions(+), 750 deletions(-)
 delete mode 100644 drmcomposition.cpp
 delete mode 100644 drmcomposition.h
 delete mode 100644 drmcompositor.cpp
 delete mode 100644 drmcompositor.h
 delete mode 100644 drmcompositorworker.h

-- 
2.11.0

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

[PATCH hwc v3 2/6] drm_hwcomposer: Submit in-fence to DRM

Add support for in-fences through the IN_FENCE_FD property. In-fences signal
when their associated buffer may be read by DRM/KMS.

Signed-off-by: Robert Foss 
Reviewed-by: Sean Paul 
---
 drmdisplaycompositor.cpp | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index a1baed1..75c1a7c 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -639,6 +639,7 @@ int DrmDisplayCompositor::CommitFrame(DrmDisplayComposition 
*display_comp,
 std::vector &source_layers = comp_plane.source_layers();
 
 int fb_id = -1;
+int fence_fd = -1;
 DrmHwcRect display_frame;
 DrmHwcRect source_crop;
 uint64_t rotation = 0;
@@ -657,30 +658,12 @@ int 
DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
 break;
   }
   DrmHwcLayer &layer = layers[source_layers.front()];
-  if (!test_only && layer.acquire_fence.get() >= 0) {
-int acquire_fence = layer.acquire_fence.get();
-int total_fence_timeout = 0;
-for (int i = 0; i < kAcquireWaitTries; ++i) {
-  int fence_timeout = kAcquireWaitTimeoutMs * (1 << i);
-  total_fence_timeout += fence_timeout;
-  ret = sync_wait(acquire_fence, fence_timeout);
-  if (ret)
-ALOGW("Acquire fence %d wait %d failed (%d). Total time %d",
-  acquire_fence, i, ret, total_fence_timeout);
-  else
-break;
-}
-if (ret) {
-  ALOGE("Failed to wait for acquire %d/%d", acquire_fence, ret);
-  break;
-}
-layer.acquire_fence.Close();
-  }
   if (!layer.buffer) {
 ALOGE("Expected a valid framebuffer for pset");
 break;
   }
   fb_id = layer.buffer->fb_id;
+  fence_fd = layer.acquire_fence.get();
   display_frame = layer.display_frame;
   source_crop = layer.source_crop;
   if (layer.blending == DrmHwcBlending::kPreMult)
@@ -697,7 +680,21 @@ int 
DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
 rotation |= 1 << DRM_ROTATE_180;
   else if (layer.transform & DrmHwcTransform::kRotate270)
 rotation |= 1 << DRM_ROTATE_270;
+
+  if (fence_fd < 0) {
+int prop_id = plane->in_fence_fd_property().id();
+if (prop_id == 0) {
+ALOGE("Failed to get IN_FENCE_FD property id");
+break;
+}
+ret = drmModeAtomicAddProperty(pset, plane->id(), prop_id, fence_fd);
+if (ret < 0) {
+  ALOGE("Failed to add IN_FENCE_FD property to pset: %d", ret);
+  break;
+}
+  }
 }
+
 // Disable the plane if there's no framebuffer
 if (fb_id < 0) {
   ret = drmModeAtomicAddProperty(pset, plane->id(),
-- 
2.11.0

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

[PATCH hwc v3 3/6] drm_hwcomposer: Add FENCE_OUT_PTR property to DrmCrtc

Add support for handling the FENCE_OUT_PTR property to DrmCrtc

Signed-off-by: Robert Foss 
Reviewed-by: Sean Paul 
---

Changes since v2:
  Sean Paul:
   - Added r-b

 drmcrtc.cpp | 10 ++
 drmcrtc.h   |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/drmcrtc.cpp b/drmcrtc.cpp
index 1fbdc12..c139869 100644
--- a/drmcrtc.cpp
+++ b/drmcrtc.cpp
@@ -51,6 +51,12 @@ int DrmCrtc::Init() {
 ALOGE("Failed to get MODE_ID property");
 return ret;
   }
+
+  ret = drm_->GetCrtcProperty(*this, "OUT_FENCE_PTR", 
&out_fence_ptr_property_);
+  if (ret) {
+ALOGE("Failed to get OUT_FENCE_PTR property");
+return ret;
+  }
   return 0;
 }
 
@@ -81,4 +87,8 @@ const DrmProperty &DrmCrtc::active_property() const {
 const DrmProperty &DrmCrtc::mode_property() const {
   return mode_property_;
 }
+
+const DrmProperty &DrmCrtc::out_fence_ptr_property() const {
+  return out_fence_ptr_property_;
+}
 }
diff --git a/drmcrtc.h b/drmcrtc.h
index ad95352..2e8c811 100644
--- a/drmcrtc.h
+++ b/drmcrtc.h
@@ -45,6 +45,7 @@ class DrmCrtc {
 
   const DrmProperty &active_property() const;
   const DrmProperty &mode_property() const;
+  const DrmProperty &out_fence_ptr_property() const;
 
  private:
   DrmResources *drm_;
@@ -63,6 +64,7 @@ class DrmCrtc {
 
   DrmProperty active_property_;
   DrmProperty mode_property_;
+  DrmProperty out_fence_ptr_property_;
 };
 }
 
-- 
2.11.0

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

Re: [PATCH hwc v2 1/6] drm_hwcomposer: Remove threading

On Wed, 2017-09-27 at 15:14 -0400, Sean Paul wrote:
> On Wed, Sep 27, 2017 at 7:58 AM, Robert Foss  om> wrote:
> > From: Sean Paul 
> > 
> > Since HWC2 doesn't require the use of threads to implement correct
> > synchronization, remove some of these threads.
> > 
> 
> My SoB seems to have been dropped (or perhaps I just forgot to add it
> in the original thread). At any rate, here you go:
> 
> Signed-off-by: Sean Paul 

Fixed in v3.


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

Re: [PATCH hwc v2 5/6] drm_hwcomposer: Add GetCrtcCount function

On Wed, 2017-09-27 at 15:12 -0400, Sean Paul wrote:
> On Wed, Sep 27, 2017 at 7:58 AM, Robert Foss  om> wrote:
> > This GetCrtrcCount helper functions enables convenient
> > fetching of the number of Crtcs from DrmResources.
> > 
> > Signed-off-by: Robert Foss 
> > ---
> >  drmresources.cpp | 4 
> >  drmresources.h   | 1 +
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/drmresources.cpp b/drmresources.cpp
> > index 762f5ef..0578cc6 100644
> > --- a/drmresources.cpp
> > +++ b/drmresources.cpp
> > @@ -241,6 +241,10 @@ DrmPlane *DrmResources::GetPlane(uint32_t id)
> > const {
> >    return NULL;
> >  }
> > 
> > +uint32_t DrmResources::GetCrtcCount() const {
> > +  return (uint32_t) crtcs_.size();
> > +}
> 
> The "blessed" way of doing this would be to add a new function
> 
> const std::vector> &crtcs() const {
>   return crtcs_;
> }
> 
> and then use crtcs()->size() wherever needed.
> 
> 

Yeah, that is nicer and more versatile.



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

Re: [PATCH hwc v2 6/6] drm_hwcomposer: Add out-fence support

On Wed, 2017-09-27 at 15:11 -0400, Sean Paul wrote:
> On Wed, Sep 27, 2017 at 7:58 AM, Robert Foss  om> wrote:
> > Add support for out-fences through the OUT_FENCE_PTR property.
> > Out-fences signal when their associated buffer may be read by a
> > device.
> > 
> > Signed-off-by: Robert Foss 
> > ---
> > 
> > Changes since v1:
> >   Sergi Granell
> > - Set atomic property to be out_fences[crtc->pipe()] not
> > out_fences[0]
> > 
> >  drmdisplaycomposition.h  |  9 +
> >  drmdisplaycompositor.cpp | 16 
> >  drmhwctwo.cpp|  9 ++---
> >  3 files changed, 27 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drmdisplaycomposition.h b/drmdisplaycomposition.h
> > index b165adc..0586d58 100644
> > --- a/drmdisplaycomposition.h
> > +++ b/drmdisplaycomposition.h
> > @@ -189,6 +189,14 @@ class DrmDisplayComposition {
> >  return planner_;
> >    }
> > 
> > +  int take_out_fence() {
> > +return out_fence_.Release();
> > +  }
> > +
> > +  void set_out_fence(int out_fence) {
> > +out_fence_.Set(dup(out_fence));
> 
> Why dup if you're just going to close the original? I think the
> helper
> functions actually hurt you here. It would be easier to understand
> what was going on if you just manipulated out_fence_ directly in
> CommitFrame (then you wouldn't need the dup/close).

Yeah, that makes a lot of sense, and is a lot easier to read too.

> 
> > +  }
> > +
> >    void Dump(std::ostringstream *out) const;
> > 
> >   private:
> > @@ -215,6 +223,7 @@ class DrmDisplayComposition {
> >    int timeline_current_ = 0;
> >    int timeline_squash_done_ = 0;
> >    int timeline_pre_comp_done_ = 0;
> > +  UniqueFd out_fence_ = -1;
> > 
> >    bool geometry_changed_;
> >    std::vector layers_;
> > diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
> > index 71c0451..a1427d3 100644
> > --- a/drmdisplaycompositor.cpp
> > +++ b/drmdisplaycompositor.cpp
> > @@ -492,6 +492,7 @@ int
> > DrmDisplayCompositor::CommitFrame(DrmDisplayComposition
> > *display_comp,
> >    display_comp->composition_planes();
> >    std::vector &pre_comp_regions =
> >    display_comp->pre_comp_regions();
> > +  uint64_t out_fences[drm_->GetCrtcCount()];
> 
> Huh. I didn't know you could do this.

C99 and variable length arrays man.
Progress at a glacial pace is still happening in C-land.


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

Re: [PATCH v3 2/2] drm/tinydrm: Add devres versions of drm_of_find_backlight

2017-09-28 Thread Noralf Trønnes



Den 28.09.2017 11.15, skrev Meghana Madhyastha:

Add devm_drm_of_find_backlight and the corresponding release
function because some drivers such as tinydrm use devres versions
of functions for requiring device resources.

Signed-off-by: Meghana Madhyastha 
---
Changes in v3:
-None

  drivers/gpu/drm/drm_of.c | 48 
  include/drm/drm_of.h |  2 ++
  2 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index d878d3a..238e8e5 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -304,3 +304,51 @@ struct backlight_device *drm_of_find_backlight(struct 
device *dev)
return backlight;
  }
  EXPORT_SYMBOL(drm_of_find_backlight);
+
+/**
+ * devm_drm_of_find_backlight_release - Release backlight device
+ * @dev: Device
+ *
+ * This is the release function corresponding to the 
devm_drm_of_find_backlight.
+ * Each devres entry is associated with a release function.
+ */


This is an internal function so no need for docs or exporting. I know
that some devm_ functions have explicit release functions, but I don't
think this is necessary since those users can just use
drm_of_find_backlight() directly instead.


+static void devm_drm_of_find_backlight_release(void *data)
+{
+   put_device(data);
+}
+EXPORT_SYMBOL(devm_drm_of_find_backlight_release);
+
+/**
+ * devm_drm_of_find_backlight - Find backlight device in device-tree
+ * devres version of the function
+ * @dev: Device
+ *
+ * This is the devres version of the function drm_of_find_backlight.
+ * Some drivers such as tinydrm use devres versions of functions for


No need to mention tinydrm here.


+ * requiring device resources.
+ *
+ * Returns:
+ * NULL if there's no backlight property.
+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
+ * is found.
+ * If the backlight device is found, a pointer to the structure is returned.
+ */
+struct backlight_device *devm_drm_of_find_backlight(struct device *dev)
+{
+   struct backlight_device *backlight;
+   int ret;
+
+   backlight = drm_of_find_backlight(dev);
+   if (IS_ERR_OR_NULL(backlight))
+   return backlight;
+
+   ret = devm_add_action(dev, devm_drm_of_find_backlight_release,
+ &backlight->dev);
+   if (ret) {
+   put_device(&backlight->dev);
+   return ERR_PTR(ret);
+   }
+
+   return backlight;
+}
+EXPORT_SYMBOL(devm_drm_of_find_backlight);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index e8fba5b..071fb3b 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -30,7 +30,9 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
struct drm_panel **panel,
struct drm_bridge **bridge);
  struct backlight_device *drm_of_find_backlight(struct device *dev);
+struct backlight_device *devm_drm_of_find_backlight(struct device *dev);
  #else


We need a dummy version of devm_drm_of_find_backlight() here that
returns NULL as in the previous patch.


+static void devm_drm_of_find_backlight_release(void *data);


And this isn't needed as explained above.

  static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
  {


I'd appreciate if you could also switch mi0283qt over to this helper :-)

Noralf.


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

Re: [PATCH v3 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

2017-09-28 Thread Noralf Trønnes



Den 28.09.2017 16.08, skrev Daniel Vetter:

On Thu, Sep 28, 2017 at 02:44:34PM +0530, Meghana Madhyastha wrote:

Rename tinydrm_of_find_backlight to drm_of_find_backlight
and move it into drm_of.c from tinydrm-helpers.c. This is
because other drivers in the drm subsystem might need to call
this function. In that case and otherwise, it is better from
an organizational point of view to move it into drm_of.c along
with the other _of.c functions.

Signed-off-by: Meghana Madhyastha 
---
Changes in v3:
-Change it back to a single patch from two patches in v2

  drivers/gpu/drm/drm_of.c   | 44 ++
  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 ---
  drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
  include/drm/drm_of.h   |  1 +
  include/drm/tinydrm/tinydrm-helpers.h  |  1 -
  5 files changed, 47 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 8dafbdf..d878d3a 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -1,6 +1,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -260,3 +261,46 @@ int drm_of_find_panel_or_bridge(const struct device_node 
*np,
return ret;
  }
  EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+/**
+ * drm_of_find_backlight - Find backlight device in device-tree
+ * @dev: Device
+ *
+ * This function looks for a DT node pointed to by a property named 'backlight'
+ * and uses of_find_backlight_by_node() to get the backlight device.
+ * Additionally if the brightness property is zero, it is set to
+ * max_brightness.
+ *
+ * Note: It is the responsibility of the caller to call put_device() when
+ * releasing the resource.
+ *
+ * Returns:
+ * NULL if there's no backlight property.
+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
+ * is found.
+ * If the backlight device is found, a pointer to the structure is returned.
+ */
+struct backlight_device *drm_of_find_backlight(struct device *dev)
+{
+   struct backlight_device *backlight;
+   struct device_node *np;
+
+   np = of_parse_phandle(dev->of_node, "backlight", 0);
+   if (!np)
+   return NULL;
+
+   backlight = of_find_backlight_by_node(np);
+   of_node_put(np);
+
+   if (!backlight)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   if (!backlight->props.brightness) {
+   backlight->props.brightness = backlight->props.max_brightness;
+   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
+ backlight->props.brightness);
+   }
+
+   return backlight;
+}
+EXPORT_SYMBOL(drm_of_find_backlight);
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bd6cce0..cd4c6a5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -237,46 +237,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
struct drm_framebuffer *fb,
  EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
  
  /**

- * tinydrm_of_find_backlight - Find backlight device in device-tree
- * @dev: Device
- *
- * This function looks for a DT node pointed to by a property named 'backlight'
- * and uses of_find_backlight_by_node() to get the backlight device.
- * Additionally if the brightness property is zero, it is set to
- * max_brightness.
- *
- * Returns:
- * NULL if there's no backlight property.
- * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
- * is found.
- * If the backlight device is found, a pointer to the structure is returned.
- */
-struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
-{
-   struct backlight_device *backlight;
-   struct device_node *np;
-
-   np = of_parse_phandle(dev->of_node, "backlight", 0);
-   if (!np)
-   return NULL;
-
-   backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
-
-   if (!backlight)
-   return ERR_PTR(-EPROBE_DEFER);
-
-   if (!backlight->props.brightness) {
-   backlight->props.brightness = backlight->props.max_brightness;
-   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
- backlight->props.brightness);
-   }
-
-   return backlight;
-}
-EXPORT_SYMBOL(tinydrm_of_find_backlight);
-
-/**
   * tinydrm_enable_backlight - Enable backlight helper
   * @backlight: Backlight device
   *
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 7e5bb7d..5e3d635 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -12,6 +12,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -189,7 +190,7 @@ static int mi0283qt_probe(struct spi_device *spi)
if (IS_ERR(mipi->regulator))

[dim PATCH] dim: allow a space separated list of URLs for each repo in drm_tip_repos

2017-09-28 Thread Jani Nikula

This lets us configure a space separated list of URLs for each repo in
drm_tip_repos, with all accepted protocols and sources, and the first
one found gets picked. This way we don't have to have a complicated set
of rules for converting between ssh, git and https protocol URLs.

Signed-off-by: Jani Nikula 

---

!!! UNTESTED !!!
---
 dim | 97 +
 1 file changed, 63 insertions(+), 34 deletions(-)

diff --git a/dim b/dim
index c6c746cdb154..d2f165893161 100755
--- a/dim
+++ b/dim
@@ -255,44 +255,73 @@ fi
 # The below functions map between these.
 #
 
-function url_to_remote # url
+function url_to_remote # url [url ...]
 {
local url remote
 
-   url="$1"
-
-   if [[ -z "$url" ]]; then
-   echoerr "$0 without url"
+   if [[ "$#" = "0" ]]; then
+   echoerr "url_to_remote without URLs"
return 1
fi
 
-   remote=$(git remote -v | grep -m 1 "$url" | cut -f 1)
-
-   if [[ -z "$remote" ]]; then
-   git_url=$(echo $url | sed -e 's/git\./anongit./' -e 
's/ssh:/git:/')
-   remote=$(git remote -v | grep -m 1 "$git_url" | cut -f 1)
+   for url; do
+   remote=$(git remote -v | grep -m 1 "$url" | cut -f 1)
+   if [[ -n "$remote" ]]; then
+   echo "$remote"
+   return 0
+   fi
+   done
 
-   if [[ -z "$remote" ]]; then
-   echoerr "No git remote for url $url or $git_url found 
in $(pwd)"
-   remote=${url%.git}
-   remote=${remote##*/}
-   read -r -i "$remote" -e -p "Enter a name to auto-add 
this remote, leave blank to abort: " || true
-   if [[ "$REPLY" == "" ]] ; then
-   echoerr "Please set it up yourself using:"
-   echoerr "$ git remote add  $url"
-   echoerr "with a name of your choice."
-   exit 1
-   fi
+   echoerr "No git remote for any of the URLs $* found in $(pwd)"
 
-   git remote add $remote $url
-   fi
+   url=$1
+   remote=${url%.git}
+   remote=${remote##*/}
+   read -r -i "$remote" -e -p "Enter a name to auto-add this remote, leave 
blank to abort: " || true
+   if [[ "$REPLY" == "" ]] ; then
+   echoerr "Please set it up yourself using:"
+   echoerr "$ git remote add  $url"
+   echoerr "with a name of your choice."
+   exit 1
fi
 
+   git remote add $remote $url
+
echo $remote
 
return 0
 }
 
+function url_to_git_url # url [url ...]
+{
+   local url git_url
+
+   if [[ "$#" = "0" ]]; then
+   echoerr "url_to_git_url without URLs"
+   return 1
+   fi
+
+   # Find the git:// URL, converting from ssh:// URL as fallback
+   for url; do
+   case $url in
+   git://*)
+   git_url=$url
+   break
+   ;;
+   ssh://*)
+   git_url=$(echo $url | sed -e 
's/git\./anongit./' -e 's/ssh:/git:/')
+   ;;
+   esac
+   done
+
+   if [[ -z "$git_url" ]]; then
+   echoerr "No git or ssh URL in any of the URLs $*"
+   return 1
+   fi
+
+   echo $git_url
+}
+
 function branch_to_remote # branch
 {
local branch remote
@@ -595,7 +624,7 @@ function commit_rerere_cache
 
 function dim_rebuild_tip
 {
-   local integration_branch specfile time first rerere repo url remote
+   local integration_branch specfile time first rerere repo url_list remote
 
integration_branch=drm-tip
specfile=$(mktemp)
@@ -627,8 +656,8 @@ function dim_rebuild_tip
echo "Done."
 
for repo in "${!drm_tip_repos[@]}"; do
-   url=${drm_tip_repos[$repo]}
-   remote=$(url_to_remote $url)
+   url_list=${drm_tip_repos[$repo]}
+   remote=$(url_to_remote $url_list)
echo -n "Fetching $repo (local remote $remote)... "
git_fetch_helper $remote
echo "Done."
@@ -639,8 +668,8 @@ function dim_rebuild_tip
local branch override sha1 fixup_file
 
read -r repo branch override <<< $conf
-   url=${drm_tip_repos[$repo]}
-   remote=$(url_to_remote $url)
+   url_list=${drm_tip_repos[$repo]}
+   remote=$(url_to_remote $url_list)
sha1=$remote/$branch
 
echo -n "Merging $repo (local remote $remote) $branch... "
@@ -1641,7 +1670,7 @@ function prep_pull_tag_summary
 # dim_pull_request branch upstream
 function dim_pull_request
 {
-

Re: [maintainer-tools PATCH] dim: fix remote repository lookup function

2017-09-28 Thread Jani Nikula

On Wed, 27 Sep 2017, Andrzej Hajda  wrote:
> On 25.08.2017 13:31, Andrzej Hajda wrote:
>> dim finds remote name by matching repository urls, but different users
>> requires different protocols/paths for remotes (ssh/git/https). Current
>> code incorrectly translates provided url to alternatives, the patch
>> fixes it.
>>
>> Signed-off-by: Andrzej Hajda 
>
> Gently ping.

Apologies for the delay. I had a hard time understanding all the sed
trickery you have there. Then I decided the right solution is to be able
to configure multiple URLs in nightly.conf for each repo in
drm_tip_repos.

Patch follows adding this support to dim, untested because I need to run
now. Unfortunately we can't update nightly.conf before dim users have
upgraded to the patched version, because otherwise their setups would
break.

BR,
Jani.

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

[PATCH v2] drm/amd/display: DC I2C review

2017-09-28 Thread Harry Wentland

While reviewing I2C in DC identified a few places. Added a couple to the
TODO list.

1) Connector info read

See get_ext_display_connection_info

On some boards the connector information has to be read through a
special I2C channel. This line is only used for this purpose and only on
driver init.

2) SCDC stuff

This should all be reworked to go through DRM's SCDC code. When this is
done some unnecessary I2C code can be retired as well.

3) Max TMDS clock read

See dal_ddc_service_i2c_query_dp_dual_mode_adaptor

This should happen in DRM as well. I haven't checked if there's
currently functionality in DRM. If not we can propose something.

4) HDMI retimer programming

Some boards have an HDMI retimer that we need to program to pass PHY
compliance.

1 & 3 might be a good exercise if someone is looking for things to do.

v2: Merge dp_dual_mode_adaptor TODO

Signed-off-by: Harry Wentland 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/display/TODO | 25 ++---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/TODO b/drivers/gpu/drm/amd/display/TODO
index eea645b102a1..46464678f2b3 100644
--- a/drivers/gpu/drm/amd/display/TODO
+++ b/drivers/gpu/drm/amd/display/TODO
@@ -62,20 +62,10 @@ TODOs
 ~ Daniel Vetter
 
 
-11. Remove existing i2c implementation from DC
-
-"Similar story for i2c, it uses the kernel's i2c code now, but there's
-still a full i2c implementation hidden beneath that in
-display/dc/i2caux. Kinda not cool, but imo ok if you fix that
-post-merging (perhaps by not including any of this in the linux DC
-code in the upstream kernel, but as an aux module in your internal
-codebase since there you probably need that, same applies to the edid
-parsing DC still does. For both cases I assume that the minimal shim
-you need on linux (bit banging and edid parsing isn't rocket since) is
-a lot less than the glue code to interface with the dc-provided
-abstraction."
-~ Daniel Vetter
-
+11. Remove dc/i2caux. This folder can be somewhat misleading. It's basically an
+overy complicated HW programming function for sendind and receiving i2c/aux
+commands. We can greatly simplify that and move it into dc/dceXYZ like other
+HW blocks.
 
 12. drm_modeset_lock in MST should no longer be needed in recent kernels
 * Adopt appropriate locking scheme
@@ -89,7 +79,8 @@ moving all your driver state printing into the various 
atomic_print_state
 callbacks. There's also plans to expose this stuff in a standard way across all
 drivers, to make debugging userspace compositors easier across different hw.
 
-15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c.
+15. Move DP/HDMI dual mode adaptors to drm_dp_dual_mode_helper.c. See
+dal_ddc_service_i2c_query_dp_dual_mode_adaptor.
 
 16. Move to core SCDC helpers (I think those are new since initial DC review).
 
@@ -110,3 +101,7 @@ guilty.
 stuff just isn't up to the challenges either. We need to figure out something
 that integrates better with DRM and linux debug printing, while not being
 useless with filtering output. dynamic debug printing might be an option.
+
+20. Use kernel i2c device to program HDMI retimer. Some boards have an HDMI
+retimer that we need to program to pass PHY compliance. Currently that's
+bypassing the i2c device and goes directly to HW. This should be changed.
-- 
2.11.0

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

Re: [PATCH] drm/i915: Replace _reference/unreference() or _ref/unref with _get/put()

On Thu, Sep 28, 2017 at 07:14:42PM +0530, Harsha Sharma wrote:
> Replace instances of drm_framebuffer_reference/unreference() with
> *_get/put() suffixes and drm_dev_unref with *_put() suffix
> because get/put is shorter and consistent with the
> kernel use of *_get/put suffixes .

Since this is done with cocci it's good to reference or include the cocci
patch you've used in the commit message.

> Signed-off-by: Harsha Sharma 

When submitting a driver patch, please make sure you also include driver
maintainers and driver-specific mailing lists, not just dri-devel.

scripts/get_maintainers.pl should help you with figuring these out.

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/i915_pci.c|  2 +-
>  drivers/gpu/drm/i915/intel_display.c   | 10 +-
>  drivers/gpu/drm/i915/intel_fbdev.c |  4 ++--
>  drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c   |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_evict.c|  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_object.c   |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_request.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/i915_vma.c  |  2 +-
>  drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c |  2 +-
>  10 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 09d97e0..2f106cc 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -510,7 +510,7 @@ static void i915_pci_remove(struct pci_dev *pdev)
>   struct drm_device *dev = pci_get_drvdata(pdev);
>  
>   i915_driver_unload(dev);
> - drm_dev_unref(dev);
> + drm_dev_put(dev);
>  }
>  
>  static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id 
> *ent)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index f172755..92f8304 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2856,7 +2856,7 @@ static int skl_format_to_fourcc(int format, bool 
> rgb_order, bool alpha)
>  
>   if (intel_plane_ggtt_offset(state) == plane_config->base) {
>   fb = c->primary->fb;
> - drm_framebuffer_reference(fb);
> + drm_framebuffer_get(fb);
>   goto valid_fb;
>   }
>   }
> @@ -2887,7 +2887,7 @@ static int skl_format_to_fourcc(int format, bool 
> rgb_order, bool alpha)
> intel_crtc->pipe, PTR_ERR(intel_state->vma));
>  
>   intel_state->vma = NULL;
> - drm_framebuffer_unreference(fb);
> + drm_framebuffer_put(fb);
>   return;
>   }
>  
> @@ -2908,7 +2908,7 @@ static int skl_format_to_fourcc(int format, bool 
> rgb_order, bool alpha)
>   if (i915_gem_object_is_tiled(obj))
>   dev_priv->preserve_bios_swizzle = true;
>  
> - drm_framebuffer_reference(fb);
> + drm_framebuffer_get(fb);
>   primary->fb = primary->state->fb = fb;
>   primary->crtc = primary->state->crtc = &intel_crtc->base;
>  
> @@ -9847,7 +9847,7 @@ struct drm_framebuffer *
>   if (obj->base.size < mode->vdisplay * fb->pitches[0])
>   return NULL;
>  
> - drm_framebuffer_reference(fb);
> + drm_framebuffer_get(fb);
>   return fb;
>  #else
>   return NULL;
> @@ -10028,7 +10028,7 @@ int intel_get_load_detect_pipe(struct drm_connector 
> *connector,
>   if (ret)
>   goto fail;
>  
> - drm_framebuffer_unreference(fb);
> + drm_framebuffer_put(fb);
>  
>   ret = drm_atomic_set_mode_for_crtc(&crtc_state->base, mode);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 262e75c..1ff7149 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -189,7 +189,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
> " releasing it\n",
> intel_fb->base.width, intel_fb->base.height,
> sizes->fb_width, sizes->fb_height);
> - drm_framebuffer_unreference(&intel_fb->base);
> + drm_framebuffer_put(&intel_fb->base);
>   intel_fb = ifbdev->fb = NULL;
>   }
>   if (!intel_fb || WARN_ON(!intel_fb->obj)) {
> @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
>   ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8;
>   ifbdev->fb = fb;
>  
> - drm_framebuffer_reference(&ifbdev->fb->base);
> + drm_framebuffer_put(&ifbdev->fb->base);
>  
>   /* Final pass to check if any active pipes don't have fbs */
>   for_each_crtc(dev, crtc) {
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_dmabuf.c
> index 89dc25a..a7055b1

Re: [PATCH v3 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

On Thu, Sep 28, 2017 at 02:44:34PM +0530, Meghana Madhyastha wrote:
> Rename tinydrm_of_find_backlight to drm_of_find_backlight
> and move it into drm_of.c from tinydrm-helpers.c. This is
> because other drivers in the drm subsystem might need to call
> this function. In that case and otherwise, it is better from
> an organizational point of view to move it into drm_of.c along
> with the other _of.c functions.
> 
> Signed-off-by: Meghana Madhyastha 
> ---
> Changes in v3:
> -Change it back to a single patch from two patches in v2
> 
>  drivers/gpu/drm/drm_of.c   | 44 
> ++
>  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 ---
>  drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
>  include/drm/drm_of.h   |  1 +
>  include/drm/tinydrm/tinydrm-helpers.h  |  1 -
>  5 files changed, 47 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 8dafbdf..d878d3a 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -1,6 +1,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -260,3 +261,46 @@ int drm_of_find_panel_or_bridge(const struct device_node 
> *np,
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
> +
> +/**
> + * drm_of_find_backlight - Find backlight device in device-tree
> + * @dev: Device
> + *
> + * This function looks for a DT node pointed to by a property named 
> 'backlight'
> + * and uses of_find_backlight_by_node() to get the backlight device.
> + * Additionally if the brightness property is zero, it is set to
> + * max_brightness.
> + *
> + * Note: It is the responsibility of the caller to call put_device() when
> + * releasing the resource.
> + *
> + * Returns:
> + * NULL if there's no backlight property.
> + * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight 
> device
> + * is found.
> + * If the backlight device is found, a pointer to the structure is returned.
> + */
> +struct backlight_device *drm_of_find_backlight(struct device *dev)
> +{
> + struct backlight_device *backlight;
> + struct device_node *np;
> +
> + np = of_parse_phandle(dev->of_node, "backlight", 0);
> + if (!np)
> + return NULL;
> +
> + backlight = of_find_backlight_by_node(np);
> + of_node_put(np);
> +
> + if (!backlight)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + if (!backlight->props.brightness) {
> + backlight->props.brightness = backlight->props.max_brightness;
> + DRM_DEBUG_KMS("Backlight brightness set to %d\n",
> +   backlight->props.brightness);
> + }
> +
> + return backlight;
> +}
> +EXPORT_SYMBOL(drm_of_find_backlight);
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
> b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> index bd6cce0..cd4c6a5 100644
> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> @@ -237,46 +237,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
> struct drm_framebuffer *fb,
>  EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
>  
>  /**
> - * tinydrm_of_find_backlight - Find backlight device in device-tree
> - * @dev: Device
> - *
> - * This function looks for a DT node pointed to by a property named 
> 'backlight'
> - * and uses of_find_backlight_by_node() to get the backlight device.
> - * Additionally if the brightness property is zero, it is set to
> - * max_brightness.
> - *
> - * Returns:
> - * NULL if there's no backlight property.
> - * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight 
> device
> - * is found.
> - * If the backlight device is found, a pointer to the structure is returned.
> - */
> -struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
> -{
> - struct backlight_device *backlight;
> - struct device_node *np;
> -
> - np = of_parse_phandle(dev->of_node, "backlight", 0);
> - if (!np)
> - return NULL;
> -
> - backlight = of_find_backlight_by_node(np);
> - of_node_put(np);
> -
> - if (!backlight)
> - return ERR_PTR(-EPROBE_DEFER);
> -
> - if (!backlight->props.brightness) {
> - backlight->props.brightness = backlight->props.max_brightness;
> - DRM_DEBUG_KMS("Backlight brightness set to %d\n",
> -   backlight->props.brightness);
> - }
> -
> - return backlight;
> -}
> -EXPORT_SYMBOL(tinydrm_of_find_backlight);
> -
> -/**
>   * tinydrm_enable_backlight - Enable backlight helper
>   * @backlight: Backlight device
>   *
> diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
> b/drivers/gpu/drm/tinydrm/mi0283qt.c
> index 7e5bb7d..5e3d635 100644
> --- a/drivers/gpu/drm/tinydrm/mi0283qt.c
> +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #inclu

[Bug 102468] RX470 powerplay issues on hybrid laptop system (dGPU does not power down)

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

taij...@posteo.de changed:

   What|Removed |Added

 Attachment #133866|0   |1
is obsolete||

--- Comment #4 from taij...@posteo.de ---
Created attachment 134540
  --> https://bugs.freedesktop.org/attachment.cgi?id=134540&action=edit
dmesg output with kernel 4.13.3

-- 
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][drm-next] drm/radeon: make functions alloc_pasid and free_pasid static

2017-09-28 Thread Colin King

From: Colin Ian King 

The functions alloc_pasid  and free_pasid are local to the
source and do not need to be in global scope, so make them static.

Cleans up sparse warnings:
warning: symbol 'alloc_pasid' was not declared. Should it be static?
warning: symbol 'free_pasid' was not declared. Should it be static?

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/radeon/radeon_kfd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c 
b/drivers/gpu/drm/radeon/radeon_kfd.c
index a2ac8ac0930d..385b4d76956d 100644
--- a/drivers/gpu/drm/radeon/radeon_kfd.c
+++ b/drivers/gpu/drm/radeon/radeon_kfd.c
@@ -352,7 +352,7 @@ static uint32_t get_max_engine_clock_in_mhz(struct kgd_dev 
*kgd)
  */
 static DEFINE_IDA(pasid_ida);
 
-int alloc_pasid(unsigned int bits)
+static int alloc_pasid(unsigned int bits)
 {
int pasid = -EINVAL;
 
@@ -367,7 +367,7 @@ int alloc_pasid(unsigned int bits)
return pasid;
 }
 
-void free_pasid(unsigned int pasid)
+static void free_pasid(unsigned int pasid)
 {
ida_simple_remove(&pasid_ida, pasid);
 }
-- 
2.14.1

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

Re: [PATCH v3 3/6] gpu: host1x: Improve debug disassembly formatting

2017-09-28 Thread Joe Perches

On Thu, 2017-09-28 at 15:50 +0300, Mikko Perttunen wrote:
> The host1x driver prints out "disassembly" dumps of the command FIFO
> and gather contents on submission timeouts. However, the output has
> been quite difficult to read with unnecessary newlines and occasional
> missing parentheses.

I think it would be cleaner/simpler to change
this by adding a line initiator with just a
KERN_ at the few places that actually
start a newline.

Then change the write_to_seqfile to skip any
output that starts with KERN_

> diff --git a/drivers/gpu/host1x/hw/debug_hw_1x01.c 
> b/drivers/gpu/host1x/hw/debug_hw_1x01.c
[]
> @@ -111,11 +111,11 @@ static void host1x_debug_show_channel_fifo(struct 
> host1x *host,
>   val = host1x_sync_readl(host, HOST1X_SYNC_CFPEEK_READ);
>  
>   if (!data_count) {
> - host1x_debug_output(o, "%08x:", val);
> + host1x_debug_output(o, "%08x: ", val);

ie: change this and the other start of lines to prepend KERN_INFO

host_x_debug_putput(o, KERN_INFO "%08x ", val);

>   data_count = show_channel_command(o, val);
>   } else {
> - host1x_debug_output(o, "%08x%s", val,
> - data_count > 0 ? ", " : "])\n");

And don't change all the other continuation lines

And change the write_to_ functions to

static inline void write_to_seqfile(void *ctx, const char *str, size_t len)
{
const char *output = printk_skip_level(str);

seq_write(ctx, output, len - (str - output)); 
}

static inline void write_to_printk(void *ctx, const char *str, size_t len)
{
const char *output = printk_skip_level(str);

if (output == str)
pr_cont("%s", str);
else
printk("s", str);
}

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

[RFC PATCH 3/4] extcon: add possibility to get extcon device by of node

Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.

Signed-off-by: Andrzej Hajda 
---
 drivers/extcon/extcon.c | 44 ++--
 include/linux/extcon.h  |  6 ++
 2 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..fdb8c1d767c1 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
 EXPORT_SYMBOL_GPL(extcon_dev_unregister);
 
 #ifdef CONFIG_OF
+
+/*
+ * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
+ * @node   : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   struct extcon_dev *edev;
+
+   mutex_lock(&extcon_dev_list_lock);
+   list_for_each_entry(edev, &extcon_dev_list, entry)
+   if (edev->dev.parent && edev->dev.parent->of_node == node)
+   goto end;
+   edev = ERR_PTR(-EPROBE_DEFER);
+end:
+   mutex_unlock(&extcon_dev_list_lock);
+
+   return edev;
+}
+
 /*
  * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
  * @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct 
device *dev, int index)
return ERR_PTR(-ENODEV);
}
 
-   mutex_lock(&extcon_dev_list_lock);
-   list_for_each_entry(edev, &extcon_dev_list, entry) {
-   if (edev->dev.parent && edev->dev.parent->of_node == node) {
-   mutex_unlock(&extcon_dev_list_lock);
-   of_node_put(node);
-   return edev;
-   }
-   }
-   mutex_unlock(&extcon_dev_list_lock);
+   edev = extcon_get_edev_by_of_node(node);
of_node_put(node);
 
-   return ERR_PTR(-EPROBE_DEFER);
+   return edev;
 }
+
 #else
+
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+   return ERR_PTR(-ENOSYS);
+}
+
 struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
 {
return ERR_PTR(-ENOSYS);
 }
+
 #endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node);
 EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
 
 /**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 744d60ca80c3..2f88e7491672 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -261,6 +261,7 @@ extern void devm_extcon_unregister_notifier_all(struct 
device *dev,
  * Following APIs get the extcon_dev from devicetree or by through extcon name.
  */
 extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node);
 extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
 int index);
 
@@ -382,6 +383,11 @@ static inline struct extcon_dev 
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
 }
 
+static inline struct extcon_dev *extcon_get_edev_by_of_node(struct device_node 
*node)
+{
+   return ERR_PTR(-ENODEV);
+}
+
 static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
 {
-- 
2.14.1

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

[RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

These bindings allows 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 
---
There are few things for discussion (IMO):
1. vendor specific connectors, I have added them here, but maybe better is
   to place them in separate files.
2. physical connector description - I have split it to three properties:
   type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
   This tripled is able to describe all USB-standard connectors, but there
   are also impossible combinations, for example(c, *, micro). Maybe better
   would be to just enumerate all possible connectors in include file.
3. Numbering of port/remote nodes, currently only 0 is assigned for Interface
   Controller. Maybe other functions should be also assigned:
   HS, SS, CC, SBU, ... whatever. Maybe functions should be described
   as an additional property of remote node?
...

Regards
Andrzej
---
 .../bindings/connector/usb-connector.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..f3a4e85122d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,49 @@
+USB Connector
+=
+
+Required properties:
+- compatible: "usb-connector"
+  connectors with vendor specific extensions can add one of additional
+  compatibles:
+"samsung,usb-connector-11pin": 11-pin Samsung micro-USB connector
+- type: the USB connector type: "a", "b", "ab", "c"
+- max-mode: max USB speed mode supported by the connector:
+  "ls", "fs", "hs", "ss", "ss+"
+
+Optional properties:
+- label: a symbolic name for the connector
+- size: size of the connector, should be specified in case of
+  non-standard USB connectors: "mini", "micro", "powered"
+
+Required nodes:
+- any data bus to the connector should be modeled using the
+  OF graph bindings specified in bindings/graph.txt.
+  There should be exactly one port with at least one endpoint to
+  different device nodes. The first endpoint (reg = <0>) should
+  point to USB Interface Controller.
+
+Example
+---
+
+musb_con: connector {
+   compatible = "samsung,usb-connector-11pin", "usb-connector";
+   label = "usb";
+   type = "b";
+   size = "micro";
+   max-mode = "hs";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   musb_con_usb_in: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&muic_usb_out>;
+   };
+
+   musb_con_mhl_in: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&mhl_out>;
+   };
+   };
+};
-- 
2.14.1

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

[RFC PATCH 0/4] dt-bindings: add bindings for USB physical connector

Hi,

This patchset introduces USB connector bindings, together with working example.
I have added comments in relevant patches to describe possible issues.

Regards
Andrzej


Andrzej Hajda (3):
  dt-bindings: add bindings for USB physical connector
  arm64: dts: exynos: add micro-USB connector node to TM2 platforms
  extcon: add possibility to get extcon device by of node

Maciej Purski (1):
  drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

 .../bindings/connector/usb-connector.txt   | 49 +++
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 47 ++-
 drivers/extcon/extcon.c| 44 +++---
 drivers/gpu/drm/bridge/sil-sii8620.c   | 98 +-
 include/linux/extcon.h |  6 ++
 5 files changed, 228 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/connector/usb-connector.txt

-- 
2.14.1

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

[RFC PATCH 4/4] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

From: Maciej Purski 

Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.

Signed-off-by: Maciej Purski 
Signed-off-by: Andrzej Hajda 
---
This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.

Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 98 ++--
 1 file changed, 95 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 5131bfb94f06..6f40cbc2445e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -78,6 +80,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+   struct extcon_dev *extcon;
+   struct notifier_block extcon_nb;
+   struct work_struct extcon_wq;
+   int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2102,6 +2108,78 @@ static void sii8620_cable_in(struct sii8620 *ctx)
enable_irq(to_i2c_client(ctx->dev)->irq);
 }
 
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+   disable_irq(to_i2c_client(ctx->dev)->irq);
+   sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+   struct sii8620 *ctx =
+   container_of(work, struct sii8620, extcon_wq);
+   int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+   if (state == ctx->cable_state)
+   return;
+
+   ctx->cable_state = state;
+
+   if (state > 0)
+   sii8620_cable_in(ctx);
+   else
+   sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+   unsigned long event, void *ptr)
+{
+   struct sii8620 *ctx =
+   container_of(self, struct sii8620, extcon_nb);
+
+   schedule_work(&ctx->extcon_wq);
+
+   return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+   struct extcon_dev *edev;
+   struct device_node *musb, *muic;
+   int ret;
+
+   /* get micro-USB connector node */
+   musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+   /* next get micro-USB Interface Controller node */
+   muic = of_graph_get_remote_node(musb, -1, 0);
+   of_node_put(musb);
+
+   if (!muic) {
+   dev_info(ctx->dev, "no extcon found, switching to 'always on' 
mode\n");
+   return 0;
+   }
+
+   edev = extcon_get_edev_by_of_node(muic);
+   of_node_put(muic);
+   if (IS_ERR(edev)) {
+   if (PTR_ERR(edev) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(ctx->dev, "Invalid or missing extcon\n");
+   return PTR_ERR(edev);
+   }
+
+   ctx->extcon = edev;
+   ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+   INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
+   ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb);
+   if (ret) {
+   dev_err(ctx->dev, "failed to register notifier for MHL\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
 {
return container_of(bridge, struct sii8620, bridge);
@@ -2201,13 +2279,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
 
+   ret = sii8620_extcon_init(ctx);
+   if (ret < 0) {
+   dev_err(ctx->dev, "failed to initialize EXTCON\n");
+   return ret;
+   }
+
i2c_set_clientdata(client, ctx);
 
ctx->bridge.funcs = &sii8620_bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(&ctx->bridge);
 
-   sii8620_cable_in(ctx);
+   if (!ctx->extcon)
+   sii8620_cable_in(ctx);
 
return 0;
 }
@@ -2216,9 +2301,16 @@ static int sii8620_remove(struct i2c_client *client)
 {
struct sii8620 *ctx = i2c_get_clientdata(client);
 
-   disable_irq(to_i2c_client(ctx->dev)->irq);
+   if (ctx->extcon) {
+   extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
+  &ctx->extcon_nb);
+

[RFC PATCH 2/4] arm64: dts: exynos: add micro-USB connector node to TM2 platforms

Since USB connector bindings are available we can describe it on TM2(e).

Signed-off-by: Andrzej Hajda 
---
 .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 47 --
 1 file changed, 44 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index e30bae4cf878..39b1ca0ef4cd 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -135,6 +135,28 @@
"RCV", "HPOUT3R";
status = "okay";
};
+
+   musb_con: musb_connector {
+   compatible = "samsung,usb-connector-11pin", "usb-connector";
+   label = "micro-usb";
+   type = "b";
+   size = "micro";
+   max-mode = "hs";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   musb_con_to_muic: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&muic_to_musb_con>;
+   };
+   musb_con_to_mhl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&mhl_to_musb_con>;
+   };
+   };
+   };
 };
 
 &adc {
@@ -768,9 +790,22 @@
clocks = <&pmu_system_controller 0>;
clock-names = "xtal";
 
-   port {
-   mhl_to_hdmi: endpoint {
-   remote-endpoint = <&hdmi_to_mhl>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <&hdmi_to_mhl>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   mhl_to_musb_con: endpoint {
+   remote-endpoint = <&musb_con_to_mhl>;
+   };
};
};
};
@@ -787,6 +822,12 @@
 
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+   port {
+   muic_to_musb_con: endpoint@0 {
+   remote-endpoint = <&musb_con_to_muic>;
+   };
+   };
};
 
regulators {
-- 
2.14.1

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

[Bug 98324] [DC] amd-staging-4.7: problems with unblanking displays when monitors are switched off

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

--- Comment #8 from Darren Salt  ---
Broken (same symptoms, though the kernel log looks a little different) with
drm-next-4.15-dc (fbf0c14dd75) (merged with 4.13.4).

-- 
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 v6 1/3] drm/vc4: Move the DSI clock divider workaround closer to the clock call.

2017-09-28 Thread Thierry Reding

On Wed, Sep 27, 2017 at 12:36:52PM -0700, Eric Anholt wrote:
> We want the adjusted_mode->clock to be the actual clock we're
> expecting to program, so that consumers see the right values for clock
> and vrefresh.
> 
> Signed-off-by: Eric Anholt 
> ---
>  drivers/gpu/drm/vc4/vc4_dsi.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Do you want me to apply this to drm-misc-next along with the touchscreen
panel driver?

Thierry


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

[PATCH v3 2/6] gpu: host1x: Enable gather filter

The gather filter is a feature present on Tegra124 and newer where the
hardware prevents GATHERed command buffers from executing commands
normally reserved for the CDMA pushbuffer which is maintained by the
kernel driver.

This commit enables the gather filter on all supporting hardware.

Signed-off-by: Mikko Perttunen 
Reviewed-by: Dmitry Osipenko 
---
 drivers/gpu/host1x/hw/channel_hw.c  | 22 ++
 drivers/gpu/host1x/hw/hw_host1x04_channel.h | 12 
 drivers/gpu/host1x/hw/hw_host1x05_channel.h | 12 
 3 files changed, 46 insertions(+)

diff --git a/drivers/gpu/host1x/hw/channel_hw.c 
b/drivers/gpu/host1x/hw/channel_hw.c
index b929d7f1e291..fb8132fc477b 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -181,10 +181,32 @@ static int channel_submit(struct host1x_job *job)
return err;
 }
 
+static void enable_gather_filter(struct host1x *host,
+struct host1x_channel *ch)
+{
+#if HOST1X_HW >= 6
+   u32 val;
+
+   if (!host->hv_regs)
+   return;
+
+   val = host1x_hypervisor_readl(
+   host, HOST1X_HV_CH_KERNEL_FILTER_GBUFFER(ch->id / 32));
+   val |= BIT(ch->id % 32);
+   host1x_hypervisor_writel(
+   host, val, HOST1X_HV_CH_KERNEL_FILTER_GBUFFER(ch->id / 32));
+#elif HOST1X_HW >= 4
+   host1x_ch_writel(ch,
+HOST1X_CHANNEL_CHANNELCTRL_KERNEL_FILTER_GBUFFER(1),
+HOST1X_CHANNEL_CHANNELCTRL);
+#endif
+}
+
 static int host1x_channel_init(struct host1x_channel *ch, struct host1x *dev,
   unsigned int index)
 {
ch->regs = dev->regs + index * HOST1X_CHANNEL_SIZE;
+   enable_gather_filter(dev, ch);
return 0;
 }
 
diff --git a/drivers/gpu/host1x/hw/hw_host1x04_channel.h 
b/drivers/gpu/host1x/hw/hw_host1x04_channel.h
index 95e6f96142b9..2e8b635aa660 100644
--- a/drivers/gpu/host1x/hw/hw_host1x04_channel.h
+++ b/drivers/gpu/host1x/hw/hw_host1x04_channel.h
@@ -117,5 +117,17 @@ static inline u32 host1x_channel_dmactrl_dmainitget(void)
 }
 #define HOST1X_CHANNEL_DMACTRL_DMAINITGET \
host1x_channel_dmactrl_dmainitget()
+static inline u32 host1x_channel_channelctrl_r(void)
+{
+   return 0x98;
+}
+#define HOST1X_CHANNEL_CHANNELCTRL \
+   host1x_channel_channelctrl_r()
+static inline u32 host1x_channel_channelctrl_kernel_filter_gbuffer_f(u32 v)
+{
+   return (v & 0x1) << 2;
+}
+#define HOST1X_CHANNEL_CHANNELCTRL_KERNEL_FILTER_GBUFFER(v) \
+   host1x_channel_channelctrl_kernel_filter_gbuffer_f(v)
 
 #endif
diff --git a/drivers/gpu/host1x/hw/hw_host1x05_channel.h 
b/drivers/gpu/host1x/hw/hw_host1x05_channel.h
index fce6e2c1ff4c..abbbc2641ce6 100644
--- a/drivers/gpu/host1x/hw/hw_host1x05_channel.h
+++ b/drivers/gpu/host1x/hw/hw_host1x05_channel.h
@@ -117,5 +117,17 @@ static inline u32 host1x_channel_dmactrl_dmainitget(void)
 }
 #define HOST1X_CHANNEL_DMACTRL_DMAINITGET \
host1x_channel_dmactrl_dmainitget()
+static inline u32 host1x_channel_channelctrl_r(void)
+{
+   return 0x98;
+}
+#define HOST1X_CHANNEL_CHANNELCTRL \
+   host1x_channel_channelctrl_r()
+static inline u32 host1x_channel_channelctrl_kernel_filter_gbuffer_f(u32 v)
+{
+   return (v & 0x1) << 2;
+}
+#define HOST1X_CHANNEL_CHANNELCTRL_KERNEL_FILTER_GBUFFER(v) \
+   host1x_channel_channelctrl_kernel_filter_gbuffer_f(v)
 
 #endif
-- 
2.14.1

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

[PATCH v3 6/6] drm/tegra: Use u64_to_user_ptr helper

Use the u64_to_user_ptr helper macro to cast IOCTL argument u64 values
to user pointers instead of writing out the cast manually. Also do
some other cleanup with user pointers to make them stand out more
and look cleaner.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/drm.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 130d193192ee..943bdf88c4a2 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -386,12 +386,10 @@ int tegra_drm_submit(struct tegra_drm_context *context,
unsigned int num_cmdbufs = args->num_cmdbufs;
unsigned int num_relocs = args->num_relocs;
unsigned int num_waitchks = args->num_waitchks;
-   struct drm_tegra_cmdbuf __user *cmdbufs =
-   (void __user *)(uintptr_t)args->cmdbufs;
-   struct drm_tegra_reloc __user *relocs =
-   (void __user *)(uintptr_t)args->relocs;
-   struct drm_tegra_waitchk __user *waitchks =
-   (void __user *)(uintptr_t)args->waitchks;
+   struct drm_tegra_cmdbuf __user *user_cmdbufs;
+   struct drm_tegra_reloc __user *user_relocs;
+   struct drm_tegra_waitchk __user *user_waitchks;
+   struct drm_tegra_syncpt __user *user_syncpt;
struct drm_tegra_syncpt syncpt;
struct host1x *host1x = dev_get_drvdata(drm->dev->parent);
struct drm_gem_object **refs;
@@ -400,6 +398,11 @@ int tegra_drm_submit(struct tegra_drm_context *context,
unsigned int num_refs;
int err;
 
+   user_cmdbufs = u64_to_user_ptr(args->cmdbufs);
+   user_relocs = u64_to_user_ptr(args->relocs);
+   user_waitchks = u64_to_user_ptr(args->waitchks);
+   user_syncpt = u64_to_user_ptr(args->syncpts);
+
/* We don't yet support other than one syncpt_incr struct per submit */
if (args->num_syncpts != 1)
return -EINVAL;
@@ -440,7 +443,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
struct tegra_bo *obj;
u64 offset;
 
-   if (copy_from_user(&cmdbuf, cmdbufs, sizeof(cmdbuf))) {
+   if (copy_from_user(&cmdbuf, user_cmdbufs, sizeof(cmdbuf))) {
err = -EFAULT;
goto fail;
}
@@ -476,7 +479,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 
host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
num_cmdbufs--;
-   cmdbufs++;
+   user_cmdbufs++;
}
 
/* copy and resolve relocations from submit */
@@ -485,7 +488,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
struct tegra_bo *obj;
 
err = host1x_reloc_copy_from_user(&job->relocarray[num_relocs],
- &relocs[num_relocs], drm,
+ &user_relocs[num_relocs], drm,
  file);
if (err < 0)
goto fail;
@@ -519,9 +522,8 @@ int tegra_drm_submit(struct tegra_drm_context *context,
struct host1x_waitchk *wait = &job->waitchk[num_waitchks];
struct tegra_bo *obj;
 
-   err = host1x_waitchk_copy_from_user(wait,
-   &waitchks[num_waitchks],
-   file);
+   err = host1x_waitchk_copy_from_user(
+   wait, &user_waitchks[num_waitchks], file);
if (err < 0)
goto fail;
 
@@ -539,8 +541,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
}
}
 
-   if (copy_from_user(&syncpt, (void __user *)(uintptr_t)args->syncpts,
-  sizeof(syncpt))) {
+   if (copy_from_user(&syncpt, user_syncpt, sizeof(syncpt))) {
err = -EFAULT;
goto fail;
}
-- 
2.14.1

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

[PATCH v3 3/6] gpu: host1x: Improve debug disassembly formatting

The host1x driver prints out "disassembly" dumps of the command FIFO
and gather contents on submission timeouts. However, the output has
been quite difficult to read with unnecessary newlines and occasional
missing parentheses.

Fix these problems by using pr_cont to remove unnecessary newlines
and by fixing other small issues.

Signed-off-by: Mikko Perttunen 
Reviewed-by: Dmitry Osipenko 
Tested-by: Dmitry Osipenko 
---
 drivers/gpu/host1x/debug.c| 14 ++-
 drivers/gpu/host1x/debug.h| 14 ---
 drivers/gpu/host1x/hw/debug_hw.c  | 46 ++-
 drivers/gpu/host1x/hw/debug_hw_1x01.c |  8 +++---
 drivers/gpu/host1x/hw/debug_hw_1x06.c |  9 ---
 5 files changed, 61 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
index 2aae0e63214c..dc77ec452ffc 100644
--- a/drivers/gpu/host1x/debug.c
+++ b/drivers/gpu/host1x/debug.c
@@ -40,7 +40,19 @@ void host1x_debug_output(struct output *o, const char *fmt, 
...)
len = vsnprintf(o->buf, sizeof(o->buf), fmt, args);
va_end(args);
 
-   o->fn(o->ctx, o->buf, len);
+   o->fn(o->ctx, o->buf, len, false);
+}
+
+void host1x_debug_cont(struct output *o, const char *fmt, ...)
+{
+   va_list args;
+   int len;
+
+   va_start(args, fmt);
+   len = vsnprintf(o->buf, sizeof(o->buf), fmt, args);
+   va_end(args);
+
+   o->fn(o->ctx, o->buf, len, true);
 }
 
 static int show_channel(struct host1x_channel *ch, void *data, bool show_fifo)
diff --git a/drivers/gpu/host1x/debug.h b/drivers/gpu/host1x/debug.h
index 4595b2e0799f..990cce47e737 100644
--- a/drivers/gpu/host1x/debug.h
+++ b/drivers/gpu/host1x/debug.h
@@ -24,22 +24,28 @@
 struct host1x;
 
 struct output {
-   void (*fn)(void *ctx, const char *str, size_t len);
+   void (*fn)(void *ctx, const char *str, size_t len, bool cont);
void *ctx;
char buf[256];
 };
 
-static inline void write_to_seqfile(void *ctx, const char *str, size_t len)
+static inline void write_to_seqfile(void *ctx, const char *str, size_t len,
+   bool cont)
 {
seq_write((struct seq_file *)ctx, str, len);
 }
 
-static inline void write_to_printk(void *ctx, const char *str, size_t len)
+static inline void write_to_printk(void *ctx, const char *str, size_t len,
+  bool cont)
 {
-   pr_info("%s", str);
+   if (cont)
+   pr_cont("%s", str);
+   else
+   pr_info("%s", str);
 }
 
 void __printf(2, 3) host1x_debug_output(struct output *o, const char *fmt, 
...);
+void __printf(2, 3) host1x_debug_cont(struct output *o, const char *fmt, ...);
 
 extern unsigned int host1x_debug_trace_cmdbuf;
 
diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c
index 770d92e62d69..1e67667e308c 100644
--- a/drivers/gpu/host1x/hw/debug_hw.c
+++ b/drivers/gpu/host1x/hw/debug_hw.c
@@ -40,48 +40,59 @@ enum {
 
 static unsigned int show_channel_command(struct output *o, u32 val)
 {
-   unsigned int mask, subop;
+   unsigned int mask, subop, num;
 
switch (val >> 28) {
case HOST1X_OPCODE_SETCLASS:
mask = val & 0x3f;
if (mask) {
-   host1x_debug_output(o, "SETCL(class=%03x, offset=%03x, 
mask=%02x, [",
+   host1x_debug_cont(o, "SETCL(class=%03x, offset=%03x, 
mask=%02x, [",
val >> 6 & 0x3ff,
val >> 16 & 0xfff, mask);
return hweight8(mask);
}
 
-   host1x_debug_output(o, "SETCL(class=%03x)\n", val >> 6 & 0x3ff);
+   host1x_debug_cont(o, "SETCL(class=%03x)\n", val >> 6 & 0x3ff);
return 0;
 
case HOST1X_OPCODE_INCR:
-   host1x_debug_output(o, "INCR(offset=%03x, [",
+   num = val & 0x;
+   host1x_debug_cont(o, "INCR(offset=%03x, [",
val >> 16 & 0xfff);
-   return val & 0x;
+   if (!num)
+   host1x_debug_cont(o, "])\n");
+
+   return num;
 
case HOST1X_OPCODE_NONINCR:
-   host1x_debug_output(o, "NONINCR(offset=%03x, [",
+   num = val & 0x;
+   host1x_debug_cont(o, "NONINCR(offset=%03x, [",
val >> 16 & 0xfff);
-   return val & 0x;
+   if (!num)
+   host1x_debug_cont(o, "])\n");
+
+   return num;
 
case HOST1X_OPCODE_MASK:
mask = val & 0x;
-   host1x_debug_output(o, "MASK(offset=%03x, mask=%03x, [",
+   host1x_debug_cont(o, "MASK(offset=%03x, mask=%03x, [",
val >> 16 & 0xfff, mask);
+   if (!mask)
+   host1x_debug_cont(o,

[PATCH v3 0/6] Miscellaneous improvements to Host1x and TegraDRM

New in v3:
- Renamed *syncpt_assign_channel to *syncpt_assign_to_channel
- Disassembler ignores opcodes not supported on the particular
  chip
- Further cleanup in u64_to_user_ptr patch

New in v2:
- Changes in syncpoint protection and u64_to_user_ptr patches.
  See the patches for notes.
- Added patch to support more opcodes in the debug dump
  disassembly.
- Added patch to fix an incorrect comment.

Thanks,
Mikko

Patch v1 notes:

Hi all,

here are some new features and improvements.

Patch 1 enables syncpoint protection which prevents channels from
touching syncpoints not belonging to them on Tegra186.

Patch 2 enables the gather filter which prevents userspace command
buffers from using CDMA commands usually reserved for the kernel.
A test is available at git://github.com/cyndis/host1x_test, branch
gather-filter.

Patch 3 greatly improves formatting of debug dumps spewed by host1x
in case of job timeouts. They are now actually readable by humans
without use of additional scripts.

Patch 4 is a simple aesthetical fix to the TegraDRM submit path.

Everything was tested on TX1 and TX2 and should be applied on the
previously posted Tegra186 support series.

Cheers,
Mikko


Mikko Perttunen (6):
  gpu: host1x: Enable Tegra186 syncpoint protection
  gpu: host1x: Enable gather filter
  gpu: host1x: Improve debug disassembly formatting
  gpu: host1x: Disassemble more instructions
  gpu: host1x: Fix incorrect comment for channel_request
  drm/tegra: Use u64_to_user_ptr helper

 drivers/gpu/drm/tegra/drm.c |  29 
 drivers/gpu/host1x/channel.c|   3 +-
 drivers/gpu/host1x/debug.c  |  14 +++-
 drivers/gpu/host1x/debug.h  |  14 ++--
 drivers/gpu/host1x/dev.h|  15 
 drivers/gpu/host1x/hw/channel_hw.c  |  25 +++
 drivers/gpu/host1x/hw/debug_hw.c| 103 ++--
 drivers/gpu/host1x/hw/debug_hw_1x01.c   |  10 +--
 drivers/gpu/host1x/hw/debug_hw_1x06.c   |  12 ++--
 drivers/gpu/host1x/hw/hw_host1x04_channel.h |  12 
 drivers/gpu/host1x/hw/hw_host1x05_channel.h |  12 
 drivers/gpu/host1x/hw/syncpt_hw.c   |  46 +
 drivers/gpu/host1x/syncpt.c |   8 +++
 13 files changed, 252 insertions(+), 51 deletions(-)

-- 
2.14.1

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

[PATCH v3 4/6] gpu: host1x: Disassemble more instructions

The disassembler for debug dumps was missing some newer host1x opcodes.
Add disassembly support for these.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/hw/debug_hw.c  | 59 ---
 drivers/gpu/host1x/hw/debug_hw_1x01.c |  2 +-
 drivers/gpu/host1x/hw/debug_hw_1x06.c |  3 +-
 3 files changed, 58 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c
index 1e67667e308c..989476801f9d 100644
--- a/drivers/gpu/host1x/hw/debug_hw.c
+++ b/drivers/gpu/host1x/hw/debug_hw.c
@@ -30,6 +30,13 @@ enum {
HOST1X_OPCODE_IMM   = 0x04,
HOST1X_OPCODE_RESTART   = 0x05,
HOST1X_OPCODE_GATHER= 0x06,
+   HOST1X_OPCODE_SETSTRMID = 0x07,
+   HOST1X_OPCODE_SETAPPID  = 0x08,
+   HOST1X_OPCODE_SETPYLD   = 0x09,
+   HOST1X_OPCODE_INCR_W= 0x0a,
+   HOST1X_OPCODE_NONINCR_W = 0x0b,
+   HOST1X_OPCODE_GATHER_W  = 0x0c,
+   HOST1X_OPCODE_RESTART_W = 0x0d,
HOST1X_OPCODE_EXTEND= 0x0e,
 };
 
@@ -38,11 +45,16 @@ enum {
HOST1X_OPCODE_EXTEND_RELEASE_MLOCK  = 0x01,
 };
 
-static unsigned int show_channel_command(struct output *o, u32 val)
+#define INVALID_PAYLOAD0x
+
+static unsigned int show_channel_command(struct output *o, u32 val,
+u32 *payload)
 {
-   unsigned int mask, subop, num;
+   unsigned int mask, subop, num, opcode;
+
+   opcode = val >> 28;
 
-   switch (val >> 28) {
+   switch (opcode) {
case HOST1X_OPCODE_SETCLASS:
mask = val & 0x3f;
if (mask) {
@@ -97,6 +109,44 @@ static unsigned int show_channel_command(struct output *o, 
u32 val)
val >> 14 & 0x1, val & 0x3fff);
return 1;
 
+#if HOST1X_HW >= 6
+   case HOST1X_OPCODE_SETSTRMID:
+   host1x_debug_cont(o, "SETSTRMID(offset=%06x)\n",
+ val & 0x3f);
+   return 0;
+
+   case HOST1X_OPCODE_SETAPPID:
+   host1x_debug_cont(o, "SETAPPID(appid=%02x)\n", val & 0xff);
+   return 0;
+
+   case HOST1X_OPCODE_SETPYLD:
+   *payload = val & 0x;
+   host1x_debug_cont(o, "SETPYLD(data=%04x)\n", *payload);
+   return 0;
+
+   case HOST1X_OPCODE_INCR_W:
+   case HOST1X_OPCODE_NONINCR_W:
+   host1x_debug_cont(o, "%s(offset=%06x, ",
+ opcode == HOST1X_OPCODE_INCR_W ?
+   "INCR_W" : "NONINCR_W",
+ val & 0x3f);
+   if (*payload == 0) {
+   host1x_debug_cont(o, "[])\n");
+   return 0;
+   } else if (*payload == INVALID_PAYLOAD) {
+   host1x_debug_cont(o, "unknown)\n");
+   return 0;
+   } else {
+   host1x_debug_cont(o, "[");
+   return *payload;
+   }
+
+   case HOST1X_OPCODE_GATHER_W:
+   host1x_debug_cont(o, "GATHER_W(count=%04x, addr=[",
+ val & 0x3fff);
+   return 2;
+#endif
+
case HOST1X_OPCODE_EXTEND:
subop = val >> 24 & 0xf;
if (subop == HOST1X_OPCODE_EXTEND_ACQUIRE_MLOCK)
@@ -122,6 +172,7 @@ static void show_gather(struct output *o, phys_addr_t 
phys_addr,
/* Map dmaget cursor to corresponding mem handle */
u32 offset = phys_addr - pin_addr;
unsigned int data_count = 0, i;
+   u32 payload = INVALID_PAYLOAD;
 
/*
 * Sometimes we're given different hardware address to the same
@@ -139,7 +190,7 @@ static void show_gather(struct output *o, phys_addr_t 
phys_addr,
 
if (!data_count) {
host1x_debug_output(o, "%08x: %08x: ", addr, val);
-   data_count = show_channel_command(o, val);
+   data_count = show_channel_command(o, val, &payload);
} else {
host1x_debug_cont(o, "%08x%s", val,
data_count > 1 ? ", " : "])\n");
diff --git a/drivers/gpu/host1x/hw/debug_hw_1x01.c 
b/drivers/gpu/host1x/hw/debug_hw_1x01.c
index 09e1aa7bb5dd..8790d5fd5f20 100644
--- a/drivers/gpu/host1x/hw/debug_hw_1x01.c
+++ b/drivers/gpu/host1x/hw/debug_hw_1x01.c
@@ -112,7 +112,7 @@ static void host1x_debug_show_channel_fifo(struct host1x 
*host,
 
if (!data_count) {
host1x_debug_output(o, "%08x: ", val);
-   data_count = show_channel_command(o, val);
+   data_count = show_channel_command(o, val, NULL);
} else {
host1x_debug_cont(o, "%08x%s", val,
  data_count > 1 ? ", " : "])\n");
diff -

[PATCH v3 1/6] gpu: host1x: Enable Tegra186 syncpoint protection

Since Tegra186 the Host1x hardware allows syncpoints to be assigned to
specific channels, preventing any other channels from incrementing
them.

Enable this feature where available and assign syncpoints to channels
when submitting a job. Syncpoints are currently never unassigned from
channels since that would require extra work and is unnecessary with
the current channel allocation model.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/dev.h   | 15 +
 drivers/gpu/host1x/hw/channel_hw.c |  3 +++
 drivers/gpu/host1x/hw/syncpt_hw.c  | 46 ++
 drivers/gpu/host1x/syncpt.c|  8 +++
 4 files changed, 72 insertions(+)

diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index def802c0a6bf..502769726480 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -79,6 +79,9 @@ struct host1x_syncpt_ops {
u32 (*load)(struct host1x_syncpt *syncpt);
int (*cpu_incr)(struct host1x_syncpt *syncpt);
int (*patch_wait)(struct host1x_syncpt *syncpt, void *patch_addr);
+   void (*assign_to_channel)(struct host1x_syncpt *syncpt,
+ struct host1x_channel *channel);
+   void (*enable_protection)(struct host1x *host);
 };
 
 struct host1x_intr_ops {
@@ -186,6 +189,18 @@ static inline int host1x_hw_syncpt_patch_wait(struct 
host1x *host,
return host->syncpt_op->patch_wait(sp, patch_addr);
 }
 
+static inline void host1x_hw_syncpt_assign_to_channel(
+   struct host1x *host, struct host1x_syncpt *sp,
+   struct host1x_channel *ch)
+{
+   return host->syncpt_op->assign_to_channel(sp, ch);
+}
+
+static inline void host1x_hw_syncpt_enable_protection(struct host1x *host)
+{
+   return host->syncpt_op->enable_protection(host);
+}
+
 static inline int host1x_hw_intr_init_host_sync(struct host1x *host, u32 cpm,
void (*syncpt_thresh_work)(struct work_struct *))
 {
diff --git a/drivers/gpu/host1x/hw/channel_hw.c 
b/drivers/gpu/host1x/hw/channel_hw.c
index 8447a56c41ca..b929d7f1e291 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -147,6 +147,9 @@ static int channel_submit(struct host1x_job *job)
 
syncval = host1x_syncpt_incr_max(sp, user_syncpt_incrs);
 
+   /* assign syncpoint to channel */
+   host1x_hw_syncpt_assign_to_channel(host, sp, ch);
+
job->syncpt_end = syncval;
 
/* add a setclass for modules that require it */
diff --git a/drivers/gpu/host1x/hw/syncpt_hw.c 
b/drivers/gpu/host1x/hw/syncpt_hw.c
index 7b0270d60742..7dfd47d74f89 100644
--- a/drivers/gpu/host1x/hw/syncpt_hw.c
+++ b/drivers/gpu/host1x/hw/syncpt_hw.c
@@ -106,6 +106,50 @@ static int syncpt_patch_wait(struct host1x_syncpt *sp, 
void *patch_addr)
return 0;
 }
 
+/**
+ * syncpt_assign_to_channel() - Assign syncpoint to channel
+ * @sp: syncpoint
+ * @ch: channel
+ *
+ * On chips with the syncpoint protection feature (Tegra186+), assign @sp to
+ * @ch, preventing other channels from incrementing the syncpoints. If @ch is
+ * NULL, unassigns the syncpoint.
+ *
+ * On older chips, do nothing.
+ */
+static void syncpt_assign_to_channel(struct host1x_syncpt *sp,
+ struct host1x_channel *ch)
+{
+#if HOST1X_HW >= 6
+   struct host1x *host = sp->host;
+
+   if (!host->hv_regs)
+   return;
+
+   host1x_sync_writel(host,
+  HOST1X_SYNC_SYNCPT_CH_APP_CH(ch ? ch->id : 0xff),
+  HOST1X_SYNC_SYNCPT_CH_APP(sp->id));
+#endif
+}
+
+/**
+ * syncpt_enable_protection() - Enable syncpoint protection
+ * @host: host1x instance
+ *
+ * On chips with the syncpoint protection feature (Tegra186+), enable this
+ * feature. On older chips, do nothing.
+ */
+static void syncpt_enable_protection(struct host1x *host)
+{
+#if HOST1X_HW >= 6
+   if (!host->hv_regs)
+   return;
+
+   host1x_hypervisor_writel(host, HOST1X_HV_SYNCPT_PROT_EN_CH_EN,
+HOST1X_HV_SYNCPT_PROT_EN);
+#endif
+}
+
 static const struct host1x_syncpt_ops host1x_syncpt_ops = {
.restore = syncpt_restore,
.restore_wait_base = syncpt_restore_wait_base,
@@ -113,4 +157,6 @@ static const struct host1x_syncpt_ops host1x_syncpt_ops = {
.load = syncpt_load,
.cpu_incr = syncpt_cpu_incr,
.patch_wait = syncpt_patch_wait,
+   .assign_to_channel = syncpt_assign_to_channel,
+   .enable_protection = syncpt_enable_protection,
 };
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index 048ac9e344ce..bce7cd6db724 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -398,6 +398,13 @@ int host1x_syncpt_init(struct host1x *host)
for (i = 0; i < host->info->nb_pts; i++) {
syncpt[i].id = i;
syncpt[i].host = host;
+
+   /*
+* Unassign syncpt from channels for pu

[PATCH v3 5/6] gpu: host1x: Fix incorrect comment for channel_request

This function actually doesn't sleep in the version that was merged.

Signed-off-by: Mikko Perttunen 
Reviewed-by: Dmitry Osipenko 
---
 drivers/gpu/host1x/channel.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/host1x/channel.c b/drivers/gpu/host1x/channel.c
index db9b91d1384c..2fb93c27c1d9 100644
--- a/drivers/gpu/host1x/channel.c
+++ b/drivers/gpu/host1x/channel.c
@@ -128,8 +128,7 @@ static struct host1x_channel *acquire_unused_channel(struct 
host1x *host)
  * host1x_channel_request() - Allocate a channel
  * @device: Host1x unit this channel will be used to send commands to
  *
- * Allocates a new host1x channel for @device. If there are no free channels,
- * this will sleep until one becomes available. May return NULL if CDMA
+ * Allocates a new host1x channel for @device. May return NULL if CDMA
  * initialization fails.
  */
 struct host1x_channel *host1x_channel_request(struct device *dev)
-- 
2.14.1

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

[Bug 92248] [KBL/SKL/BYT/BXT/GLK] igt/kms_plane_scaling fail

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

--- Comment #42 from Hector Velazquez 
 ---
This test is still failing on GLK QA

Tests List:

igt@kms_plane_scaling



Output

. . .


This is my configuration:

==
Graphic stack
==
Component: drm
tag: libdrm-2.4.81-56-g7c71188
commit: 7c71188610b4ceba0339c2bc884320bcb749adee

Component: cairo
tag: 1.15.6-42-gdccbed7
commit: dccbed7d78d32bd3b912e8810379451dd94e6a1f

Component: intel-gpu-tools
tag: intel-gpu-tools-1.19-332-g0a91a5e
commit: 0a91a5e9624d41d23b79e2540eda111cb56d42d9

Component: piglit
tag: piglit-v1
commit: 95e2f51a28b6cf7ff77d84e1234121c98f10ef64

==
 Software
==
kernel version  : 4.14.0-rc2-drm-tip-ww39-commit-d76cbbc+
hostname: GLK-2-GLKRVP1DDR405
architecture: x86_64
os version  : Ubuntu 16.10
os codename : yakkety
kernel driver   : i915
bios revision   : 62.30
bios release date   : 08/22/2017
ksc : 1.41
hardware acceleration   : disabled
swap partition  : enabled on (/dev/sda3)

==
Graphic drivers
==
grep: /opt/X11R7/var/log/Xorg.0.log: No such file or directory
libdrm  : 2.4.83
cairo   : 1.15.9
intel-gpu-tools (tag)   : intel-gpu-tools-1.19-332-g0a91a5e
intel-gpu-tools (commit): 0a91a5e

==
 Hardware
==
. . .

==
 Firmware
==
dmc fw loaded : yes
dmc version   : 1.4
guc fw loaded : SUCCESS
guc version wanted: 10.56
guc version found : 10.56
huc fw loaded : yes

==
 kernel parameters
==
quiet drm.debug=0xe pci=pcie_bus_safe i915.alpha_support=1
i915.enable_guc_loading=2 i915.enable_guc_submission=2 intel_iommu=igfx_off
auto panic=1 nmi_watchdog=panic resume=/dev/sda3 fastboot

-- 
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

[drm:amdgpu-non-dc-cleanups 3/13] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:127:9: error: initialization from incompatible pointer type

2017-09-28 Thread kbuild test robot

tree:   git://people.freedesktop.org/~airlied/linux.git amdgpu-non-dc-cleanups
head:   1560fe3a3f2d9c13d1f91675468d3b71b2a8e811
commit: 754270c7c56292e97d0eff924a5d5d83f92add07 [3/13] Merge branch 
'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux into drm-next
config: x86_64-randconfig-ws0-09281411 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 754270c7c56292e97d0eff924a5d5d83f92add07
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the drm/amdgpu-non-dc-cleanups HEAD 
1560fe3a3f2d9c13d1f91675468d3b71b2a8e811 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from 
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/pp_debug.h:33,
from 
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:24:
   include/linux/stddef.h:7:14: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
#define NULL ((void *)0)
 ^
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:127:3: note: in 
expansion of macro 'NULL'
 {NULL, phm_thermal_l2h_irq},
  ^~~~
   include/linux/stddef.h:7:14: note: (near initialization for 
'thermal_irq_src[0]')
#define NULL ((void *)0)
 ^
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:127:3: note: in 
expansion of macro 'NULL'
 {NULL, phm_thermal_l2h_irq},
  ^~~~
   include/linux/stddef.h:7:14: error: invalid initializer
#define NULL ((void *)0)
 ^
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:127:3: note: in 
expansion of macro 'NULL'
 {NULL, phm_thermal_l2h_irq},
  ^~~~
   include/linux/stddef.h:7:14: note: (near initialization for 
'thermal_irq_src[0].')
#define NULL ((void *)0)
 ^
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:127:3: note: in 
expansion of macro 'NULL'
 {NULL, phm_thermal_l2h_irq},
  ^~~~
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:127:9: error: 
positional initialization of field in 'struct' declared with 'designated_init' 
attribute [-Werror=designated-init]
 {NULL, phm_thermal_l2h_irq},
^~~
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:127:9: note: (near 
initialization for 'thermal_irq_src[0]')
>> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:127:9: error: 
>> initialization from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:127:9: note: (near 
initialization for 'thermal_irq_src[0].set')
   In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from 
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/pp_debug.h:33,
from 
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:24:
   include/linux/stddef.h:7:14: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
#define NULL ((void *)0)
 ^
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:128:3: note: in 
expansion of macro 'NULL'
 {NULL, phm_thermal_h2l_irq},
  ^~~~
   include/linux/stddef.h:7:14: note: (near initialization for 
'thermal_irq_src[1]')
#define NULL ((void *)0)
 ^
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:128:3: note: in 
expansion of macro 'NULL'
 {NULL, phm_thermal_h2l_irq},
  ^~~~
   include/linux/stddef.h:7:14: error: invalid initializer
#define NULL ((void *)0)
 ^
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:128:3: note: in 
expansion of macro 'NULL'
 {NULL, phm_thermal_h2l_irq},
  ^~~~
   include/linux/stddef.h:7:14: note: (near initialization for 
'thermal_irq_src[1].')
#define NULL ((void *)0)
 ^
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:128:3: note: in 
expansion of macro 'NULL'
 {NULL, phm_thermal_h2l_irq},
  ^~~~
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:128:9: error: 
positional initialization of field in 'struct' declared with 'designated_init' 
attribute [-Werror=designated-init]
 {NULL, phm_thermal_h2l_irq},
^~~
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:128:9: note: (near 
initialization for 'thermal_irq_src[1]')
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:128:9: error: 
initialization from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:128:9: note: (near 
initialization for 'thermal_irq_sr

Re: [PATCH hwc v1] drm_hwcomposer: Add CONTRIBUTING file

2017-09-28 Thread Eric Engestrom

On Wednesday, 2017-09-27 18:55:49 +, Robert Foss wrote:
> > > +- When submitting new code please follow the naming conventions
> > > documented
> > > +  in the generated documentation. Also please make full use of all
> > > the helpers and
> > > +  convenience macros provided by drm_hwcomposer. The below command
> > > can help you
> > > +  with formatting of your patches:
> > > +  git diff | clang-format-diff-3.5 -p 1 -style=file
> > > +
> > 
> > One could wire that in the pre-merge hook on the server side.
> > It should be quite lightweight, although I'm not sure about the
> > integration with FDO's Debian(?) setup ;-)
> 
> Yeah, me neither. Maybe asking Daniel Stone about how this should be
> done is the next step.
> 

The package `clang-format-3.5` would need to be installed, but other than
that the integration would be rather trivial; just add this to the
`update` hook:

  format_diff=$(git diff -U0 $oldrev..$newrev | clang-format-diff-3.5 -p1)
  if [ -n "$format_diff" ]; then
echo 'Code is not formatted properly; please apply this change and try 
again:'
printf -- '8<\n%s\n>8\n' "$format_diff"
exit 1
  fi

Note that if malformatted commits are to be rejected, it might be best
to have a pre-commit hook on each client (will need manual setup on each
clone) to re-format the code before being committed and therefore before
being sent to ML, to avoid patchwork losing track of reformatted patches.

Alternatively, such patches could be accepted with just a warning being
printed when pushing, but there's a good chance such warnings would just
end up being ignored.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-fixes

2017-09-28 Thread Sean Paul

Hi Dave,
Here's the latest from -misc-fixes. It's been a while since the last one due to
plumbers and XDC. I'll be out of office next week, but will do my best to send
-fixes amongst moving boxes and chaos.

drm-misc-fixes-2017-09-28-1:
Driver Changes:
- qxl: fix primary surface and fb unpinning (Gerd)
- sun41: fix CEC_PIN config gate now that media has been merged (Hans)
- tegra: fix TRACE_INCLUDE_PATH (Thierry)

Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: Gerd Hoffmann 

Cheers, Sean

The following changes since commit 4a704d6db0ee4a349d5d523813a718e429b4914d:

  Merge tag 'kbuild-fixes-v4.14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild 
(2017-09-21 06:01:03 -1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-09-28-1

for you to fetch changes up to a98c75fcd0ec02623f4f56d824d76e659410a52b:

  drm/tegra: trace: Fix path to include (2017-09-26 11:08:17 +0200)


Driver Changes:
- qxl: fix primary surface and fb unpinning (Gerd)
- sun41: fix CEC_PIN config gate now that media has been merged (Hans)
- tegra: fix TRACE_INCLUDE_PATH (Thierry)

Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: Gerd Hoffmann 


Gerd Hoffmann (2):
  qxl: fix primary surface handling
  qxl: fix framebuffer unpinning

Hans Verkuil (1):
  drm/sun4i: cec: Enable back CEC-pin framework

Sean Paul (1):
  Merge remote-tracking branch 'origin/master' into drm-misc-fixes

Thierry Reding (1):
  drm/tegra: trace: Fix path to include

 drivers/gpu/drm/qxl/qxl_display.c  | 41 +-
 drivers/gpu/drm/sun4i/Kconfig  |  2 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |  2 +-
 drivers/gpu/drm/tegra/trace.h  |  2 +-
 4 files changed, 26 insertions(+), 21 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH][drm-next] drm/amd/powerplay: fix spelling mistake: "dividable" -> "divisible"

2017-09-28 Thread Colin King

From: Colin Ian King 

Trivial fix to spelling mistakes in pr_err error message and ASSERT
messages.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c | 2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c | 2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c
index fcf88b8fc738..9d1086894d2b 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smc.c
@@ -2332,7 +2332,7 @@ static int ci_load_smc_ucode(struct pp_hwmgr *hwmgr)
PHM_WRITE_FIELD(hwmgr->device, SMC_IND_ACCESS_CNTL, 
AUTO_INCREMENT_IND_0, 0);
 
if (0 != byte_count) {
-   pr_err("SMC size must be dividable by 4\n");
+   pr_err("SMC size must be divisible by 4\n");
return -EINVAL;
}
 
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
index 78aa1122eacc..a778e174ba01 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c
@@ -108,7 +108,7 @@ static int iceland_upload_smc_firmware_data(struct pp_hwmgr 
*hwmgr,
 
PHM_WRITE_FIELD(hwmgr->device, SMC_IND_ACCESS_CNTL, 
AUTO_INCREMENT_IND_0, 0);
 
-   PP_ASSERT_WITH_CODE((0 == byte_count), "SMC size must be dividable by 
4.", return -EINVAL);
+   PP_ASSERT_WITH_CODE((0 == byte_count), "SMC size must be divisible by 
4.", return -EINVAL);
 
return 0;
 }
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
index 2ae05bbdb974..c997117f2461 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
@@ -513,7 +513,7 @@ static int smu7_upload_smc_firmware_data(struct pp_hwmgr 
*hwmgr, uint32_t length
 
PHM_WRITE_FIELD(hwmgr->device, SMC_IND_ACCESS_CNTL, 
AUTO_INCREMENT_IND_11, 0);
 
-   PP_ASSERT_WITH_CODE((0 == byte_count), "SMC size must be dividable by 
4.", return -EINVAL);
+   PP_ASSERT_WITH_CODE((0 == byte_count), "SMC size must be divisible by 
4.", return -EINVAL);
 
return 0;
 }
-- 
2.14.1

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

Re: [PATCH] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

On Thu, Sep 28, 2017 at 11:27 AM, Meghana Madhyastha
 wrote:
> On Thu, Sep 28, 2017 at 09:15:39AM +0200, Daniel Vetter wrote:
>> On Wed, Sep 27, 2017 at 05:08:07PM +0200, Noralf Trønnes wrote:
>> >
>> > Den 27.09.2017 15.54, skrev Meghana Madhyastha:
>> > > Rename tinydrm_of_find_backlight to drm_of_find_backlight
>> > > and move it into drm_of.c from tinydrm-helpers.c. This is
>> > > because other drivers in the drm subsystem might need to call
>> > > this function. In that case and otherwise, it is better from
>> > > an organizational point of view to move it into drm_of.c along
>> > > with the other _of.c functions.
>> > >
>> > > Signed-off-by: Meghana Madhyastha 
>> > > ---
>> >
>> > I suggest you split this patch in 2, one to add the function and one to
>> > use it in tinydrm.
>>
>> In general I'd agree to split into 3 phases: 1) add new function 2)
>> convert drivers 3) remove old one.
>>
>> But since there's only 1 caller this seems like overkill.
>>
>> > >   drivers/gpu/drm/drm_of.c   | 41 
>> > > ++
>> > >   drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 
>> > > -
>> > >   drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
>> > >   include/drm/drm_of.h   |  1 +
>> > >   include/drm/tinydrm/tinydrm-helpers.h  |  1 -
>> > >   5 files changed, 44 insertions(+), 42 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
>> > > index 8dafbdf..d8cded3 100644
>> > > --- a/drivers/gpu/drm/drm_of.c
>> > > +++ b/drivers/gpu/drm/drm_of.c
>> > > @@ -1,6 +1,7 @@
>> > >   #include 
>> > >   #include 
>> > >   #include 
>> > > +#include 
>> > >   #include 
>> > >   #include 
>> > >   #include 
>> > > @@ -260,3 +261,43 @@ int drm_of_find_panel_or_bridge(const struct 
>> > > device_node *np,
>> > >   return ret;
>> > >   }
>> > >   EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
>> > > +
>> > > +/**
>> > > + * drm_of_find_backlight - Find backlight device in device-tree
>> > > + * @dev: Device
>> > > + *
>> > > + * This function looks for a DT node pointed to by a property named 
>> > > 'backlight'
>> > > + * and uses of_find_backlight_by_node() to get the backlight device.
>> > > + * Additionally if the brightness property is zero, it is set to
>> > > + * max_brightness.
>> >
>> > Please add a note here about the callers responsibility to call
>> > put_device() when releasing the resource.
>> > See the of_find_backlight_by_node() docs.
>> >
>> > > + *
>> > > + * Returns:
>> > > + * NULL if there's no backlight property.
>> > > + * Error pointer -EPROBE_DEFER if the DT node is found, but no 
>> > > backlight device
>> > > + * is found.
>> > > + * If the backlight device is found, a pointer to the structure is 
>> > > returned.
>> > > + */
>> > > +struct backlight_device *drm_of_find_backlight(struct device *dev)
>> > > +{
>> > > + struct backlight_device *backlight;
>> > > + struct device_node *np;
>> > > +
>> > > + np = of_parse_phandle(dev->of_node, "backlight", 0);
>> > > + if (!np)
>> > > + return NULL;
>> > > +
>> > > + backlight = of_find_backlight_by_node(np);
>> > > + of_node_put(np);
>> > > +
>> > > + if (!backlight)
>> > > + return ERR_PTR(-EPROBE_DEFER);
>> > > +
>> > > + if (!backlight->props.brightness) {
>> > > + backlight->props.brightness = backlight->props.max_brightness;
>> > > + DRM_DEBUG_KMS("Backlight brightness set to %d\n",
>> > > +   backlight->props.brightness);
>> > > + }
>> > > +
>> > > + return backlight;
>> > > +}
>> > > +EXPORT_SYMBOL(drm_of_find_backlight);
>> >
>> > Can you also please add a devm_ version of this function. tinydrm uses
>> > devres[1] versions of functions for requiring device resources, so it
>> > would be nice to do this for backlight as well. tinydrm is currently
>> > broken in this respect, it doesn't put the backlight device.
>> >
>> > I had a devm_of_find_backlight() version lying around that I've adjusted
>> > to give you an idea of what I'm talking about:
>> >
>> > static void devm_drm_of_find_backlight_release(void *data)
>> > {
>> > put_device(data);
>> > }
>> >
>> > struct backlight_device *devm_drm_of_find_backlight(struct device *dev)
>> > {
>> > struct backlight_device *backlight;
>> > int ret;
>> >
>> > backlight = drm_of_find_backlight(dev);
>> > if (IS_ERR_OR_NULL(backlight))
>> > return backlight;
>> >
>> > ret = devm_add_action(dev, devm_drm_of_find_backlight_release,
>> >   backlight->dev);
>> > if (ret) {
>> > put_device(backlight->dev);
>> > return ERR_PTR(ret);
>> > }
>> >
>> > return backlight;
>> > }
>>
>> Good idea for a follow up patch imo.
>>
>> Another follow up patch series which would be really good is then
>> converting drivers over to using this (preferrably the devm_ version). A
>> quick git grep shows there's quite a few.
>
> I have a quick question on this

Re: [PATCH 2/3] drm: rcar-du: Reject planes located fully off-screen

On Thu, Sep 28, 2017 at 11:16 AM, Laurent Pinchart
 wrote:
> Hi Daniel,
>
> On Thursday, 28 September 2017 10:10:34 EEST Daniel Vetter wrote:
>> On Wed, Sep 27, 2017 at 07:58:42PM +0100, Kieran Bingham wrote:
>> > Hi Laurent,
>> >
>> > Thankyou for the patch,
>> >
>> > This looks good, and passes the tests.
>> >
>> > On 16/08/17 00:03, Laurent Pinchart wrote:
>> > > There is no point in accepting fully off-screen planes as they won't be
>> > > displayed. Reject them in the atomic check.
>> > >
>> > > Signed-off-by: Laurent Pinchart
>> > > 
>> >
>> > Reviewed-by: Kieran Bingham 
>>
>> Just a note, this is different from what i915 does. Not sure you want to
>> intentionally be incompatible with i915 and hence defacto make this part
>> of atomic undefined (or break some apps, depending upon how this pans
>> out). I think X loves to put the cursor offscreen at least.
>>
>> I think we even have igts to test this properly.
>
> If you update the documentation I'll submit a v2 that allows fully off-screen
> planes :-)

Quoting them:

"The destination rectangle can lie outside of the visible area of the
current mode of the CRTC."

This shit is better than I thought!

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

Now can I raise you one and challenge you to run the kms tests in igt
and see how non-compliant your driver is :-)

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

Re: [PATCH] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

On Thu, Sep 28, 2017 at 09:15:39AM +0200, Daniel Vetter wrote:
> On Wed, Sep 27, 2017 at 05:08:07PM +0200, Noralf Trønnes wrote:
> > 
> > Den 27.09.2017 15.54, skrev Meghana Madhyastha:
> > > Rename tinydrm_of_find_backlight to drm_of_find_backlight
> > > and move it into drm_of.c from tinydrm-helpers.c. This is
> > > because other drivers in the drm subsystem might need to call
> > > this function. In that case and otherwise, it is better from
> > > an organizational point of view to move it into drm_of.c along
> > > with the other _of.c functions.
> > > 
> > > Signed-off-by: Meghana Madhyastha 
> > > ---
> > 
> > I suggest you split this patch in 2, one to add the function and one to
> > use it in tinydrm.
> 
> In general I'd agree to split into 3 phases: 1) add new function 2)
> convert drivers 3) remove old one.
> 
> But since there's only 1 caller this seems like overkill.
> 
> > >   drivers/gpu/drm/drm_of.c   | 41 
> > > ++
> > >   drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 
> > > -
> > >   drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
> > >   include/drm/drm_of.h   |  1 +
> > >   include/drm/tinydrm/tinydrm-helpers.h  |  1 -
> > >   5 files changed, 44 insertions(+), 42 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> > > index 8dafbdf..d8cded3 100644
> > > --- a/drivers/gpu/drm/drm_of.c
> > > +++ b/drivers/gpu/drm/drm_of.c
> > > @@ -1,6 +1,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -260,3 +261,43 @@ int drm_of_find_panel_or_bridge(const struct 
> > > device_node *np,
> > >   return ret;
> > >   }
> > >   EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
> > > +
> > > +/**
> > > + * drm_of_find_backlight - Find backlight device in device-tree
> > > + * @dev: Device
> > > + *
> > > + * This function looks for a DT node pointed to by a property named 
> > > 'backlight'
> > > + * and uses of_find_backlight_by_node() to get the backlight device.
> > > + * Additionally if the brightness property is zero, it is set to
> > > + * max_brightness.
> > 
> > Please add a note here about the callers responsibility to call
> > put_device() when releasing the resource.
> > See the of_find_backlight_by_node() docs.
> > 
> > > + *
> > > + * Returns:
> > > + * NULL if there's no backlight property.
> > > + * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight 
> > > device
> > > + * is found.
> > > + * If the backlight device is found, a pointer to the structure is 
> > > returned.
> > > + */
> > > +struct backlight_device *drm_of_find_backlight(struct device *dev)
> > > +{
> > > + struct backlight_device *backlight;
> > > + struct device_node *np;
> > > +
> > > + np = of_parse_phandle(dev->of_node, "backlight", 0);
> > > + if (!np)
> > > + return NULL;
> > > +
> > > + backlight = of_find_backlight_by_node(np);
> > > + of_node_put(np);
> > > +
> > > + if (!backlight)
> > > + return ERR_PTR(-EPROBE_DEFER);
> > > +
> > > + if (!backlight->props.brightness) {
> > > + backlight->props.brightness = backlight->props.max_brightness;
> > > + DRM_DEBUG_KMS("Backlight brightness set to %d\n",
> > > +   backlight->props.brightness);
> > > + }
> > > +
> > > + return backlight;
> > > +}
> > > +EXPORT_SYMBOL(drm_of_find_backlight);
> > 
> > Can you also please add a devm_ version of this function. tinydrm uses
> > devres[1] versions of functions for requiring device resources, so it
> > would be nice to do this for backlight as well. tinydrm is currently
> > broken in this respect, it doesn't put the backlight device.
> > 
> > I had a devm_of_find_backlight() version lying around that I've adjusted
> > to give you an idea of what I'm talking about:
> > 
> > static void devm_drm_of_find_backlight_release(void *data)
> > {
> >     put_device(data);
> > }
> > 
> > struct backlight_device *devm_drm_of_find_backlight(struct device *dev)
> > {
> >     struct backlight_device *backlight;
> >     int ret;
> > 
> >     backlight = drm_of_find_backlight(dev);
> >     if (IS_ERR_OR_NULL(backlight))
> >         return backlight;
> > 
> >     ret = devm_add_action(dev, devm_drm_of_find_backlight_release,
> >               backlight->dev);
> >     if (ret) {
> >         put_device(backlight->dev);
> >         return ERR_PTR(ret);
> >     }
> > 
> >     return backlight;
> > }
> 
> Good idea for a follow up patch imo.
> 
> Another follow up patch series which would be really good is then
> converting drivers over to using this (preferrably the devm_ version). A
> quick git grep shows there's quite a few.

I have a quick question on this. I did a git grep and found that the
other drivers used the function of_find_backlight_by_node defined in
video/backlight. This seems to be doing a different thing (taking
struct d

Re: [PATCH v3 07/11] drm: omapdrm: Register omapdrm platform device in omapdss driver

2017-09-28 Thread Tomi Valkeinen

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 28/09/17 11:56, Laurent Pinchart wrote:

>> Was there a reason to create the omapdrm device in omap_dss_init (i.e.
>> module_init), instead of omapdss's probe? Now the omapdrm device is
>> always created even if there's no DSS device on the SoC.
> 
> Not really, no.
> 
> Do you think this requires a quick -stable fix ? I'm working on a patch 
> series 
> that will remove the omapdrm device completely.

With -stable, you mean 4.14? Afaics, the only downside is a small amount
of memory that's not used. It does behave differently than before, as
the now-removed platform code did only add the omapdrm device if there's
a dss device in the DT data. I don't think that really matters, though.

But still, maybe it's nice to fix for 4.14, as we're still only at -rc2.

We encountered this with TI kernel, which has DSS6 driver. The omapdrm
side is shared, but the dss side is different than with the current dss.
So, the dss6 driver needs to create omapdrm device, but old dss driver
already creates it...

We'll hack around it, as it's only an issue in a development kernel.

 Tomi

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

Re: [PATCH 2/3] drm: rcar-du: Reject planes located fully off-screen

2017-09-28 Thread Laurent Pinchart

Hi Daniel,

On Thursday, 28 September 2017 10:10:34 EEST Daniel Vetter wrote:
> On Wed, Sep 27, 2017 at 07:58:42PM +0100, Kieran Bingham wrote:
> > Hi Laurent,
> > 
> > Thankyou for the patch,
> > 
> > This looks good, and passes the tests.
> > 
> > On 16/08/17 00:03, Laurent Pinchart wrote:
> > > There is no point in accepting fully off-screen planes as they won't be
> > > displayed. Reject them in the atomic check.
> > > 
> > > Signed-off-by: Laurent Pinchart
> > > 
> > 
> > Reviewed-by: Kieran Bingham 
> 
> Just a note, this is different from what i915 does. Not sure you want to
> intentionally be incompatible with i915 and hence defacto make this part
> of atomic undefined (or break some apps, depending upon how this pans
> out). I think X loves to put the cursor offscreen at least.
> 
> I think we even have igts to test this properly.

If you update the documentation I'll submit a v2 that allows fully off-screen 
planes :-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH V5 23/25] drm/etnaviv: do not enable debug registers unconditionally

2017-09-28 Thread Christian Gmeiner

Hi Lucas,


2017-09-28 11:05 GMT+02:00 Lucas Stach :
> Am Sonntag, den 24.09.2017, 15:15 +0200 schrieb Christian Gmeiner:
>> Everytime etnaviv_gpu_update_clock(..) gets call it overwrittes
>> the the complete VIVS_HI_CLOCK_CONTROL register. Instead read
>> the register, change scaling value and write the new value.
>>
>> Signed-off-by: Christian Gmeiner 
>> ---
>>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> index cfe6c76d077e..10a6485a2401 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> @@ -421,8 +421,9 @@ static void etnaviv_gpu_update_clock(struct
>> etnaviv_gpu *gpu)
>>gpu->base_rate_shader >> gpu-
>> >freq_scale);
>>   } else {
>>   unsigned int fscale = 1 << (6 - gpu->freq_scale);
>> - u32 clock =
>> VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(fscale);
>> + u32 clock = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
>>
>> + clock |= VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(fscale);
>
> So now you keep the old FSCALE value and additionally set the new one.
> This needs to mask out the old value first.
>
> If you don't mind I'll fix this up while applying.
>

Yes please as I hope I do not need to send another round of the patches.

> Regards,
> Lucas
>>   etnaviv_gpu_load_clock(gpu, clock);
>>   }
>>  }

thanks
--
Christian Gmeiner, MSc

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

[PATCH v3 2/2] drm/tinydrm: Add devres versions of drm_of_find_backlight

Add devm_drm_of_find_backlight and the corresponding release
function because some drivers such as tinydrm use devres versions
of functions for requiring device resources.

Signed-off-by: Meghana Madhyastha 
---
Changes in v3:
-None

 drivers/gpu/drm/drm_of.c | 48 
 include/drm/drm_of.h |  2 ++
 2 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index d878d3a..238e8e5 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -304,3 +304,51 @@ struct backlight_device *drm_of_find_backlight(struct 
device *dev)
return backlight;
 }
 EXPORT_SYMBOL(drm_of_find_backlight);
+
+/**
+ * devm_drm_of_find_backlight_release - Release backlight device
+ * @dev: Device
+ *
+ * This is the release function corresponding to the 
devm_drm_of_find_backlight.
+ * Each devres entry is associated with a release function.
+ */
+static void devm_drm_of_find_backlight_release(void *data)
+{
+   put_device(data);
+}
+EXPORT_SYMBOL(devm_drm_of_find_backlight_release);
+
+/**
+ * devm_drm_of_find_backlight - Find backlight device in device-tree
+ * devres version of the function
+ * @dev: Device
+ *
+ * This is the devres version of the function drm_of_find_backlight.
+ * Some drivers such as tinydrm use devres versions of functions for
+ * requiring device resources.
+ *
+ * Returns:
+ * NULL if there's no backlight property.
+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
+ * is found.
+ * If the backlight device is found, a pointer to the structure is returned.
+ */
+struct backlight_device *devm_drm_of_find_backlight(struct device *dev)
+{
+   struct backlight_device *backlight;
+   int ret;
+
+   backlight = drm_of_find_backlight(dev);
+   if (IS_ERR_OR_NULL(backlight))
+   return backlight;
+
+   ret = devm_add_action(dev, devm_drm_of_find_backlight_release,
+ &backlight->dev);
+   if (ret) {
+   put_device(&backlight->dev);
+   return ERR_PTR(ret);
+   }
+
+   return backlight;
+}
+EXPORT_SYMBOL(devm_drm_of_find_backlight);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index e8fba5b..071fb3b 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -30,7 +30,9 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
struct drm_panel **panel,
struct drm_bridge **bridge);
 struct backlight_device *drm_of_find_backlight(struct device *dev);
+struct backlight_device *devm_drm_of_find_backlight(struct device *dev);
 #else
+static void devm_drm_of_find_backlight_release(void *data);
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
 {
-- 
2.7.4

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

[PATCH v3 1/2] drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c

Rename tinydrm_of_find_backlight to drm_of_find_backlight
and move it into drm_of.c from tinydrm-helpers.c. This is
because other drivers in the drm subsystem might need to call
this function. In that case and otherwise, it is better from
an organizational point of view to move it into drm_of.c along
with the other _of.c functions.

Signed-off-by: Meghana Madhyastha 
---
Changes in v3:
-Change it back to a single patch from two patches in v2

 drivers/gpu/drm/drm_of.c   | 44 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 ---
 drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
 include/drm/drm_of.h   |  1 +
 include/drm/tinydrm/tinydrm-helpers.h  |  1 -
 5 files changed, 47 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 8dafbdf..d878d3a 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -260,3 +261,46 @@ int drm_of_find_panel_or_bridge(const struct device_node 
*np,
return ret;
 }
 EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
+
+/**
+ * drm_of_find_backlight - Find backlight device in device-tree
+ * @dev: Device
+ *
+ * This function looks for a DT node pointed to by a property named 'backlight'
+ * and uses of_find_backlight_by_node() to get the backlight device.
+ * Additionally if the brightness property is zero, it is set to
+ * max_brightness.
+ *
+ * Note: It is the responsibility of the caller to call put_device() when
+ * releasing the resource.
+ *
+ * Returns:
+ * NULL if there's no backlight property.
+ * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
+ * is found.
+ * If the backlight device is found, a pointer to the structure is returned.
+ */
+struct backlight_device *drm_of_find_backlight(struct device *dev)
+{
+   struct backlight_device *backlight;
+   struct device_node *np;
+
+   np = of_parse_phandle(dev->of_node, "backlight", 0);
+   if (!np)
+   return NULL;
+
+   backlight = of_find_backlight_by_node(np);
+   of_node_put(np);
+
+   if (!backlight)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   if (!backlight->props.brightness) {
+   backlight->props.brightness = backlight->props.max_brightness;
+   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
+ backlight->props.brightness);
+   }
+
+   return backlight;
+}
+EXPORT_SYMBOL(drm_of_find_backlight);
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bd6cce0..cd4c6a5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -237,46 +237,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, 
struct drm_framebuffer *fb,
 EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
 
 /**
- * tinydrm_of_find_backlight - Find backlight device in device-tree
- * @dev: Device
- *
- * This function looks for a DT node pointed to by a property named 'backlight'
- * and uses of_find_backlight_by_node() to get the backlight device.
- * Additionally if the brightness property is zero, it is set to
- * max_brightness.
- *
- * Returns:
- * NULL if there's no backlight property.
- * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
- * is found.
- * If the backlight device is found, a pointer to the structure is returned.
- */
-struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
-{
-   struct backlight_device *backlight;
-   struct device_node *np;
-
-   np = of_parse_phandle(dev->of_node, "backlight", 0);
-   if (!np)
-   return NULL;
-
-   backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
-
-   if (!backlight)
-   return ERR_PTR(-EPROBE_DEFER);
-
-   if (!backlight->props.brightness) {
-   backlight->props.brightness = backlight->props.max_brightness;
-   DRM_DEBUG_KMS("Backlight brightness set to %d\n",
- backlight->props.brightness);
-   }
-
-   return backlight;
-}
-EXPORT_SYMBOL(tinydrm_of_find_backlight);
-
-/**
  * tinydrm_enable_backlight - Enable backlight helper
  * @backlight: Backlight device
  *
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 7e5bb7d..5e3d635 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -189,7 +190,7 @@ static int mi0283qt_probe(struct spi_device *spi)
if (IS_ERR(mipi->regulator))
return PTR_ERR(mipi->regulator);
 
-   mipi->backlight = tinydrm_of_find_backlight(dev);
+   mipi->backlight = drm_of_find_b

[PATCH v3 0/2] drm/tinydrm: drm_of_find_backlight helper

This patchset introduces some changes such as move
tinydrm_of_find_backlight to drm_of.c and rename it to
drm_of_find_backlight for better organizational structure.

Changes in v3:
-Changed it back to a single patch for the caller in mi0283qt.c
 and the removal and renaming of the helper function.

Meghana Madhyastha (2):
  drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c
  drm/tinydrm: Add devres versions of drm_of_find_backlight

 drivers/gpu/drm/drm_of.c   | 92 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 ---
 drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
 include/drm/drm_of.h   |  3 +
 include/drm/tinydrm/tinydrm-helpers.h  |  1 -
 5 files changed, 97 insertions(+), 42 deletions(-)

-- 
2.7.4

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

Re: [PATCH V5 23/25] drm/etnaviv: do not enable debug registers unconditionally

2017-09-28 Thread Lucas Stach

Am Sonntag, den 24.09.2017, 15:15 +0200 schrieb Christian Gmeiner:
> Everytime etnaviv_gpu_update_clock(..) gets call it overwrittes
> the the complete VIVS_HI_CLOCK_CONTROL register. Instead read
> the register, change scaling value and write the new value.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index cfe6c76d077e..10a6485a2401 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -421,8 +421,9 @@ static void etnaviv_gpu_update_clock(struct
> etnaviv_gpu *gpu)
>    gpu->base_rate_shader >> gpu-
> >freq_scale);
>   } else {
>   unsigned int fscale = 1 << (6 - gpu->freq_scale);
> - u32 clock =
> VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(fscale);
> + u32 clock = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
>  
> + clock |= VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(fscale);

So now you keep the old FSCALE value and additionally set the new one.
This needs to mask out the old value first.

If you don't mind I'll fix this up while applying.

Regards,
Lucas
>   etnaviv_gpu_load_clock(gpu, clock);
>   }
>  }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 07/11] drm: omapdrm: Register omapdrm platform device in omapdss driver

2017-09-28 Thread Laurent Pinchart

Hi Tomi,

On Thursday, 28 September 2017 11:03:32 EEST Tomi Valkeinen wrote:
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> On 11/08/17 16:49, Laurent Pinchart wrote:
> > The omapdrm platform device is a virtual device created for the sole
> > purpose of handling the omapdss/omapdrm driver split. It should
> > eventually be removed. As a first step to ease refactoring move its
> > registration from platform code to driver code.
> > 
> > The omapdrm driver name must be changed internally to avoid probing both
> > the device registered in platform code and the device registered in the
> > omapdss driver, as that would otherwise break bisection.
> > 
> > Signed-off-by: Laurent Pinchart 
> > Reviewed-by: Tomi Valkeinen 
> > ---
> > Changes since v1:
> > 
> > - Drop the CONFIG_DRM_OMAP conditional compilation
> > - Unregister the platform device at exit time
> > ---
> > 
> >  drivers/gpu/drm/omapdrm/dss/core.c | 15 +++
> >  drivers/gpu/drm/omapdrm/omap_drv.c |  2 +-
> >  2 files changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/omapdrm/dss/core.c
> > b/drivers/gpu/drm/omapdrm/dss/core.c index 4dabe32c7098..8678d8b4efce
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/core.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/core.c
> > @@ -22,6 +22,7 @@
> > 
> >  #define DSS_SUBSYS_NAME "CORE"
> > 
> > +#include 
> > 
> >  #include 
> >  #include 
> >  #include 
> > 
> > @@ -103,6 +104,14 @@ static void (*dss_output_drv_unreg_funcs[])(void) = {
> > 
> > dss_uninit_platform_driver,
> >  
> >  };
> > 
> > +static struct platform_device omap_drm_device = {
> > +   .dev = {
> > +   .coherent_dma_mask = DMA_BIT_MASK(32),
> > +   },
> > +   .name = "omapdrm_",
> > +   .id = 0,
> > +};
> > +
> > 
> >  static int __init omap_dss_init(void)
> >  {
> >  
> > int r;
> > 
> > @@ -118,6 +127,10 @@ static int __init omap_dss_init(void)
> > 
> > goto err_reg;
> > 
> > }
> > 
> > +   r = platform_device_register(&omap_drm_device);
> > +   if (r)
> > +   goto err_reg;
> > +
> 
> Was there a reason to create the omapdrm device in omap_dss_init (i.e.
> module_init), instead of omapdss's probe? Now the omapdrm device is
> always created even if there's no DSS device on the SoC.

Not really, no.

Do you think this requires a quick -stable fix ? I'm working on a patch series 
that will remove the omapdrm device completely.

-- 
Regards,

Laurent Pinchart

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

Re: Build error for NVIDIA Tegra DRM since 4.14-rc1

2017-09-28 Thread Jon Hunter

Hi Linus,

On 28/09/17 08:10, Linus Lüssing wrote:
> Hi,
> 
> Sorry, did not search for the exact commit yet, but since v4.14-rc1
> I get a build error when trying to build the ARM multi_v7_defconfig
> target:
> 
> ~~
> $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x00208000 zImage 
> uImage modules dtbs
> [...]
>   CHK include/config/kernel.release
>   CHK include/generated/uapi/linux/version.h
>   CHK include/generated/utsrelease.h
>   CHK include/generated/bounds.h
>   CHK include/generated/timeconst.h
>   CHK include/generated/asm-offsets.h
>   CALLscripts/checksyscalls.sh
>   CHK scripts/mod/devicetable-offsets.h
>   CHK include/generated/compile.h
>   CHK include/generated/at91_pm_data-offsets.h
>   CC  drivers/gpu/drm/tegra/trace.o
> In file included from drivers/gpu/drm/tegra/trace.h:68:0,
>  from drivers/gpu/drm/tegra/trace.c:2:
> ./include/trace/define_trace.h:88:42: fatal error: ./trace.h: No such file or 
> directory
>  #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
>   ^
> compilation terminated.
> scripts/Makefile.build:311: recipe for target 'drivers/gpu/drm/tegra/trace.o' 
> failed
> make[4]: *** [drivers/gpu/drm/tegra/trace.o] Error 1
> scripts/Makefile.build:570: recipe for target 'drivers/gpu/drm/tegra' failed
> make[3]: *** [drivers/gpu/drm/tegra] Error 2
> scripts/Makefile.build:570: recipe for target 'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:570: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:1019: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
> ~~
> 
> v4.14-rc2 fails, too. v4.13.2 and v4.13.3 worked fine with multi_v7_defconfig.
> 
> Setting CONFIG_DRM_TEGRA=n for v4.14-rc1 or v4.14-rc2 helps for
> the build to succeed, too.

Yes, sorry about this, we are aware [0] and there is a fix on its way
upstream [1].

Cheers
Jon

[0] https://www.spinics.net/lists/linux-tegra/msg30857.html
[1] https://lkml.org/lkml/2017/9/26/242

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

Re: [PATCH] drm/cma: correctly handle non-zero offset for mmap

On Thu, Sep 28, 2017 at 10:23 AM, Liviu Dudau  wrote:
> Hi Daniel,
>
> On Thu, Sep 28, 2017 at 09:40:35AM +0200, Daniel Vetter wrote:
>> On Wed, Sep 27, 2017 at 4:01 PM, Steven Price  wrote:
>> > From: Tu Vuong 
>> >
>> > When a CMA GEM object is exported via DRM PRIME it should be possible
>> > to mmap the object using an offset. However drm_gem_cma_mmap_obj always
>> > zeroed vm_pgoff.
>>
>> No, at least no one ever had run into this. Pretty much all drivers
>> work like this.
>
> Can you be a bit more specific with "work like this"? You mean all
> drivers expect mmap-ed calles to have zero offset or the fact that they
> all zero vm_pgoff therefore ignore the offset?

Iirc some drivers even outright reject the mmap if it's not aligned to
the full obj.

>> > Fix this by moving the zeroing of vm_pgoff to drm_gem_cma_mmap (which
>> > is only used for non-PRIME mmap) and correct the size parameter in the
>> > call to dma_mmap_wc as the offset may not be non-zero.
>>
>> Since this is an uabi change we need the corresponding patch to
>> upstream open source userspace. Reviewed and all that and ready for
>> acceptance. See
>
> If ignoring the offset is considered uabi, then I agree. Otherwise it
> looks to me more like a fix, rather than an uabi change.
>
> Maybe we should have first a patch warning when vm_pgoff is not zero so
> that we can find out how many in the userspace use that?

Not sure warning is a good idea, because it still means we get to
audit everything. Might as well go ahead an reject it with -EINVAL,
and make sure that's consistent across drivers. But that's all work,
so what exactly is the use-case you have and want to do sub-mmapping
for? Once we have that it's much easier to discuss what to do, instead
of abstraction discussions without the full stack at hand.

Thanks, Daniel

> Best regards,
> Liviu
>
>>
>> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>>
>> > Signed-off-by: Tu Vuong 
>> > Signed-off-by: Steven Price 
>> > Reviewed-by: Brian Starkey 
>> > CC: Brian Starkey 
>> > CC: Liviu Dudau 
>>
>> Thanks, Daniel
>>
>> > ---
>> >  drivers/gpu/drm/drm_gem_cma_helper.c | 13 -
>> >  1 file changed, 8 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
>> > b/drivers/gpu/drm/drm_gem_cma_helper.c
>> > index 373e33f22be4..25828b33c5be 100644
>> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
>> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
>> > @@ -276,15 +276,12 @@ static int drm_gem_cma_mmap_obj(struct 
>> > drm_gem_cma_object *cma_obj,
>> > int ret;
>> >
>> > /*
>> > -* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and 
>> > set the
>> > -* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want 
>> > to map
>> > -* the whole buffer.
>> > +* Clear the VM_PFNMAP flag that was set by drm_gem_mmap()
>> >  */
>> > vma->vm_flags &= ~VM_PFNMAP;
>> > -   vma->vm_pgoff = 0;
>> >
>> > ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
>> > - cma_obj->paddr, vma->vm_end - vma->vm_start);
>> > + cma_obj->paddr, cma_obj->base.size);
>> > if (ret)
>> > drm_gem_vm_close(vma);
>> >
>> > @@ -322,6 +319,12 @@ int drm_gem_cma_mmap(struct file *filp, struct 
>> > vm_area_struct *vma)
>> > gem_obj = vma->vm_private_data;
>> > cma_obj = to_drm_gem_cma_obj(gem_obj);
>> >
>> > +   /*
>> > +* Set the vm_pgoff (used as a fake buffer offset by DRM) to 0 as 
>> > we
>> > +* want to map the whole buffer.
>> > +*/
>> > +   vma->vm_pgoff = 0;
>> > +
>> > return drm_gem_cma_mmap_obj(cma_obj, vma);
>> >  }
>> >  EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
>> > --
>> > 2.11.0
>> > ___
>> > dri-devel mailing list
>> > dri-devel@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
> --
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---
> ¯\_(ツ)_/¯



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

Re: [PATCH] drm/cma: correctly handle non-zero offset for mmap

2017-09-28 Thread Liviu Dudau

Hi Daniel,

On Thu, Sep 28, 2017 at 09:40:35AM +0200, Daniel Vetter wrote:
> On Wed, Sep 27, 2017 at 4:01 PM, Steven Price  wrote:
> > From: Tu Vuong 
> >
> > When a CMA GEM object is exported via DRM PRIME it should be possible
> > to mmap the object using an offset. However drm_gem_cma_mmap_obj always
> > zeroed vm_pgoff.
> 
> No, at least no one ever had run into this. Pretty much all drivers
> work like this.

Can you be a bit more specific with "work like this"? You mean all
drivers expect mmap-ed calles to have zero offset or the fact that they
all zero vm_pgoff therefore ignore the offset?

> 
> > Fix this by moving the zeroing of vm_pgoff to drm_gem_cma_mmap (which
> > is only used for non-PRIME mmap) and correct the size parameter in the
> > call to dma_mmap_wc as the offset may not be non-zero.
> 
> Since this is an uabi change we need the corresponding patch to
> upstream open source userspace. Reviewed and all that and ready for
> acceptance. See

If ignoring the offset is considered uabi, then I agree. Otherwise it
looks to me more like a fix, rather than an uabi change.

Maybe we should have first a patch warning when vm_pgoff is not zero so
that we can find out how many in the userspace use that?

Best regards,
Liviu

> 
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> 
> > Signed-off-by: Tu Vuong 
> > Signed-off-by: Steven Price 
> > Reviewed-by: Brian Starkey 
> > CC: Brian Starkey 
> > CC: Liviu Dudau 
> 
> Thanks, Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_gem_cma_helper.c | 13 -
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> > b/drivers/gpu/drm/drm_gem_cma_helper.c
> > index 373e33f22be4..25828b33c5be 100644
> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> > @@ -276,15 +276,12 @@ static int drm_gem_cma_mmap_obj(struct 
> > drm_gem_cma_object *cma_obj,
> > int ret;
> >
> > /*
> > -* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set 
> > the
> > -* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want 
> > to map
> > -* the whole buffer.
> > +* Clear the VM_PFNMAP flag that was set by drm_gem_mmap()
> >  */
> > vma->vm_flags &= ~VM_PFNMAP;
> > -   vma->vm_pgoff = 0;
> >
> > ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
> > - cma_obj->paddr, vma->vm_end - vma->vm_start);
> > + cma_obj->paddr, cma_obj->base.size);
> > if (ret)
> > drm_gem_vm_close(vma);
> >
> > @@ -322,6 +319,12 @@ int drm_gem_cma_mmap(struct file *filp, struct 
> > vm_area_struct *vma)
> > gem_obj = vma->vm_private_data;
> > cma_obj = to_drm_gem_cma_obj(gem_obj);
> >
> > +   /*
> > +* Set the vm_pgoff (used as a fake buffer offset by DRM) to 0 as we
> > +* want to map the whole buffer.
> > +*/
> > +   vma->vm_pgoff = 0;
> > +
> > return drm_gem_cma_mmap_obj(cma_obj, vma);
> >  }
> >  EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
> > --
> > 2.11.0
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 

| 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: [Mesa-dev] XDC 2017 feedback

2017-09-28 Thread Daniel Stone

Hi,

On 28 September 2017 at 03:49, Ian Romanick  wrote:
> On 09/27/2017 04:55 PM, Rob Clark wrote:
>> Sadly by the time we were aware of the dates for the khronos f2f it
>> was not possible to change the dates for XDC :-(
>>
>> The XDC dates were set in Feb, and afaict the khronos dates were
>> announced in July (?), so take this up with khronos ;-)
>
> Ok... so we're going to go there.
>
> Frankly, that's a giant steaming load of bull.

That's a bit much; can you please tone it down?

> Blocks of hotel rooms,
> multiple conference rooms for 500+ people, and catering for the Khronos
> meeting was booked in late 2016.  We're already working on contracts for
> the September 2018 meeting.  Contracts of this scale are really hard to
> change.  There are 5x to 10x as many people at a Khronos face-to-face as
> at XDC.  Events of that scale have a massively deep pipeline.
>
> Google was just unwilling to find a different dates for space *at their
> own campus*.  That's really, really weak.  This is especially
> infuriating because there are numerous Googlers who attend the Khronos
> meetings.  Did the organizers poll any of them?  The XDC organizers
> clearly did not even exercise due diligence to detect a possible
> conflict.  If the organizers had cared to be aware of dates of
> conflicting events, they would have known.

For starters, yes, it obviously sucks that the two clashed. That being said ...

Logistically, Khronos (and their multiple full-time paid
administrative staff) can move on two axes: time and location.
Location is easy, since any city of any size has a number of four-star
hotels who can host that number of people in exchange for eyewatering
amounts of money directly, as well as guaranteed blocks of rooms at
rates many XDC attendees couldn't afford. With the hosting locked down
to avoid the insane cost, we could only move XDC in time rather than
space.

Time-wise, it's not just Khronos F2F which, being quarterly, is pretty
hard to avoid no matter when you do it. There was Plumbers and OSS NA
before (with the no-go zone of school holidays before that, and
European holidays in August), and afterwards Linaro Connect, Kernel
Recipes, ELCE, GNOME/Qt conferences, the GStreamer conference, and
Kernel Summit. That's before you even touch things like IBC. It really
hurts time-wise, and choosing not to clash means going directly
back-to-back (asking people to be away for 2 weeks at a time), or you
put space between them and ask people to do intercontinental trips
twice in three weeks. At least XDC managed to not overlap the Vulkan
WSI sessions at the F2F: there were people at XDC who'd done both.

I don't know why you think an event of 105 people doesn't have a deep
pipeline either ... ?! Most places don't have a surfeit of 120-person
meeting rooms. The ones they do have tend to book up a long time in
advance, for obvious reasons. Given that we were mostly external,
those rooms have to be not in sensitive buildings, and on the ground
floor close to an exit. Even with that, it required two full-time
dedicated security staff (another logistical dependency) to make sure
the herds of external people didn't end up wandering through an
otherwise badge-only building. The catering also needed to be booked,
and A/V staff to assist. We had a dependency on Jen and Stephane's
time as the local support: they had to be there in person, and be able
to dedicate their full week to the conference.

None of that is being 'unwilling', 'weak', 'not exercis[ing] due
diligence', or not caring. It's organising a conference actually being
really difficult: a deference you're paying Khronos (who have an
objectively easier job), and not the people who organise XDC. Just it
doesn't work out perfectly, doesn't mean it's due to idiocy or lack of
effort.

Even if you do get all your ducks perfectly in a row, sometimes
Network Rail announce a few weeks after you've booked everything that
they're going to close the line to Cambridge for engineering works, so
it's suddenly really difficult to even get there in the first place.
Ho hum.

Hopefully next year it doesn't clash. But I can guarantee you that
even if it doesn't, there will still be people who are unable to come,
because there is just no globally-optimal solution.

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

Re: [PATCH v3 07/11] drm: omapdrm: Register omapdrm platform device in omapdss driver

2017-09-28 Thread Tomi Valkeinen

Hi Laurent,


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 11/08/17 16:49, Laurent Pinchart wrote:
> The omapdrm platform device is a virtual device created for the sole
> purpose of handling the omapdss/omapdrm driver split. It should
> eventually be removed. As a first step to ease refactoring move its
> registration from platform code to driver code.
> 
> The omapdrm driver name must be changed internally to avoid probing both
> the device registered in platform code and the device registered in the
> omapdss driver, as that would otherwise break bisection.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Tomi Valkeinen 
> ---
> Changes since v1:
> 
> - Drop the CONFIG_DRM_OMAP conditional compilation
> - Unregister the platform device at exit time
> ---
>  drivers/gpu/drm/omapdrm/dss/core.c | 15 +++
>  drivers/gpu/drm/omapdrm/omap_drv.c |  2 +-
>  2 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
> b/drivers/gpu/drm/omapdrm/dss/core.c
> index 4dabe32c7098..8678d8b4efce 100644
> --- a/drivers/gpu/drm/omapdrm/dss/core.c
> +++ b/drivers/gpu/drm/omapdrm/dss/core.c
> @@ -22,6 +22,7 @@
>  
>  #define DSS_SUBSYS_NAME "CORE"
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -103,6 +104,14 @@ static void (*dss_output_drv_unreg_funcs[])(void) = {
>   dss_uninit_platform_driver,
>  };
>  
> +static struct platform_device omap_drm_device = {
> + .dev = {
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + },
> + .name = "omapdrm_",
> + .id = 0,
> +};
> +
>  static int __init omap_dss_init(void)
>  {
>   int r;
> @@ -118,6 +127,10 @@ static int __init omap_dss_init(void)
>   goto err_reg;
>   }
>  
> + r = platform_device_register(&omap_drm_device);
> + if (r)
> + goto err_reg;
> +

Was there a reason to create the omapdrm device in omap_dss_init (i.e.
module_init), instead of omapdss's probe? Now the omapdrm device is
always created even if there's no DSS device on the SoC.

 Tomi

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

Re: drm_hwcomposer moving to fd.o

On Thu, Sep 28, 2017 at 9:43 AM, Tapani Pälli  wrote:
>
>
> On 09/28/2017 10:35 AM, Tomeu Vizoso wrote:
>>
>> On 09/28/2017 09:08 AM, Daniel Vetter wrote:
>>>
>>> On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang 
>>> wrote:

 2017-09-26 13:26 GMT+08:00 Daniel Vetter :
>
> On Mon, Sep 25, 2017 at 09:06:55AM +0200, Tomeu Vizoso wrote:
>>
>> On 09/25/2017 04:44 AM, Chih-Wei Huang wrote:
>>>
>>> Hey Robert, thank you for the reply.
>>>
>>> 2017-09-22 23:43 GMT+08:00 Robert Foss :

 Hey Chih-Wei,
 On Fri, 2017-09-22 at 10:40 +0800, Chih-Wei Huang wrote:
>>>
>>>
 The android-ia project has supported using drm_hwcomposer and an
 alternative hwcomposer, so it would think there should be no issues.
>>>
>>>
>>> By x86 GPUs, I meant i915(i965)/nouveau/radeon/amdgpu/virgl/vmwgfx.
>>> Among these only virgl works with the current drm_hwcomposer.
>>> All the others don't have a ready atomic mode-setting API to use it.
>>> That's the problem which should be addressed I meant.
>>
>>
>> Most if not all of those drivers support the atomic updates API in
>> mainline (and have for a few releases by now).
>
>
> amdgpu does not (but will once DC has landed, at least when you enable
> DC). Radeon doesn't, and likely never will. Nouveau is atomic only for
> nv50+.


 Thank you for the clarification.

 I have made test with kernel 4.13 +
 gbm_grallc + drm_hwcomposer + mesa 17.1
 on Android-x86 7.1.
 Except virgl all others just failed as expected.

 i915 (i965) was tested in Intel Broxton.
 It's the best result. SurfaceFlinger runs and
 bootanimation is shown. However, after boot
 complete it only shown systemui + navbar with
 black background. No app icons or mouse cursor
 in the desktop. I guess the composition of 3+
 layers has some problems.
>>>
>>>
>>> Could be a bug in either drm_hwcomposer making assumptions that don't
>>> hold, or i915 for implementing stuff wrongly. Would need someone to
>>> debug. Given that we have products shipping on bxt using atomic (CrOS)
>>> I'm leaining towards drm_hwcomposer making bad assumptions.
>>
>>
>> An easy way of making sure that the problem is with compositing with
>> overlays is applying this hack:
>>
>>
>> https://git.collabora.com/cgit/user/tomeu/drm_hwcomposer.git/commit/?h=android-etnaviv&id=dbe21cb52f602eef11bf5ac083691e5b2b0a35ba
>>
>> It should also allow you to move on and test more stuff.
>
>
> back when Android-IA used drm_hwcomposer there were some fixes made before
> things started to work, this is a shot in the dark but following commits
> might fix something (disclaimer, this is based on some old snapshot of
> drm_hwcomposer but one might be able to port relevant changes ...)
>
> handle cursor separately:
>
> https://github.com/android-ia/external-drm_hwcomposer/commit/f9029ff42f7f925a2e34aad1caa1481f72f347ac
>
> introduce own planner for IA:
>
> https://github.com/android-ia/external-drm_hwcomposer/commit/e5f32f820a93352c631b379d9721795c783fc4e7

Both of these should be fixed in the generic code I'd say. Cursor is a
perfect case of random special cases that might make some planes
unsuable in certain conditions (but there's really nothing special
with it being the cursor plane).

And the 2nd patch shows how we probably want to expose the can_scale
and can_position stuff from the plane's atomic_check functions as
hints to the compositor. Plus ofc the compositor should try to only
use the supported drm_fourcc codes (if it indeed gets that wrong).

So yeah I'd say that's bugs in drm_hwcomposer, if this helps with fixing it.
-Daniel


 vmwgfx also has issues on drm_hwcomposer
 initialization. SurfaceFlinger didn't crashes but
 no bootanimation. It seems just blocked.
>>
>>
>> If you want to test another driver in qemu, you can test Varad's patches
>> in https://patchwork.freedesktop.org/series/29006/ for atomic updates in
>> the Cirrus driver.
>>
>> Regards,
>>
>> Tomeu
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>



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

Re: drm_hwcomposer moving to fd.o

2017-09-28 Thread Tapani Pälli

On 09/28/2017 10:35 AM, Tomeu Vizoso wrote:

On 09/28/2017 09:08 AM, Daniel Vetter wrote:

On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang wrote:

2017-09-26 13:26 GMT+08:00 Daniel Vetter :

On Mon, Sep 25, 2017 at 09:06:55AM +0200, Tomeu Vizoso wrote:

On 09/25/2017 04:44 AM, Chih-Wei Huang wrote:

Hey Robert, thank you for the reply.

2017-09-22 23:43 GMT+08:00 Robert Foss :

Hey Chih-Wei,
On Fri, 2017-09-22 at 10:40 +0800, Chih-Wei Huang wrote:

The android-ia project has supported using drm_hwcomposer and an
alternative hwcomposer, so it would think there should be no issues.

By x86 GPUs, I meant i915(i965)/nouveau/radeon/amdgpu/virgl/vmwgfx.
Among these only virgl works with the current drm_hwcomposer.
All the others don't have a ready atomic mode-setting API to use it.
That's the problem which should be addressed I meant.

Most if not all of those drivers support the atomic updates API in
mainline (and have for a few releases by now).

amdgpu does not (but will once DC has landed, at least when you enable
DC). Radeon doesn't, and likely never will. Nouveau is atomic only for
nv50+.

Thank you for the clarification.

I have made test with kernel 4.13 +
gbm_grallc + drm_hwcomposer + mesa 17.1
on Android-x86 7.1.
Except virgl all others just failed as expected.

i915 (i965) was tested in Intel Broxton.
It's the best result. SurfaceFlinger runs and
bootanimation is shown. However, after boot
complete it only shown systemui + navbar with
black background. No app icons or mouse cursor
in the desktop. I guess the composition of 3+
layers has some problems.

Could be a bug in either drm_hwcomposer making assumptions that don't
hold, or i915 for implementing stuff wrongly. Would need someone to
debug. Given that we have products shipping on bxt using atomic (CrOS)
I'm leaining towards drm_hwcomposer making bad assumptions.

An easy way of making sure that the problem is with compositing with
overlays is applying this hack:

https://git.collabora.com/cgit/user/tomeu/drm_hwcomposer.git/commit/?h=android-etnaviv&id=dbe21cb52f602eef11bf5ac083691e5b2b0a35ba

It should also allow you to move on and test more stuff.

back when Android-IA used drm_hwcomposer there were some fixes made
before things started to work, this is a shot in the dark but following
commits might fix something (disclaimer, this is based on some old
snapshot of drm_hwcomposer but one might be able to port relevant
changes ...)

handle cursor separately:

https://github.com/android-ia/external-drm_hwcomposer/commit/f9029ff42f7f925a2e34aad1caa1481f72f347ac

introduce own planner for IA:

https://github.com/android-ia/external-drm_hwcomposer/commit/e5f32f820a93352c631b379d9721795c783fc4e7

vmwgfx also has issues on drm_hwcomposer
initialization. SurfaceFlinger didn't crashes but
no bootanimation. It seems just blocked.

If you want to test another driver in qemu, you can test Varad's patches
in https://patchwork.freedesktop.org/series/29006/ for atomic updates in
the Cirrus driver.

Regards,

Tomeu
___
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/cma: correctly handle non-zero offset for mmap

On Wed, Sep 27, 2017 at 4:01 PM, Steven Price  wrote:
> From: Tu Vuong 
>
> When a CMA GEM object is exported via DRM PRIME it should be possible
> to mmap the object using an offset. However drm_gem_cma_mmap_obj always
> zeroed vm_pgoff.

No, at least no one ever had run into this. Pretty much all drivers
work like this.

> Fix this by moving the zeroing of vm_pgoff to drm_gem_cma_mmap (which
> is only used for non-PRIME mmap) and correct the size parameter in the
> call to dma_mmap_wc as the offset may not be non-zero.

Since this is an uabi change we need the corresponding patch to
upstream open source userspace. Reviewed and all that and ready for
acceptance. See

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

> Signed-off-by: Tu Vuong 
> Signed-off-by: Steven Price 
> Reviewed-by: Brian Starkey 
> CC: Brian Starkey 
> CC: Liviu Dudau 

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_gem_cma_helper.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 373e33f22be4..25828b33c5be 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -276,15 +276,12 @@ static int drm_gem_cma_mmap_obj(struct 
> drm_gem_cma_object *cma_obj,
> int ret;
>
> /*
> -* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set 
> the
> -* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to 
> map
> -* the whole buffer.
> +* Clear the VM_PFNMAP flag that was set by drm_gem_mmap()
>  */
> vma->vm_flags &= ~VM_PFNMAP;
> -   vma->vm_pgoff = 0;
>
> ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
> - cma_obj->paddr, vma->vm_end - vma->vm_start);
> + cma_obj->paddr, cma_obj->base.size);
> if (ret)
> drm_gem_vm_close(vma);
>
> @@ -322,6 +319,12 @@ int drm_gem_cma_mmap(struct file *filp, struct 
> vm_area_struct *vma)
> gem_obj = vma->vm_private_data;
> cma_obj = to_drm_gem_cma_obj(gem_obj);
>
> +   /*
> +* Set the vm_pgoff (used as a fake buffer offset by DRM) to 0 as we
> +* want to map the whole buffer.
> +*/
> +   vma->vm_pgoff = 0;
> +
> return drm_gem_cma_mmap_obj(cma_obj, vma);
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
> --
> 2.11.0
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: drm_hwcomposer moving to fd.o

2017-09-28 Thread Tomeu Vizoso

On 09/28/2017 09:08 AM, Daniel Vetter wrote:
> On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang  
> wrote:
>> 2017-09-26 13:26 GMT+08:00 Daniel Vetter :
>>> On Mon, Sep 25, 2017 at 09:06:55AM +0200, Tomeu Vizoso wrote:
 On 09/25/2017 04:44 AM, Chih-Wei Huang wrote:
> Hey Robert, thank you for the reply.
>
> 2017-09-22 23:43 GMT+08:00 Robert Foss :
>> Hey Chih-Wei,
>> On Fri, 2017-09-22 at 10:40 +0800, Chih-Wei Huang wrote:
>
>> The android-ia project has supported using drm_hwcomposer and an
>> alternative hwcomposer, so it would think there should be no issues.
>
> By x86 GPUs, I meant i915(i965)/nouveau/radeon/amdgpu/virgl/vmwgfx.
> Among these only virgl works with the current drm_hwcomposer.
> All the others don't have a ready atomic mode-setting API to use it.
> That's the problem which should be addressed I meant.

 Most if not all of those drivers support the atomic updates API in
 mainline (and have for a few releases by now).
>>>
>>> amdgpu does not (but will once DC has landed, at least when you enable
>>> DC). Radeon doesn't, and likely never will. Nouveau is atomic only for
>>> nv50+.
>>
>> Thank you for the clarification.
>>
>> I have made test with kernel 4.13 +
>> gbm_grallc + drm_hwcomposer + mesa 17.1
>> on Android-x86 7.1.
>> Except virgl all others just failed as expected.
>>
>> i915 (i965) was tested in Intel Broxton.
>> It's the best result. SurfaceFlinger runs and
>> bootanimation is shown. However, after boot
>> complete it only shown systemui + navbar with
>> black background. No app icons or mouse cursor
>> in the desktop. I guess the composition of 3+
>> layers has some problems.
> 
> Could be a bug in either drm_hwcomposer making assumptions that don't
> hold, or i915 for implementing stuff wrongly. Would need someone to
> debug. Given that we have products shipping on bxt using atomic (CrOS)
> I'm leaining towards drm_hwcomposer making bad assumptions.

An easy way of making sure that the problem is with compositing with
overlays is applying this hack:

https://git.collabora.com/cgit/user/tomeu/drm_hwcomposer.git/commit/?h=android-etnaviv&id=dbe21cb52f602eef11bf5ac083691e5b2b0a35ba

It should also allow you to move on and test more stuff.

>> vmwgfx also has issues on drm_hwcomposer
>> initialization. SurfaceFlinger didn't crashes but
>> no bootanimation. It seems just blocked.

If you want to test another driver in qemu, you can test Varad's patches
in https://patchwork.freedesktop.org/series/29006/ for atomic updates in
the Cirrus driver.

Regards,

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

[Bug 196615] amdgpu - resume from suspend is no longer working on rx480

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

klavkala...@gmail.com changed:

   What|Removed |Added

 CC||klavkala...@gmail.com

--- Comment #16 from klavkala...@gmail.com ---
This bug remains for me. It was working after the patch was reverted, and
continued to work fine for the rest of the 4.12 version, but as of linux
4.13.3, still the same symtoms. When browsing the sources for this kernel, it
seems the patch is still there. Was it supposed to be reapplied?

-- 
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: [Mesa-dev] XDC 2017 feedback

2017-09-28 Thread Ian Romanick

On 09/27/2017 10:07 PM, Rob Clark wrote:
> On Wed, Sep 27, 2017 at 10:49 PM, Ian Romanick  wrote:
>> On 09/27/2017 04:55 PM, Rob Clark wrote:
>>> On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick  wrote:
 On 09/26/2017 09:57 AM, Daniel Vetter wrote:
> Hi all,
>
> First again big thanks to Stéphane and Jennifer for organizing a great 
> XDC.
>
> Like last year we'd like to hear feedback on how this year's XDC went,
> both the good (and what you'd like to see more of) and the not so
> good. Talk selection, organization, location, scheduling of talks,
> anything really.

 Not scheduling it to conflict with another industry event would be a
 good start.  This is the first XDC that I've missed in nearly a decade.
 I know I'm not the only person that missed one or the other due to
 scheduling fail.
>>>
>>> Sadly by the time we were aware of the dates for the khronos f2f it
>>> was not possible to change the dates for XDC :-(
>>>
>>> The XDC dates were set in Feb, and afaict the khronos dates were
>>> announced in July (?), so take this up with khronos ;-)
>>
>> Ok... so we're going to go there.
>>
>> Frankly, that's a giant steaming load of bull.  Blocks of hotel rooms,
>> multiple conference rooms for 500+ people, and catering for the Khronos
>> meeting was booked in late 2016.  We're already working on contracts for
>> the September 2018 meeting.  Contracts of this scale are really hard to
>> change.  There are 5x to 10x as many people at a Khronos face-to-face as
>> at XDC.  Events of that scale have a massively deep pipeline.
>>
>> Google was just unwilling to find a different dates for space *at their
>> own campus*.  That's really, really weak.  This is especially
>> infuriating because there are numerous Googlers who attend the Khronos
>> meetings.  Did the organizers poll any of them?  The XDC organizers
>> clearly did not even exercise due diligence to detect a possible
>> conflict.  If the organizers had cared to be aware of dates of
>> conflicting events, they would have known.
> 
> I have no doubt there is a long lead time on organizing large conf's..
> I wasn't calling that into question.  The July date was based on a
> quick search of my khr emails.  I couldn't find any earlier reference
> to dates, but I could have missed something.
> 
> If you had known of the khr dates, and brought it up in Feb (or really
> somewhat earlier, given that XDC is roughly same time each year +/-
> few weeks), that *might* have been early enough to move things.  But
> IIRC there wasn't much flexibility in booking such a large room from
> the google side either.  Plus also trying to fit around LPC/etc..
> Khronos isn't the only other conference to avoid.  Once the XDC date
> is announced and people have begun booking travel, we can't really
> move things.  Sorry, it sucks, I wasn't happy about it either, but it
> is what it is.  As far as other conferences that XDC attendees are
> likely to go to, and given the turn-out (by far largest XDC in NA), I
> think the dates worked out reasonably well overall.

The point of my original post wasn't to start a big to-do.  My point was
just that future organizers should be more careful.

Once school starts in September, other conferences stop.  I had always
assumed that was part of the reason XDC was scheduled the way that it
was scheduled.  There are basically two events from mid-September to
early October to avoid: LPC / kernel summit and Khronos meetings.  At
least as far back as 2008, XDC had always been able to avoid both.
Hopefully that long run will be repeated and improved.

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

Re: [Mesa-dev] XDC 2017 feedback

2017-09-28 Thread Ian Romanick

On 09/27/2017 04:55 PM, Rob Clark wrote:
> On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick  wrote:
>> On 09/26/2017 09:57 AM, Daniel Vetter wrote:
>>> Hi all,
>>>
>>> First again big thanks to Stéphane and Jennifer for organizing a great XDC.
>>>
>>> Like last year we'd like to hear feedback on how this year's XDC went,
>>> both the good (and what you'd like to see more of) and the not so
>>> good. Talk selection, organization, location, scheduling of talks,
>>> anything really.
>>
>> Not scheduling it to conflict with another industry event would be a
>> good start.  This is the first XDC that I've missed in nearly a decade.
>> I know I'm not the only person that missed one or the other due to
>> scheduling fail.
> 
> Sadly by the time we were aware of the dates for the khronos f2f it
> was not possible to change the dates for XDC :-(
> 
> The XDC dates were set in Feb, and afaict the khronos dates were
> announced in July (?), so take this up with khronos ;-)

Ok... so we're going to go there.

Frankly, that's a giant steaming load of bull.  Blocks of hotel rooms,
multiple conference rooms for 500+ people, and catering for the Khronos
meeting was booked in late 2016.  We're already working on contracts for
the September 2018 meeting.  Contracts of this scale are really hard to
change.  There are 5x to 10x as many people at a Khronos face-to-face as
at XDC.  Events of that scale have a massively deep pipeline.

Google was just unwilling to find a different dates for space *at their
own campus*.  That's really, really weak.  This is especially
infuriating because there are numerous Googlers who attend the Khronos
meetings.  Did the organizers poll any of them?  The XDC organizers
clearly did not even exercise due diligence to detect a possible
conflict.  If the organizers had cared to be aware of dates of
conflicting events, they would have known.

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

Re: [Mesa-dev] XDC 2017 feedback

2017-09-28 Thread Ian Romanick

On 09/26/2017 09:57 AM, Daniel Vetter wrote:
> Hi all,
> 
> First again big thanks to Stéphane and Jennifer for organizing a great XDC.
> 
> Like last year we'd like to hear feedback on how this year's XDC went,
> both the good (and what you'd like to see more of) and the not so
> good. Talk selection, organization, location, scheduling of talks,
> anything really.

Not scheduling it to conflict with another industry event would be a
good start.  This is the first XDC that I've missed in nearly a decade.
I know I'm not the only person that missed one or the other due to
scheduling fail.

> Here's a few things we took into account from Helsinki and tried to apply:
> - More breaks for more hallway track.
> - Try to schedule the hot topics on the first day (did we pick the
> right ones) for better hallway track.
> - More lightning talk time to give all the late/rejected submissions
> some place to give a quick showcase.
> 
> Things that didn't work out perfectly this year and that we'll try to
> get better at next year:
> - Lots of people missed the submission deadline and their talks were
> rejected only because of that. We'll do better PR by sending out a
> pile of reminders.
> - Comparitively few people asked for travel assistance. No idea
> whether this was a year with more budget around, or whether this isn't
> all that well know and we need to make more PR in maybe the call for
> papers about it.
> 
> But that's just the stuff we've gathered already, we'd like to hear
> more feedback. Just reply to this mail or send a mail to
> bo...@foundation.x.org if you don't want the entire world to read it.
> And if you want to send at pseudonymous feedback, drop a pastebin onto
> the #xf-bod channel on the OFTC irc server.
> 
> Thanks, Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/atomic: Make atomic iterators less surprising

2017-09-28 Thread Dmitry Osipenko

On 27.09.2017 11:35, Maarten Lankhorst wrote:
> Commit 669c9215afea ("drm/atomic: Make async plane update checks work as
> intended, v2.") assumed incorrectly that if only 1 plane is matched in
> the loop, the variables will be set to that plane. In reality we reset
> them to NULL every time a new plane was iterated. This behavior is
> surprising, so fix this by making the for loops only assign the
> variables on a match.
> 
> Cc: Dmitry Osipenko 
> Fixes: 669c9215afea ("drm/atomic: Make async plane update checks work as 
> intended, v2.")
> Signed-off-by: Maarten Lankhorst 
> ---
>  include/drm/drm_atomic.h | 85 
> 
>  1 file changed, 42 insertions(+), 43 deletions(-)
> 
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 6fae95f28e10..5afd6e364fb6 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -585,12 +585,12 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
>   */
>  #define for_each_oldnew_connector_in_state(__state, connector, 
> old_connector_state, new_connector_state, __i) \
>   for ((__i) = 0; 
> \
> -  (__i) < (__state)->num_connector &&
> \
> -  ((connector) = (__state)->connectors[__i].ptr, 
> \
> -  (old_connector_state) = (__state)->connectors[__i].old_state,  
> \
> -  (new_connector_state) = (__state)->connectors[__i].new_state, 1);  
> \
> -  (__i)++)   \
> - for_each_if (connector)
> +  (__i) < (__state)->num_connector;  
> \
> +  (__i)++)   
> \
> + for_each_if ((__state)->connectors[__i].ptr &&  
> \
> +  ((connector) = (__state)->connectors[__i].ptr, 
> \
> +  (old_connector_state) = 
> (__state)->connectors[__i].old_state,  \
> +  (new_connector_state) = 
> (__state)->connectors[__i].new_state, 1))
>  
>  /**
>   * for_each_old_connector_in_state - iterate over all connectors in an 
> atomic update
> @@ -606,11 +606,11 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
>   */
>  #define for_each_old_connector_in_state(__state, connector, 
> old_connector_state, __i) \
>   for ((__i) = 0; 
> \
> -  (__i) < (__state)->num_connector &&
> \
> -  ((connector) = (__state)->connectors[__i].ptr, 
> \
> -  (old_connector_state) = (__state)->connectors[__i].old_state, 1);  
> \
> -  (__i)++)   \
> - for_each_if (connector)
> +  (__i) < (__state)->num_connector;  
> \
> +  (__i)++)   
> \
> + for_each_if ((__state)->connectors[__i].ptr &&  
> \
> +  ((connector) = (__state)->connectors[__i].ptr, 
> \
> +  (old_connector_state) = 
> (__state)->connectors[__i].old_state, 1))
>  
>  /**
>   * for_each_new_connector_in_state - iterate over all connectors in an 
> atomic update
> @@ -626,11 +626,11 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
>   */
>  #define for_each_new_connector_in_state(__state, connector, 
> new_connector_state, __i) \
>   for ((__i) = 0; 
> \
> -  (__i) < (__state)->num_connector &&
> \
> -  ((connector) = (__state)->connectors[__i].ptr, 
> \
> -  (new_connector_state) = (__state)->connectors[__i].new_state, 1);  
> \
> -  (__i)++)   \
> - for_each_if (connector)
> +  (__i) < (__state)->num_connector;  
> \
> +  (__i)++)   
> \
> + for_each_if ((__state)->connectors[__i].ptr &&  
> \
> +  ((connector) = (__state)->connectors[__i].ptr, 
> \
> +  (new_connector_state) = 
> (__state)->connectors[__i].new_state, 1))
>  
>  /**
>   * for_each_oldnew_crtc_in_state - iterate over all CRTCs in an atomic update
> @@ -646,12 +646,12 @@ void drm_state_dump(struct drm_device *dev, struct 
> drm_printer *p);
>   */
>  #define for_each_oldnew_crtc_in_state(__state, crtc, old_crtc_state, 
> new_crtc_state, __i) \
>   for ((__i) = 0; \
> -  (__i) < (__state)->dev->mode_config.nu

Re: [Mesa-dev] XDC 2017 feedback

2017-09-28 Thread Ryan Houdek

It was a great time! Next year I should pay more attention that this was
happening so I don't sign up at the last moment causing me to miss a day,
and having a fever on the last day.
Looking forward to next year's!

On Wed, Sep 27, 2017 at 4:25 PM, Ian Romanick  wrote:

> On 09/26/2017 09:57 AM, Daniel Vetter wrote:
> > Hi all,
> >
> > First again big thanks to Stéphane and Jennifer for organizing a great
> XDC.
> >
> > Like last year we'd like to hear feedback on how this year's XDC went,
> > both the good (and what you'd like to see more of) and the not so
> > good. Talk selection, organization, location, scheduling of talks,
> > anything really.
>
> Not scheduling it to conflict with another industry event would be a
> good start.  This is the first XDC that I've missed in nearly a decade.
> I know I'm not the only person that missed one or the other due to
> scheduling fail.
>
> > Here's a few things we took into account from Helsinki and tried to
> apply:
> > - More breaks for more hallway track.
> > - Try to schedule the hot topics on the first day (did we pick the
> > right ones) for better hallway track.
> > - More lightning talk time to give all the late/rejected submissions
> > some place to give a quick showcase.
> >
> > Things that didn't work out perfectly this year and that we'll try to
> > get better at next year:
> > - Lots of people missed the submission deadline and their talks were
> > rejected only because of that. We'll do better PR by sending out a
> > pile of reminders.
> > - Comparitively few people asked for travel assistance. No idea
> > whether this was a year with more budget around, or whether this isn't
> > all that well know and we need to make more PR in maybe the call for
> > papers about it.
> >
> > But that's just the stuff we've gathered already, we'd like to hear
> > more feedback. Just reply to this mail or send a mail to
> > bo...@foundation.x.org if you don't want the entire world to read it.
> > And if you want to send at pseudonymous feedback, drop a pastebin onto
> > the #xf-bod channel on the OFTC irc server.
> >
> > Thanks, Daniel
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Build error for NVIDIA Tegra DRM since 4.14-rc1

2017-09-28 Thread Linus Lüssing

Hi,

Sorry, did not search for the exact commit yet, but since v4.14-rc1
I get a build error when trying to build the ARM multi_v7_defconfig
target:

~~
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x00208000 zImage 
uImage modules dtbs
[...]
  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK include/generated/at91_pm_data-offsets.h
  CC  drivers/gpu/drm/tegra/trace.o
In file included from drivers/gpu/drm/tegra/trace.h:68:0,
 from drivers/gpu/drm/tegra/trace.c:2:
./include/trace/define_trace.h:88:42: fatal error: ./trace.h: No such file or 
directory
 #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
  ^
compilation terminated.
scripts/Makefile.build:311: recipe for target 'drivers/gpu/drm/tegra/trace.o' 
failed
make[4]: *** [drivers/gpu/drm/tegra/trace.o] Error 1
scripts/Makefile.build:570: recipe for target 'drivers/gpu/drm/tegra' failed
make[3]: *** [drivers/gpu/drm/tegra] Error 2
scripts/Makefile.build:570: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:570: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1019: recipe for target 'drivers' failed
make: *** [drivers] Error 2
~~

v4.14-rc2 fails, too. v4.13.2 and v4.13.3 worked fine with multi_v7_defconfig.

Setting CONFIG_DRM_TEGRA=n for v4.14-rc1 or v4.14-rc2 helps for
the build to succeed, too.

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

[PATCH] drm/rockchip: Rely on the default best_encoder() behavior

2017-09-28 Thread Haneen Mohammed

Since the output has 1:1 relationship between connectors and encoders,
and the driver is relying on the atomic helpers, remove the custom
best_encoder() and let the core call drm_atomic_helper_best_encoder().

Signed-off-by: Haneen Mohammed 
---
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a57da05..275844d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -287,14 +287,6 @@ static int cdn_dp_connector_get_modes(struct drm_connector 
*connector)
return ret;
 }
 
-static struct drm_encoder *
-cdn_dp_connector_best_encoder(struct drm_connector *connector)
-{
-   struct cdn_dp_device *dp = connector_to_dp(connector);
-
-   return &dp->encoder;
-}
-
 static int cdn_dp_connector_mode_valid(struct drm_connector *connector,
   struct drm_display_mode *mode)
 {
@@ -346,7 +338,6 @@ static int cdn_dp_connector_mode_valid(struct drm_connector 
*connector,
 
 static struct drm_connector_helper_funcs cdn_dp_connector_helper_funcs = {
.get_modes = cdn_dp_connector_get_modes,
-   .best_encoder = cdn_dp_connector_best_encoder,
.mode_valid = cdn_dp_connector_mode_valid,
 };
 
-- 
2.7.4

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

[PATCH] drm/cma: correctly handle non-zero offset for mmap

2017-09-28 Thread Steven Price

From: Tu Vuong 

When a CMA GEM object is exported via DRM PRIME it should be possible
to mmap the object using an offset. However drm_gem_cma_mmap_obj always
zeroed vm_pgoff.

Fix this by moving the zeroing of vm_pgoff to drm_gem_cma_mmap (which
is only used for non-PRIME mmap) and correct the size parameter in the
call to dma_mmap_wc as the offset may not be non-zero.

Signed-off-by: Tu Vuong 
Signed-off-by: Steven Price 
Reviewed-by: Brian Starkey 
CC: Brian Starkey 
CC: Liviu Dudau 
---
 drivers/gpu/drm/drm_gem_cma_helper.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 373e33f22be4..25828b33c5be 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -276,15 +276,12 @@ static int drm_gem_cma_mmap_obj(struct drm_gem_cma_object 
*cma_obj,
int ret;
 
/*
-* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
-* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to map
-* the whole buffer.
+* Clear the VM_PFNMAP flag that was set by drm_gem_mmap()
 */
vma->vm_flags &= ~VM_PFNMAP;
-   vma->vm_pgoff = 0;
 
ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
- cma_obj->paddr, vma->vm_end - vma->vm_start);
+ cma_obj->paddr, cma_obj->base.size);
if (ret)
drm_gem_vm_close(vma);
 
@@ -322,6 +319,12 @@ int drm_gem_cma_mmap(struct file *filp, struct 
vm_area_struct *vma)
gem_obj = vma->vm_private_data;
cma_obj = to_drm_gem_cma_obj(gem_obj);
 
+   /*
+* Set the vm_pgoff (used as a fake buffer offset by DRM) to 0 as we
+* want to map the whole buffer.
+*/
+   vma->vm_pgoff = 0;
+
return drm_gem_cma_mmap_obj(cma_obj, vma);
 }
 EXPORT_SYMBOL_GPL(drm_gem_cma_mmap);
-- 
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: XDC 2017 feedback

2017-09-28 Thread Miguel Angel Vico

Hi,

In general, I think the organization was great. I agree having
everything happen in a single room was a good point. Here's some of my
personal feedback:

 * I didn't like the tables layout at all. I found it to be extremely
   uncomfortable to have to look sideways in order to see the screens
   and presenter.

 * There were a very few power strips, and not well distributed along
   the tables.

Also, this is what I've been able to gather from some of my colleagues
here at NVIDIA::

 * Some people watching the conference remotely complained about the
   stream quality, and the recordings wouldn't include the presenter.

   In one of the hallway conversations, Martin mentioned in XDC2016
   they had a team of camera experts doing the job, and will try to
   improve that part in future XDC's.

 * The microphone/audio situation wasn't great either.  I don't know
   how practical it is with something the size of XDC, but at Khronos
   meetings, they usually set up microphones for the audience too, with
   tap-on/tap-off switches, and a ratio of 1:2 or 1:3 for
   microphones:people.  That makes Q&A a lot easier.  Alternatively,
   having a question queue rather than running mics around the room can
   speed things up, but makes cross-talk harder.

 * The table/chair layout was really cumbersome. Beyond just the
   orientation, some people had a lot of trouble getting in/out to use
   the restroom, grab snacks, etc.

On a positive note:

 * More time for hallway conversations was in general a good thing.
   Some of us got a ton of useful feedback talking to others.

 * The food was great, and having food on-site gave us even more time
   for hallway-tracking.

 * Surprisingly, parking was not an issue.

 * Signage was good, and the security guards were polite/helpful. It
   was easy to find the room and get our badges.

 * The wifi worked great in general, which is a rarity at conferences.
   It was pretty spotty at XDC 2016.

Thank you.

On Tue, 26 Sep 2017 11:49:10 -0700
Manasi Navare wrote:

> Hi,
> 
> XDC was a really great conference and loved the fact that it was
> in just one room which kept all the hallway conversations in that room 
> resulting
> into more networking.
> But I agree with Andres that for the videos, it would be great to split the
> huge youtube video stream per presentation and have seperate links for each
> talk somewhere on the XDC page.
> 
> Regards
> Manasi
> 
> 
> 
> On Tue, Sep 26, 2017 at 01:25:15PM -0400, Andres Rodriguez wrote:
> > Hi,
> > 
> > A small piece of feedback from those of us watching remotely. It would be
> > nice to have a simple to access index for the long livestream videos.
> > 
> > I think the XDC 2017 wiki page would be a good place for this information. A
> > brief example:
> > 
> > Presentation Title | Presenter Name | Link with timestamp
> > ---||-
> > ...| ...| youtu.be/video-id?t=XhYmZs
> > 
> > Or alternatively, a list of hyperlinks with the presentation title as text
> > that point to the correct timestamp in the video would also be sufficient.
> > 
> > Really enjoyed the talks, and would like them to be slightly easier to
> > access and share with others.
> > 
> > Regards,
> > Andres
> > 
> > 
> > On 2017-09-26 12:57 PM, Daniel Vetter wrote:  
> > >Hi all,
> > >
> > >First again big thanks to Stéphane and Jennifer for organizing a great XDC.
> > >
> > >Like last year we'd like to hear feedback on how this year's XDC went,
> > >both the good (and what you'd like to see more of) and the not so
> > >good. Talk selection, organization, location, scheduling of talks,
> > >anything really.
> > >
> > >Here's a few things we took into account from Helsinki and tried to apply:
> > >- More breaks for more hallway track.
> > >- Try to schedule the hot topics on the first day (did we pick the
> > >right ones) for better hallway track.
> > >- More lightning talk time to give all the late/rejected submissions
> > >some place to give a quick showcase.
> > >
> > >Things that didn't work out perfectly this year and that we'll try to
> > >get better at next year:
> > >- Lots of people missed the submission deadline and their talks were
> > >rejected only because of that. We'll do better PR by sending out a
> > >pile of reminders.
> > >- Comparitively few people asked for travel assistance. No idea
> > >whether this was a year with more budget around, or whether this isn't
> > >all that well know and we need to make more PR in maybe the call for
> > >papers about it.
> > >
> > >But that's just the stuff we've gathered already, we'd like to hear
> > >more feedback. Just reply to this mail or send a mail to
> > >bo...@foundation.x.org if you don't want the entire world to read it.
> > >And if you want to send at pseudonymous feedback, drop a pastebin onto
> > >the #xf-bod channel on the OFTC irc server.
> > >
> > >Thanks, Daniel
> > >  
> > ___

Re: [PATCH v2 0/3] drm/tinydrm: drm_of_find_backlight helper

On Thu, Sep 28, 2017 at 11:31:37AM +0530, Meghana Madhyastha wrote:
> This patchset introduces some changes such as move
> tinydrm_of_find_backlight to drm_of.c and rename it to
> drm_of_find_backlight for better organizational structure.
> 
> Changes in v2:
> -Broke the patch into a patchset of 3 patches
> -Added devres versions of drm_of_find_backlight
> -Added a note about caller having to call put_device

Sorry for making you respin this once more, but the split-up here doesn't
make sense. After patch 1 tinydrm doesn't compile anymore (since it still
uses tinydrm_of_find_backlight, but that's removed already). I've also
made a few other comments on v1 of your series.
-Daniel

> 
> Meghana Madhyastha (3):
>   drm/tinydrm: Move tinydrm_of_find_backlight into drm_of.c
>   drm/tinydrm: Call drm_of_find_backlight instead of
> tinydrm_of_find_backlight
>   drm/tinydrm: Add devres versions of drm_of_find_backlight
> 
>  drivers/gpu/drm/drm_of.c   | 44 
> ++
>  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 ---
>  drivers/gpu/drm/tinydrm/mi0283qt.c |  3 +-
>  include/drm/drm_of.h   |  3 ++
>  include/drm/tinydrm/tinydrm-helpers.h  |  1 -
>  5 files changed, 49 insertions(+), 42 deletions(-)
> 
> -- 
> 2.7.4
> 

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

Re: [PATCH] drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl