Re: [RFC v3 5/8] drm/msm: update cursors asynchronously through atomic

[Archit Taneja]

Hi,

On 05/16/2017 08:14 PM, Archit Taneja wrote:



On 5/13/2017 12:40 AM, Gustavo Padovan wrote:

From: Gustavo Padovan 

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.


Works well on DB820c (which has a APQ8096 SoC).

Tested-by: Archit Taneja 


Actually, after some more thorough testing, I found one issue, mentioned below.





v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Rob Clark 
Signed-off-by: Gustavo Padovan 
---
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 151 +-
  1 file changed, 63 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index a38c5fe..07106c1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -33,15 +33,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
  struct drm_crtc *crtc, struct drm_framebuffer *fb,
  struct drm_rect *src, struct drm_rect *dest);
  -static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h,
-struct drm_modeset_acquire_ctx *ctx);
-
  static struct mdp5_kms *get_kms(struct drm_plane *plane)
  {
  struct msm_drm_private *priv = plane->dev->dev_private;
@@ -257,7 +248,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
  };
static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
-.update_plane = mdp5_update_cursor_plane_legacy,
+.update_plane = drm_atomic_helper_update_plane,
  .disable_plane = drm_atomic_helper_disable_plane,
  .destroy = mdp5_plane_destroy,
  .set_property = drm_atomic_helper_plane_set_property,
@@ -484,11 +475,73 @@ static void mdp5_plane_atomic_update(struct drm_plane 
*plane,
  }
  }
  +static int mdp5_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+struct drm_crtc_state *crtc_state;
+
+crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+state->crtc);


I see a kernel splat here (a NULL pointer dereference). The async_check
function assumes that there is always going to be a plane_state->crtc
available. This doesn't seem to be the case at least in the
drm_atomic_helper_disable_plane() path. Moving the check to set
legacy_cursor_update after calling __drm_atomic_helper_disable_plane()
seems to fix the issue. Do you think it's a legit fix?

One more point w.r.t msm driver is that we don't use the default
drm_atomic_helper_commit() for our atomic_commit op. So I had to
call drm_atomic_helper_async_commit() from our atomic_commit
implementation
(i.e, in msm_atomic_commit in drivers/gpu/drm/msm/msm_atomic.c)

Thanks,
Archit


+if (WARN_ON(!crtc_state))
+return -EINVAL;
+
+if (!crtc_state->active)
+return -EINVAL;
+
+mdp5_state = to_mdp5_plane_state(state);
+
+/* don't use fast path if we don't have a hwpipe allocated yet */
+if (!mdp5_state->hwpipe)
+return -EINVAL;
+
+/* only allow changing of position(crtc x/y or src x/y) in fast path */
+if (plane->state->crtc != state->crtc ||
+plane->state->src_w != state->src_w ||
+plane->state->src_h != state->src_h ||
+plane->state->crtc_w != state->crtc_w ||
+plane->state->crtc_h != state->crtc_h ||
+!plane->state->fb ||
+plane->state->fb != state->fb)
+return -EINVAL;
+
+return 0;
+}
+
+static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
+   struct drm_plane_state *new_state)
+{
+plane->state->src_x = new_state->src_x;
+plane->state->src_y = new_state->src_y;
+plane->state->crtc_x = new_state->crtc_x;
+plane->state->crtc_y = new_state->crtc_y;
+
+if (plane_enabled(new_state)) {
+struct mdp5_ctl *ctl;
+struct mdp5_pipeline *pipeline =
+mdp5_crtc_get_pipeline(plane->crtc);
+int ret;
+
+ret = mdp5_plane_mode_set(plane, new_state->crtc, new_state->fb,
+_state->src, _state->dst);
+WARN_ON(ret < 0);
+
+ctl = mdp5_crtc_get_ctl(new_state->crtc);
+
+mdp5_ctl_commit(ctl, pipeline, mdp5_plane_get_flush(plane));
+}
+
+*to_mdp5_plane_state(plane->state) =
+*to_mdp5_plane_state(new_state);
+}
+
  static const struct drm_plane_helper_funcs 

[Bug 101029] notebook does not work when not booted using nomodeset AMD APU

[bugzilla-daemon]

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

--- Comment #13 from Craig  ---
Created attachment 131381
  --> https://bugs.freedesktop.org/attachment.cgi?id=131381=edit
Kernel Log

-- 
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 101029] notebook does not work when not booted using nomodeset AMD APU

[bugzilla-daemon]

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

--- Comment #12 from Craig  ---
Created attachment 131380
  --> https://bugs.freedesktop.org/attachment.cgi?id=131380=edit
Syslog

-- 
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 101029] notebook does not work when not booted using nomodeset AMD APU

[bugzilla-daemon]

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

--- Comment #11 from Craig  ---
ok I added the modprobe.blacklist=amdgpu to the kernel command line, wouldnt
boot until I also added modprobe.blacklist=radeon. Anyways once I was in I did
run sudo modprobe amdgpu and got the usual "AMD-Vi: Completion-Wait loop timed
out" amongst other errors.  It did log some strange things in kern.log and
syslog. I also ran dmesg -k >/home/craig/DMESG.txt and it created a file with
nothing in it. I will attach the kern.log and syslog... not sure if that helps,
as you can see i am very new at doing this kind of thing.

-- 
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 101029] notebook does not work when not booted using nomodeset AMD APU

[bugzilla-daemon]

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

--- Comment #10 from Michel Dänzer  ---
Okay, I guess we need to try another trick: Boot with

 modprobe.blacklist=amdgpu

on the kernel command line to prevent the amdgpu module from being loaded
automatically. Once the system is booted up, manually run

 sudo modprobe amdgpu

This should increase the chance of capturing the dmesg output somewhere.

-- 
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 101029] notebook does not work when not booted using nomodeset AMD APU

[bugzilla-daemon]

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

--- Comment #9 from Craig  ---
Created attachment 131379
  --> https://bugs.freedesktop.org/attachment.cgi?id=131379=edit
Bootup Screenshot 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

[Bug 101029] notebook does not work when not booted using nomodeset AMD APU

[bugzilla-daemon]

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

--- Comment #8 from Craig  ---
Created attachment 131378
  --> https://bugs.freedesktop.org/attachment.cgi?id=131378=edit
Bootup Screenshot 2

-- 
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 101029] notebook does not work when not booted using nomodeset AMD APU

[bugzilla-daemon]

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

--- Comment #7 from Craig  ---
(In reply to Craig from comment #6)
> Created attachment 131377 [details]
> Bootup Screenshot

I am running Ubuntu 17.04. Anyways I have checked through the logs (kern.log,
syslog  and it appears that the last time it recorded anything in them was when
I was using "nomodeset" on bootup.  I have attached screenshots of what I get
when I boot up without nomodeset as a parameter.  Is it possible that it is not
writing to disk when I bootup without "nomodeset"? There is no dmesg log in the
/var/log folder. It appears that I could use journalctl -b but that only works
if I am able to boot into the system or the dmesg command but also needs to be
able to boot into it to run that.

-- 
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 101029] notebook does not work when not booted using nomodeset AMD APU

[bugzilla-daemon]

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

--- Comment #6 from Craig  ---
Created attachment 131377
  --> https://bugs.freedesktop.org/attachment.cgi?id=131377=edit
Bootup Screenshot

-- 
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 101029] notebook does not work when not booted using nomodeset AMD APU

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer  ---
(In reply to Craig from comment #4)
> Does Dmesg log to a file somewhere?

Depending on your distro, it might be captured in /var/log/kern.log*,
/var/log/dmesg*, or in the systemd journal.

-- 
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 101029] notebook does not work when not booted using nomodeset AMD APU

[bugzilla-daemon]

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

--- Comment #4 from Craig  ---
(In reply to Michel Dänzer from comment #3)
> Comment on attachment 131361 [details]
> CurrentDMesg
> 
> This dmesg is with nomodeset, so it doesn't contain any information related
> to the problem.
> 
> Please attach the dmesg output from an attempt without nomodeset.

I am not sure how to get a dmesg out of it.  Does Dmesg log to a file
somewhere?  I can't boot into the OS and output anything to text file as it
just provides a "AMD-Vi: Completion-Wait loop timed out" and a bunch of disk
checks that kept failing never allowing me to logon.  I left it for 8-9 hours
and i was still unable to do anything with the system other than a
Ctrl-Alt-SysRq REISUB.

Please let me know how to proceed.

thanks

-- 
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 v5 3/3] drm/i915: Add format modifiers for Intel

[Emil Velikov]

Hi Ben,

A couple of small questions/suggestions that I hope you find useful.
Please don't block any of this work based on my comments.

On 16 May 2017 at 22:31, Ben Widawsky  wrote:

> +static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
> +uint32_t format,
> +uint64_t modifier)
> +{
> +   struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +
> +   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> +   return false;
> +
> +   if (INTEL_GEN(dev_priv) >= 9)
> +   return skl_mod_supported(format, modifier);
> +   else if (INTEL_GEN(dev_priv) >= 4)
> +   return i965_mod_supported(format, modifier);
> +   else
> +   return i8xx_mod_supported(format, modifier);
> +
Nit: if you rewrite this as below, the control flow should be clearer.
Thus the 'return false;' at the end, will be [more] obvious that it's
unreachable ;-)

   if (INTEL_GEN(dev_priv) >= 9)
   return skl_mod_supported(format, modifier);

   if (INTEL_GEN(dev_priv) >= 4)
   return i965_mod_supported(format, modifier);

   return i8xx_mod_supported(format, modifier);


> +   return false;
> +}
> +


> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c

> +static bool intel_sprite_plane_format_mod_supported(struct drm_plane *plane,
> +uint32_t format,
> +uint64_t modifier)
> +{
> +   struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +
> +   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> +   return false;
> +
> +   BUG_ON(plane->base.type != DRM_PLANE_TYPE_OVERLAY);
> +
> +   switch (format) {
> +   case DRM_FORMAT_XBGR2101010:
> +   case DRM_FORMAT_ABGR2101010:
> +   if (IS_VALLEYVIEW(dev_priv) || 
> IS_CHERRYVIEW(dev_priv))
> +   return true;
> +   break;
> +   case DRM_FORMAT_RGB565:
> +   case DRM_FORMAT_ABGR:
> +   case DRM_FORMAT_ARGB:
> +   if (INTEL_GEN(dev_priv) >= 9 || 
> IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> +   return true;
> +   break;
> +   case DRM_FORMAT_XBGR:
> +   if (INTEL_GEN(dev_priv) >= 6)
> +   return true;
> +   break;
> +   case DRM_FORMAT_XRGB:
> +   case DRM_FORMAT_YUYV:
> +   case DRM_FORMAT_YVYU:
> +   case DRM_FORMAT_UYVY:
> +   case DRM_FORMAT_VYUY:
> +   return true;
> +   }
> +
> +   return false;
> +}
> +
> +const struct drm_plane_funcs intel_sprite_plane_funcs = {
> +.update_plane = drm_atomic_helper_update_plane,
> +.disable_plane = drm_atomic_helper_disable_plane,
> +.destroy = intel_plane_destroy,
> +.set_property = drm_atomic_helper_plane_set_property,
> +.atomic_get_property = intel_plane_atomic_get_property,
> +.atomic_set_property = intel_plane_atomic_set_property,
> +.atomic_duplicate_state = intel_plane_duplicate_state,
> +.atomic_destroy_state = intel_plane_destroy_state,
> +.format_mod_supported = intel_sprite_plane_format_mod_supported,
> +};
> +
Having a dull moment - is intel_sprite_plane_funcs (+
intel_sprite_plane_format_mod_supported) unused or I'm seeing things?
If one is to keep it, for future work, perhaps it's worth adding a 2-3
word comment,

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

Re: [Intel-gfx] [PATCH v2 2/3] drm: Create a format/modifier blob

[Emil Velikov]

Hi Ben,

On 16 May 2017 at 22:31, Ben Widawsky  wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
>
> v2:
> * Removed __packed, and alignment (.+)
> * Fix indent in drm_format_modifier fields (Liviu)
> * Remove duplicated modifier > 64 check (Liviu)
> * Change comment about modifier (Liviu)
> * Remove arguments to blob creation, use plane instead (Liviu)
> * Fix data types (Ben)
> * Make the blob part of uapi (Daniel)
>
> Cc: Rob Clark 
> Cc: Daniel Stone 
> Cc: Kristian H. Kristensen 
> Cc: Liviu Dudau 
> Signed-off-by: Ben Widawsky 
> Reviewed-by: Daniel Stone 

I think this is almost perfect, barring the UAPI nitpick.
The rest is somewhat of a bikeshedding.

With the UAPI resolved, regardless of the rest
Reviewed-by: Emil Velikov 


> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c

> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
> *plane)
> +{
> +   const struct drm_mode_config *config = >mode_config;
> +   const uint64_t *temp_modifiers = plane->modifiers;
> +   unsigned int format_modifier_count = 0;
> +   struct drm_property_blob *blob = NULL;
> +   struct drm_format_modifier *mod;
> +   size_t blob_size = 0, formats_size, modifiers_size;
There's no need to initialize blob and blob_size here.

> +   struct drm_format_modifier_blob *blob_data;
> +   int i, j, ret = 0;
Make i and j unsigned to match format_modifier_count and
plane->format_count respectively.
Then expand ret in the only place where it's used?

> +
> +   if (plane->modifiers)
> +   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> +   format_modifier_count++;
> +
> +   formats_size = sizeof(*plane->format_types) * plane->format_count;
> +   if (WARN_ON(!formats_size)) {
> +   /* 0 formats are never expected */
> +   return 0;
> +   }
> +
> +   modifiers_size =
> +   sizeof(struct drm_format_modifier) * format_modifier_count;
> +
> +   blob_size = sizeof(struct drm_format_modifier_blob);
> +   blob_size += ALIGN(formats_size, 8);
Worth having the "Modifiers offset is a pointer..." comment moved/copied here?

> +   blob_size += modifiers_size;
> +
> +   blob = drm_property_create_blob(dev, blob_size, NULL);
> +   if (IS_ERR(blob))
> +   return -1;
> +
Maybe propagate the exact error... Hmm we don't seem to check if
create_in_format_blob fails either so perhaps it's not worth it.


> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -665,6 +665,56 @@ struct drm_mode_atomic {
> __u64 user_data;
>  };
>
> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> +   /* Version of this blob format */
> +   u32 version;
> +
> +   /* Flags */
> +   u32 flags;
> +
> +   /* Number of fourcc formats supported */
> +   u32 count_formats;
> +
> +   /* Where in this blob the formats exist (in bytes) */
> +   u32 formats_offset;
> +
> +   /* Number of drm_format_modifiers */
> +   u32 count_modifiers;
> +
> +   /* Where in this blob the modifiers exist (in bytes) */
> +   u32 modifiers_offset;
> +
> +   /* u32 formats[] */
> +   /* struct drm_format_modifier modifiers[] */
> +};
> +
> +struct drm_format_modifier {
> +   /* Bitmask of formats in get_plane format list this info applies to. 
> The
> +* offset allows a sliding window of which 64 formats (bits).
> +*
> +* Some examples:
> +* In today's world with < 65 formats, and formats 0, and 2 are
> +* supported
> +* 0x0005
> +*^-offset = 0, formats = 5
> +*
> +* If the number formats grew to 128, and formats 98-102 are
> +* supported with the modifier:
> +*
> +* 0x003c 
> +*^
> +*|__offset = 64, formats = 0x3c
> +*
> +*/
> +   __u64 formats;
> +   __u32 offset;
> +   __u32 pad;
> +
> +   /* The modifier that applies to the >get_plane format list bitmask. */
> +   __u64 modifier;
Please drop the leading __ from the type names in UAPI headers.

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

Re: [PATCH v2 2/3] drm: Create a format/modifier blob

[Liviu Dudau]

On Tue, May 16, 2017 at 02:31:25PM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
> 
> v2:
> * Removed __packed, and alignment (.+)
> * Fix indent in drm_format_modifier fields (Liviu)
> * Remove duplicated modifier > 64 check (Liviu)
> * Change comment about modifier (Liviu)
> * Remove arguments to blob creation, use plane instead (Liviu)
> * Fix data types (Ben)
> * Make the blob part of uapi (Daniel)

Thanks for updating the patch!

> 
> Cc: Rob Clark 
> Cc: Daniel Stone 
> Cc: Kristian H. Kristensen 
> Cc: Liviu Dudau 
> Signed-off-by: Ben Widawsky 
> Reviewed-by: Daniel Stone 

Looks good to me!
Reviewed-by: Liviu Dudau 

Best regards,
Liviu

> ---
>  drivers/gpu/drm/drm_mode_config.c |  7 +++
>  drivers/gpu/drm/drm_plane.c   | 89 
> +++
>  include/drm/drm_mode_config.h |  6 +++
>  include/uapi/drm/drm_mode.h   | 50 ++
>  4 files changed, 152 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index d9862259a2a7..6bfbc3839df5 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.gamma_lut_size_property = prop;
>  
> + prop = drm_property_create(dev,
> +DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
> +"IN_FORMATS", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.modifiers = prop;
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 20203871e06d..f5b032b5f761 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -62,6 +62,92 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>   return num;
>  }
>  
> +static inline u32 *
> +formats_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (u32 *)(((char *)blob) + blob->formats_offset);
> +}
> +
> +static inline struct drm_format_modifier *
> +modifiers_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (struct drm_format_modifier *)(((char *)blob) + 
> blob->modifiers_offset);
> +}
> +
> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
> *plane)
> +{
> + const struct drm_mode_config *config = >mode_config;
> + const uint64_t *temp_modifiers = plane->modifiers;
> + unsigned int format_modifier_count = 0;
> + struct drm_property_blob *blob = NULL;
> + struct drm_format_modifier *mod;
> + size_t blob_size = 0, formats_size, modifiers_size;
> + struct drm_format_modifier_blob *blob_data;
> + int i, j, ret = 0;
> +
> + if (plane->modifiers)
> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> + format_modifier_count++;
> +
> + formats_size = sizeof(*plane->format_types) * plane->format_count;
> + if (WARN_ON(!formats_size)) {
> + /* 0 formats are never expected */
> + return 0;
> + }
> +
> + modifiers_size =
> + sizeof(struct drm_format_modifier) * format_modifier_count;
> +
> + blob_size = sizeof(struct drm_format_modifier_blob);
> + blob_size += ALIGN(formats_size, 8);
> + blob_size += modifiers_size;
> +
> + blob = drm_property_create_blob(dev, blob_size, NULL);
> + if (IS_ERR(blob))
> + return -1;
> +
> + blob_data = (struct drm_format_modifier_blob *)blob->data;
> + blob_data->version = FORMAT_BLOB_CURRENT;
> + blob_data->count_formats = plane->format_count;
> + blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
> + blob_data->count_modifiers = format_modifier_count;
> +
> + /* Modifiers offset is a pointer to a struct with a 64 bit field so it
> +  * should be naturally aligned to 8B.
> +  */
> + blob_data->modifiers_offset =
> + ALIGN(blob_data->formats_offset + formats_size, 8);
> +
> + memcpy(formats_ptr(blob_data), plane->format_types, formats_size);
> +
> + /* If we can't determine support, just bail */
> + if (!plane->funcs->format_mod_supported)
> + goto done;
> +
> + mod = modifiers_ptr(blob_data);
> + for (i = 0; i < format_modifier_count; i++) {
> + for (j = 0; j < plane->format_count; j++) {
> + if (plane->funcs->format_mod_supported(plane,
> +
> plane->format_types[j],
> +
> plane->modifiers[i])) {
> +
> + mod->formats |= 1 << j;
> + }
> + }
> +
> +   

[PATCH v2 0/5] R-Car DU: Fix IOMMU operation when connected to VSP

[Laurent Pinchart]

Hello,

This patch series fixes the rcar-du-drm driver to support VSP plane sources
with an IOMMU. It is available for convenience at

git://linuxtv.org/pinchartl/media.git iommu/devel/du

On R-Car Gen3 the DU has no direct memory access but sources planes through
VSP instances. When an IOMMU is inserted between the VSP and memory, the DU
framebuffers need to be DMA mapped using the VSP device, not the DU device as
currently done. The same situation can also be reproduced on Gen2 hardware by
linking the VSP to the DU in DT [1], effectively disabling direct memory
access by the DU.

The situation is made quite complex by the fact that different planes can be
connected to different DU instances, and thus served by different IOMMUs (or,
in practice on existing hardware, by the same IOMMU but through different
micro-TLBs). We thus can't allocate and map buffers to the right device in a
single dma_alloc_wc() operation as done in the DRM CMA GEM helpers.

However, on such setups, the DU DT node doesn't reference IOMMUs as the DU
does not perform any direct memory access. We can thus keep the GEM object
allocation unchanged, and the DMA addresses that we receive in the DU driver
will be physical addresses. Those buffers then need to be mapped to the VSP
device when they are associated with planes. Fortunately the atomic framework
provides two plane helper operations, .prepare_fb() and .cleanup_fb() that we
can use for this purpose.

The reality is slightly more complex than this on Gen3, as an FCP device
instance sits between VSP instances and memory. It is the FCP devices that are
connected to the IOMMUs, and buffer mapping thus need to be performed using
the FCP devices. This isn't required on Gen2 as the platforms don't have any
FCPs.

Patches 1/5 and 2/5 extend the rcar-fcp driver API to expose the FCP struct
device. Patch 3/5 then updates the vsp1 driver to map the display lists and
video buffers through the FCP when it exists. This alone fixes VSP operation
with an IOMMU on R-Car Gen3 systems.

Moving on to addressing the DU issue, patch 4/5 extends the vsp1 driver API to
allow mapping a scatter-gather list to the VSP, with the implementation using
the FCP devices instead when available. Patch 5/5 finally uses the vsp1
mapping API in the rcar-du-drm driver to map and unmap buffers when needed.

The series has been tested on the H2 Lager board and M3-W Salvator-X boards.
The IOMMU is known not to work properly on the H3 ES1.1, so the H3 Salvator-X
board hasn't been tested. In all cases both the DU and VSP operation has been
tested, and tests were run with and without linking the DU and VSP devices to
the IOMMU in DT.

For H2, the patches were tested on top of v4.12-rc1 with a set of out-of-tree
patches to link the VSP and DU to the IOMMUs and to enable VSP+DU combined
similar to R-Car Gen3, and an additional DMA mapping API patch [2] that fixes
IOMMU operation on ARM32, currently broken in v4.12-rc1. For M3-W, they were
were tested on top of renesas-drivers-2017-05-16-v4.12-rc1 with a set of
out-of-tree patches to add FCP, VSP, DU and IPMMU instances to the M3-W DT, as
well as a hack for the IPMMU driver to whitelist all bus master devices.

All tests passed successfully. The issue previously noticed on H3 with
synchronization between page flip and VSP operation that was caused by buffers
getting unmapped (and possibly freed) before the VSP was done reading them is
now gone thanks to the VSP+DU flicker fix that should be merged in v4.13 and
is available in renesas-drivers-2017-05-16-v4.12-rc1.

A possible improvement is to modify the GEM object allocation mechanism to use
non-contiguous memory when the DU driver detects that all the VSP instances it
is connected to use an IOMMU (possibly through FCP devices).

[1] https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg06589.html
[2] https://www.spinics.net/lists/arm-kernel/msg581410.html

Laurent Pinchart (4):
  v4l: rcar-fcp: Don't get/put module reference
  v4l: rcar-fcp: Add an API to retrieve the FCP device
  v4l: vsp1: Add API to map and unmap DRM buffers through the VSP
  drm: rcar-du: Map memory through the VSP device

Magnus Damm (1):
  v4l: vsp1: Map the DL and video buffers through the proper bus master

 drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 74 +---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h|  2 +
 drivers/media/platform/rcar-fcp.c| 17 
 drivers/media/platform/vsp1/vsp1.h   |  1 +
 drivers/media/platform/vsp1/vsp1_dl.c|  4 +-
 drivers/media/platform/vsp1/vsp1_drm.c   | 25 +++
 drivers/media/platform/vsp1/vsp1_drv.c   |  9 
 drivers/media/platform/vsp1/vsp1_video.c |  2 +-
 include/media/rcar-fcp.h |  5 +++
 include/media/vsp1.h |  3 ++
 10 files changed, 124 insertions(+), 18 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v2 3/5] v4l: vsp1: Map the DL and video buffers through the proper bus master

[Laurent Pinchart]

From: Magnus Damm 

On Gen2 hardware the VSP1 is a bus master and accesses the display list
and video buffers through DMA directly. On Gen3 hardware, however,
memory accesses go through a separate IP core called FCP.

The VSP1 driver unconditionally maps DMA buffers through the VSP device.
While this doesn't cause any practical issue so far, DMA mappings will
be incorrect as soon as we will enable IOMMU support for the FCP on Gen3
platforms, resulting in IOMMU faults.

Fix this by mapping all buffers through the FCP device if present, and
through the VSP1 device as usual otherwise.

Suggested-by: Magnus Damm 
[Cache the bus master device]
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1.h   | 1 +
 drivers/media/platform/vsp1/vsp1_dl.c| 4 ++--
 drivers/media/platform/vsp1/vsp1_drv.c   | 9 +
 drivers/media/platform/vsp1/vsp1_video.c | 2 +-
 4 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 85387a64179a..847963b6e9eb 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -74,6 +74,7 @@ struct vsp1_device {
 
void __iomem *mmio;
struct rcar_fcp_device *fcp;
+   struct device *bus_master;
 
struct vsp1_bru *bru;
struct vsp1_clu *clu;
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 7d8f37772b56..445d1c31fff3 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -137,7 +137,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
dlb->vsp1 = vsp1;
dlb->size = size;
 
-   dlb->entries = dma_alloc_wc(vsp1->dev, dlb->size, >dma,
+   dlb->entries = dma_alloc_wc(vsp1->bus_master, dlb->size, >dma,
GFP_KERNEL);
if (!dlb->entries)
return -ENOMEM;
@@ -150,7 +150,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
  */
 static void vsp1_dl_body_cleanup(struct vsp1_dl_body *dlb)
 {
-   dma_free_wc(dlb->vsp1->dev, dlb->size, dlb->entries, dlb->dma);
+   dma_free_wc(dlb->vsp1->bus_master, dlb->size, dlb->entries, dlb->dma);
 }
 
 /**
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 048446af5ae7..95c26edead85 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -764,6 +764,15 @@ static int vsp1_probe(struct platform_device *pdev)
PTR_ERR(vsp1->fcp));
return PTR_ERR(vsp1->fcp);
}
+
+   /*
+* When the FCP is present, it handles all bus master accesses
+* for the VSP and must thus be used in place of the VSP device
+* to map DMA buffers.
+*/
+   vsp1->bus_master = rcar_fcp_get_device(vsp1->fcp);
+   } else {
+   vsp1->bus_master = vsp1->dev;
}
 
/* Configure device parameters based on the version register. */
diff --git a/drivers/media/platform/vsp1/vsp1_video.c 
b/drivers/media/platform/vsp1/vsp1_video.c
index eab3c3ea85d7..5af3486afe07 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -1197,7 +1197,7 @@ struct vsp1_video *vsp1_video_create(struct vsp1_device 
*vsp1,
video->queue.ops = _video_queue_qops;
video->queue.mem_ops = _dma_contig_memops;
video->queue.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
-   video->queue.dev = video->vsp1->dev;
+   video->queue.dev = video->vsp1->bus_master;
ret = vb2_queue_init(>queue);
if (ret < 0) {
dev_err(video->vsp1->dev, "failed to initialize vb2 queue\n");
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 1/5] v4l: rcar-fcp: Don't get/put module reference

[Laurent Pinchart]

Direct callers of the FCP API hold a reference to the FCP module due to
module linkage, there's no need to take another one manually. Take a
reference to the device instead to ensure that it won't disappear behind
the caller's back.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-fcp.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/rcar-fcp.c 
b/drivers/media/platform/rcar-fcp.c
index 7146fc5ef168..e9f609edf513 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -53,14 +53,7 @@ struct rcar_fcp_device *rcar_fcp_get(const struct 
device_node *np)
if (fcp->dev->of_node != np)
continue;
 
-   /*
-* Make sure the module won't be unloaded behind our back. This
-* is a poor man's safety net, the module should really not be
-* unloaded while FCP users can be active.
-*/
-   if (!try_module_get(fcp->dev->driver->owner))
-   fcp = NULL;
-
+   get_device(fcp->dev);
goto done;
}
 
@@ -81,7 +74,7 @@ EXPORT_SYMBOL_GPL(rcar_fcp_get);
 void rcar_fcp_put(struct rcar_fcp_device *fcp)
 {
if (fcp)
-   module_put(fcp->dev->driver->owner);
+   put_device(fcp->dev);
 }
 EXPORT_SYMBOL_GPL(rcar_fcp_put);
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 2/5] v4l: rcar-fcp: Add an API to retrieve the FCP device

[Laurent Pinchart]

The new rcar_fcp_get_device() function retrieves the struct device
related to the FCP device. This is useful to handle DMA mapping through
the right device.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/rcar-fcp.c | 6 ++
 include/media/rcar-fcp.h  | 5 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/media/platform/rcar-fcp.c 
b/drivers/media/platform/rcar-fcp.c
index e9f609edf513..2988031d285d 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -78,6 +78,12 @@ void rcar_fcp_put(struct rcar_fcp_device *fcp)
 }
 EXPORT_SYMBOL_GPL(rcar_fcp_put);
 
+struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp)
+{
+   return fcp->dev;
+}
+EXPORT_SYMBOL_GPL(rcar_fcp_get_device);
+
 /**
  * rcar_fcp_enable - Enable an FCP
  * @fcp: The FCP instance
diff --git a/include/media/rcar-fcp.h b/include/media/rcar-fcp.h
index 8723f05c6321..b60a7b176c37 100644
--- a/include/media/rcar-fcp.h
+++ b/include/media/rcar-fcp.h
@@ -19,6 +19,7 @@ struct rcar_fcp_device;
 #if IS_ENABLED(CONFIG_VIDEO_RENESAS_FCP)
 struct rcar_fcp_device *rcar_fcp_get(const struct device_node *np);
 void rcar_fcp_put(struct rcar_fcp_device *fcp);
+struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp);
 int rcar_fcp_enable(struct rcar_fcp_device *fcp);
 void rcar_fcp_disable(struct rcar_fcp_device *fcp);
 #else
@@ -27,6 +28,10 @@ static inline struct rcar_fcp_device *rcar_fcp_get(const 
struct device_node *np)
return ERR_PTR(-ENOENT);
 }
 static inline void rcar_fcp_put(struct rcar_fcp_device *fcp) { }
+static inline struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp)
+{
+   return NULL;
+}
 static inline int rcar_fcp_enable(struct rcar_fcp_device *fcp)
 {
return 0;
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device

[Laurent Pinchart]

For planes handled by a VSP instance, map the framebuffer memory through
the VSP to ensure proper IOMMU handling.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 74 ---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h |  2 +
 2 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..1b874cfd40f3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -19,7 +19,9 @@
 #include 
 #include 
 
+#include 
 #include 
+#include 
 #include 
 
 #include 
@@ -170,12 +172,9 @@ static void rcar_du_vsp_plane_setup(struct 
rcar_du_vsp_plane *plane)
cfg.dst.width = state->state.crtc_w;
cfg.dst.height = state->state.crtc_h;
 
-   for (i = 0; i < state->format->planes; ++i) {
-   struct drm_gem_cma_object *gem;
-
-   gem = drm_fb_cma_get_gem_obj(fb, i);
-   cfg.mem[i] = gem->paddr + fb->offsets[i];
-   }
+   for (i = 0; i < state->format->planes; ++i)
+   cfg.mem[i] = sg_dma_address(state->sg_tables[i].sgl)
+  + fb->offsets[i];
 
for (i = 0; i < ARRAY_SIZE(formats_kms); ++i) {
if (formats_kms[i] == state->format->fourcc) {
@@ -187,6 +186,67 @@ static void rcar_du_vsp_plane_setup(struct 
rcar_du_vsp_plane *plane)
vsp1_du_atomic_update(plane->vsp->vsp, plane->index, );
 }
 
+static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+   struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+   struct rcar_du_device *rcdu = vsp->dev;
+   unsigned int i;
+   int ret;
+
+   if (!state->fb)
+   return 0;
+
+   for (i = 0; i < rstate->format->planes; ++i) {
+   struct drm_gem_cma_object *gem =
+   drm_fb_cma_get_gem_obj(state->fb, i);
+   struct sg_table *sgt = >sg_tables[i];
+
+   ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr, gem->paddr,
+ gem->base.size);
+   if (ret)
+   goto fail;
+
+   ret = vsp1_du_map_sg(vsp->vsp, sgt);
+   if (!ret) {
+   sg_free_table(sgt);
+   ret = -ENOMEM;
+   goto fail;
+   }
+   }
+
+   return 0;
+
+fail:
+   for (i--; i >= 0; i--) {
+   struct sg_table *sgt = >sg_tables[i];
+
+   vsp1_du_unmap_sg(vsp->vsp, sgt);
+   sg_free_table(sgt);
+   }
+
+   return ret;
+}
+
+static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+   struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+   struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+   unsigned int i;
+
+   if (!state->fb)
+   return;
+
+   for (i = 0; i < rstate->format->planes; ++i) {
+   struct sg_table *sgt = >sg_tables[i];
+
+   vsp1_du_unmap_sg(vsp->vsp, sgt);
+   sg_free_table(sgt);
+   }
+}
+
 static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
  struct drm_plane_state *state)
 {
@@ -227,6 +287,8 @@ static void rcar_du_vsp_plane_atomic_update(struct 
drm_plane *plane,
 }
 
 static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = {
+   .prepare_fb = rcar_du_vsp_plane_prepare_fb,
+   .cleanup_fb = rcar_du_vsp_plane_cleanup_fb,
.atomic_check = rcar_du_vsp_plane_atomic_check,
.atomic_update = rcar_du_vsp_plane_atomic_update,
 };
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index f1d0f1824528..8861661590ff 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -43,6 +43,7 @@ static inline struct rcar_du_vsp_plane 
*to_rcar_vsp_plane(struct drm_plane *p)
  * struct rcar_du_vsp_plane_state - Driver-specific plane state
  * @state: base DRM plane state
  * @format: information about the pixel format used by the plane
+ * @sg_tables: scatter-gather tables for the frame buffer memory
  * @alpha: value of the plane alpha property
  * @zpos: value of the plane zpos property
  */
@@ -50,6 +51,7 @@ struct rcar_du_vsp_plane_state {
struct drm_plane_state state;
 
const struct rcar_du_format_info *format;
+   struct sg_table sg_tables[3];
 
unsigned int alpha;
unsigned int zpos;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v2 4/5] v4l: vsp1: Add API to map and unmap DRM buffers through the VSP

[Laurent Pinchart]

The display buffers must be mapped for DMA through the device that
performs memory access. Expose an API to map and unmap memory through
the VSP device to be used by the DU.

As all the buffers allocated by the DU driver are coherent, we can skip
cache handling when mapping and unmapping them. This will need to be
revisited when support for non-coherent buffers will be added to the DU
driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 25 +
 include/media/vsp1.h   |  3 +++
 2 files changed, 28 insertions(+)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 9d235e830f5a..c809c2aadca0 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -12,9 +12,11 @@
  */
 
 #include 
+#include 
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -524,6 +526,29 @@ void vsp1_du_atomic_flush(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(vsp1_du_atomic_flush);
 
+int vsp1_du_map_sg(struct device *dev, struct sg_table *sgt)
+{
+   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
+
+   /*
+* As all the buffers allocated by the DU driver are coherent, we can
+* skip cache sync. This will need to be revisited when support for
+* non-coherent buffers will be added to the DU driver.
+*/
+   return dma_map_sg_attrs(vsp1->bus_master, sgt->sgl, sgt->nents,
+   DMA_TO_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);
+}
+EXPORT_SYMBOL_GPL(vsp1_du_map_sg);
+
+void vsp1_du_unmap_sg(struct device *dev, struct sg_table *sgt)
+{
+   struct vsp1_device *vsp1 = dev_get_drvdata(dev);
+
+   dma_unmap_sg_attrs(vsp1->bus_master, sgt->sgl, sgt->nents,
+  DMA_TO_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);
+}
+EXPORT_SYMBOL_GPL(vsp1_du_unmap_sg);
+
 /* 
-
  * Initialization
  */
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 38aac554dbba..6aa630c9f7af 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -13,6 +13,7 @@
 #ifndef __MEDIA_VSP1_H__
 #define __MEDIA_VSP1_H__
 
+#include 
 #include 
 #include 
 
@@ -46,5 +47,7 @@ void vsp1_du_atomic_begin(struct device *dev);
 int vsp1_du_atomic_update(struct device *dev, unsigned int rpf,
  const struct vsp1_du_atomic_config *cfg);
 void vsp1_du_atomic_flush(struct device *dev);
+int vsp1_du_map_sg(struct device *dev, struct sg_table *sgt);
+void vsp1_du_unmap_sg(struct device *dev, struct sg_table *sgt);
 
 #endif /* __MEDIA_VSP1_H__ */
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v7 0/5] replace hwmon_device_register for hwmon_device_register_with_info

[Ben Skeggs]

On 05/17/2017 07:18 AM, Oscar Salvador wrote:

This v7 fixes removes dummy functions which only had a return and moves the code
into the switch statements.

Hey Oscar,

I see new warnings with this series:

/home/skeggsb/git/nouveau/drm/nouveau/nouveau_hwmon.c:645:8: warning: 
assignment discards ‘const’ qualifier from pointer target type 
[-Wdiscarded-qualifiers]

   *buf = input_label;

and

/home/skeggsb/git/nouveau/drm/nouveau/nouveau_hwmon.c:200:18: warning: 
‘pwm_fan_sensor_groups’ defined but not used [-Wunused-variable]


The second one also warns for temp1_auto_point_sensor_groups too.

Thanks,
Ben.



Versions:

v1 -> v2:
 * Keep temp attrs as read only
v2 -> v3:
 * Code fix-ups: struct and string as const and add return within switch
 due to fallthrough
 * Add Signed-off-by to all commits
v3 -> v4:
 * Rever const to struct attribute. Kbuild complains.
v4 -> v5:
 * Drops a check for attr_set in "nouveau_temp_is_visible".
v5 -> v6:
* Change to nouveau/hwmon all commit titles
* Drop author change
* Coding-Style
* Move the check before the switch in nouveau_power_is_visible function
* Expose temperature attrs as RW again
* Get rid of nouveau_hwmon_set_pwm1/_enable and implement the code 
inside
nouveau_pwm_write
* Get rid of nouveau_hwmon_set_temp_* and implement the code inside
nouveau_temp_write
v6 -> v7:
* Got rid of all dummy functions that only had a return, and moved
code into the switch statements.


This patchseries replaces the deprecated hwmon_device_register function with the
new one hwmon_device_register_with_info.
It also does some cleanup.

Oscar Salvador (5):
   nouveau/hwmon: Add config for all sensors and their settings
   nouveau/hwmon: Add nouveau_hwmon_ops structure with
 .is_visible/.read_string
   nouveau/hwmon: Remove old code, add .write/.read operations
   nouveau/hwmon: expose the auto_point and pwm_min/max attrs
   nouveau/hwmon: Change permissions to numeric

  drivers/gpu/drm/nouveau/nouveau_hwmon.c | 979 +++-
  1 file changed, 460 insertions(+), 519 deletions(-)


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

[Bug 100577] DC + TearFree display lock

[bugzilla-daemon]

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

--- Comment #6 from Andy Furniss  ---
Testing current amd-staging-4.9 + patch from Bug 101053 I can't reproduce this
anymore.

It was a couple of hours running, I'll try longer and with 4.11 over the next
few days and either reconfirm or close this.

-- 
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] fix spelling mistake: "dimesions" -> "dimensions"

[Eric Anholt]

Colin King  writes:

> From: Colin Ian King 
>
> Trivial fix to spelling mistake in DRM_ERROR message and split
> over two lines to clean up a "line over 80 characters" checkpatch
> warning.

Added "drm/vc4" to the commit summary, and pushed.  Thanks!


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

[PATCH v3 1/3] drm: Plumb modifiers through plane init

[Ben Widawsky]

This is the plumbing for supporting fb modifiers on planes. Modifiers
have already been introduced to some extent, but this series will extend
this to allow querying modifiers per plane. Based on this, the client to
enable optimal modifications for framebuffers.

This patch simply allows the DRM drivers to initialize their list of
supported modifiers upon initializing the plane.

v2: A minor addition from Daniel

v3: Updated commit message
s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu)
Remove some excess newlines (Liviu)
Update comment for > 64 modifiers (Liviu)

Cc: Liviu Dudau 
Reviewed-by: Daniel Stone  (v2)
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   |  1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c|  1 +
 drivers/gpu/drm/arm/malidp_planes.c |  2 +-
 drivers/gpu/drm/armada/armada_crtc.c|  1 +
 drivers/gpu/drm/armada/armada_overlay.c |  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 ++-
 drivers/gpu/drm/drm_modeset_helper.c|  1 +
 drivers/gpu/drm/drm_plane.c | 35 -
 drivers/gpu/drm/drm_simple_kms_helper.c |  3 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |  2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c|  5 +++-
 drivers/gpu/drm/i915/intel_sprite.c |  4 +--
 drivers/gpu/drm/imx/ipuv3-plane.c   |  4 +--
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|  2 +-
 drivers/gpu/drm/meson/meson_plane.c |  1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  4 +--
 drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |  5 ++--
 drivers/gpu/drm/omapdrm/omap_plane.c|  3 ++-
 drivers/gpu/drm/qxl/qxl_display.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  4 +--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  4 +--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 +--
 drivers/gpu/drm/sti/sti_cursor.c|  2 +-
 drivers/gpu/drm/sti/sti_gdp.c   |  2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c |  2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c |  2 +-
 drivers/gpu/drm/tegra/dc.c  | 12 -
 drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|  4 +--
 drivers/gpu/drm/zte/zx_plane.c  |  2 +-
 include/drm/drm_plane.h | 20 +-
 include/drm/drm_simple_kms_helper.h |  1 +
 include/uapi/drm/drm_fourcc.h   | 11 
 41 files changed, 126 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..cd8a24c7c67d 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -218,6 +218,7 @@ static struct drm_plane *arc_pgu_plane_init(struct 
drm_device *drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, _pgu_plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 798a3cc480a2..0caa03ae8708 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -303,6 +303,7 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device 
*drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, _plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
devm_kfree(drm->dev, plane);
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 814fda23cead..b156610c68a5 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -400,7 +400,7 @@ int malidp_de_planes_init(struct drm_device *drm)
DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(drm, >base, crtcs,
   _de_plane_funcs, formats,
-  n, plane_type, NULL);
+  n, NULL, plane_type, 

[PATCH v2 2/3] drm: Create a format/modifier blob

[Ben Widawsky]

Updated blob layout (Rob, Daniel, Kristian, xerpi)

v2:
* Removed __packed, and alignment (.+)
* Fix indent in drm_format_modifier fields (Liviu)
* Remove duplicated modifier > 64 check (Liviu)
* Change comment about modifier (Liviu)
* Remove arguments to blob creation, use plane instead (Liviu)
* Fix data types (Ben)
* Make the blob part of uapi (Daniel)

Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Kristian H. Kristensen 
Cc: Liviu Dudau 
Signed-off-by: Ben Widawsky 
Reviewed-by: Daniel Stone 
---
 drivers/gpu/drm/drm_mode_config.c |  7 +++
 drivers/gpu/drm/drm_plane.c   | 89 +++
 include/drm/drm_mode_config.h |  6 +++
 include/uapi/drm/drm_mode.h   | 50 ++
 4 files changed, 152 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;
 
+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.modifiers = prop;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 20203871e06d..f5b032b5f761 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,92 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
 }
 
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane)
+{
+   const struct drm_mode_config *config = >mode_config;
+   const uint64_t *temp_modifiers = plane->modifiers;
+   unsigned int format_modifier_count = 0;
+   struct drm_property_blob *blob = NULL;
+   struct drm_format_modifier *mod;
+   size_t blob_size = 0, formats_size, modifiers_size;
+   struct drm_format_modifier_blob *blob_data;
+   int i, j, ret = 0;
+
+   if (plane->modifiers)
+   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+   format_modifier_count++;
+
+   formats_size = sizeof(*plane->format_types) * plane->format_count;
+   if (WARN_ON(!formats_size)) {
+   /* 0 formats are never expected */
+   return 0;
+   }
+
+   modifiers_size =
+   sizeof(struct drm_format_modifier) * format_modifier_count;
+
+   blob_size = sizeof(struct drm_format_modifier_blob);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = plane->format_count;
+   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+   blob_data->count_modifiers = format_modifier_count;
+
+   /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+* should be naturally aligned to 8B.
+*/
+   blob_data->modifiers_offset =
+   ALIGN(blob_data->formats_offset + formats_size, 8);
+
+   memcpy(formats_ptr(blob_data), plane->format_types, formats_size);
+
+   /* If we can't determine support, just bail */
+   if (!plane->funcs->format_mod_supported)
+   goto done;
+
+   mod = modifiers_ptr(blob_data);
+   for (i = 0; i < format_modifier_count; i++) {
+   for (j = 0; j < plane->format_count; j++) {
+   if (plane->funcs->format_mod_supported(plane,
+  
plane->format_types[j],
+  
plane->modifiers[i])) {
+
+   mod->formats |= 1 << j;
+   }
+   }
+
+   mod->modifier = plane->modifiers[i];
+   mod->offset = 0;
+   mod->pad = 0;
+   mod++;
+   }
+
+done:
+   drm_object_attach_property(>base, config->modifiers,
+  blob->base.id);
+
+   return ret;
+}
+
 /**
  * drm_universal_plane_init - 

[PATCH v5 3/3] drm/i915: Add format modifiers for Intel

[Ben Widawsky]

This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.

v2:
  - Add LINEAR and Yf modifiers to list (Ville)
  - Combine i8xx and i965 into one list of formats (Ville)
  - Allow 1010102 formats for Y/Yf tiled (Ville)

v3:
  - Handle cursor formats (Ville)
  - Put handling for LINEAR in the mod_support functions (Ville)

v4:
  - List each modifier explicitly in supported modifiers (Ville)
  - Handle the CURSOR plane (Ville)

v5:
  - Split out cursor and sprite handling (Ville)

Cc: Ville Syrjälä 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 131 +--
 drivers/gpu/drm/i915/intel_sprite.c  |  76 +++-
 2 files changed, 201 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9dd67d51e7c9..3519c10abcc3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
 };
 
+static const uint64_t i9xx_format_modifiers[] = {
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -87,6 +93,14 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint64_t skl_format_modifiers[] = {
+   I915_FORMAT_MOD_Yf_TILED,
+   I915_FORMAT_MOD_Y_TILED,
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13381,6 +13395,103 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
 }
 
+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_XRGB:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   case I915_FORMAT_MOD_Y_TILED:
+   return true;
+   default:
+   return false;
+   }
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_VYUY:
+   /* All i915 modifiers are fine */
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   case I915_FORMAT_MOD_Y_TILED:
+   case I915_FORMAT_MOD_Yf_TILED:
+   return true;
+   default:
+   return false;
+   }
+   default:
+   return false;
+   }
+}
+
+static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+   return false;
+
+   if (INTEL_GEN(dev_priv) >= 9)
+   return skl_mod_supported(format, modifier);
+   else if (INTEL_GEN(dev_priv) >= 4)
+   return i965_mod_supported(format, modifier);
+   else
+   return i8xx_mod_supported(format, modifier);
+
+   return false;
+}
+
+static bool intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
+   uint32_t format,
+   

Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

[Ben Widawsky]

On 17-05-03 17:08:27, Daniel Vetter wrote:

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:

Updated blob layout (Rob, Daniel, Kristian, xerpi)

Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/drm_mode_config.c |   7 +++
 drivers/gpu/drm/drm_plane.c   | 119 ++
 include/drm/drm_mode_config.h |   6 ++
 include/uapi/drm/drm_mode.h   |  26 +
 4 files changed, 158 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;

+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.modifiers = prop;
+
return 0;
 }

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 286e183891e5..2e89e0e73435 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
 }

+struct drm_format_modifier_blob {
+#define FORMAT_BLOB_CURRENT 1
+   /* Version of this blob format */
+   u32 version;
+
+   /* Flags */
+   u32 flags;
+
+   /* Number of fourcc formats supported */
+   u32 count_formats;
+
+   /* Where in this blob the formats exist (in bytes) */
+   u32 formats_offset;
+
+   /* Number of drm_format_modifiers */
+   u32 count_modifiers;
+
+   /* Where in this blob the modifiers exist (in bytes) */
+   u32 modifiers_offset;
+
+   /* u32 formats[] */
+   /* struct drm_format_modifier modifiers[] */
+} __packed;


The struct should be in the uapi header. Otherwise it won't show up in
libdrm headers when following the proper process.
-Daniel



I don't agree that blobs are ever really part of the API, but it doesn't hurt to
move it... in other words, done.


+
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane,
+const struct drm_plane_funcs *funcs,
+const uint32_t *formats, unsigned int 
format_count,
+const uint64_t *format_modifiers)
+{
+   const struct drm_mode_config *config = >mode_config;
+   const uint64_t *temp_modifiers = format_modifiers;
+   unsigned int format_modifier_count = 0;
+   struct drm_property_blob *blob = NULL;
+   struct drm_format_modifier *mod;
+   size_t blob_size = 0, formats_size, modifiers_size;
+   struct drm_format_modifier_blob *blob_data;
+   int i, j, ret = 0;
+
+   if (format_modifiers)
+   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+   format_modifier_count++;
+
+   formats_size = sizeof(__u32) * format_count;
+   if (WARN_ON(!formats_size)) {
+   /* 0 formats are never expected */
+   return 0;
+   }
+
+   modifiers_size =
+   sizeof(struct drm_format_modifier) * format_modifier_count;
+
+   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = format_count;
+   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+   blob_data->count_modifiers = format_modifier_count;
+
+   /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+* should be naturally aligned to 8B.
+*/
+   blob_data->modifiers_offset =
+   ALIGN(blob_data->formats_offset + formats_size, 8);
+
+   memcpy(formats_ptr(blob_data), formats, formats_size);
+
+   /* If we can't determine support, just bail */
+   if (!funcs->format_mod_supported)
+   goto done;
+
+   mod = modifiers_ptr(blob_data);
+   for (i = 0; i < format_modifier_count; 

[PATCH v7 1/5] nouveau/hwmon: Add config for all sensors and their settings

[Oscar Salvador]

This is a preparation for the next patches. It just adds the sensors with
their possible configurable settings and then fills the struct 
hwmon_channel_info
with all this information.

Signed-off-by: Oscar Salvador 
Reviewed-by: Martin Peres 
---
 drivers/gpu/drm/nouveau/nouveau_hwmon.c | 72 +
 1 file changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 23b1670..24b40c5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -692,6 +692,78 @@ static const struct attribute_group hwmon_power_attrgroup 
= {
 static const struct attribute_group hwmon_power_caps_attrgroup = {
.attrs = hwmon_power_caps_attributes,
 };
+
+static const u32 nouveau_config_chip[] = {
+   HWMON_C_UPDATE_INTERVAL,
+   0
+};
+
+static const u32 nouveau_config_in[] = {
+   HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
+   0
+};
+
+static const u32 nouveau_config_temp[] = {
+   HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+   HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
+   HWMON_T_EMERGENCY_HYST,
+   0
+};
+
+static const u32 nouveau_config_fan[] = {
+   HWMON_F_INPUT,
+   0
+};
+
+static const u32 nouveau_config_pwm[] = {
+   HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
+   0
+};
+
+static const u32 nouveau_config_power[] = {
+   HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
+   0
+};
+
+static const struct hwmon_channel_info nouveau_chip = {
+   .type = hwmon_chip,
+   .config = nouveau_config_chip,
+};
+
+static const struct hwmon_channel_info nouveau_temp = {
+   .type = hwmon_temp,
+   .config = nouveau_config_temp,
+};
+
+static const struct hwmon_channel_info nouveau_fan = {
+   .type = hwmon_fan,
+   .config = nouveau_config_fan,
+};
+
+static const struct hwmon_channel_info nouveau_in = {
+   .type = hwmon_in,
+   .config = nouveau_config_in,
+};
+
+static const struct hwmon_channel_info nouveau_pwm = {
+   .type = hwmon_pwm,
+   .config = nouveau_config_pwm,
+};
+
+static const struct hwmon_channel_info nouveau_power = {
+   .type = hwmon_power,
+   .config = nouveau_config_power,
+};
+
+static const struct hwmon_channel_info *nouveau_info[] = {
+   _chip,
+   _temp,
+   _fan,
+   _in,
+   _pwm,
+   _power,
+   NULL
+};
 #endif
 
 int
-- 
2.1.4

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

[PATCH v7 5/5] nouveau/hwmon: Change permissions to numeric

[Oscar Salvador]

This patch replaces the symbolic permissions with the numeric ones.

Signed-off-by: Oscar Salvador 
Reviewed-by: Martin Peres 
---
 drivers/gpu/drm/nouveau/nouveau_hwmon.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 53ad696..51a9fb8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -45,7 +45,7 @@ nouveau_hwmon_show_temp1_auto_point1_pwm(struct device *d,
 {
return snprintf(buf, PAGE_SIZE, "%d\n", 100);
 }
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, S_IRUGO,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, 0444,
  nouveau_hwmon_show_temp1_auto_point1_pwm, NULL, 0);
 
 static ssize_t
@@ -77,7 +77,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp(struct device *d,
 
return count;
 }
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp, 0644,
  nouveau_hwmon_temp1_auto_point1_temp,
  nouveau_hwmon_set_temp1_auto_point1_temp, 0);
 
@@ -110,7 +110,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp_hyst(struct device 
*d,
 
return count;
 }
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, 0644,
  nouveau_hwmon_temp1_auto_point1_temp_hyst,
  nouveau_hwmon_set_temp1_auto_point1_temp_hyst, 0);
 
@@ -165,7 +165,7 @@ nouveau_hwmon_set_pwm1_min(struct device *d, struct 
device_attribute *a,
 
return count;
 }
-static SENSOR_DEVICE_ATTR(pwm1_min, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(pwm1_min, 0644,
  nouveau_hwmon_get_pwm1_min,
  nouveau_hwmon_set_pwm1_min, 0);
 
@@ -188,7 +188,7 @@ nouveau_hwmon_set_pwm1_max(struct device *d, struct 
device_attribute *a,
 
return count;
 }
-static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(pwm1_max, 0644,
  nouveau_hwmon_get_pwm1_max,
  nouveau_hwmon_set_pwm1_max, 0);
 
-- 
2.1.4

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

[PATCH v7 0/5] replace hwmon_device_register for hwmon_device_register_with_info

[Oscar Salvador]

This v7 fixes removes dummy functions which only had a return and moves the code
into the switch statements.

Versions:

v1 -> v2:
* Keep temp attrs as read only
v2 -> v3:
* Code fix-ups: struct and string as const and add return within switch
due to fallthrough
* Add Signed-off-by to all commits
v3 -> v4:
* Rever const to struct attribute. Kbuild complains.
v4 -> v5:
* Drops a check for attr_set in "nouveau_temp_is_visible".
v5 -> v6:
* Change to nouveau/hwmon all commit titles
* Drop author change
* Coding-Style
* Move the check before the switch in nouveau_power_is_visible function
* Expose temperature attrs as RW again
* Get rid of nouveau_hwmon_set_pwm1/_enable and implement the code 
inside
nouveau_pwm_write
* Get rid of nouveau_hwmon_set_temp_* and implement the code inside
nouveau_temp_write
v6 -> v7:
* Got rid of all dummy functions that only had a return, and moved
code into the switch statements.


This patchseries replaces the deprecated hwmon_device_register function with the
new one hwmon_device_register_with_info.
It also does some cleanup.

Oscar Salvador (5):
  nouveau/hwmon: Add config for all sensors and their settings
  nouveau/hwmon: Add nouveau_hwmon_ops structure with
.is_visible/.read_string
  nouveau/hwmon: Remove old code, add .write/.read operations
  nouveau/hwmon: expose the auto_point and pwm_min/max attrs
  nouveau/hwmon: Change permissions to numeric

 drivers/gpu/drm/nouveau/nouveau_hwmon.c | 979 +++-
 1 file changed, 460 insertions(+), 519 deletions(-)

-- 
2.1.4

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

[PATCH v7 3/5] nouveau/hwmon: Remove old code, add .write/.read operations

[Oscar Salvador]

This patch removes old code related to the old api and transforms the
functions for the new api. It also adds the .write and .read operations.

Signed-off-by: Oscar Salvador 
Reviewed-by: Martin Peres 
---
 drivers/gpu/drm/nouveau/nouveau_hwmon.c | 844 ++--
 1 file changed, 261 insertions(+), 583 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index e9908fa..bd14d3b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -38,21 +38,6 @@
 #include 
 
 #if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
-static ssize_t
-nouveau_hwmon_show_temp(struct device *d, struct device_attribute *a, char 
*buf)
-{
-   struct drm_device *dev = dev_get_drvdata(d);
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nvkm_therm *therm = nvxx_therm(>client.device);
-   int temp = nvkm_therm_temp_get(therm);
-
-   if (temp < 0)
-   return temp;
-
-   return snprintf(buf, PAGE_SIZE, "%d\n", temp * 1000);
-}
-static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, nouveau_hwmon_show_temp,
- NULL, 0);
 
 static ssize_t
 nouveau_hwmon_show_temp1_auto_point1_pwm(struct device *d,
@@ -130,234 +115,7 @@ static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, 
S_IRUGO | S_IWUSR,
  nouveau_hwmon_set_temp1_auto_point1_temp_hyst, 0);
 
 static ssize_t
-nouveau_hwmon_max_temp(struct device *d, struct device_attribute *a, char *buf)
-{
-   struct drm_device *dev = dev_get_drvdata(d);
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nvkm_therm *therm = nvxx_therm(>client.device);
-
-   return snprintf(buf, PAGE_SIZE, "%d\n",
-  therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK) * 1000);
-}
-static ssize_t
-nouveau_hwmon_set_max_temp(struct device *d, struct device_attribute *a,
-   const char *buf, size_t count)
-{
-   struct drm_device *dev = dev_get_drvdata(d);
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nvkm_therm *therm = nvxx_therm(>client.device);
-   long value;
-
-   if (kstrtol(buf, 10, ) == -EINVAL)
-   return count;
-
-   therm->attr_set(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK, value / 1000);
-
-   return count;
-}
-static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO | S_IWUSR, nouveau_hwmon_max_temp,
- nouveau_hwmon_set_max_temp,
- 0);
-
-static ssize_t
-nouveau_hwmon_max_temp_hyst(struct device *d, struct device_attribute *a,
-   char *buf)
-{
-   struct drm_device *dev = dev_get_drvdata(d);
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nvkm_therm *therm = nvxx_therm(>client.device);
-
-   return snprintf(buf, PAGE_SIZE, "%d\n",
- therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST) * 1000);
-}
-static ssize_t
-nouveau_hwmon_set_max_temp_hyst(struct device *d, struct device_attribute *a,
-   const char *buf, size_t count)
-{
-   struct drm_device *dev = dev_get_drvdata(d);
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nvkm_therm *therm = nvxx_therm(>client.device);
-   long value;
-
-   if (kstrtol(buf, 10, ) == -EINVAL)
-   return count;
-
-   therm->attr_set(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST,
-   value / 1000);
-
-   return count;
-}
-static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IRUGO | S_IWUSR,
- nouveau_hwmon_max_temp_hyst,
- nouveau_hwmon_set_max_temp_hyst, 0);
-
-static ssize_t
-nouveau_hwmon_critical_temp(struct device *d, struct device_attribute *a,
-   char *buf)
-{
-   struct drm_device *dev = dev_get_drvdata(d);
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nvkm_therm *therm = nvxx_therm(>client.device);
-
-   return snprintf(buf, PAGE_SIZE, "%d\n",
-  therm->attr_get(therm, NVKM_THERM_ATTR_THRS_CRITICAL) * 1000);
-}
-static ssize_t
-nouveau_hwmon_set_critical_temp(struct device *d, struct device_attribute *a,
-   const char *buf,
-   size_t count)
-{
-   struct drm_device *dev = dev_get_drvdata(d);
-   struct nouveau_drm *drm = nouveau_drm(dev);
-   struct nvkm_therm *therm = nvxx_therm(>client.device);
-   long value;
-
-   if (kstrtol(buf, 10, ) == -EINVAL)
-   return count;
-
-   therm->attr_set(therm, NVKM_THERM_ATTR_THRS_CRITICAL, value / 1000);
-
-   return count;
-}
-static 

[PATCH v7 4/5] nouveau/hwmon: expose the auto_point and pwm_min/max attrs

[Oscar Salvador]

This patch creates a special group attributes for attrs like "*auto_point*".
We check if we have support for them, and if we do, we gather them all in
an attribute_group's structure which is the parameter regarding special groups
of hwmon_device_register_with_info
We also do the same for pwm_min/max attrs.

Signed-off-by: Oscar Salvador 
Reviewed-by: Martin Peres 
---
 drivers/gpu/drm/nouveau/nouveau_hwmon.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index bd14d3b..53ad696 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -192,6 +192,23 @@ static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO | S_IWUSR,
  nouveau_hwmon_get_pwm1_max,
  nouveau_hwmon_set_pwm1_max, 0);
 
+static struct attribute *pwm_fan_sensor_attrs[] = {
+   _dev_attr_pwm1_min.dev_attr.attr,
+   _dev_attr_pwm1_max.dev_attr.attr,
+   NULL
+};
+ATTRIBUTE_GROUPS(pwm_fan_sensor);
+
+static struct attribute *temp1_auto_point_sensor_attrs[] = {
+   _dev_attr_temp1_auto_point1_pwm.dev_attr.attr,
+   _dev_attr_temp1_auto_point1_temp.dev_attr.attr,
+   _dev_attr_temp1_auto_point1_temp_hyst.dev_attr.attr,
+   NULL
+};
+ATTRIBUTE_GROUPS(temp1_auto_point_sensor);
+
+#define N_ATTR_GROUPS   3
+
 static const u32 nouveau_config_chip[] = {
HWMON_C_UPDATE_INTERVAL,
0
@@ -687,17 +704,28 @@ nouveau_hwmon_init(struct drm_device *dev)
 #if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(>client.device);
+   const struct attribute_group *special_groups[N_ATTR_GROUPS];
struct nouveau_hwmon *hwmon;
struct device *hwmon_dev;
int ret = 0;
+   int i = 0;
 
hwmon = drm->hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return -ENOMEM;
hwmon->dev = dev;
 
+   if (therm && therm->attr_get && therm->attr_set) {
+   if (nvkm_therm_temp_get(therm) >= 0)
+   special_groups[i++] = _auto_point_sensor_group;
+   if (therm->fan_get && therm->fan_get(therm) >= 0)
+   special_groups[i++] = _fan_sensor_group;
+   }
+
+   special_groups[i] = 0;
hwmon_dev = hwmon_device_register_with_info(dev->dev, "nouveau", dev,
-   _chip_info, 
NULL);
+   _chip_info,
+   special_groups);
if (IS_ERR(hwmon_dev)) {
ret = PTR_ERR(hwmon_dev);
NV_ERROR(drm, "Unable to register hwmon device: %d\n", ret);
-- 
2.1.4

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

[PATCH v7 2/5] nouveau/hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string

[Oscar Salvador]

This patch introduces the nouveau_hwmon_ops structure, sets up
.is_visible and .read_string operations and adds all the functions
for these operations.
This is also a preparation for the next patches, where most of the
work is being done.
This code doesn't interacture with the old one.
It's just to make easier the review of all patches.

Signed-off-by: Oscar Salvador 
Reviewed-by: Martin Peres 
---
 drivers/gpu/drm/nouveau/nouveau_hwmon.c | 163 
 1 file changed, 163 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 24b40c5..e9908fa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -764,6 +764,169 @@ static const struct hwmon_channel_info *nouveau_info[] = {
_power,
NULL
 };
+
+static umode_t
+nouveau_chip_is_visible(const void *data, u32 attr, int channel)
+{
+   switch (attr) {
+   case hwmon_chip_update_interval:
+   return 0444;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_power_is_visible(const void *data, u32 attr, int channel)
+{
+   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+   struct nvkm_iccsense *iccsense = nvxx_iccsense(>client.device);
+
+   if (!iccsense || !iccsense->data_valid || list_empty(>rails))
+   return 0;
+
+   switch (attr) {
+   case hwmon_power_input:
+   return 0444;
+   case hwmon_power_max:
+   if (iccsense->power_w_max)
+   return 0444;
+   return 0;
+   case hwmon_power_crit:
+   if (iccsense->power_w_crit)
+   return 0444;
+   return 0;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_temp_is_visible(const void *data, u32 attr, int channel)
+{
+   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+   struct nvkm_therm *therm = nvxx_therm(>client.device);
+
+   if (therm && therm->attr_get && nvkm_therm_temp_get(therm) < 0)
+   return 0;
+
+   switch (attr) {
+   case hwmon_temp_input:
+   case hwmon_temp_max:
+   case hwmon_temp_max_hyst:
+   case hwmon_temp_crit:
+   case hwmon_temp_crit_hyst:
+   case hwmon_temp_emergency:
+   case hwmon_temp_emergency_hyst:
+   return 0444;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_pwm_is_visible(const void *data, u32 attr, int channel)
+{
+   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+   struct nvkm_therm *therm = nvxx_therm(>client.device);
+
+   if (therm && therm->attr_get && therm->fan_get &&
+   therm->fan_get(therm) < 0)
+   return 0;
+
+   switch (attr) {
+   case hwmon_pwm_enable:
+   case hwmon_pwm_input:
+   return 0644;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_input_is_visible(const void *data, u32 attr, int channel)
+{
+   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+   struct nvkm_volt *volt = nvxx_volt(>client.device);
+
+   if (!volt || nvkm_volt_get(volt) < 0)
+   return 0;
+
+   switch (attr) {
+   case hwmon_in_input:
+   case hwmon_in_label:
+   case hwmon_in_min:
+   case hwmon_in_max:
+   return 0444;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_fan_is_visible(const void *data, u32 attr, int channel)
+{
+   struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+   struct nvkm_therm *therm = nvxx_therm(>client.device);
+
+   if (!therm || !therm->attr_get || nvkm_therm_fan_sense(therm) < 0)
+   return 0;
+
+   switch (attr) {
+   case hwmon_fan_input:
+   return 0444;
+   default:
+   return 0;
+   }
+}
+
+static umode_t
+nouveau_is_visible(const void *data, enum hwmon_sensor_types type, u32 attr,
+   int channel)
+{
+   switch (type) {
+   case hwmon_chip:
+   return nouveau_chip_is_visible(data, attr, channel);
+   case hwmon_temp:
+   return nouveau_temp_is_visible(data, attr, channel);
+   case hwmon_fan:
+   return nouveau_fan_is_visible(data, attr, channel);
+   case hwmon_in:
+   return nouveau_input_is_visible(data, attr, channel);
+   case hwmon_pwm:
+   return nouveau_pwm_is_visible(data, attr, channel);
+   case hwmon_power:
+   return nouveau_power_is_visible(data, attr, channel);
+   default:
+   return 0;
+   }
+}
+
+static const char input_label[] = "GPU core";
+
+static int
+nouveau_read_string(struct device *dev, enum hwmon_sensor_types type, u32 

[PATCH 3/3] drm/radeon: Cleanup pageflipping IRQ handling for evergreen, si

[Lyude]

Same as the previous patch, but for pageflipping now.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/radeon/evergreen.c | 70 ++--
 drivers/gpu/drm/radeon/radeon.h|  7 +---
 drivers/gpu/drm/radeon/si.c| 72 ++
 3 files changed, 22 insertions(+), 127 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 76a2f20..3bfc951 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -4452,18 +4452,9 @@ void evergreen_disable_interrupt_state(struct 
radeon_device *rdev)
WREG32(DMA_CNTL, tmp);
WREG32(GRBM_INT_CNTL, 0);
WREG32(SRBM_INT_CNTL, 0);
-   for (i = 0; i < rdev->num_crtc; i++)
+   for (i = 0; i < rdev->num_crtc; i++) {
WREG32(INT_MASK + crtc_offsets[i], 0);
-
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
-   if (rdev->num_crtc >= 4) {
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET, 0);
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET, 0);
-   }
-   if (rdev->num_crtc >= 6) {
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET, 0);
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET, 0);
+   WREG32(GRPH_INT_CONTROL + crtc_offsets[i], 0);
}
 
/* only one DAC on DCE5 */
@@ -4559,23 +4550,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
 
WREG32(GRBM_INT_CNTL, grbm_int_cntl);
 
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET,
-  GRPH_PFLIP_INT_MASK);
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET,
-  GRPH_PFLIP_INT_MASK);
-   if (rdev->num_crtc >= 4) {
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET,
-  GRPH_PFLIP_INT_MASK);
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET,
-  GRPH_PFLIP_INT_MASK);
-   }
-   if (rdev->num_crtc >= 6) {
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET,
-  GRPH_PFLIP_INT_MASK);
-   WREG32(GRPH_INT_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET,
-  GRPH_PFLIP_INT_MASK);
-   }
-
for (i = 0; i < EVERGREEN_MAX_DISP_REGISTERS; i++) {
radeon_irq_kms_set_irq_n_enabled(rdev,
 DC_HPDx_INT_CONTROL(i),
@@ -4594,6 +4568,9 @@ int evergreen_irq_set(struct radeon_device *rdev)
rdev, INT_MASK + crtc_offsets[i], VBLANK_INT_MASK,
rdev->irq.crtc_vblank_int[i] ||
atomic_read(>irq.pflip[i]), "vblank", i);
+
+   WREG32(GRPH_INT_CONTROL + crtc_offsets[i],
+  GRPH_PFLIP_INT_MASK);
}
}
 
@@ -4611,6 +4588,7 @@ int evergreen_irq_set(struct radeon_device *rdev)
 static void evergreen_irq_ack(struct radeon_device *rdev)
 {
int i;
+   u32 *grph_int = rdev->irq.stat_regs.evergreen.grph_int;
u32 *disp_int = rdev->irq.stat_regs.evergreen.disp_int;
u32 *afmt_status = rdev->irq.stat_regs.evergreen.afmt_status;
 
@@ -4627,45 +4605,19 @@ static void evergreen_irq_ack(struct radeon_device 
*rdev)
  AFMT_AZ_FORMAT_WTRIG_ACK);
 
if (i < rdev->num_crtc) {
+   grph_int[i] = RREG32(GRPH_INT_STATUS + crtc_offsets[i]);
+
if (disp_int[i] & LB_Dx_VBLANK_INTERRUPT)
WREG32(VBLANK_STATUS + crtc_offsets[i],
   VBLANK_ACK);
if (disp_int[i] & LB_Dx_VLINE_INTERRUPT)
WREG32(VLINE_STATUS + crtc_offsets[i],
   VLINE_ACK);
+   if (grph_int[i] & GRPH_PFLIP_INT_OCCURRED)
+   WREG32(GRPH_INT_STATUS + crtc_offsets[i],
+  GRPH_PFLIP_INT_CLEAR);
}
}
-
-   rdev->irq.stat_regs.evergreen.d1grph_int = RREG32(GRPH_INT_STATUS + 
EVERGREEN_CRTC0_REGISTER_OFFSET);
-   rdev->irq.stat_regs.evergreen.d2grph_int = RREG32(GRPH_INT_STATUS + 
EVERGREEN_CRTC1_REGISTER_OFFSET);
-   if (rdev->num_crtc >= 4) {
-   rdev->irq.stat_regs.evergreen.d3grph_int = 
RREG32(GRPH_INT_STATUS + EVERGREEN_CRTC2_REGISTER_OFFSET);
-   rdev->irq.stat_regs.evergreen.d4grph_int = 
RREG32(GRPH_INT_STATUS + EVERGREEN_CRTC3_REGISTER_OFFSET);
-   }
-   if (rdev->num_crtc >= 6) {
-   rdev->irq.stat_regs.evergreen.d5grph_int = 
RREG32(GRPH_INT_STATUS + EVERGREEN_CRTC4_REGISTER_OFFSET);
-   

[PATCH 1/3] drm/radeon: Cleanup display interrupt handling for evergreen, si

[Lyude]

The current code here is really, really bad. A huge amount of it looks
to be copy pasted, it has some weird hatred of arrays and code sharing,
switch cases everywhere for things that really don't need them, and it
makes the file seem immensely more complex then it actually is. This is
a pain for maintanence, and is vulnerable to more weird irq handling
bugs.

So, let's start cleaning this up a bit. Modify all of the IRQ handlers
for evergreen/si so that they just use for loops. As well, we add a
helper function radeon_irq_kms_set_irq_n_enabled(), whose purpose is
just to update the state of registers that enable/disable interrupts
while printing any changes to the set of enabled interrupts to the
kernel log.

There is one change here that doesn't look very important (testing
hasn't shown that it changes anyything afaict), but should be noted in
case this patch breaks something. The way the code originally handled
enabling or acking IRQs went like this:

 - Check enable/interrupt status of all IRQs
 - Write back any acknowledgements, enablements, or disablements to
   IRQs, all at the same time

But now with the helpers we've implemented, it goes a little more like
this
 - For each IRQ:
   - Check enable/interrupt status
   - Write back ack/new status

Signed-off-by: Lyude 
---
 drivers/gpu/drm/radeon/evergreen.c  | 699 ++--
 drivers/gpu/drm/radeon/evergreend.h |  74 +---
 drivers/gpu/drm/radeon/radeon.h |  13 +-
 drivers/gpu/drm/radeon/radeon_irq_kms.c |  35 ++
 drivers/gpu/drm/radeon/si.c | 565 +-
 drivers/gpu/drm/radeon/sid.h|  72 +---
 6 files changed, 290 insertions(+), 1168 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 0bf1035..35baf0a 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1714,38 +1714,10 @@ void evergreen_pm_finish(struct radeon_device *rdev)
  */
 bool evergreen_hpd_sense(struct radeon_device *rdev, enum radeon_hpd_id hpd)
 {
-   bool connected = false;
-
-   switch (hpd) {
-   case RADEON_HPD_1:
-   if (RREG32(DC_HPD1_INT_STATUS) & DC_HPDx_SENSE)
-   connected = true;
-   break;
-   case RADEON_HPD_2:
-   if (RREG32(DC_HPD2_INT_STATUS) & DC_HPDx_SENSE)
-   connected = true;
-   break;
-   case RADEON_HPD_3:
-   if (RREG32(DC_HPD3_INT_STATUS) & DC_HPDx_SENSE)
-   connected = true;
-   break;
-   case RADEON_HPD_4:
-   if (RREG32(DC_HPD4_INT_STATUS) & DC_HPDx_SENSE)
-   connected = true;
-   break;
-   case RADEON_HPD_5:
-   if (RREG32(DC_HPD5_INT_STATUS) & DC_HPDx_SENSE)
-   connected = true;
-   break;
-   case RADEON_HPD_6:
-   if (RREG32(DC_HPD6_INT_STATUS) & DC_HPDx_SENSE)
-   connected = true;
-   break;
-   default:
-   break;
-   }
+   if (hpd == RADEON_HPD_NONE)
+   return false;
 
-   return connected;
+   return !!(RREG32(DC_HPDx_INT_STATUS(hpd)) & DC_HPDx_SENSE);
 }
 
 /**
@@ -1759,61 +1731,15 @@ bool evergreen_hpd_sense(struct radeon_device *rdev, 
enum radeon_hpd_id hpd)
 void evergreen_hpd_set_polarity(struct radeon_device *rdev,
enum radeon_hpd_id hpd)
 {
-   u32 tmp;
bool connected = evergreen_hpd_sense(rdev, hpd);
 
-   switch (hpd) {
-   case RADEON_HPD_1:
-   tmp = RREG32(DC_HPD1_INT_CONTROL);
-   if (connected)
-   tmp &= ~DC_HPDx_INT_POLARITY;
-   else
-   tmp |= DC_HPDx_INT_POLARITY;
-   WREG32(DC_HPD1_INT_CONTROL, tmp);
-   break;
-   case RADEON_HPD_2:
-   tmp = RREG32(DC_HPD2_INT_CONTROL);
-   if (connected)
-   tmp &= ~DC_HPDx_INT_POLARITY;
-   else
-   tmp |= DC_HPDx_INT_POLARITY;
-   WREG32(DC_HPD2_INT_CONTROL, tmp);
-   break;
-   case RADEON_HPD_3:
-   tmp = RREG32(DC_HPD3_INT_CONTROL);
-   if (connected)
-   tmp &= ~DC_HPDx_INT_POLARITY;
-   else
-   tmp |= DC_HPDx_INT_POLARITY;
-   WREG32(DC_HPD3_INT_CONTROL, tmp);
-   break;
-   case RADEON_HPD_4:
-   tmp = RREG32(DC_HPD4_INT_CONTROL);
-   if (connected)
-   tmp &= ~DC_HPDx_INT_POLARITY;
-   else
-   tmp |= DC_HPDx_INT_POLARITY;
-   WREG32(DC_HPD4_INT_CONTROL, tmp);
-   break;
-   case RADEON_HPD_5:
-   tmp = RREG32(DC_HPD5_INT_CONTROL);
-   if (connected)
-  

[PATCH 0/3] Cleanup evergreen/si IRQ handling code

[Lyude]

This is the first part of me going through and cleaning up the IRQ handling
code for radeon, since after taking a look at it the other day while trying to
debug something I realized basically all of the code was copy pasted
everywhere, and quite difficult to actually read through.

Will come up with something for r600 and cik once I've got the chipsets on hand
to test with.

Lyude (3):
  drm/radeon: Cleanup display interrupt handling for evergreen, si
  drm/radeon: Cleanup HDMI audio interrupt handling for evergreen
  drm/radeon: Cleanup pageflipping IRQ handling for evergreen, si

 drivers/gpu/drm/radeon/evergreen.c  | 915 +---
 drivers/gpu/drm/radeon/evergreend.h |  74 +--
 drivers/gpu/drm/radeon/radeon.h |  27 +-
 drivers/gpu/drm/radeon/radeon_irq_kms.c |  35 ++
 drivers/gpu/drm/radeon/si.c | 627 --
 drivers/gpu/drm/radeon/sid.h|  72 +--
 6 files changed, 328 insertions(+), 1422 deletions(-)

-- 
2.9.4

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

[PATCH 2/3] drm/radeon: Cleanup HDMI audio interrupt handling for evergreen

[Lyude]

Same as the previous patch, but now for handling HDMI audio interrupts.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/radeon/evergreen.c | 152 ++---
 drivers/gpu/drm/radeon/radeon.h|   7 +-
 2 files changed, 24 insertions(+), 135 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 35baf0a..76a2f20 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -4481,7 +4481,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
u32 cp_int_cntl = CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE;
u32 cp_int_cntl1 = 0, cp_int_cntl2 = 0;
u32 grbm_int_cntl = 0;
-   u32 afmt1 = 0, afmt2 = 0, afmt3 = 0, afmt4 = 0, afmt5 = 0, afmt6 = 0;
u32 dma_cntl, dma_cntl1 = 0;
u32 thermal_int = 0;
 
@@ -4504,13 +4503,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
thermal_int = RREG32(CG_THERMAL_INT) &
~(THERM_INT_MASK_HIGH | THERM_INT_MASK_LOW);
 
-   afmt1 = RREG32(AFMT_AUDIO_PACKET_CONTROL + 
EVERGREEN_CRTC0_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
-   afmt2 = RREG32(AFMT_AUDIO_PACKET_CONTROL + 
EVERGREEN_CRTC1_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
-   afmt3 = RREG32(AFMT_AUDIO_PACKET_CONTROL + 
EVERGREEN_CRTC2_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
-   afmt4 = RREG32(AFMT_AUDIO_PACKET_CONTROL + 
EVERGREEN_CRTC3_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
-   afmt5 = RREG32(AFMT_AUDIO_PACKET_CONTROL + 
EVERGREEN_CRTC4_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
-   afmt6 = RREG32(AFMT_AUDIO_PACKET_CONTROL + 
EVERGREEN_CRTC5_REGISTER_OFFSET) & ~AFMT_AZ_FORMAT_WTRIG_MASK;
-
dma_cntl = RREG32(DMA_CNTL) & ~TRAP_ENABLE;
 
if (rdev->family >= CHIP_CAYMAN) {
@@ -4553,31 +4545,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
thermal_int |= THERM_INT_MASK_HIGH | THERM_INT_MASK_LOW;
}
 
-   if (rdev->irq.afmt[0]) {
-   DRM_DEBUG("evergreen_irq_set: hdmi 0\n");
-   afmt1 |= AFMT_AZ_FORMAT_WTRIG_MASK;
-   }
-   if (rdev->irq.afmt[1]) {
-   DRM_DEBUG("evergreen_irq_set: hdmi 1\n");
-   afmt2 |= AFMT_AZ_FORMAT_WTRIG_MASK;
-   }
-   if (rdev->irq.afmt[2]) {
-   DRM_DEBUG("evergreen_irq_set: hdmi 2\n");
-   afmt3 |= AFMT_AZ_FORMAT_WTRIG_MASK;
-   }
-   if (rdev->irq.afmt[3]) {
-   DRM_DEBUG("evergreen_irq_set: hdmi 3\n");
-   afmt4 |= AFMT_AZ_FORMAT_WTRIG_MASK;
-   }
-   if (rdev->irq.afmt[4]) {
-   DRM_DEBUG("evergreen_irq_set: hdmi 4\n");
-   afmt5 |= AFMT_AZ_FORMAT_WTRIG_MASK;
-   }
-   if (rdev->irq.afmt[5]) {
-   DRM_DEBUG("evergreen_irq_set: hdmi 5\n");
-   afmt6 |= AFMT_AZ_FORMAT_WTRIG_MASK;
-   }
-
if (rdev->family >= CHIP_CAYMAN) {
cayman_cp_int_cntl_setup(rdev, 0, cp_int_cntl);
cayman_cp_int_cntl_setup(rdev, 1, cp_int_cntl1);
@@ -4616,6 +4583,12 @@ int evergreen_irq_set(struct radeon_device *rdev)
 DC_HPDx_RX_INT_EN,
 rdev->irq.hpd[i], "HPD", i);
 
+   radeon_irq_kms_set_irq_n_enabled(rdev,
+AFMT_AUDIO_PACKET_CONTROL +
+crtc_offsets[i],
+AFMT_AZ_FORMAT_WTRIG_MASK,
+rdev->irq.afmt[i], "hdmi", i);
+
if (i < rdev->num_crtc) {
radeon_irq_kms_set_irq_n_enabled(
rdev, INT_MASK + crtc_offsets[i], VBLANK_INT_MASK,
@@ -4629,13 +4602,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
else
WREG32(CG_THERMAL_INT, thermal_int);
 
-   WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC0_REGISTER_OFFSET, 
afmt1);
-   WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC1_REGISTER_OFFSET, 
afmt2);
-   WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC2_REGISTER_OFFSET, 
afmt3);
-   WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC3_REGISTER_OFFSET, 
afmt4);
-   WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC4_REGISTER_OFFSET, 
afmt5);
-   WREG32(AFMT_AUDIO_PACKET_CONTROL + EVERGREEN_CRTC5_REGISTER_OFFSET, 
afmt6);
-
/* posting read */
RREG32(SRBM_STATUS);
 
@@ -4646,15 +4612,19 @@ static void evergreen_irq_ack(struct radeon_device 
*rdev)
 {
int i;
u32 *disp_int = rdev->irq.stat_regs.evergreen.disp_int;
-   u32 tmp;
+   u32 *afmt_status = rdev->irq.stat_regs.evergreen.afmt_status;
 
for (i = 0; i < EVERGREEN_MAX_DISP_REGISTERS; i++) {
disp_int[i] = RREG32(DISP_INTERRUPT_STATUS(i));
+   afmt_status[i] = RREG32(AFMT_STATUS 

Re: [PATCH v2] drm: Add DRM_ROTATE_ and DRM_REFLECT_ defines to UAPI

[kbuild test robot]

Hi Robert,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.12-rc1 next-20170516]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Robert-Foss/drm-Add-DRM_ROTATE_-and-DRM_REFLECT_-defines-to-UAPI/20170517-003242
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

   drivers/gpu//drm/imx/ipuv3-plane.c: In function 'ipu_plane_state_reset':
>> drivers/gpu//drm/imx/ipuv3-plane.c:276:30: error: 'DRM_ROTATE_0' undeclared 
>> (first use in this function)
  ipu_state->base.rotation = DRM_ROTATE_0;
 ^~~~
   drivers/gpu//drm/imx/ipuv3-plane.c:276:30: note: each undeclared identifier 
is reported only once for each function it appears in
--
   drivers/gpu//drm/omapdrm/omap_drv.c: In function 'dev_lastclose':
>> drivers/gpu//drm/omapdrm/omap_drv.c:580:12: error: 'DRM_ROTATE_0' undeclared 
>> (first use in this function)
   DRM_ROTATE_0);
   ^~~~
   drivers/gpu//drm/omapdrm/omap_drv.c:580:12: note: each undeclared identifier 
is reported only once for each function it appears in
--
   drivers/gpu//drm/omapdrm/omap_plane.c: In function 
'omap_plane_atomic_disable':
>> drivers/gpu//drm/omapdrm/omap_plane.c:144:27: error: 'DRM_ROTATE_0' 
>> undeclared (first use in this function)
 plane->state->rotation = DRM_ROTATE_0;
  ^~~~
   drivers/gpu//drm/omapdrm/omap_plane.c:144:27: note: each undeclared 
identifier is reported only once for each function it appears in
   drivers/gpu//drm/omapdrm/omap_plane.c: In function 'omap_plane_atomic_check':
   drivers/gpu//drm/omapdrm/omap_plane.c:180:25: error: 'DRM_ROTATE_0' 
undeclared (first use in this function)
 if (state->rotation != DRM_ROTATE_0 &&
^~~~
   drivers/gpu//drm/omapdrm/omap_plane.c: In function 
'omap_plane_install_properties':
   drivers/gpu//drm/omapdrm/omap_plane.c:216:11: error: 'DRM_ROTATE_0' 
undeclared (first use in this function)
  DRM_ROTATE_0,
  ^~~~
>> drivers/gpu//drm/omapdrm/omap_plane.c:217:26: error: 'DRM_ROTATE_90' 
>> undeclared (first use in this function)
  DRM_ROTATE_0 | DRM_ROTATE_90 |
 ^
>> drivers/gpu//drm/omapdrm/omap_plane.c:218:11: error: 'DRM_ROTATE_180' 
>> undeclared (first use in this function)
  DRM_ROTATE_180 | DRM_ROTATE_270 |
  ^~
>> drivers/gpu//drm/omapdrm/omap_plane.c:218:28: error: 'DRM_ROTATE_270' 
>> undeclared (first use in this function)
  DRM_ROTATE_180 | DRM_ROTATE_270 |
   ^~
>> drivers/gpu//drm/omapdrm/omap_plane.c:219:11: error: 'DRM_REFLECT_X' 
>> undeclared (first use in this function)
  DRM_REFLECT_X | DRM_REFLECT_Y);
  ^
>> drivers/gpu//drm/omapdrm/omap_plane.c:219:27: error: 'DRM_REFLECT_Y' 
>> undeclared (first use in this function)
  DRM_REFLECT_X | DRM_REFLECT_Y);
  ^
   drivers/gpu//drm/omapdrm/omap_plane.c: In function 'omap_plane_reset':
   drivers/gpu//drm/omapdrm/omap_plane.c:276:30: error: 'DRM_ROTATE_0' 
undeclared (first use in this function)
 omap_state->base.rotation = DRM_ROTATE_0;
 ^~~~
--
   drivers/gpu//drm/omapdrm/omap_fb.c: In function 
'omap_framebuffer_update_scanout':
>> drivers/gpu//drm/omapdrm/omap_fb.c:170:27: error: 'DRM_ROTATE_MASK' 
>> undeclared (first use in this function)
  switch (win->rotation & DRM_ROTATE_MASK) {
  ^~~
   drivers/gpu//drm/omapdrm/omap_fb.c:170:27: note: each undeclared identifier 
is reported only once for each function it appears in
>> drivers/gpu//drm/omapdrm/omap_fb.c:176:8: error: 'DRM_ROTATE_0' undeclared 
>> (first use in this function)
  case DRM_ROTATE_0:
   ^~~~
>> drivers/gpu//drm/omapdrm/omap_fb.c:179:8: error: 'DRM_ROTATE_90' undeclared 
>> (first use in this function)
  case DRM_ROTATE_90:
   ^
>> drivers/gpu//drm/omapdrm/omap_fb.c:182:8: error: 'DRM_ROTATE_180' undeclared 
>> (first use in this function)
  case DRM_ROTATE_180:
   ^~
>> drivers/gpu//drm/omapdrm/omap_fb.c:185:8: er

Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

[Eric Anholt]

Laurent Pinchart  writes:

> Hi Eric,
>
> On Tuesday 16 May 2017 09:47:49 Eric Anholt wrote:
>> Rob Herring  writes:
>> > On Mon, May 15, 2017 at 7:03 PM, Eric Anholt  wrote:
>> >> Laurent Pinchart  writes:
>> >>> Hi Eric,
>> >>> 
>> >>> Thank you for the patch.
>> >>> 
>> >>> On Thursday 11 May 2017 16:56:23 Eric Anholt wrote:
>>  The Raspberry Pi 7" Touchscreen is a DPI touchscreen panel with
>>  DSI->DPI bridge and touchscreen controller integrated, that connects
>>  to the Raspberry Pi through its 15-pin "DSI" connector (some lines are
>>  DSI, some lines are I2C).
>>  
>>  This device is represented in the DT as three nodes (DSI device, I2C
>>  device, panel).  Input will be left to a separate binding later, as it
>>  will be a basic I2C client device.
>>  
>>  Signed-off-by: Eric Anholt 
>>  ---
>>  
>>   .../raspberrypi,7inch-touchscreen-bridge.txt   | 68 ++
>>   .../panel/raspberrypi,7inch-touchscreen-panel.txt  |  7 +++
>>   2 files changed, 75 insertions(+)
>>   create mode 100644
>>  
>>  Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touc
>>  hscreen-bridge.txt create mode 100644
>>  Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touch
>>  screen-panel.txt
>>  
>>  diff --git
>>  a/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to
>>  uchscreen-bridge.txt
>>  b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to
>>  uchscreen-bridge.txt new file mode 100644
>>  index ..a5669beaf68f
>>  --- /dev/null
>>  +++
>>  b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to
>>  uchscreen-bridge.txt
>>  @@ -0,0 +1,68 @@
>>  +Official 7" (800x480) Raspberry Pi touchscreen panel's bridge.
>>  +
>>  +This DSI panel contains:
>>  +
>>  +- TC358762 DSI->DPI bridge
>>  +- Atmel microcontroller on I2C for power sequencing the DSI bridge and
>>  +  controlling backlight
>>  +- Touchscreen controller on I2C for touch input
>>  +
>>  +and this covers the TC358762 bridge and Atmel microcontroller, while
>>  +../panel/raspberrypi,7inch-touchscreen-panel.txt covers the panel.
>> >>> 
>> >>> The TC358762 is a standalone bridge that doesn't depend on the ATTiny
>> >>> microcontroller used by the RPI. As it's usable standalone, I believe
>> >>> this binding should be split in two.
>> >> 
>> >> Do you have a plan for how I would implement a driver on top of that
>> >> binding change, though?  Note that we don't program the Toshiba
>> >> directly, we only send commands to the Atmel.
>> > 
>> > I agree. If it is a black box and the interface to the host is defined
>> > by the Atmel uC firmware, then that's what the DT should describe.
>> > Perhaps a diagram here or pointer to one would help and remove
>> > mentioning what kind of bridge chip it is.
>> 
>> It's a *very* black box.  I have some non-public schematics that don't
>> even say what panel is involved, and no documentation of the uc
>> interface.  The driver code is just replicating the firmware's
>> programming sequence.
>> 
>> I would certainly love to be building a generic TC358762 driver, which
>> would be a lot more satisfying.  I just don't think it's doable for this
>> panel.  Given that, what do I need to do to the DT?  Should I just drop
>> mention of the Toshiba and talk about this being a bridge with a custom
>> microcontroller firmware?
>
> I think that would be best, yes. Could you share a simple block-diagram of 
> the 
> hardware ? It would help turning my random advices into semi-random advices 
> :-)

In terms of physical connections:

   [15-pin "DSI" connector on 2835]
|   |
| I2C   | DSI
|   |
   / \SPI   |
[TS]  [Atmel]--[TC358762]
   \|
\PWM|
 \  | DPI
[some backlight]--[some unknown panel]

The binding I'm trying to create is to expose what's necessary for a
driver that talks I2C to the Atmel, which then controls the PWM and does
the command sequence over SPI to the Toshiba that sets up its end of the
DSI link.


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

[Bug 101011] Shadow of Mordor crashes with mesa from 08.05.2017.

[bugzilla-daemon]

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

--- Comment #3 from nadro-li...@wp.pl ---
I can also confirm that this issue is fixed. Thanks!

-- 
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 v2] drm: Add DRM_ROTATE_ and DRM_REFLECT_ defines to UAPI

[kbuild test robot]

Hi Robert,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.12-rc1 next-20170516]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Robert-Foss/drm-Add-DRM_ROTATE_-and-DRM_REFLECT_-defines-to-UAPI/20170517-003242
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 
'mdp5_plane_install_rotation_property':
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:70:9: error: 'DRM_ROTATE_0' 
>> undeclared (first use in this function)
DRM_ROTATE_0,
^~~~
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:70:9: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:72:9: error: 'DRM_ROTATE_180' 
>> undeclared (first use in this function)
DRM_ROTATE_180 |
^~
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:73:9: error: 'DRM_REFLECT_X' 
>> undeclared (first use in this function)
DRM_REFLECT_X |
^
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:74:9: error: 'DRM_REFLECT_Y' 
>> undeclared (first use in this function)
DRM_REFLECT_Y);
^
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 
'mdp5_plane_atomic_check_with_state':
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:372:8: error: 'DRM_ROTATE_0' 
undeclared (first use in this function)
   DRM_ROTATE_0 |
   ^~~~
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:373:8: error: 'DRM_REFLECT_X' 
undeclared (first use in this function)
   DRM_REFLECT_X |
   ^
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:374:8: error: 'DRM_REFLECT_Y' 
undeclared (first use in this function)
   DRM_REFLECT_Y);
   ^
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 'mdp5_plane_mode_set':
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:973:7: error: 'DRM_ROTATE_0' 
undeclared (first use in this function)
  DRM_ROTATE_0 |
  ^~~~
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:974:7: error: 'DRM_REFLECT_X' 
undeclared (first use in this function)
  DRM_REFLECT_X |
  ^
   drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:975:7: error: 'DRM_REFLECT_Y' 
undeclared (first use in this function)
  DRM_REFLECT_Y);
  ^

vim +/DRM_ROTATE_0 +70 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c

06c0dd96 Rob Clark 2013-11-30  64  }
06c0dd96 Rob Clark 2013-11-30  65  
8089082f jilai wang2015-07-31  66  static void 
mdp5_plane_install_rotation_property(struct drm_device *dev,
8089082f jilai wang2015-07-31  67   struct drm_plane *plane)
8089082f jilai wang2015-07-31  68  {
5b560c3a Ville Syrjälä 2016-10-21  69   
drm_plane_create_rotation_property(plane,
5b560c3a Ville Syrjälä 2016-10-21 @70  
DRM_ROTATE_0,
5b560c3a Ville Syrjälä 2016-10-21  71  
DRM_ROTATE_0 |
574a37b1 Ville Syrjälä 2016-10-21 @72  
DRM_ROTATE_180 |
5b560c3a Ville Syrjälä 2016-10-21 @73  
DRM_REFLECT_X |
5b560c3a Ville Syrjälä 2016-10-21 @74  
DRM_REFLECT_Y);
8089082f jilai wang2015-07-31  75  }
8089082f jilai wang2015-07-31  76  
06c0dd96 Rob Clark 2013-11-30  77  /* helper to install properties which 
are common to planes and crtcs */

:: The code at line 70 was first introduced by commit
:: 5b560c3a99a0d1a65132ce6f2f5a8505536613e4 drm/msm/mdp5: Use per-plane 
rotation property

:: TO: Ville Syrjälä <ville.syrj...@linux.intel.com>
:: CC: Daniel Vetter <daniel.vet...@ffwll.ch>

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


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

Re: [PATCH 2/2] dt/bindings: display: move rotation into a common place

[Noralf Trønnes]

Den 16.05.2017 10.19, skrev Baruch Siach:

Commit b60c1be74741 (dt-bindings: display/panel: Add common rotation property)
added the rotation property description in a new file. We have a place for
common display panel properties already. Move there the rotation property.

Cc: Noralf Trønnes 
Cc: Rob Herring 
Signed-off-by: Baruch Siach 
---


Acked-by: Noralf Trønnes 


  Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++
  Documentation/devicetree/bindings/display/panel/panel.txt| 4 
  2 files changed, 6 insertions(+), 4 deletions(-)
  delete mode 100644 Documentation/devicetree/bindings/display/panel/panel.txt

diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt 
b/Documentation/devicetree/bindings/display/panel/panel-common.txt
index 0603af877155..c92dcfd8c32f 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
@@ -89,3 +89,9 @@ backlight controller.
  
  - backlight: For panels whose backlight is controlled by an external backlight

controller, this property contains a phandle that references the controller.
+
+
+Rotation
+
+
+- rotation: Display rotation in degrees counter clockwise (0,90,180,270)
diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt 
b/Documentation/devicetree/bindings/display/panel/panel.txt
deleted file mode 100644
index e2e6867852b8..
--- a/Documentation/devicetree/bindings/display/panel/panel.txt
+++ /dev/null
@@ -1,4 +0,0 @@
-Common display properties
--
-
-- rotation:Display rotation in degrees counter clockwise (0,90,180,270)


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

[Bug 101053] DC R9 285 fullscreen video regression since drm/amd/display: Parse scanline registers

[bugzilla-daemon]

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

--- Comment #3 from Harry Wentland  ---
Thanks for testing. It should land in amd-staging-4.9 in a week or so.

-- 
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 101053] DC R9 285 fullscreen video regression since drm/amd/display: Parse scanline registers

[bugzilla-daemon]

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

--- Comment #2 from Andy Furniss  ---
That fixes it, thanks.

-- 
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 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

[Laurent Pinchart]

Hi Eric,

On Tuesday 16 May 2017 09:47:49 Eric Anholt wrote:
> Rob Herring  writes:
> > On Mon, May 15, 2017 at 7:03 PM, Eric Anholt  wrote:
> >> Laurent Pinchart  writes:
> >>> Hi Eric,
> >>> 
> >>> Thank you for the patch.
> >>> 
> >>> On Thursday 11 May 2017 16:56:23 Eric Anholt wrote:
>  The Raspberry Pi 7" Touchscreen is a DPI touchscreen panel with
>  DSI->DPI bridge and touchscreen controller integrated, that connects
>  to the Raspberry Pi through its 15-pin "DSI" connector (some lines are
>  DSI, some lines are I2C).
>  
>  This device is represented in the DT as three nodes (DSI device, I2C
>  device, panel).  Input will be left to a separate binding later, as it
>  will be a basic I2C client device.
>  
>  Signed-off-by: Eric Anholt 
>  ---
>  
>   .../raspberrypi,7inch-touchscreen-bridge.txt   | 68 ++
>   .../panel/raspberrypi,7inch-touchscreen-panel.txt  |  7 +++
>   2 files changed, 75 insertions(+)
>   create mode 100644
>  
>  Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touc
>  hscreen-bridge.txt create mode 100644
>  Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touch
>  screen-panel.txt
>  
>  diff --git
>  a/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to
>  uchscreen-bridge.txt
>  b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to
>  uchscreen-bridge.txt new file mode 100644
>  index ..a5669beaf68f
>  --- /dev/null
>  +++
>  b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-to
>  uchscreen-bridge.txt
>  @@ -0,0 +1,68 @@
>  +Official 7" (800x480) Raspberry Pi touchscreen panel's bridge.
>  +
>  +This DSI panel contains:
>  +
>  +- TC358762 DSI->DPI bridge
>  +- Atmel microcontroller on I2C for power sequencing the DSI bridge and
>  +  controlling backlight
>  +- Touchscreen controller on I2C for touch input
>  +
>  +and this covers the TC358762 bridge and Atmel microcontroller, while
>  +../panel/raspberrypi,7inch-touchscreen-panel.txt covers the panel.
> >>> 
> >>> The TC358762 is a standalone bridge that doesn't depend on the ATTiny
> >>> microcontroller used by the RPI. As it's usable standalone, I believe
> >>> this binding should be split in two.
> >> 
> >> Do you have a plan for how I would implement a driver on top of that
> >> binding change, though?  Note that we don't program the Toshiba
> >> directly, we only send commands to the Atmel.
> > 
> > I agree. If it is a black box and the interface to the host is defined
> > by the Atmel uC firmware, then that's what the DT should describe.
> > Perhaps a diagram here or pointer to one would help and remove
> > mentioning what kind of bridge chip it is.
> 
> It's a *very* black box.  I have some non-public schematics that don't
> even say what panel is involved, and no documentation of the uc
> interface.  The driver code is just replicating the firmware's
> programming sequence.
> 
> I would certainly love to be building a generic TC358762 driver, which
> would be a lot more satisfying.  I just don't think it's doable for this
> panel.  Given that, what do I need to do to the DT?  Should I just drop
> mention of the Toshiba and talk about this being a bridge with a custom
> microcontroller firmware?

I think that would be best, yes. Could you share a simple block-diagram of the 
hardware ? It would help turning my random advices into semi-random advices 
:-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

[Eric Anholt]

Rob Herring  writes:

> On Mon, May 15, 2017 at 7:03 PM, Eric Anholt  wrote:
>> Laurent Pinchart  writes:
>>
>>> Hi Eric,
>>>
>>> Thank you for the patch.
>>>
>>> On Thursday 11 May 2017 16:56:23 Eric Anholt wrote:
 The Raspberry Pi 7" Touchscreen is a DPI touchscreen panel with
 DSI->DPI bridge and touchscreen controller integrated, that connects
 to the Raspberry Pi through its 15-pin "DSI" connector (some lines are
 DSI, some lines are I2C).

 This device is represented in the DT as three nodes (DSI device, I2C
 device, panel).  Input will be left to a separate binding later, as it
 will be a basic I2C client device.

 Signed-off-by: Eric Anholt 
 ---
  .../raspberrypi,7inch-touchscreen-bridge.txt   | 68 
 +++
  .../panel/raspberrypi,7inch-touchscreen-panel.txt  |  7 +++
  2 files changed, 75 insertions(+)
  create mode 100644
 Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touchscr
 een-bridge.txt create mode 100644
 Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscre
 en-panel.txt

 diff --git
 a/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touchs
 creen-bridge.txt
 b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touchs
 creen-bridge.txt new file mode 100644
 index ..a5669beaf68f
 --- /dev/null
 +++
 b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touchs
 creen-bridge.txt @@ -0,0 +1,68 @@
 +Official 7" (800x480) Raspberry Pi touchscreen panel's bridge.
 +
 +This DSI panel contains:
 +
 +- TC358762 DSI->DPI bridge
 +- Atmel microcontroller on I2C for power sequencing the DSI bridge and
 +  controlling backlight
 +- Touchscreen controller on I2C for touch input
 +
 +and this covers the TC358762 bridge and Atmel microcontroller, while
 +../panel/raspberrypi,7inch-touchscreen-panel.txt covers the panel.
>>>
>>> The TC358762 is a standalone bridge that doesn't depend on the ATTiny
>>> microcontroller used by the RPI. As it's usable standalone, I believe this
>>> binding should be split in two.
>>
>> Do you have a plan for how I would implement a driver on top of that
>> binding change, though?  Note that we don't program the Toshiba
>> directly, we only send commands to the Atmel.
>
> I agree. If it is a black box and the interface to the host is defined
> by the Atmel uC firmware, then that's what the DT should describe.
> Perhaps a diagram here or pointer to one would help and remove
> mentioning what kind of bridge chip it is.

It's a *very* black box.  I have some non-public schematics that don't
even say what panel is involved, and no documentation of the uc
interface.  The driver code is just replicating the firmware's
programming sequence.

I would certainly love to be building a generic TC358762 driver, which
would be a lot more satisfying.  I just don't think it's doable for this
panel.  Given that, what do I need to do to the DT?  Should I just drop
mention of the Toshiba and talk about this being a bridge with a custom
microcontroller firmware?


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

[Bug 101055] All GL programs segfault: i915_state_derived.c:calculate_vertex_layout: i915->fs == 0

[bugzilla-daemon]

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

--- Comment #2 from Karl-Johan Karlsson 
 ---
You're right, sorry. I'm not entirely clear on the difference. I switched to
the classic driver, and with that both glxgears and KDE Plasma works.

-- 
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 v2] drm: Add DRM_ROTATE_ and DRM_REFLECT_ defines to UAPI

[Ville Syrjälä]

On Tue, May 16, 2017 at 11:55:00AM -0400, Robert Foss wrote:
> Add DRM_ROTATE_ and DRM_REFLECT_ defines to the UAPI as a convenience.
> 
> Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
> through the atomic API, but realizing that userspace is likely to take
> shortcuts and assume that the enum values are what is sent over the
> wire.
> 
> As a result these defines are provided purely as a convenience to
> userspace applications.
> 
> Signed-off-by: Robert Foss 
> ---
> Changes since v1:
>  - Moved defines from drm.h to drm_mode.h
>  - Changed define prefix from DRM_ to DRM_MODE_PROP_

DRM_MODE_PROP_ would potentially cause confusion with the prop types.
DRM_MODE_ROTATE_ etc. could be acceptable I suppose.

>  - Updated uses of the defines to the new prefix
>  - Removed include from drm_rect.c
>  - Stopped using the BIT() macro
> 
>  drivers/gpu/drm/drm_atomic.c   |  2 +-
>  drivers/gpu/drm/drm_atomic_helper.c|  2 +-
>  drivers/gpu/drm/drm_blend.c| 43 +--
>  drivers/gpu/drm/drm_fb_helper.c|  4 +-
>  drivers/gpu/drm/drm_plane_helper.c |  2 +-
>  drivers/gpu/drm/drm_rect.c | 36 
>  drivers/gpu/drm/nouveau/nv50_display.c |  2 +-
>  include/drm/drm_blend.h| 21 +-
>  include/uapi/drm/drm_mode.h| 76 
> ++

I'm pretty sure this won't even compile properly since it's missing all
but one driver.

>  9 files changed, 124 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f32506a7c1d6..ec1839b01d2a 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -769,7 +769,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
>   } else if (property == plane->rotation_property) {
> - if (!is_power_of_2(val & DRM_ROTATE_MASK))
> + if (!is_power_of_2(val & DRM_MODE_PROP_ROTATE_MASK))
>   return -EINVAL;
>   state->rotation = val;
>   } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 8be9719284b0..37f461aa5e66 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3220,7 +3220,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane 
> *plane)
>  
>   if (plane->state) {
>   plane->state->plane = plane;
> - plane->state->rotation = DRM_ROTATE_0;
> + plane->state->rotation = DRM_MODE_PROP_ROTATE_0;
>   }
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index a0d0d6843288..044640a04d51 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -119,15 +119,15 @@
>   * drm_property_create_bitmask()) called "rotation" and has the following
>   * bitmask enumaration values:
>   *
> - * DRM_ROTATE_0:
> + * DRM_MODE_PROP_ROTATE_0:
>   *   "rotate-0"
> - * DRM_ROTATE_90:
> + * DRM_MODE_PROP_ROTATE_90:
>   *   "rotate-90"
> - * DRM_ROTATE_180:
> + * DRM_MODE_PROP_ROTATE_180:
>   *   "rotate-180"
> - * DRM_ROTATE_270:
> + * DRM_MODE_PROP_ROTATE_270:
>   *   "rotate-270"
> - * DRM_REFLECT_X:
> + * DRM_MODE_PROP_REFLECT_X:
>   *   "reflect-x"
>   * DRM_REFELCT_Y:
>   *   "reflect-y"
> @@ -142,17 +142,17 @@ int drm_plane_create_rotation_property(struct drm_plane 
> *plane,
>  unsigned int supported_rotations)
>  {
>   static const struct drm_prop_enum_list props[] = {
> - { __builtin_ffs(DRM_ROTATE_0) - 1,   "rotate-0" },
> - { __builtin_ffs(DRM_ROTATE_90) - 1,  "rotate-90" },
> - { __builtin_ffs(DRM_ROTATE_180) - 1, "rotate-180" },
> - { __builtin_ffs(DRM_ROTATE_270) - 1, "rotate-270" },
> - { __builtin_ffs(DRM_REFLECT_X) - 1,  "reflect-x" },
> - { __builtin_ffs(DRM_REFLECT_Y) - 1,  "reflect-y" },
> + { __builtin_ffs(DRM_MODE_PROP_ROTATE_0) - 1,   "rotate-0" },
> + { __builtin_ffs(DRM_MODE_PROP_ROTATE_90) - 1,  "rotate-90" },
> + { __builtin_ffs(DRM_MODE_PROP_ROTATE_180) - 1, "rotate-180" },
> + { __builtin_ffs(DRM_MODE_PROP_ROTATE_270) - 1, "rotate-270" },
> + { __builtin_ffs(DRM_MODE_PROP_REFLECT_X) - 1,  "reflect-x" },
> + { __builtin_ffs(DRM_MODE_PROP_REFLECT_Y) - 1,  "reflect-y" },
>   };
>   struct drm_property *prop;
>  
> - WARN_ON((supported_rotations & DRM_ROTATE_MASK) == 0);
> - WARN_ON(!is_power_of_2(rotation & DRM_ROTATE_MASK));
> + WARN_ON((supported_rotations & DRM_MODE_PROP_ROTATE_MASK) == 0);
> + WARN_ON(!is_power_of_2(rotation & DRM_MODE_PROP_ROTATE_MASK));
>   WARN_ON(rotation & 

[Bug 101053] DC R9 285 fullscreen video regression since drm/amd/display: Parse scanline registers

[bugzilla-daemon]

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

--- Comment #1 from Harry Wentland  ---
Created attachment 131374
  --> https://bugs.freedesktop.org/attachment.cgi?id=131374=edit
fix scanline params

Thanks, Andy. Please try attached patch. The regression change you mentioned
contains some bad code (that I wrote -_-).

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

[PATCH v2] drm: Add DRM_ROTATE_ and DRM_REFLECT_ defines to UAPI

[Robert Foss]

Add DRM_ROTATE_ and DRM_REFLECT_ defines to the UAPI as a convenience.

Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
through the atomic API, but realizing that userspace is likely to take
shortcuts and assume that the enum values are what is sent over the
wire.

As a result these defines are provided purely as a convenience to
userspace applications.

Signed-off-by: Robert Foss 
---
Changes since v1:
 - Moved defines from drm.h to drm_mode.h
 - Changed define prefix from DRM_ to DRM_MODE_PROP_
 - Updated uses of the defines to the new prefix
 - Removed include from drm_rect.c
 - Stopped using the BIT() macro

 drivers/gpu/drm/drm_atomic.c   |  2 +-
 drivers/gpu/drm/drm_atomic_helper.c|  2 +-
 drivers/gpu/drm/drm_blend.c| 43 +--
 drivers/gpu/drm/drm_fb_helper.c|  4 +-
 drivers/gpu/drm/drm_plane_helper.c |  2 +-
 drivers/gpu/drm/drm_rect.c | 36 
 drivers/gpu/drm/nouveau/nv50_display.c |  2 +-
 include/drm/drm_blend.h| 21 +-
 include/uapi/drm/drm_mode.h| 76 ++
 9 files changed, 124 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f32506a7c1d6..ec1839b01d2a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -769,7 +769,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
} else if (property == config->prop_src_h) {
state->src_h = val;
} else if (property == plane->rotation_property) {
-   if (!is_power_of_2(val & DRM_ROTATE_MASK))
+   if (!is_power_of_2(val & DRM_MODE_PROP_ROTATE_MASK))
return -EINVAL;
state->rotation = val;
} else if (property == plane->zpos_property) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8be9719284b0..37f461aa5e66 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3220,7 +3220,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane 
*plane)
 
if (plane->state) {
plane->state->plane = plane;
-   plane->state->rotation = DRM_ROTATE_0;
+   plane->state->rotation = DRM_MODE_PROP_ROTATE_0;
}
 }
 EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index a0d0d6843288..044640a04d51 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -119,15 +119,15 @@
  * drm_property_create_bitmask()) called "rotation" and has the following
  * bitmask enumaration values:
  *
- * DRM_ROTATE_0:
+ * DRM_MODE_PROP_ROTATE_0:
  * "rotate-0"
- * DRM_ROTATE_90:
+ * DRM_MODE_PROP_ROTATE_90:
  * "rotate-90"
- * DRM_ROTATE_180:
+ * DRM_MODE_PROP_ROTATE_180:
  * "rotate-180"
- * DRM_ROTATE_270:
+ * DRM_MODE_PROP_ROTATE_270:
  * "rotate-270"
- * DRM_REFLECT_X:
+ * DRM_MODE_PROP_REFLECT_X:
  * "reflect-x"
  * DRM_REFELCT_Y:
  * "reflect-y"
@@ -142,17 +142,17 @@ int drm_plane_create_rotation_property(struct drm_plane 
*plane,
   unsigned int supported_rotations)
 {
static const struct drm_prop_enum_list props[] = {
-   { __builtin_ffs(DRM_ROTATE_0) - 1,   "rotate-0" },
-   { __builtin_ffs(DRM_ROTATE_90) - 1,  "rotate-90" },
-   { __builtin_ffs(DRM_ROTATE_180) - 1, "rotate-180" },
-   { __builtin_ffs(DRM_ROTATE_270) - 1, "rotate-270" },
-   { __builtin_ffs(DRM_REFLECT_X) - 1,  "reflect-x" },
-   { __builtin_ffs(DRM_REFLECT_Y) - 1,  "reflect-y" },
+   { __builtin_ffs(DRM_MODE_PROP_ROTATE_0) - 1,   "rotate-0" },
+   { __builtin_ffs(DRM_MODE_PROP_ROTATE_90) - 1,  "rotate-90" },
+   { __builtin_ffs(DRM_MODE_PROP_ROTATE_180) - 1, "rotate-180" },
+   { __builtin_ffs(DRM_MODE_PROP_ROTATE_270) - 1, "rotate-270" },
+   { __builtin_ffs(DRM_MODE_PROP_REFLECT_X) - 1,  "reflect-x" },
+   { __builtin_ffs(DRM_MODE_PROP_REFLECT_Y) - 1,  "reflect-y" },
};
struct drm_property *prop;
 
-   WARN_ON((supported_rotations & DRM_ROTATE_MASK) == 0);
-   WARN_ON(!is_power_of_2(rotation & DRM_ROTATE_MASK));
+   WARN_ON((supported_rotations & DRM_MODE_PROP_ROTATE_MASK) == 0);
+   WARN_ON(!is_power_of_2(rotation & DRM_MODE_PROP_ROTATE_MASK));
WARN_ON(rotation & ~supported_rotations);
 
prop = drm_property_create_bitmask(plane->dev, 0, "rotation",
@@ -178,14 +178,14 @@ EXPORT_SYMBOL(drm_plane_create_rotation_property);
  * @supported_rotations: Supported rotations
  *
  * Attempt to simplify the rotation to a form that is supported.
- * Eg. if the hardware supports everything except DRM_REFLECT_X
+ * Eg. if the hardware supports everything except 

Re: [PATCH v1] drm: Add DRM_ROTATE_ and DRM_REFLECT_ defines to UAPI

[Robert Foss]

On 2017-05-16 06:58 AM, Emil Velikov wrote:

On 15 May 2017 at 18:13, Robert Foss  wrote:



On 2017-05-15 09:23 AM, Emil Velikov wrote:


Hi Rob,

On 14 May 2017 at 18:26, Robert Foss  wrote:


Add DRM_ROTATE_ and DRM_REFLECT_ defines to the UAPI as a convenience.

Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
through the atomic API, but realizing that userspace is likely to take
shortcuts and assume that the enum values are what is sent over the
wire.

As a result these defines are provided purely as a convenience to
userspace applications.

Signed-off-by: Robert Foss 
---
 drivers/gpu/drm/drm_rect.c |  1 +
 include/drm/drm_blend.h| 18 
 include/uapi/drm/drm.h | 73
++
 3 files changed, 74 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index bc5575960ebc..bdb27434bb10 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
index 13221cf9b3eb..d149a63b893b 100644
--- a/include/drm/drm_blend.h
+++ b/include/drm/drm_blend.h
@@ -29,24 +29,6 @@
 struct drm_device;
 struct drm_atomic_state;


Since the defines are used here, move the above include to this file?



Done.





-/*
- * Rotation property bits. DRM_ROTATE_ rotates the image by the
- * specified amount in degrees in counter clockwise direction.
DRM_REFLECT_X and
- * DRM_REFLECT_Y reflects the image along the specified axis prior to
rotation
- *
- * WARNING: These defines are UABI since they're exposed in the rotation
- * property.
- */
-#define DRM_ROTATE_0   BIT(0)
-#define DRM_ROTATE_90  BIT(1)
-#define DRM_ROTATE_180 BIT(2)
-#define DRM_ROTATE_270 BIT(3)
-#define DRM_ROTATE_MASK (DRM_ROTATE_0   | DRM_ROTATE_90 | \
-DRM_ROTATE_180 | DRM_ROTATE_270)
-#define DRM_REFLECT_X  BIT(4)
-#define DRM_REFLECT_Y  BIT(5)
-#define DRM_REFLECT_MASK (DRM_REFLECT_X | DRM_REFLECT_Y)
-
 static inline bool drm_rotation_90_or_270(unsigned int rotation)
 {
return rotation & (DRM_ROTATE_90 | DRM_ROTATE_270);
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 42d9f64ce416..d7140b0091bc 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h



drm_mode.h might be a better fit.



About this, I don't disagree, but other defines in drm_mode.h seem to be
prefixed with DRM_MODE_ which this isn't which is why I didn't put it there.

Knowing this, do you still prefer these defines living in drm_mode.h?


Feel free to give them a DRM_MODE_ prefix or something else - say
DRM_MODE_PROP_.

AFAICT drm_mode.h deals with KMS specifics and the prop_id mentioned
in the documentation is already there, so it would make sense to add
it there.


Done.


Rob.


-Emil


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

Re: [PATCH v3 2/2] v4l: vsp1: Provide a writeback video device

[Geert Uytterhoeven]

Hi Kieran,

On Tue, May 9, 2017 at 6:39 PM, Kieran Bingham
 wrote:
> When the VSP1 is used in an active display pipeline, the output of the
> WPF can supply the LIF entity directly and simultaneously write to
> memory.
>
> Support this functionality in the VSP1 driver, by extending the WPF
> source pads, and establishing a V4L2 video device node connected to the
> new source.
>
> The source will be able to perform pixel format conversion, but not
> rescaling, and as such the output from the memory node will always be
> of the same dimensions as the display output.
>
> Signed-off-by: Kieran Bingham 

> --- a/drivers/media/platform/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/vsp1/vsp1_video.c

> @@ -900,6 +901,147 @@ static const struct vb2_ops vsp1_video_queue_qops = {
> .stop_streaming = vsp1_video_stop_streaming,
>  };
>
> +
> +/* 
> -
> + * videobuf2 queue operations for writeback nodes
> + */
> +
> +static void vsp1_video_wb_process_buffer(struct vsp1_video *video)
> +{
> +   struct vsp1_vb2_buffer *buf;
> +   unsigned long flags;
> +
> +   /*
> +* Writeback uses a running stream, unlike the M2M interface which
> +* controls a pipeline process manually though the use of
> +* vsp1_pipeline_run().
> +*
> +* Instead writeback will commence at the next frame interval, and can
> +* be marked complete at the interval following that. To handle this 
> we
> +* store the configured buffer as pending until the next callback.
> +*
> +* |||||
> +*  A   |<-->|
> +*   B   |<-->|
> +*C   |<-->| : Only at interrupt C can A be marked done
> +*/
> +
> +   spin_lock_irqsave(>irqlock, flags);
> +
> +   /* Move the pending image to the active hw queue */
> +   if (video->pending) {
> +   list_add_tail(>pending->queue, >irqqueue);
> +   video->pending = NULL;
> +   }
> +
> +   buf = list_first_entry_or_null(>wbqueue, struct 
> vsp1_vb2_buffer,
> +   queue);
> +
> +   if (buf) {
> +   video->rwpf->mem = buf->mem;
> +
> +   /*
> +* Store this buffer as pending. It will commence at the next
> +* frame start interrupt
> +*/
> +   video->pending = buf;
> +   list_del(>queue);
> +   } else {
> +   /* Disable writeback with no buffer */
> +   video->rwpf->mem = (struct vsp1_rwpf_memory) { 0 };

With gcc 4.9.0:

drivers/media/platform/vsp1/vsp1_video.c: In function
'vsp1_video_wb_process_buffer':
drivers/media/platform/vsp1/vsp1_video.c:942:30: warning: missing
braces around initializer [-Wmissing-braces]
   video->rwpf->mem = (struct vsp1_rwpf_memory) { 0 };

-   video->rwpf->mem = (struct vsp1_rwpf_memory) { 0 };
+   video->rwpf->mem = (struct vsp1_rwpf_memory) { { 0, } };

> +static void vsp1_video_wb_stop_streaming(struct vb2_queue *vq)
> +{
> +   struct vsp1_video *video = vb2_get_drv_priv(vq);
> +   struct vsp1_rwpf *rwpf = video->rwpf;
> +   struct vsp1_pipeline *pipe = rwpf->pipe;
> +   struct vsp1_vb2_buffer *buffer;
> +   unsigned long flags;
> +
> +   /*
> +* Disable the completion interrupts, and clear the WPF memory to
> +* prevent writing out frames
> +*/
> +   spin_lock_irqsave(>irqlock, flags);
> +   video->frame_end = NULL;
> +   rwpf->mem = (struct vsp1_rwpf_memory) { 0 };

Likewise:

-   rwpf->mem = (struct vsp1_rwpf_memory) { 0 };
+   rwpf->mem = (struct vsp1_rwpf_memory) { { 0, } };

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2] drm/cec: Add Source Physical address decode to drm_display_info

[clinton . a . taylor]

From: Clint Taylor 

During VSDB decode bytes 4 and 5 contain the source physical address for
use the HDMI CEC. Make this data available as part of drm_display_info.

V2: Fix HTMLDOCS warnings for struct drm_hdmi_cec_spa

Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/drm_edid.c  | 10 ++
 include/drm/drm_connector.h | 20 
 2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2e55599..e64605b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3938,6 +3938,16 @@ static void drm_parse_hdmi_deep_color_info(struct 
drm_connector *connector,
struct drm_display_info *info = >display_info;
u8 len = cea_db_payload_len(db);
 
+   if (len >= 4) {
+   info->src_phy_addr.a = (db[4] & 0xF0) >> 4;
+   info->src_phy_addr.b = db[4] & 0x0F;
+   info->src_phy_addr.c = (db[5] & 0xF0) >> 4;
+   info->src_phy_addr.d = db[5] & 0x0F;
+
+   DRM_DEBUG_KMS("HDMI SPA = %01x.%01x.%01x.%01x\n",
+   info->src_phy_addr.a, info->src_phy_addr.b,
+   info->src_phy_addr.c, info->src_phy_addr.d);
+   }
if (len >= 6)
info->dvi_dual = db[6] & 1;
if (len >= 7)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 9c15993..0df3511 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -127,6 +127,21 @@ struct drm_scdc {
struct drm_scrambling scrambling;
 };
 
+/**
+ * struct drm_hdmi_cec_spa
+ *
+ * Provides the Source Physical address from an HDMI VSDB EDID
+ */
+struct drm_hdmi_cec_spa {
+   /** @a: sink's Source Physical Address A field */
+   u8 a;
+   /** @b: sink's Source Physical Address B field */
+   u8 b;
+   /** @c: sink's Source Physical Address C field */
+   u8 c;
+   /** @d: sink's Source Physical Address D field */
+   u8 d;
+};
 
 /**
  * struct drm_hdmi_info - runtime information about the connected HDMI sink
@@ -263,6 +278,11 @@ struct drm_display_info {
 * @hdmi: advance features of a HDMI sink.
 */
struct drm_hdmi_info hdmi;
+
+   /**
+* @src_phy_addr: HDMI CEC Source Physical Address
+*/
+   struct drm_hdmi_cec_spa src_phy_addr;
 };
 
 int drm_display_info_set_bus_formats(struct drm_display_info *info,
-- 
1.9.1

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

[PULL] drm-misc-next

[Sean Paul]

Hi Dave,
Apologies for the previous early pull request. This one, hopefully, is more
appropriately timed. I've rolled the previous PR into this one, so you might
notice a couple familiar summaries.

As with the previous pull, I've Cc'd all of the summary-line contributors so
they can keep me honest in my summarization.


drm-misc-next-2017-05-16:
UAPI Changes:
- Return -ENODEV instead of -ENXIO when creating cma fb w/o valid gem (Daniel)
- Add aspect ratio and custom scaling propertis to connector state (Maarten)

Cross-subsystem Changes:
- None

Core Changes:
- Add Laurent as bridge reviewer and Andrzej as bridge maintainer (Archit)
- Maintain new STM driver through -misc (Yannick)
- Misc doc improvements (as is tradition) (Daniel)
- Add driver-private objects to atomic state (Dhinakaran)
- Deprecate preclose hook in modern drivers (use postclose) (Daniel)
- Add hwmode to vblank struct. This fixes mode access in irq context and reduced
  a bunch of boilerplate (Daniel)

Driver Changes:
- vc4: Add out-fence support to vc4 V3D rendering (Eric)
- stm: Add stm32f429 display hw and am-480272h3tmqw-t01h panel support (Yannick)
- vc4: Remove 256MB cma limit from vc4 (Eric)
- dw-hdmi: Disable audio when inactive, instead of always enabled (Romain)
- zte: Add support for VGA to the ZTE driver (Shawn)
- i915: Track DP MST bandwidth and check it in atomic_check (Dhinakaran)
- vgem: Enable gem dmabuf import iface to facilitate ion testing (Laura)
- vc4: Add support for Cygnus (new dt compat string + couple bug fixes) (Eric)
- pl111: Add driver for pl111 CLCD display controller (Eric/Tom)
- vgem: Subclass drm_device instead of standalone platform device (Chris)

Cc: Archit Taneja 
Cc: Eric Anholt 
Cc: Yannick Fertre 
Cc: Romain Perier 
Cc: Navare, Manasi D 
Cc: Shawn Guo 
Cc: Dhinakaran Pandiyan 
Cc: Laura Abbott 
Cc: Maarten Lankhorst 
Cc: Tom Cooksey 
Cc: Daniel Vetter 
Cc: Chris Wilson 

Thanks,

Sean


The following changes since commit 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf:

  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next 
(2017-05-02 04:46:01 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-05-16

for you to fetch changes up to 9cf8f5802f39d9991158b29033c852bccfc3a4d4:

  drm: add missing declaration to drm_blend.h (2017-05-16 15:09:56 +0200)


UAPI Changes:
- Return -ENODEV instead of -ENXIO when creating cma fb w/o valid gem (Daniel)
- Add aspect ratio and custom scaling propertis to connector state (Maarten)

Cross-subsystem Changes:
- None

Core Changes:
- Add Laurent as bridge reviewer and Andrzej as bridge maintainer (Archit)
- Maintain new STM driver through -misc (Yannick)
- Misc doc improvements (as is tradition) (Daniel)
- Add driver-private objects to atomic state (Dhinakaran)
- Deprecate preclose hook in modern drivers (use postclose) (Daniel)
- Add hwmode to vblank struct. This fixes mode access in irq context and reduced
  a bunch of boilerplate (Daniel)

Driver Changes:
- vc4: Add out-fence support to vc4 V3D rendering (Eric)
- stm: Add stm32f429 display hw and am-480272h3tmqw-t01h panel support (Yannick)
- vc4: Remove 256MB cma limit from vc4 (Eric)
- dw-hdmi: Disable audio when inactive, instead of always enabled (Romain)
- zte: Add support for VGA to the ZTE driver (Shawn)
- i915: Track DP MST bandwidth and check it in atomic_check (Dhinakaran)
- vgem: Enable gem dmabuf import iface to facilitate ion testing (Laura)
- vc4: Add support for Cygnus (new dt compat string + couple bug fixes) (Eric)
- pl111: Add driver for pl111 CLCD display controller (Eric/Tom)
- vgem: Subclass drm_device instead of standalone platform device (Chris)

Cc: Archit Taneja 
Cc: Eric Anholt 
Cc: Yannick Fertre 
Cc: Romain Perier 
Cc: Navare, Manasi D 
Cc: Shawn Guo 
Cc: Dhinakaran Pandiyan 
Cc: Laura Abbott 
Cc: Maarten Lankhorst 
Cc: Tom Cooksey 
Cc: Daniel Vetter 
Cc: Chris Wilson 


Andres Rodriguez (1):
  dma-buf: avoid scheduling on fence status query v2

Archit Taneja (1):
  MAINTAINERS: Update maintainers/reviewers for bridge drivers

Boris Brezillon (1):
  drm/vc4: Add runtime PM support to the HDMI encoder driver

Chris Wilson (4):
  drm/mm: Split up long running selftests with 

Re: [RFC v3 6/8] drm/msm: remove mdp5_cursor_plane_funcs

[Archit Taneja]

On 5/13/2017 12:40 AM, Gustavo Padovan wrote:

From: Gustavo Padovan 

After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.


Tested-by: Archit Taneja 

Thanks,
Archit



Cc: Rob Clark 
Signed-off-by: Gustavo Padovan 
---
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
  1 file changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 07106c1..794ca07 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -247,19 +247,6 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
.atomic_print_state = mdp5_plane_atomic_print_state,
  };
  
-static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {

-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
-   .destroy = mdp5_plane_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
-   .atomic_set_property = mdp5_plane_atomic_set_property,
-   .atomic_get_property = mdp5_plane_atomic_get_property,
-   .reset = mdp5_plane_reset,
-   .atomic_duplicate_state = mdp5_plane_duplicate_state,
-   .atomic_destroy_state = mdp5_plane_destroy_state,
-   .atomic_print_state = mdp5_plane_atomic_print_state,
-};
-
  static int mdp5_plane_prepare_fb(struct drm_plane *plane,
 struct drm_plane_state *new_state)
  {
@@ -,16 +1098,9 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
  
  	spin_lock_init(_plane->pipe_lock);
  
-	if (type == DRM_PLANE_TYPE_CURSOR)

-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   _cursor_plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
-   else
-   ret = drm_universal_plane_init(dev, plane, 0xff,
-   _plane_funcs,
-   mdp5_plane->formats, mdp5_plane->nformats,
-   type, NULL);
+   ret = drm_universal_plane_init(dev, plane, 0xff, _plane_funcs,
+  mdp5_plane->formats,
+  mdp5_plane->nformats, type, NULL);
if (ret)
goto fail;
  



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

Re: [RFC v3 5/8] drm/msm: update cursors asynchronously through atomic

[Archit Taneja]

On 5/13/2017 12:40 AM, Gustavo Padovan wrote:

From: Gustavo Padovan 

Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.


Works well on DB820c (which has a APQ8096 SoC).

Tested-by: Archit Taneja 



v3: move size checks back to drivers (Ville Syrjälä)

v2: move fb setting to core and use new state (Eric Anholt)

Cc: Rob Clark 
Signed-off-by: Gustavo Padovan 
---
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 151 +-
  1 file changed, 63 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index a38c5fe..07106c1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -33,15 +33,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest);
  
-static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,

-   struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   int crtc_x, int crtc_y,
-   unsigned int crtc_w, unsigned int crtc_h,
-   uint32_t src_x, uint32_t src_y,
-   uint32_t src_w, uint32_t src_h,
-   struct drm_modeset_acquire_ctx *ctx);
-
  static struct mdp5_kms *get_kms(struct drm_plane *plane)
  {
struct msm_drm_private *priv = plane->dev->dev_private;
@@ -257,7 +248,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
  };
  
  static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {

-   .update_plane = mdp5_update_cursor_plane_legacy,
+   .update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = mdp5_plane_destroy,
.set_property = drm_atomic_helper_plane_set_property,
@@ -484,11 +475,73 @@ static void mdp5_plane_atomic_update(struct drm_plane 
*plane,
}
  }
  
+static int mdp5_plane_atomic_async_check(struct drm_plane *plane,

+struct drm_plane_state *state)
+{
+   struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+   state->crtc);
+   if (WARN_ON(!crtc_state))
+   return -EINVAL;
+
+   if (!crtc_state->active)
+   return -EINVAL;
+
+   mdp5_state = to_mdp5_plane_state(state);
+
+   /* don't use fast path if we don't have a hwpipe allocated yet */
+   if (!mdp5_state->hwpipe)
+   return -EINVAL;
+
+   /* only allow changing of position(crtc x/y or src x/y) in fast path */
+   if (plane->state->crtc != state->crtc ||
+   plane->state->src_w != state->src_w ||
+   plane->state->src_h != state->src_h ||
+   plane->state->crtc_w != state->crtc_w ||
+   plane->state->crtc_h != state->crtc_h ||
+   !plane->state->fb ||
+   plane->state->fb != state->fb)
+   return -EINVAL;
+
+   return 0;
+}
+
+static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
+  struct drm_plane_state *new_state)
+{
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+
+   if (plane_enabled(new_state)) {
+   struct mdp5_ctl *ctl;
+   struct mdp5_pipeline *pipeline =
+   mdp5_crtc_get_pipeline(plane->crtc);
+   int ret;
+
+   ret = mdp5_plane_mode_set(plane, new_state->crtc, new_state->fb,
+   _state->src, _state->dst);
+   WARN_ON(ret < 0);
+
+   ctl = mdp5_crtc_get_ctl(new_state->crtc);
+
+   mdp5_ctl_commit(ctl, pipeline, mdp5_plane_get_flush(plane));
+   }
+
+   *to_mdp5_plane_state(plane->state) =
+   *to_mdp5_plane_state(new_state);
+}
+
  static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
.prepare_fb = mdp5_plane_prepare_fb,
.cleanup_fb = mdp5_plane_cleanup_fb,
.atomic_check = mdp5_plane_atomic_check,
.atomic_update = mdp5_plane_atomic_update,
+   .atomic_async_check = mdp5_plane_atomic_async_check,
+   .atomic_async_update = mdp5_plane_atomic_async_update,
  };
  
  static void set_scanout_locked(struct mdp5_kms *mdp5_kms,

@@ -997,84 

[PATCH] drm/amd/powerplay: fix a signedness bugs

[Dan Carpenter]

Smatch complains about a signedness bug here:

vega10_hwmgr.c:4202 vega10_force_clock_level()
warn: always true condition '(i >= 0) => (0-u32max >= 0)'

Fixes: 7b52db39a4c2 ("drm/amd/powerplay: fix bug sclk/mclk level can't be set 
on vega10.")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index ad30f5d3a10d..2614af2f553f 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -4186,7 +4186,7 @@ static int vega10_force_clock_level(struct pp_hwmgr 
*hwmgr,
enum pp_clock_type type, uint32_t mask)
 {
struct vega10_hwmgr *data = (struct vega10_hwmgr *)(hwmgr->backend);
-   uint32_t i;
+   int i;
 
if (hwmgr->dpm_level != AMD_DPM_FORCED_LEVEL_MANUAL)
return -EINVAL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 195743] Screen flicker and instability on hdmi monitors with AMDGPU, EDID problems

[bugzilla-daemon]

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

--- Comment #3 from keziolio...@gmail.com ---
Thanks for the reply 

Yes I did update the kernel, along with the rest of the system (I use
ArchLinux).

The problem seems to be getting worse, from linux 4.7 to 4.10 and git, with
latter versions the "screens off and on" flicker seems to be cycling and
generally more unstable (on 4.10), instead of an "one shot" glitch that I can
fix with xrandr (on 4.7). This is why I think it's a kernel issue.

Unfortunately for now I can't easily bisect the kernel version, as I use btrfs
and it breaks if I load an old kernel. I'll try later with a live system but
that's going to take some time.

I have 3 monitors, two of them HDMI and one DVI, only the HDMI ones are
affected, even if I found breakage on the DVI one some times.


The problem does not occur in wayland, only xorg is affected. But I tried older
versions of xorg and the problem persists (so I guess it's not a xorg issue)

I tried to force the edid with the kernel command line, but the problem still
occurs, the monitors do shut down (they are not detected) or flicker

I don't really know what to try now, and I have not found a workaround yet,
disabling udev has no effect.

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

Re: [PATCH 1/2] drm/doc: Document adjusted/request modes a bit better

[Andrzej Hajda]

On 15.05.2017 11:11, Daniel Vetter wrote:
> Laurent started a massive discussion on IRC about this. Let's try to
> document common usage a bit better.
>
> v2: Cross-links+typos.
>
> Cc: Laurent Pinchart 
> Cc: Ville Syrjälä 
> Cc: Jose Abreu 
> Signed-off-by: Daniel Vetter 
Reviewed-by: Andrzej Hajda 

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

Re: [PATCH] drm: Add crtc/encoder/bridge->mode_valid() callbacks

[Andrzej Hajda]

On 15.05.2017 11:33, Daniel Vetter wrote:
> From: Jose Abreu 
>
> This adds a new callback to crtc, encoder and bridge helper functions
> called mode_valid(). This callback shall be implemented if the
> corresponding component has some sort of restriction in the modes
> that can be displayed. A NULL callback implicates that the component
> can display all the modes.
>
> We also change the documentation so that the new and old callbacks
> are correctly documented.
>
> Only the callbacks were implemented to simplify review process,
> following patches will make use of them.
>
> Changes in v2 from Daniel:
> - Update the warning about how modes aren't filtered in atomic_check -
>   the heleprs help out a lot more now.
> - Consistenly roll out that warning, crtc/encoder's atomic_check
>   missed it.
> - Sprinkle more links all over the place, so it's easier to see where
>   this stuff is used and how the differen hooks are related.
> - Note that ->mode_valid is optional everywhere.
> - Explain why the connector's mode_valid is special and does _not_ get
>   called in atomic_check.
>
> v3: Document what can and cannot be checked in mode_valid a bit better
> (Andrjez). Answer: Only allowed to look at the mode, nothing else.
>
> Cc: Laurent Pinchart 
> Signed-off-by: Jose Abreu 
> Cc: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Alexey Brodkin 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: Andrzej Hajda 
> Cc: Archit Taneja 
> Signed-off-by: Daniel Vetter  (v2)
Reviewed-by: Andrzej Hajda 

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

Re: [PATCH 2/2] drm/doc: Clarify mode_fixup vs. atomic_check a bit more

[Andrzej Hajda]

On 15.05.2017 11:11, Daniel Vetter wrote:
> Brought up by both Laurent and Andrzej when reviewing the new
> ->mode_valid hooks. Since mode_fixup is just a simpler version of the
> much more generic atomic_check we can't really unify it with
> mode_valid. Most drivers should probably switch their current
> mode_fixup code to either the new mode_valid or the atomic_check
> hooks, but e.g. that doesn't exist yet for bridges, and for CRTCs the
> situation is a bit more complicated. Hence there's no clear
> equivalence between mode_fixup and mode_valid, even if it looks like
> that at first glance.
>
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Jose Abreu 
> Signed-off-by: Daniel Vetter 
> ---
>  include/drm/drm_modeset_helper_vtables.h | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index c72fca544a41..613b2a602b77 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -156,7 +156,11 @@ struct drm_crtc_helper_funcs {
>* allowed.
>*
>* Atomic drivers which need to inspect and adjust more state should
> -  * instead use the @atomic_check callback.
> +  * instead use the @atomic_check callback, but note that they're not
> +  * perfectly equivalent: @mode_valid is called from
> +  * drm_atomic_helper_check_modeset(), but @atomic_check is called from
> +  * drm_atomic_helper_check_planes(), because originally it was meant for
> +  * plane update checks only..

Two dots.

Beside this:
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

>*
>* Also beware that userspace can request its own custom modes, neither
>* core nor helpers filter modes to the list of probe modes reported by
> @@ -529,7 +533,9 @@ struct drm_encoder_helper_funcs {
>* allowed.
>*
>* Atomic drivers which need to inspect and adjust more state should
> -  * instead use the @atomic_check callback.
> +  * instead use the @atomic_check callback. If @atomic_check is used,
> +  * this hook isn't called since @atomic_check allows a strict superset
> +  * of the functionality of @mode_fixup.
>*
>* Also beware that userspace can request its own custom modes, neither
>* core nor helpers filter modes to the list of probe modes reported by
> @@ -716,6 +722,11 @@ struct drm_encoder_helper_funcs {
>* update the CRTC to match what the encoder needs for the requested
>* connector.
>*
> +  * Since this provides a strict superset of the functionality of
> +  * @mode_fixup (the requested and adjusted modes are both available
> +  * through the passed in  drm_crtc_state) @mode_fixup is not
> +  * called when @atomic_check is implemented.
> +  *
>* This function is used by the atomic helpers, but it is optional.
>*
>* NOTE:


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

Re: [PATCH] drm: add missing declaration to drm_blend.h

[Daniel Vetter]

On Tue, May 16, 2017 at 03:34:45PM +0300, Tomi Valkeinen wrote:
> drm_blend.h is missing declaration for 'struct drm_plane'. Add it.
> 
> Signed-off-by: Tomi Valkeinen 

Hm I didn't realize we need this already, this same hunk is in my wip
branch somewhere ...

Applied, thanks.
-Daniel

> ---
>  include/drm/drm_blend.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
> index 13221cf9b3eb..bc9e596be4c2 100644
> --- a/include/drm/drm_blend.h
> +++ b/include/drm/drm_blend.h
> @@ -28,6 +28,7 @@
>  
>  struct drm_device;
>  struct drm_atomic_state;
> +struct drm_plane;
>  
>  /*
>   * Rotation property bits. DRM_ROTATE_ rotates the image by the
> -- 
> 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: use kvmalloc_array for drm_malloc*

[Daniel Vetter]

On Tue, May 16, 2017 at 11:52:55AM +0200, Michal Hocko wrote:
> On Tue 16-05-17 11:22:30, Daniel Vetter wrote:
> > On Tue, May 16, 2017 at 11:06:06AM +0200, Michal Hocko wrote:
> > > From: Michal Hocko 
> > > 
> > > drm_malloc* has grown their own kmalloc with vmalloc fallback
> > > implementations. MM has grown kvmalloc* helpers in the meantime. Let's
> > > use those because it a) reduces the code and b) MM has a better idea
> > > how to implement fallbacks (e.g. do not vmalloc before kmalloc is tried
> > > with __GFP_NORETRY).
> > > 
> > > Signed-off-by: Michal Hocko 
> > 
> > Shouldn't we go one step further and just remove these wrappers, maybe
> > with cocci?
> 
> my cocci sucks...
> 
> > Especially drm_malloc_gfp is surpremely pointless after this
> > patch (and drm_malloc_ab probably not that useful either).
> 
> So what about the following instead? It passes allyesconfig compilation.

Yeah, looks good, but perhaps rebased onto your first patch. That way we
split the functional change from the refactor (not the first time innocent
looking changes in i915 gem code resulted in surprises).

Your patch also seems to need some stuff from -rc1, and atm drm-misc is
still pre-rc1, so I'll pull both patches in once that's sorted (I can do
the rebase myself, since it's rather trivial). But pls remind me in case
it falls through the cracks and isn't in linux-next by end of this week
:-)

Thanks, Daniel

> ---
> From 6325ff674d9800e5648b9a86fdd36c9d5de9692f Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Tue, 16 May 2017 11:00:47 +0200
> Subject: [PATCH] drm: replace drm_[cm]alloc* by kvmalloc alternatives
> 
> drm_[cm]alloc* has grown their own kmalloc with vmalloc fallback
> implementations. MM has grown kvmalloc* helpers in the meantime. Let's
> use those because it a) reduces the code and b) MM has a better idea
> how to implement fallbacks (e.g. do not vmalloc before kmalloc is tried
> with __GFP_NORETRY).
> 
> drm_calloc_large needs to get __GFP_ZERO explicitly.
> 
> drm_free_large can be replaced by kvfree directly.
> 
> Signed-off-by: Michal Hocko 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c| 16 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 19 +++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  7 +-
>  drivers/gpu/drm/drm_gem.c  |  6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c  | 12 ++--
>  drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c|  4 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c   | 12 ++--
>  drivers/gpu/drm/exynos/exynos_drm_gem.c| 11 +--
>  drivers/gpu/drm/i915/i915_debugfs.c|  4 +-
>  drivers/gpu/drm/i915/i915_gem.c|  4 +-
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 34 +-
>  drivers/gpu/drm/i915/i915_gem_gtt.c|  6 +-
>  drivers/gpu/drm/i915/i915_gem_userptr.c|  8 +--
>  drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 12 ++--
>  drivers/gpu/drm/msm/msm_gem.c  | 10 +--
>  drivers/gpu/drm/radeon/radeon_cs.c | 11 +--
>  drivers/gpu/drm/radeon/radeon_gem.c|  2 +-
>  drivers/gpu/drm/radeon/radeon_ring.c   |  4 +-
>  drivers/gpu/drm/radeon/radeon_vm.c |  4 +-
>  drivers/gpu/drm/ttm/ttm_tt.c   | 13 ++--
>  drivers/gpu/drm/udl/udl_dmabuf.c   |  2 +-
>  drivers/gpu/drm/udl/udl_gem.c  |  2 +-
>  drivers/gpu/drm/vc4/vc4_gem.c  | 15 +++--
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 27 
>  include/drm/drmP.h |  1 -
>  include/drm/drm_mem_util.h | 78 
> --
>  26 files changed, 126 insertions(+), 198 deletions(-)
>  delete mode 100644 include/drm/drm_mem_util.h
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> index a6649874e6ce..9f0247cdda5e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> @@ -96,7 +96,7 @@ static int amdgpu_bo_list_set(struct amdgpu_device *adev,
>   int r;
>   unsigned long total_size = 0;
>  
> - array = drm_malloc_ab(num_entries, sizeof(struct amdgpu_bo_list_entry));
> + array = kvmalloc_array(num_entries, sizeof(struct 
> amdgpu_bo_list_entry), GFP_KERNEL);
>   if (!array)
>   return -ENOMEM;
>   memset(array, 0, num_entries * sizeof(struct amdgpu_bo_list_entry));
> @@ -148,7 +148,7 @@ static int amdgpu_bo_list_set(struct amdgpu_device *adev,
>   for (i = 0; i < list->num_entries; ++i)
>   amdgpu_bo_unref(>array[i].robj);
>  
> - drm_free_large(list->array);
> + kvfree(list->array);
>  
>   list->gds_obj = gds_obj;
>   list->gws_obj = gws_obj;
> @@ -163,7 +163,7 @@ static int 

Re: [PATCH v2 43/53] docs: update old references for DocBook from the documentation

[Bartlomiej Zolnierkiewicz]

On Tuesday, May 16, 2017 09:16:35 AM Mauro Carvalho Chehab wrote:
> DocBook is mentioned several times at the documentation. Update
> the obsolete references from it at the DocBook.
> 
> Acked-by: SeongJae Park 
> Signed-off-by: Mauro Carvalho Chehab 

For fbdev part:

Acked-by: Bartlomiej Zolnierkiewicz 

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

[PATCH] drm: add missing declaration to drm_blend.h

[Tomi Valkeinen]

drm_blend.h is missing declaration for 'struct drm_plane'. Add it.

Signed-off-by: Tomi Valkeinen 
---
 include/drm/drm_blend.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
index 13221cf9b3eb..bc9e596be4c2 100644
--- a/include/drm/drm_blend.h
+++ b/include/drm/drm_blend.h
@@ -28,6 +28,7 @@
 
 struct drm_device;
 struct drm_atomic_state;
+struct drm_plane;
 
 /*
  * Rotation property bits. DRM_ROTATE_ rotates the image by the
-- 
2.7.4

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

Re: [linux-sunxi] Re: [PATCH v7 05/13] drm/sun4i: abstract a engine type

[Maxime Ripard]

On Mon, May 15, 2017 at 05:35:02PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月15日 GMT+08:00 下午5:20:01, Maxime Ripard 
>  写到:
> >On Mon, May 15, 2017 at 12:30:37AM +0800, Icenowy Zheng wrote:
> >> As we are going to add support for the Allwinner DE2 engine in
> >sun4i-drm
> >> driver, we will finally have two types of display engines -- the DE1
> >> backend and the DE2 mixer. They both do some display blending and
> >feed
> >> graphics data to TCON, and is part of the "Display Engine" called by
> >> Allwinner, so I choose to call them both "engine" here.
> >> 
> >> Abstract the engine type to a new struct with an ops struct, which
> >contains
> >> functions that should be called outside the engine-specified code (in
> >> TCON, CRTC or TV Encoder code).
> >> 
> >> Signed-off-by: Icenowy Zheng 
> >> Reviewed-by: Chen-Yu Tsai 
> >> ---
> >> Changes in v7:
> >> - Mention "Display Engine" for the name "engine".
> >> - Fixed some small issues found by Chen-Yu and added his ACK.
> >> Changes in v6:
> >> - Rebased on wens's multi-pipeline patchset.
> >> - Split out Makefile changes.
> >
> >You also added a get_id callback here...
> >
> >> +static const struct sunxi_engine_ops sun4i_backend_engine_ops = {
> >> +  .commit = sun4i_backend_commit,
> >> +  .layers_init= sun4i_layers_init,
> >> +  .apply_color_correction = sun4i_backend_apply_color_correction,
> >> +  .disable_color_correction   = 
> >> sun4i_backend_disable_color_correction,
> >> +};
> >> +
> >
> >... that you don't populate ...
> >
> >> @@ -477,7 +481,7 @@ static int sun4i_tcon_bind(struct device *dev,
> >struct device *master,
> >>dev_set_drvdata(dev, tcon);
> >>tcon->drm = drm;
> >>tcon->dev = dev;
> >> -  tcon->id = backend->id;
> >> +  tcon->id = sunxi_engine_get_id(engine);
> >
> >... that you call to fill the TCON ID ...
> >
> >> +/**
> >> + * sunxi_engine_get_id - Get the ID of the engine.
> >> + * @engine:   pointer to the engine
> >> + *
> >> + * If the ID is not necessary, just do not implement it in
> >sunxi_engine_ops,
> >> + * and a default -1 will be returned.
> >> + */
> >> +static inline int
> >> +sunxi_engine_get_id(struct sunxi_engine *engine)
> >> +{
> >> +  if (engine->ops && engine->ops->get_id)
> >> +  return engine->ops->get_id(engine);
> >> +
> >> +  return -1;
> >
> >... and will return -1 if not populated, which essentially means that
> >instead of having 0 or 1, we're now having -1 as our id.
> >
> >This is a regression, and I'm even wondering if we can't just store
> >the ID in the sunxi_engine structure. Is anything preventing us to do
> >that, instead of using a callback?
> 
> Some engines (de2 mixer) doesn't use the ID. But 0 is a valid ID here.

Surely it will at some point.

> If we just store it in sunxi_engine, it should be assigned -1 for de2 mixer.
> Is this applicable?
> 
> If it's okay I will do so.

Yes, it sounds reasonable.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[PATCH v5] dma-buf/sync-file: Defer creation of sync_file->name

[Chris Wilson]

Constructing the name takes the majority of the time for allocating a
sync_file to wrap a fence, and the name is very rarely used (only via
the sync_file status user interface). To reduce the impact on the common
path (that of creating sync_file to pass around), defer the construction
of the name until it is first used.

v2: Update kerneldoc (kbuild test robot)
v3: sync_debug.c was peeking at the name
v4: Comment upon the potential race between two users of
sync_file_get_name() and claim that such a race is below the level of
notice. However, to prevent any future nuisance, use a global spinlock
to serialize the assignment of the name.
v5: Completely avoid the read/write race by only storing the name passed
in from the user inside sync_file->user_name and passing in a buffer to
dynamically construct the name otherwise.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Daniel Vetter 
Cc: David Herrmann 
---
 drivers/dma-buf/sync_debug.c |  4 +++-
 drivers/dma-buf/sync_file.c  | 39 ---
 include/linux/sync_file.h|  5 +++--
 3 files changed, 38 insertions(+), 10 deletions(-)

diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index 4b1731ee7458..59a3b2f8ee91 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -132,9 +132,11 @@ static void sync_print_obj(struct seq_file *s, struct 
sync_timeline *obj)
 static void sync_print_sync_file(struct seq_file *s,
  struct sync_file *sync_file)
 {
+   char buf[128];
int i;
 
-   seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
+   seq_printf(s, "[%p] %s: %s\n", sync_file,
+  sync_file_get_name(sync_file, buf, sizeof(buf)),
   sync_status_str(dma_fence_get_status(sync_file->fence)));
 
if (dma_fence_is_array(sync_file->fence)) {
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index c9eb4997cfcc..d7e219d2669d 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -80,11 +80,6 @@ struct sync_file *sync_file_create(struct dma_fence *fence)
 
sync_file->fence = dma_fence_get(fence);
 
-   snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
-fence->ops->get_driver_name(fence),
-fence->ops->get_timeline_name(fence), fence->context,
-fence->seqno);
-
return sync_file;
 }
 EXPORT_SYMBOL(sync_file_create);
@@ -129,6 +124,36 @@ struct dma_fence *sync_file_get_fence(int fd)
 }
 EXPORT_SYMBOL(sync_file_get_fence);
 
+/**
+ * sync_file_get_name - get the name of the sync_file
+ * @sync_file: sync_file to get the fence from
+ * @buf:   destination buffer to copy sync_file name into
+ * @len:   available size of destination buffer.
+ *
+ * Each sync_file may have a name assigned either by the user (when merging
+ * sync_files together) or created from the fence it contains. In the latter
+ * case construction of the name is deferred until use, and so requires
+ * sync_file_get_name().
+ *
+ * Returns: a string representing the name.
+ */
+char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len)
+{
+   if (sync_file->user_name[0]) {
+   strlcpy(buf, sync_file->user_name, len);
+   } else {
+   struct dma_fence *fence = sync_file->fence;
+
+   snprintf(buf, len, "%s-%s%llu-%d",
+fence->ops->get_driver_name(fence),
+fence->ops->get_timeline_name(fence),
+fence->context,
+fence->seqno);
+   }
+
+   return buf;
+}
+
 static int sync_file_set_fence(struct sync_file *sync_file,
   struct dma_fence **fences, int num_fences)
 {
@@ -266,7 +291,7 @@ static struct sync_file *sync_file_merge(const char *name, 
struct sync_file *a,
goto err;
}
 
-   strlcpy(sync_file->name, name, sizeof(sync_file->name));
+   strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
return sync_file;
 
 err:
@@ -419,7 +444,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
}
 
 no_fences:
-   strlcpy(info.name, sync_file->name, sizeof(info.name));
+   sync_file_get_name(sync_file, info.name, sizeof(info.name));
info.status = dma_fence_is_signaled(sync_file->fence);
info.num_fences = num_fences;
 
diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index d37beefdfbd5..5226d62ae91b 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -23,7 +23,7 @@
 /**
  * struct sync_file - sync file to export to the userspace
  * @file:  file representing this fence
- * @name:  name of sync_file. 

Re: [PATCH] drm: use kvmalloc_array for drm_malloc*

[Chris Wilson]

On Tue, May 16, 2017 at 12:53:52PM +0200, Michal Hocko wrote:
> On Tue 16-05-17 10:31:19, Chris Wilson wrote:
> > On Tue, May 16, 2017 at 11:06:06AM +0200, Michal Hocko wrote:
> > > From: Michal Hocko 
> > > 
> > > drm_malloc* has grown their own kmalloc with vmalloc fallback
> > > implementations. MM has grown kvmalloc* helpers in the meantime. Let's
> > > use those because it a) reduces the code and b) MM has a better idea
> > > how to implement fallbacks (e.g. do not vmalloc before kmalloc is tried
> > > with __GFP_NORETRY).
> > 
> > Better? The same idea. The only difference I was reluctant to hand out
> > large pages for long lived objects. If that's the wisdom of the core mm,
> > so be it.
> 
> vmalloc tends to fragment physical memory more os it is preferable to
> try the physically contiguous request first and only fall back to
> vmalloc if the first attempt would be too costly or it fails.

Not relevant for the changelog in this patch, but it would be nice to
have that written in kvmalloc() as to why the scatterring of 4k vmapped
pages prevents defragmentation when compared to allocating large pages.
I have vague recollections of seeing the conversation, but a summary as
to the reason why kvmalloc prefers large pages will be good for future
reference.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] drm: Add DRM_ROTATE_ and DRM_REFLECT_ defines to UAPI

[Emil Velikov]

On 15 May 2017 at 18:13, Robert Foss  wrote:
>
>
> On 2017-05-15 09:23 AM, Emil Velikov wrote:
>>
>> Hi Rob,
>>
>> On 14 May 2017 at 18:26, Robert Foss  wrote:
>>>
>>> Add DRM_ROTATE_ and DRM_REFLECT_ defines to the UAPI as a convenience.
>>>
>>> Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
>>> through the atomic API, but realizing that userspace is likely to take
>>> shortcuts and assume that the enum values are what is sent over the
>>> wire.
>>>
>>> As a result these defines are provided purely as a convenience to
>>> userspace applications.
>>>
>>> Signed-off-by: Robert Foss 
>>> ---
>>>  drivers/gpu/drm/drm_rect.c |  1 +
>>>  include/drm/drm_blend.h| 18 
>>>  include/uapi/drm/drm.h | 73
>>> ++
>>>  3 files changed, 74 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
>>> index bc5575960ebc..bdb27434bb10 100644
>>> --- a/drivers/gpu/drm/drm_rect.c
>>> +++ b/drivers/gpu/drm/drm_rect.c
>>> @@ -24,6 +24,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>
>>> diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
>>> index 13221cf9b3eb..d149a63b893b 100644
>>> --- a/include/drm/drm_blend.h
>>> +++ b/include/drm/drm_blend.h
>>> @@ -29,24 +29,6 @@
>>>  struct drm_device;
>>>  struct drm_atomic_state;
>>>
>> Since the defines are used here, move the above include to this file?
>
>
> Done.
>
>
>>
>>> -/*
>>> - * Rotation property bits. DRM_ROTATE_ rotates the image by the
>>> - * specified amount in degrees in counter clockwise direction.
>>> DRM_REFLECT_X and
>>> - * DRM_REFLECT_Y reflects the image along the specified axis prior to
>>> rotation
>>> - *
>>> - * WARNING: These defines are UABI since they're exposed in the rotation
>>> - * property.
>>> - */
>>> -#define DRM_ROTATE_0   BIT(0)
>>> -#define DRM_ROTATE_90  BIT(1)
>>> -#define DRM_ROTATE_180 BIT(2)
>>> -#define DRM_ROTATE_270 BIT(3)
>>> -#define DRM_ROTATE_MASK (DRM_ROTATE_0   | DRM_ROTATE_90 | \
>>> -DRM_ROTATE_180 | DRM_ROTATE_270)
>>> -#define DRM_REFLECT_X  BIT(4)
>>> -#define DRM_REFLECT_Y  BIT(5)
>>> -#define DRM_REFLECT_MASK (DRM_REFLECT_X | DRM_REFLECT_Y)
>>> -
>>>  static inline bool drm_rotation_90_or_270(unsigned int rotation)
>>>  {
>>> return rotation & (DRM_ROTATE_90 | DRM_ROTATE_270);
>>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>>> index 42d9f64ce416..d7140b0091bc 100644
>>> --- a/include/uapi/drm/drm.h
>>> +++ b/include/uapi/drm/drm.h
>>
>>
>> drm_mode.h might be a better fit.
>
>
> About this, I don't disagree, but other defines in drm_mode.h seem to be
> prefixed with DRM_MODE_ which this isn't which is why I didn't put it there.
>
> Knowing this, do you still prefer these defines living in drm_mode.h?
>
Feel free to give them a DRM_MODE_ prefix or something else - say
DRM_MODE_PROP_.

AFAICT drm_mode.h deals with KMS specifics and the prop_id mentioned
in the documentation is already there, so it would make sense to add
it there.

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

Re: [kbuild-all] [radeon-alex:amd-staging-4.11 1061/1085] sparc64-linux-gnu-gcc: error: unrecognized command line option '-msse'; did you mean '-fdse'?

[Christian König]

Am 16.05.2017 um 11:16 schrieb Michel Dänzer:

[ Dropping build robot aliases, adding amd-gfx and DC folks ]

On 16/05/17 05:18 PM, Philip Li wrote:

On Tue, May 16, 2017 at 10:04:32AM +0200, Christian König wrote:

Am 16.05.2017 um 07:20 schrieb zhoucm1:

On 2017年05月15日 17:52, kbuild test robot wrote:

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11
head:   c285c73f2213f503a93aa142fff186e160b4a371
commit: 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24 [1061/1085]
drm/amd: fix init order of sched job
config: sparc-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
 wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
 chmod +x ~/bin/make.cross
 git checkout 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24
 # save the attached .config to linux build tree
 make.cross ARCH=sparc

All errors (new ones prefixed by >>):


sparc64-linux-gnu-gcc: error: unrecognized command line
option '-msse'; did you mean '-fdse'?
sparc64-linux-gnu-gcc: error: unrecognized command line
option '-mpreferred-stack-boundary=4'

[...]


Thanks for input, the issue does exist (as introduced by
"drm/amdgpu/display: Enable DCN in DC"), so the report like
https://lists.01.org/pipermail/kbuild-all/2017-May/033857.html
does make sense.

It's because some DC Makefiles hardcode -msse and other compiler flags
which aren't supported on all architectures.

DC folks, please fix this, either by only adding flags on architectures
where they're supported, or by preventing the corresponding code from
getting built on architectures where they're not supported.


Ah, yes that's indeed an issue.

But please at least fix the bisect or otherwise the wrong people get 
those mails and wonder about the error messages.


Christian.

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

Re: [PATCH] dma-buf/sync-file: Defer creation of sync_file->name

[kbuild test robot]

Hi Chris,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc1 next-20170516]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/dma-buf-sync-file-Defer-creation-of-sync_file-name/20170512-193751
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers//dma-buf/sync_debug.c: In function 'sync_print_sync_file':
>> drivers//dma-buf/sync_debug.c:137:53: error: 'struct sync_file' has no 
>> member named 'name'
 seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
^~

vim +137 drivers//dma-buf/sync_debug.c

0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  131 
 
d7fdb0ae drivers/staging/android/sync_debug.c Gustavo Padovan   2016-01-21  132 
 static void sync_print_sync_file(struct seq_file *s,
d7fdb0ae drivers/staging/android/sync_debug.c Gustavo Padovan   2016-01-21  133 
  struct sync_file *sync_file)
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  134 
 {
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  135 
int i;
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  136 
 
d7fdb0ae drivers/staging/android/sync_debug.c Gustavo Padovan   2016-01-21 @137 
seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
d6c99f4b drivers/dma-buf/sync_debug.c Chris Wilson  2017-01-04  138 
   sync_status_str(dma_fence_get_status(sync_file->fence)));
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  139 
 
f54d1867 drivers/dma-buf/sync_debug.c Chris Wilson  2016-10-25  140 
if (dma_fence_is_array(sync_file->fence)) {

:: The code at line 137 was first introduced by commit
:: d7fdb0ae9d115fa14ff3a5382c8a62de41c7786a staging/android: rename 
sync_fence to sync_file

:: TO: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
:: CC: Greg Kroah-Hartman <gre...@linuxfoundation.org>

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


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

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

[bugzilla-daemon]

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

--- Comment #9 from taij...@posteo.de ---
Created attachment 131372
  --> https://bugs.freedesktop.org/attachment.cgi?id=131372=edit
new dmesg output with kernel 4.12-rc1

after updating the kernel to 4.12-rc1 at least some of the error messages have
shifted: 

[drm:amdgpu_suspend [amdgpu]] *ERROR* suspend of IP block  failed
-110

has gone away, but there is still plenty of this going on:

[   18.422475] amdgpu: [powerplay] 
failed to send pre message 62 ret is 0 

And of course this is also still a thing:

[3.053342] amdgpu: [powerplay] [AVFS] Something is broken. See log!
[3.055251] amdgpu: [powerplay] Can't find requested voltage id in
vdd_dep_on_sclk table!

-- 
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: use kvmalloc_array for drm_malloc*

[Chris Wilson]

On Tue, May 16, 2017 at 11:06:06AM +0200, Michal Hocko wrote:
> From: Michal Hocko 
> 
> drm_malloc* has grown their own kmalloc with vmalloc fallback
> implementations. MM has grown kvmalloc* helpers in the meantime. Let's
> use those because it a) reduces the code and b) MM has a better idea
> how to implement fallbacks (e.g. do not vmalloc before kmalloc is tried
> with __GFP_NORETRY).

Better? The same idea. The only difference I was reluctant to hand out
large pages for long lived objects. If that's the wisdom of the core mm,
so be it.
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] gpu: drm: i915: compress logic into one line

[Daniel Vetter]

On Mon, May 15, 2017 at 05:00:28PM -0500, Gustavo A. R. Silva wrote:
> Simplify logic to avoid unnecessary variable declaration and assignment.
> 
> Signed-off-by: Gustavo A. R. Silva 

Both applied, thanks.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b13b53b..ca6479a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9565,7 +9565,6 @@ static int ironlake_crtc_compute_clock(struct 
> intel_crtc *crtc,
>  {
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_shared_dpll *pll;
>   const struct intel_limit *limit;
>   int refclk = 12;
>  
> @@ -9609,8 +9608,7 @@ static int ironlake_crtc_compute_clock(struct 
> intel_crtc *crtc,
>  
>   ironlake_compute_dpll(crtc, crtc_state, NULL);
>  
> - pll = intel_get_shared_dpll(crtc, crtc_state, NULL);
> - if (pll == NULL) {
> + if (!intel_get_shared_dpll(crtc, crtc_state, NULL)) {
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(crtc->pipe));
>   return -EINVAL;
> -- 
> 2.5.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH] drm/i915/guc:fix spelling mistake: "adddress" -> "address"

[Daniel Vetter]

On Tue, May 16, 2017 at 10:22:35AM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in seq_printf message.
> 
> Fixes: a8b9370fc79c1 ("drm/i915/guc: Dump the GuC stage descriptor pool in 
> debugfs")
> Signed-off-by: Colin Ian King 

Applied, thanks.
-Daniel
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index bd9abef40c66..76abff186d01 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2582,7 +2582,7 @@ static int i915_guc_stage_pool(struct seq_file *m, void 
> *data)
>  desc->db_trigger_uk);
>   seq_printf(m, "\tProcess descriptor: 0x%x\n",
>  desc->process_desc);
> - seq_printf(m, "\tWorkqueue adddress: 0x%x, size: 0x%x\n",
> + seq_printf(m, "\tWorkqueue address: 0x%x, size: 0x%x\n",
>  desc->wq_addr, desc->wq_size);
>   seq_putc(m, '\n');
>  
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH] drm/i915/guc:fix spelling mistake: "adddress" -> "address"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in seq_printf message.

Fixes: a8b9370fc79c1 ("drm/i915/guc: Dump the GuC stage descriptor pool in 
debugfs")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bd9abef40c66..76abff186d01 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2582,7 +2582,7 @@ static int i915_guc_stage_pool(struct seq_file *m, void 
*data)
   desc->db_trigger_uk);
seq_printf(m, "\tProcess descriptor: 0x%x\n",
   desc->process_desc);
-   seq_printf(m, "\tWorkqueue adddress: 0x%x, size: 0x%x\n",
+   seq_printf(m, "\tWorkqueue address: 0x%x, size: 0x%x\n",
   desc->wq_addr, desc->wq_size);
seq_putc(m, '\n');
 
-- 
2.11.0

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

Re: [PATCH] drm: use kvmalloc_array for drm_malloc*

[Daniel Vetter]

On Tue, May 16, 2017 at 11:06:06AM +0200, Michal Hocko wrote:
> From: Michal Hocko 
> 
> drm_malloc* has grown their own kmalloc with vmalloc fallback
> implementations. MM has grown kvmalloc* helpers in the meantime. Let's
> use those because it a) reduces the code and b) MM has a better idea
> how to implement fallbacks (e.g. do not vmalloc before kmalloc is tried
> with __GFP_NORETRY).
> 
> Signed-off-by: Michal Hocko 

Shouldn't we go one step further and just remove these wrappers, maybe
with cocci? Especially drm_malloc_gfp is surpremely pointless after this
patch (and drm_malloc_ab probably not that useful either).
-Daniel
> ---
>  include/drm/drm_mem_util.h | 23 ++-
>  1 file changed, 2 insertions(+), 21 deletions(-)
> 
> diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_mem_util.h
> index d0f6cf2e5324..b461e4e4e6db 100644
> --- a/include/drm/drm_mem_util.h
> +++ b/include/drm/drm_mem_util.h
> @@ -43,31 +43,12 @@ static __inline__ void *drm_calloc_large(size_t nmemb, 
> size_t size)
>  /* Modeled after cairo's malloc_ab, it's like calloc but without the 
> zeroing. */
>  static __inline__ void *drm_malloc_ab(size_t nmemb, size_t size)
>  {
> - if (size != 0 && nmemb > SIZE_MAX / size)
> - return NULL;
> -
> - if (size * nmemb <= PAGE_SIZE)
> - return kmalloc(nmemb * size, GFP_KERNEL);
> -
> - return vmalloc(size * nmemb);
> + return kvmalloc_array(nmemb, size, GFP_KERNEL);
>  }
>  
>  static __inline__ void *drm_malloc_gfp(size_t nmemb, size_t size, gfp_t gfp)
>  {
> - if (size != 0 && nmemb > SIZE_MAX / size)
> - return NULL;
> -
> - if (size * nmemb <= PAGE_SIZE)
> - return kmalloc(nmemb * size, gfp);
> -
> - if (gfp & __GFP_RECLAIMABLE) {
> - void *ptr = kmalloc(nmemb * size,
> - gfp | __GFP_NOWARN | __GFP_NORETRY);
> - if (ptr)
> - return ptr;
> - }
> -
> - return __vmalloc(size * nmemb, gfp, PAGE_KERNEL);
> + return kvmalloc_array(nmemb, size, gfp);
>  }
>  
>  static __inline void drm_free_large(void *ptr)
> -- 
> 2.11.0
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
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: [kbuild-all] [radeon-alex:amd-staging-4.11 1061/1085] sparc64-linux-gnu-gcc: error: unrecognized command line option '-msse'; did you mean '-fdse'?

[Michel Dänzer]

[ Dropping build robot aliases, adding amd-gfx and DC folks ]

On 16/05/17 05:18 PM, Philip Li wrote:
> On Tue, May 16, 2017 at 10:04:32AM +0200, Christian König wrote:
>> Am 16.05.2017 um 07:20 schrieb zhoucm1:
>>> On 2017年05月15日 17:52, kbuild test robot wrote:
 tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11
 head:   c285c73f2213f503a93aa142fff186e160b4a371
 commit: 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24 [1061/1085]
 drm/amd: fix init order of sched job
 config: sparc-allmodconfig (attached as .config)
 compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
 reproduce:
 wget 
 https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross
 -O ~/bin/make.cross
 chmod +x ~/bin/make.cross
 git checkout 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24
 # save the attached .config to linux build tree
 make.cross ARCH=sparc

 All errors (new ones prefixed by >>):

>> sparc64-linux-gnu-gcc: error: unrecognized command line
>> option '-msse'; did you mean '-fdse'?
>> sparc64-linux-gnu-gcc: error: unrecognized command line
>> option '-mpreferred-stack-boundary=4'

[...]

> Thanks for input, the issue does exist (as introduced by
> "drm/amdgpu/display: Enable DCN in DC"), so the report like 
> https://lists.01.org/pipermail/kbuild-all/2017-May/033857.html
> does make sense.

It's because some DC Makefiles hardcode -msse and other compiler flags
which aren't supported on all architectures.

DC folks, please fix this, either by only adding flags on architectures
where they're supported, or by preventing the corresponding code from
getting built on architectures where they're not supported.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

Three tags in total. I also just realized that in the last one I've
forgotten to mention the LPE audio fixes from Ville, which also touch
sound/. Those patches are all reviewed by Takashi.

drm-intel-next-2017-05-15:
Another pile of stuff for 4.12:

- OA improvements and fixes from Robert Bragg
- fixes for the dp aux backlight driver (Puthikorn Voravootivat)
- no RCU during shrinking (unfortunately), from Joonas
- small atomic leftovers (better unpin, statified hw verifier), from
  Maarten
- g4x wm fixes (Ville)
- piles of cursor fixes/improvements (Ville)
- g4x overlay plane support (Ville)
- prep for new guc logging/notification (Michal Wajdeczko)
- pile of static checker appeasement from Imre
- implement dma_buf->kmap, good for testing (Chris)
- fine-tune ring handling (Chris)
drm-intel-next-2017-05-02:
Somehow not much these 2 weeks ...

- (hopefully) stability fixes for byt/bsw gt wake (Chris)
- tighten up requests (especially restarts) checks and debug tracking
  (Chris)
- unify context handling more for gen5+ (Chris+Joonas)
- oddball bugfixes as usual
drm-intel-next-2017-04-18:
First slice of 4.13 features:

new uabi:
- extend error state dumping to include non-batch buffers requested by
  userspace (Chris), so that mesa gets more useful error state dumps
- reapply the link status patch, for handlig dp link failures
  (Manasi). This needs updated -modesetting to work correctly.
- Add new _WC cache domain, our assumption that wc can be subsumed by
  the existing cache domains didn't pan out (Chris)

feature work:
- first pile of conversion to atomic properties for connectors
  (Maarten)
- refactor dp link rate handling code and related areas (Jani)
- split engine info into class and runtime stuff (Oscar Mateo)
- more robust wait_for_register code (Chris, Michal Wajdeczko)
- fix rcu issues in the shrinker and simplify locking (Joonas)
- guc/huc for glk (Anusha)
- enable atomic modesetting for vlv/chv (Ville), plus final fixes for
  that

I chatted with Sean, and the plan is that he'll send you the drm-misc-next
pull for opening 4.13 drm-next later today. We need to backmerge the
entire thing into drm-intel afterwards, Maarten needs the connector state
hooks for landing the remaining connector atomicification patches for
i915.

Cheers, Daniel


The following changes since commit 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf:

  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next 
(2017-05-02 04:46:01 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-next-2017-05-15

for you to fetch changes up to 2388cd9c5056b10c8e461ca2ab075f49d6f1b25d:

  drm/i915: Update DRIVER_DATE to 20170515 (2017-05-15 09:11:48 +0200)


Another pile of stuff for 4.12:

- OA improvements and fixes from Robert Bragg
- fixes for the dp aux backlight driver (Puthikorn Voravootivat)
- no RCU during shrinking (unfortunately), from Joonas
- small atomic leftovers (better unpin, statified hw verifier), from
  Maarten
- g4x wm fixes (Ville)
- piles of cursor fixes/improvements (Ville)
- g4x overlay plane support (Ville)
- prep for new guc logging/notification (Michal Wajdeczko)
- pile of static checker appeasement from Imre
- implement dma_buf->kmap, good for testing (Chris)
- fine-tune ring handling (Chris)


Ander Conselvan de Oliveira (2):
  drm/i915/glk: Don't allow 12 bpc when htotal is too big
  drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

Andrea Arcangeli (1):
  i915: initialize the free_list of the fencing atomic_helper

Anusha Srivatsa (2):
  drm/i915/GuC/GLK: Load GuC on GLK
  drm/i915/GLK/HuC: Load HuC on GLK

Chris Wilson (51):
  drm/i915: intel_ring.engine is unused
  drm/i915: Onion unwind for intel_init_ring_common()
  drm/i915: Park the signaler before sleeping
  drm/i915: Apply a cond_resched() to the saturated signaler
  drm/i915: Use the right mapping_gfp_mask for final shmem allocation
  drm/i915: Assert the engine is idle before overwiting the HWS
  drm/i915: Advance ring->head fully when idle
  drm/i915: The shrinker already acquires struct_mutex, so call it unlocked
  drm/i915: Drain any freed objects prior to hibernation
  drm/i915: Break up long runs of freeing objects
  drm/i915: Insert cond_resched() into i915_gem_free_objects
  drm/i915: Use drm_i915_private directly from debugfs
  drm/i915: Stop second guessing the caller for 
intel_uncore_wait_for_register()
  drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
  drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()
  drm/i915: Use __intel_uncore_wait_for_register_fw for 
sandybride_pcode_read
  drm/i915: Use safer intel_uncore_wait_for_register in ring-init
  drm/i915: Rename intel_engine_cs.exec_id to uabi_id

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

[bugzilla-daemon]

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

--- Comment #8 from takeshi ogasawara  ---
Hi 

The same thing happens to my system

System:
Ubuntu 17.04 + Kernel 4.12rc1
AMD Ryzen 7 1700X
ASRock X370 taichi Bios v2.20
Sapphire R9 Fury 4 GB Nitro
2x16GiB

[1.798013] amdgpu: [powerplay] Can't find requested voltage id in
vdd_dep_on_sclk table!
[1.805082] amdgpu: [powerplay] Failed to setup PCC HW register! Wrong GPIO
assigned for VDDC_PCC_GPIO_PINID!


When Xorg got settled, the following message remains in ker.log

May 16 17:03:57 anilaR9 kernel: [  725.962865] INFO: task amdgpu_cs:0:1365
blocked for more than 120 seconds.
May 16 17:03:57 anilaR9 kernel: [  725.962873] amdgpu_cs:0 D0  1365  
1318 0x0040
May 16 17:03:57 anilaR9 kernel: [  725.962916]  amdgpu_ctx_add_fence+0x63/0x100
[amdgpu]
May 16 17:03:57 anilaR9 kernel: [  725.962936]  amdgpu_cs_ioctl+0x107a/0x1410
[amdgpu]
May 16 17:03:57 anilaR9 kernel: [  725.962966]  ?
amdgpu_cs_find_mapping+0xa0/0xa0 [amdgpu]
May 16 17:03:57 anilaR9 kernel: [  725.962983]  amdgpu_drm_ioctl+0x4f/0x90
[amdgpu]

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

Re: [PATCH 1/2] dt/bindings: display: fix display-timing reference

[Laurent Pinchart]

Hi Baruch,

Thank you for the patch.

On Tuesday 16 May 2017 11:19:04 Baruch Siach wrote:

A commit message body would be nice.

> Fixes: 14da3ed8dd08 ("devicetree/bindings: display: Document common panel
> properties")
> Cc: Laurent Pinchart 
> Cc: Rob Herring 
> Signed-off-by: Baruch Siach 
> ---
>  Documentation/devicetree/bindings/display/panel/panel-common.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> b/Documentation/devicetree/bindings/display/panel/panel-common.txt index
> ec52c472c845..0603af877155 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> @@ -38,7 +38,7 @@ Display Timings
>require specific display timings. The panel-timing subnode expresses
> those timings as specified in the timing subnode section of the display
> timing bindings defined in
> -  Documentation/devicetree/bindings/display/display-timing.txt.
> +  Documentation/devicetree/bindings/display/panel/display-timing.txt.

My bad.

Acked-by: Laurent Pinchart 

> 
> 
>  Connectivity

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2] drm/tegra: Correct idr_alloc() minimum id

[Mikko Perttunen]

Reviewed-by: Mikko Perttunen 

On 14.05.2017 23:47, Dmitry Osipenko wrote:

The client ID 0 is reserved by the host1x/cdma to mark the timeout timer
work as already been scheduled and context ID is used as the clients one.
This fixes spurious CDMA timeouts.

Fixes: bdd2f9cd10eb ("drm/tegra: Don't leak kernel pointer to userspace")
Signed-off-by: Dmitry Osipenko 
---

v2: Changed the commit description, now explains the cause of CDMA timeouts.

 drivers/gpu/drm/tegra/drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index c5844a065681..489cb32453f7 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -548,7 +548,7 @@ static int tegra_client_open(struct tegra_drm_file *fpriv,
if (err < 0)
return err;

-   err = idr_alloc(>contexts, context, 0, 0, GFP_KERNEL);
+   err = idr_alloc(>contexts, context, 1, 0, GFP_KERNEL);
if (err < 0) {
client->ops->close_channel(context);
return err;


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

RE: [Intel-gfx] HDMI audio to support extcon

[Yang, Libin]

>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Monday, May 15, 2017 9:49 PM
>To: Yang, Libin 
>Cc: Vetter, Daniel ; Bossart, Pierre-louis louis.boss...@intel.com>; jani.nik...@linux.intel.com; intel-
>g...@lists.freedesktop.org; Girdwood, Liam R ;
>DRI Development 
>Subject: Re: [Intel-gfx] HDMI audio to support extcon
>
>Adding dri-devel.
>
>On Mon, May 15, 2017 at 08:16:44AM +, Yang, Libin wrote:
>> Hi Daniel,
>>
>> >-Original Message-
>> >From: Vetter, Daniel
>> >Sent: Friday, May 12, 2017 2:06 AM
>> >To: Bossart, Pierre-louis ; Yang,
>> >Libin ; jani.nik...@linux.intel.com
>> >Cc: Girdwood, Liam R ; Lin, Mengdong
>> >
>> >Subject: Re: HDMI audio to support extcon
>> >
>> >On Thu, 2017-05-11 at 11:13 -0500, Pierre-louis Bossart wrote:
>> >> On 5/11/17 9:41 AM, Yang, Libin wrote:
>> >> > > -Original Message-
>> >> > > From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> >> > > Sent: Thursday, May 11, 2017 4:29 PM
>> >> > > To: Yang, Libin ; Vetter, Daniel
>> >> > > 
>> >> > > Cc: Bossart, Pierre-louis ;
>> >> > > Lin, Mengdong ; Girdwood, Liam R
>> >> > > 
>> >> > > Subject: Re: HDMI audio to support extcon
>> >> > >
>> >> > > On Thu, 11 May 2017, "Yang, Libin"  wrote:
>> >> > > > Hi Daniel & Jani,
>> >> > > >
>> >> > > > Currently Pierre and I are trying to enabling extcon for HDMI
>> >> > > > audio, which
>> >> > >
>> >> > > will be used in Android for the hotplug event notification.
>> >> > >
>> >> > > What's "extcon"?
>> >> >
>> >> > Extcon is used by kernel to communicate with userspace. It tries
>> >> > to replace switch class (switch class is a legacy method to
>> >> > communicate with userspace in Android). The code is located in
>> >> > drivers/extcon/*
>> >>
>> >> Most Android kernels are ancient (3.10 to 3.18) and use an
>> >> Android-specific switch class implemented in the kernel, the
>> >> uevents are then used by AOSP to enable HDMI outputs. See
>> >>
>> >https://android.googlesource.com/platform/frameworks/base/+/0e2d281
>/s
>> >> ervices/java/com/android/server/WiredAccessoryManager.java#348
>> >>
>> >> For Android-IA we are using 4.9 and we'd like to move forward with
>> >> the extcon solution which part of the mainline kernel. The extcon
>> >> api relies on a registration and a state which set/unset when the
>> >> external device is hot-plugged/removed. The change in state
>> >> generates the uevents required by Android.When the CONFIG_ANDROID
>> >> is defined, the kernel creates a /sys/class/switch symlink which is
>> >> backwards compatible with what Android can parse.
>> >>
>> >> The question is where do we put the extcon registration 1. in the
>> >> i915 code (e.g. in intel_codec_enable()/disable()) 2. in the
>> >> HDaudio and LPEaudio code (two locations to maintain)
>> >>
>> >> Ideally we'd like to add information on ports to userspace so that
>> >> multiple outputs can be enabled. Currently Android can only support
>> >> one output since it doesn't get additional information.
>> >>
>> >> Does this help frame the problem statement?
>> >
>> >Yay for reinventing wheels in Android I guess (we have hotplug
>> >notifications since forever in drm ofc), but so be it. I think the
>> >right way to do this is to wire this into the generic drm output
>> >probe helpers in drm_probe_helpers.c, perhaps filtered to only handle
>HDMI (or whatever it is Android wants).
>>
>> The extcon implementation may be related to our hardware. For example,
>> it depends on the DDI port number and audio capability. I'm not sure
>> it is OK to implement it in drm level.
>
>Why does it depend upon the DDI port and stuff like that? Do we need to
>make sure that the extcon id somehow lines up with the port on the sound
>side, or is just having a link between the drm connector and sound port
>enough?

Each DDI port should have an interface to the userspace if it has audio
capability. This means we need check the DDI port firstly. And then
we will export the extcon interface to the userspace. This should be
hardware dependent? What's more, to make extcon more powerful,
I'm planning to extend the extcon function with acomp, so we can 
notify the userspace which PCM will be impacted on the hotplug events.

Regards,
Libin

>
>Not sure where exactly the problem is here, but I also wasn't involved in the
>extcon discussions. Please explain.
>-Daniel
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH] drm/tegra: Check offsets of a submitted command buffer and of relocations

[Mikko Perttunen]

On 16.05.2017 10:32, Erik Faye-Lund wrote:

On Tue, May 16, 2017 at 8:56 AM, Mikko Perttunen  wrote:

On 14.05.2017 23:47, Dmitry Osipenko wrote:


If commands buffer claims a number of words that is higher than its BO can
fit, a kernel OOPS will be fired on the out-of-bounds BO access. This was
triggered by an opentegra Xorg driver that erroneously pushed too many
commands to the pushbuf. The CMDA commands buffer address is 4 bytes
aligned, so check the alignment as well.

Add a sanity check for the relocations in a same way.

[   46.829393] Unable to handle kernel paging request at virtual address
f09b2000
...
[] (host1x_job_pin) from []
(tegra_drm_submit+0x474/0x510)
[] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c)
[] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec)
[] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c)

Signed-off-by: Dmitry Osipenko 
Reviewed-by: Erik Faye-Lund 
---
 drivers/gpu/drm/tegra/drm.c | 30 ++
 drivers/gpu/drm/tegra/gem.c |  5 -
 drivers/gpu/drm/tegra/gem.h |  5 +
 3 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 768750226452..c5844a065681 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -362,6 +362,8 @@ int tegra_drm_submit(struct tegra_drm_context
*context,
while (num_cmdbufs) {
struct drm_tegra_cmdbuf cmdbuf;
struct host1x_bo *bo;
+   struct tegra_bo *obj;
+   u64 offset;

if (copy_from_user(, cmdbufs, sizeof(cmdbuf))) {
err = -EFAULT;
@@ -374,6 +376,14 @@ int tegra_drm_submit(struct tegra_drm_context
*context,
goto fail;
}

+   offset = (u64)cmdbuf.offset + (u64)cmdbuf.words *
sizeof(u32);
+   obj = host1x_to_tegra_bo(bo);
+
+   if (offset & 3 || offset > obj->gem.size) {
+   err = -EINVAL;
+   goto fail;
+   }
+
host1x_job_add_gather(job, bo, cmdbuf.words,
cmdbuf.offset);
num_cmdbufs--;
cmdbufs++;
@@ -381,11 +391,31 @@ int tegra_drm_submit(struct tegra_drm_context
*context,

/* copy and resolve relocations from submit */
while (num_relocs--) {
+   struct host1x_reloc *reloc;
+   struct tegra_bo *obj;
+
err =
host1x_reloc_copy_from_user(>relocarray[num_relocs],
  [num_relocs],
drm,
  file);
if (err < 0)
goto fail;
+
+   reloc = >relocarray[num_relocs];
+   obj = host1x_to_tegra_bo(reloc->cmdbuf.bo);
+
+   if (reloc->cmdbuf.offset & 3 ||
+   reloc->cmdbuf.offset > obj->gem.size) {



This could still fail if the bo's size is not divisible by 4, even with >=
comparison (we would overwrite the buffer by 1 to 3 bytes). I would do the
same as in the gather case, i.e. find out the address immediately after the
write and compare using >. Perhaps add a helper function if it makes sense.
I also don't think the "& 3" checks are needed.


The bo-size is always a multiple of PAGE_SIZE, due to the rounding in
tegra_bo_alloc_object(), so I don't think this actually can fail. But
maybe we want to future-proof this code for a potential future where
this is not the case?



Yeah, I think whether or not this might change in the future, the code 
would be easier to understand with the change.

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

Re: [kbuild-all] [radeon-alex:amd-staging-4.11 1061/1085] sparc64-linux-gnu-gcc: error: unrecognized command line option '-msse'; did you mean '-fdse'?

[Philip Li]

On Tue, May 16, 2017 at 10:04:32AM +0200, Christian König wrote:
> Am 16.05.2017 um 07:20 schrieb zhoucm1:
> >
> >
> >On 2017年05月15日 17:52, kbuild test robot wrote:
> >>tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11
> >>head:   c285c73f2213f503a93aa142fff186e160b4a371
> >>commit: 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24 [1061/1085]
> >>drm/amd: fix init order of sched job
> >>config: sparc-allmodconfig (attached as .config)
> >>compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> >>reproduce:
> >> wget 
> >> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross
> >>-O ~/bin/make.cross
> >> chmod +x ~/bin/make.cross
> >> git checkout 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24
> >> # save the attached .config to linux build tree
> >> make.cross ARCH=sparc
> >>
> >>All errors (new ones prefixed by >>):
> >>
> sparc64-linux-gnu-gcc: error: unrecognized command line
> option '-msse'; did you mean '-fdse'?
> sparc64-linux-gnu-gcc: error: unrecognized command line
> option '-mpreferred-stack-boundary=4'
> >@@ -460,9 +460,9 @@ int amd_sched_job_init(struct amd_sched_job *job,
> >job->sched = sched;
> >job->s_entity = entity;
> >job->s_fence = amd_sched_fence_create(entity, owner);
> >-   job->id = atomic64_inc_return(>job_id_count);
> >if (!job->s_fence)
> >return -ENOMEM;
> >+   job->id = atomic64_inc_return(>job_id_count);
> >
> >INIT_WORK(>finish_work, amd_sched_job_finish);
> >INIT_LIST_HEAD(>node);
> >
> >Sorry, I don't know how commit 5f92704 results in your this error.
> >But from error message, it seems your compiler problems.
> 
> Yeah, that looks like a problem with the build bot.
> 
> We recently had a couple of those, so guys please fix your bots or
> people will start to ignore such messages.
Thanks for input, the issue does exist (as introduced by
"drm/amdgpu/display: Enable DCN in DC"), so the report like 
https://lists.01.org/pipermail/kbuild-all/2017-May/033857.html
does make sense. Of course, we will check to make sure the
bisect can point to the right/very first bad commit.

> 
> Regards,
> Christian.
> 
> >
> >Regards,
> >David Zhou
> >>---
> >>0-DAY kernel test infrastructureOpen Source
> >>Technology Center
> >>https://lists.01.org/pipermail/kbuild-all Intel Corporation
> >
> 
> ___
> kbuild-all mailing list
> kbuild-...@lists.01.org
> https://lists.01.org/mailman/listinfo/kbuild-all
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Pandiyan, Dhinakaran]

On Mon, 2017-05-15 at 17:43 -0700, Puthikorn Voravootivat wrote:
> 
> 
> On Mon, May 15, 2017 at 4:07 PM, Pandiyan, Dhinakaran
>  wrote:
> On Fri, 2017-05-12 at 17:31 -0700, Puthikorn Voravootivat
> wrote:
> >
> >
> >
> > On Fri, May 12, 2017 at 5:12 PM, Pandiyan, Dhinakaran
> >  wrote:
> > On Thu, 2017-05-11 at 16:02 -0700, Puthikorn
> Voravootivat
> > wrote:
> > > Read desired PWM frequency from panel vbt and
> calculate the
> > > value for divider in DPCD address 0x724 and 0x728
> to have
> > > as many bits as possible for PWM duty cyle for
> granularity
> > of
> > > brightness adjustment while the frequency is still
> within
> > 25%
> > > of the desired frequency.
> >
> > I read a few eDP panel data sheets, the PWM
> frequencies all
> > start from
> > ~200Hz. If the VBT chooses this lowest value to
> allow for more
> > brightness control, and then this patch lowers the
> value by
> > another 25%,
> > we'll end up below the panel allowed PWM frequency.
> >
> > In fact, one of the systems I checked had PWM
> frequency as
> > 200Hz in VBT
> > and the panel datasheet also had PWM frequency range
> starting
> > from
> > 200Hz. Have you considered this case?
> >
> > The spec said "A given LCD panel typically has a limited
> range of
> > backlight frequency capability.
> > To limit the programmable frequency range, limitations are
> placed on
> > the allowable total divider ratio with the Sink device"
> >  So I think it should be auto cap to 200Hz in this case.
> >
> > -DK
> > >
> > > Signed-off-by: Puthikorn Voravootivat
> 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c |
> 81
> > +++
> > >  1 file changed, 81 insertions(+)
> > >
> > > diff --git
> a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > index 0b48851013cc..6f10a2f1ab76 100644
> > > ---
> a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > +++
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > @@ -113,12 +113,86 @@
> > intel_dp_aux_set_dynamic_backlight_percent(struct
> intel_dp
> > *intel_dp,
> > >   }
> > >  }
> > >
> > > +/*
> > > + * Set PWM Frequency divider to match desired
> frequency in
> > vbt.
> > > + * The PWM Frequency is calculated as 27Mhz / (F
> x P).
> > > + * - Where F = PWM Frequency Pre-Divider value
> programmed
> > by field 7:0 of the
> > > + * EDP_BACKLIGHT_FREQ_SET register
> (DPCD
> > Address 00728h)
> > > + * - Where P = 2^Pn, where Pn is the value
> programmed by
> > field 4:0 of the
> > > + * EDP_PWMGEN_BIT_COUNT register
> (DPCD Address
> > 00724h)
> > > + */
> > > +static void intel_dp_aux_set_pwm_freq(struct
> > intel_connector *connector)
> > > +{
> > > + struct drm_i915_private *dev_priv =
> > to_i915(connector->base.dev);
> > > + struct intel_dp *intel_dp =
> > enc_to_intel_dp(>encoder->base);
> > > + int freq, fxp, fxp_min, fxp_max, fxp_actual,
> f = 1;
> > > + u8 pn, pn_min, pn_max;
> > > +
> > > + /* Find desired value of (F x P)
> > > +  * Note that, if F x P is out of supported
> range, the
> > maximum value or
> > > +  * minimum value will applied automatically.
> So no
> > need to check that.
> > > +  */
> > > + freq = dev_priv->vbt.backlight.pwm_freq_hz;
> > > + DRM_DEBUG_KMS("VBT defined backlight
> frequency %u Hz
> > \n", freq);
> > > + if (!freq) {
> > > + 

Re: [PATCH 2/2] drm/doc: Clarify mode_fixup vs. atomic_check a bit more

[Jose Abreu]

Hi Daniel,


On 15-05-2017 10:11, Daniel Vetter wrote:
> Brought up by both Laurent and Andrzej when reviewing the new
> ->mode_valid hooks. Since mode_fixup is just a simpler version of the
> much more generic atomic_check we can't really unify it with
> mode_valid. Most drivers should probably switch their current
> mode_fixup code to either the new mode_valid or the atomic_check
> hooks, but e.g. that doesn't exist yet for bridges, and for CRTCs the
> situation is a bit more complicated. Hence there's no clear
> equivalence between mode_fixup and mode_valid, even if it looks like
> that at first glance.
>
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Jose Abreu 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  include/drm/drm_modeset_helper_vtables.h | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index c72fca544a41..613b2a602b77 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -156,7 +156,11 @@ struct drm_crtc_helper_funcs {
>* allowed.
>*
>* Atomic drivers which need to inspect and adjust more state should
> -  * instead use the @atomic_check callback.
> +  * instead use the @atomic_check callback, but note that they're not
> +  * perfectly equivalent: @mode_valid is called from
> +  * drm_atomic_helper_check_modeset(), but @atomic_check is called from
> +  * drm_atomic_helper_check_planes(), because originally it was meant for
> +  * plane update checks only..
>*
>* Also beware that userspace can request its own custom modes, neither
>* core nor helpers filter modes to the list of probe modes reported by
> @@ -529,7 +533,9 @@ struct drm_encoder_helper_funcs {
>* allowed.
>*
>* Atomic drivers which need to inspect and adjust more state should
> -  * instead use the @atomic_check callback.
> +  * instead use the @atomic_check callback. If @atomic_check is used,
> +  * this hook isn't called since @atomic_check allows a strict superset
> +  * of the functionality of @mode_fixup.
>*
>* Also beware that userspace can request its own custom modes, neither
>* core nor helpers filter modes to the list of probe modes reported by
> @@ -716,6 +722,11 @@ struct drm_encoder_helper_funcs {
>* update the CRTC to match what the encoder needs for the requested
>* connector.
>*
> +  * Since this provides a strict superset of the functionality of
> +  * @mode_fixup (the requested and adjusted modes are both available
> +  * through the passed in  drm_crtc_state) @mode_fixup is not
> +  * called when @atomic_check is implemented.
> +  *
>* This function is used by the atomic helpers, but it is optional.
>*
>* NOTE:

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

Re: [PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper

[Jose Abreu]

Hi Laurent,


On 15-05-2017 08:05, Laurent Pinchart wrote:
> On Monday 15 May 2017 08:47:49 Daniel Vetter wrote:
>> On Sun, May 14, 2017 at 02:04:24PM +0300, Laurent Pinchart wrote:
>>> On Friday 12 May 2017 17:06:14 Jose Abreu wrote:
 On 12-05-2017 10:35, Laurent Pinchart wrote:
> On Tuesday 09 May 2017 18:00:12 Jose Abreu wrote:
>> +if (mode->status == MODE_OK)
>> +mode->status = 
> drm_mode_validate_connector(connector,
>> 
> mode);
> I would reverse the arguments order to match the style of the other
> validation functions.
 Hmm, I think it makes more sense to pass connector first and then
 mode ...
>>> I disagree, as this function validates a mode against a pipeline, the same
>>> way the other validation functions validate a mode against other
>>> parameters, but it's your patch :-)
>> Call it drm_connector_validate_mode, because the first argument is
>> generally the object we operate on :-)
> But the function doesn't validate a mode for a connector, it validates a mode 
> for a complete pipeline...
>

Hmm, but note that in the same function there is
drm_mode_validate_size() and drm_mode_validate_flag() calls,
which take as first argument the mode and then the object to
validate (I hadn't seen this). So, maybe leave it as
drm_mode_validate_connector() as it takes a connector as argument
or change to drm_mode_validate_pipeline() as you said, or even
drm_mode_validate_datapath(), drm_mode_validate_videopath(),
drm_mode_validate_components() ?

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/tegra: Check offsets of a submitted command buffer and of relocations

[Mikko Perttunen]

On 14.05.2017 23:47, Dmitry Osipenko wrote:

If commands buffer claims a number of words that is higher than its BO can
fit, a kernel OOPS will be fired on the out-of-bounds BO access. This was
triggered by an opentegra Xorg driver that erroneously pushed too many
commands to the pushbuf. The CMDA commands buffer address is 4 bytes
aligned, so check the alignment as well.

Add a sanity check for the relocations in a same way.

[   46.829393] Unable to handle kernel paging request at virtual address 
f09b2000
...
[] (host1x_job_pin) from [] (tegra_drm_submit+0x474/0x510)
[] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c)
[] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec)
[] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4)
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c)
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c)

Signed-off-by: Dmitry Osipenko 
Reviewed-by: Erik Faye-Lund 
---
 drivers/gpu/drm/tegra/drm.c | 30 ++
 drivers/gpu/drm/tegra/gem.c |  5 -
 drivers/gpu/drm/tegra/gem.h |  5 +
 3 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 768750226452..c5844a065681 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -362,6 +362,8 @@ int tegra_drm_submit(struct tegra_drm_context *context,
while (num_cmdbufs) {
struct drm_tegra_cmdbuf cmdbuf;
struct host1x_bo *bo;
+   struct tegra_bo *obj;
+   u64 offset;

if (copy_from_user(, cmdbufs, sizeof(cmdbuf))) {
err = -EFAULT;
@@ -374,6 +376,14 @@ int tegra_drm_submit(struct tegra_drm_context *context,
goto fail;
}

+   offset = (u64)cmdbuf.offset + (u64)cmdbuf.words * sizeof(u32);
+   obj = host1x_to_tegra_bo(bo);
+
+   if (offset & 3 || offset > obj->gem.size) {
+   err = -EINVAL;
+   goto fail;
+   }
+
host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
num_cmdbufs--;
cmdbufs++;
@@ -381,11 +391,31 @@ int tegra_drm_submit(struct tegra_drm_context *context,

/* copy and resolve relocations from submit */
while (num_relocs--) {
+   struct host1x_reloc *reloc;
+   struct tegra_bo *obj;
+
err = host1x_reloc_copy_from_user(>relocarray[num_relocs],
  [num_relocs], drm,
  file);
if (err < 0)
goto fail;
+
+   reloc = >relocarray[num_relocs];
+   obj = host1x_to_tegra_bo(reloc->cmdbuf.bo);
+
+   if (reloc->cmdbuf.offset & 3 ||
+   reloc->cmdbuf.offset > obj->gem.size) {


This could still fail if the bo's size is not divisible by 4, even with 
>= comparison (we would overwrite the buffer by 1 to 3 bytes). I would 
do the same as in the gather case, i.e. find out the address immediately 
after the write and compare using >. Perhaps add a helper function if it 
makes sense. I also don't think the "& 3" checks are needed.



+   err = -EINVAL;
+   goto fail;
+   }
+
+   obj = host1x_to_tegra_bo(reloc->target.bo);
+
+   if (reloc->target.offset & 3 ||
+   reloc->target.offset > obj->gem.size) {
+   err = -EINVAL;
+   goto fail;
+   }
}

if (copy_from_user(job->waitchk, waitchks,
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index b76d7ac75696..a0ff30c01ac1 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -20,11 +20,6 @@
 #include "drm.h"
 #include "gem.h"

-static inline struct tegra_bo *host1x_to_tegra_bo(struct host1x_bo *bo)
-{
-   return container_of(bo, struct tegra_bo, base);
-}
-
 static void tegra_bo_put(struct host1x_bo *bo)
 {
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
diff --git a/drivers/gpu/drm/tegra/gem.h b/drivers/gpu/drm/tegra/gem.h
index 6c5f12ac0087..8b32a6fd586d 100644
--- a/drivers/gpu/drm/tegra/gem.h
+++ b/drivers/gpu/drm/tegra/gem.h
@@ -52,6 +52,11 @@ static inline struct tegra_bo *to_tegra_bo(struct 
drm_gem_object *gem)
return container_of(gem, struct tegra_bo, gem);
 }

+static inline struct tegra_bo *host1x_to_tegra_bo(struct host1x_bo *bo)
+{
+   return container_of(bo, struct tegra_bo, base);
+}
+
 struct tegra_bo *tegra_bo_create(struct drm_device *drm, size_t size,
 unsigned long flags);
 struct tegra_bo *tegra_bo_create_with_handle(struct drm_file *file,


___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH 1/2] drm/doc: Document adjusted/request modes a bit better

[Jose Abreu]

Hi Daniel,


On 15-05-2017 10:11, Daniel Vetter wrote:
> Laurent started a massive discussion on IRC about this. Let's try to
> document common usage a bit better.
>
> v2: Cross-links+typos.
>
> Cc: Laurent Pinchart 
> Cc: Ville Syrjälä 
> Cc: Jose Abreu 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

> ---
>  include/drm/drm_bridge.h |  2 +-
>  include/drm/drm_crtc.h   | 28 +---
>  include/drm/drm_modeset_helper_vtables.h |  6 --
>  3 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index f694de756ecf..f3ad38d0d621 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -91,7 +91,7 @@ struct drm_bridge_funcs {
>* the display chain, either the final _connector or the next
>* _bridge. The parameter adjusted_mode is the input mode the bridge
>* requires. It can be modified by this callback and does not need to
> -  * match mode.
> +  * match mode. See also _crtc_state.adjusted_mode for more details.
>*
>* This is the only hook that allows a bridge to reject a modeset. If
>* this function passes all other callbacks must succeed for this
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 06236b002c22..5f5d53973ca5 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -90,8 +90,6 @@ struct drm_plane_helper_funcs;
>   * @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
>   * @connector_mask: bitmask of (1 << drm_connector_index(connector)) of 
> attached connectors
>   * @encoder_mask: bitmask of (1 << drm_encoder_index(encoder)) of attached 
> encoders
> - * @adjusted_mode: for use by helpers and drivers to compute adjusted mode 
> timings
> - * @mode: current mode timings
>   * @mode_blob: _property_blob for @mode
>   * @state: backpointer to global drm_atomic_state
>   *
> @@ -131,9 +129,33 @@ struct drm_crtc_state {
>   u32 connector_mask;
>   u32 encoder_mask;
>  
> - /* adjusted_mode: for use by helpers and drivers */
> + /**
> +  * @adjusted_mode:
> +  *
> +  * Internal display timings which can be used by the driver to handle
> +  * differences between the mode requested by userspace in @mode and what
> +  * is actually programmed into the hardware. It is purely driver
> +  * implementation defined what exactly this adjusted mode means. Usually
> +  * it is used to store the hardware display timings used between the
> +  * CRTC and encoder blocks.
> +  */
>   struct drm_display_mode adjusted_mode;
>  
> + /**
> +  * @mode:
> +  *
> +  * Display timings requested by userspace. The driver should try to
> +  * match the refresh rate as close as possible (but note that it's
> +  * undefined what exactly is close enough, e.g. some of the HDMI modes
> +  * only differ in less than 1% of the refresh rate). The active width
> +  * and height as observed by userspace for positioning planes must match
> +  * exactly.
> +  *
> +  * For external connectors where the sink isn't fixed (like with a
> +  * built-in panel), this mode here should match the physical mode on the
> +  * wire to the last details (i.e. including sync polarities and
> +  * everything).
> +  */
>   struct drm_display_mode mode;
>  
>   /* blob property to expose current mode to atomic userspace */
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index 91d071ff1232..c72fca544a41 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -138,7 +138,8 @@ struct drm_crtc_helper_funcs {
>* encoders need to be fed with. Note that this is the inverse semantics
>* of the meaning for the _encoder and _bridge_funcs.mode_fixup
>* vfunc. If the CRTC cannot support the requested conversion from mode
> -  * to adjusted_mode it should reject the modeset.
> +  * to adjusted_mode it should reject the modeset. See also
> +  * _crtc_state.adjusted_mode for more details.
>*
>* This function is used by both legacy CRTC helpers and atomic helpers.
>* With atomic helpers it is optional.
> @@ -510,7 +511,8 @@ struct drm_encoder_helper_funcs {
>* mode is the display mode that should be fed to the next element in
>* the display chain, either the final _connector or a _bridge.
>* The parameter adjusted_mode is the input mode the encoder requires. 
> It
> -  * can be modified by this callback and does not need to match mode.
> +  * can be modified by this callback and does not need to match mode. See
> +  

Re: [PATCH] drm/tegra: Check offsets of a submitted command buffer and of relocations

[Dmitry Osipenko]

On 16.05.2017 09:56, Mikko Perttunen wrote:
> On 14.05.2017 23:47, Dmitry Osipenko wrote:
>> +if (reloc->cmdbuf.offset & 3 ||
>> +reloc->cmdbuf.offset > obj->gem.size) {
> 
> This could still fail if the bo's size is not divisible by 4, even with >=
> comparison (we would overwrite the buffer by 1 to 3 bytes). I would do the 
> same
> as in the gather case, i.e. find out the address immediately after the write 
> and
> compare using >. Perhaps add a helper function if it makes sense. I also don't
> think the "& 3" checks are needed.
> 
Sorry, I forgot to mention the reason of the relocations cmdbuf offset alignment
requirement in the commit description. So the reason is that during the patching
of the gather in do_relocs(), the unaligned offset would cause a partial
overwrite of the command buffer word following the relocation and only a part of
the relocation address being written to the actual address word.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 3/3] drm/stm: Add STM32 DSI host driver

[Archit Taneja]

Hi,

On 05/15/2017 04:03 PM, Philippe CORNU wrote:

Hi Neil,
Many thanks for your comments.

The PHY part of the MIPI DSI is the main difference between all chipsets
based on the Synopsys DesignWare MIPI DSI.
There is no "generic DSI PHY interface" and that is probably why all soc
vendors have implemented their own drivers (RockChip, NXP/Freescale,
HiSilicon and now STM32).


We don't really need a generic DSI PHY interface to ensure we use a common
bridge driver. We need to do what's been done in the DW HDMI bridge driver.
The dw_hdmi_plat_data struct contains phy ops, which can be used to abstract
vendor PHYs.



Regarding creating a "generic dw MIPI DSI bridge" as the recent dw hdmi
bridge, several attempts have been done in the past but without success:
* Liu Ying from Freescale in February 2015
(https://lkml.org/lkml/2015/2/12/38).
* Chris Zhong from Rockchip in November 2015
(http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1024586.html).


We can't have 3 almost identical DW MIPI DSI implementations in the kernel.
You'll need to separate out the vendor specific PHY pieces into ops (like
it's done in the DW HDMI) and post a bridge driver for this.

You don't need to convert the existing rockhip and hisilicon implementations
into bridge drivers. We can CC the authors of the rockchip and hisil so that
they can adapt to the bridge driver too.

Thanks,
Archit



The Rockchip driver looks nice and is updated regularly.
So, instead of creating a new driver for the STM32 family, we decided to
use Rockchip’s in our own drm/stm directory and replace the
Rockchip-specific PHY by the STM32.

Comments are welcome :-)
Many thanks,
Philippe


On 05/15/2017 10:22 AM, Neil Armstrong wrote:

On 05/12/2017 04:56 PM, Philippe CORNU wrote:

This mipi dsi host driver is based on the Rockchip version of the
Synopsys Designware mipi dsi driver (rockchip/dw-mipi-dsi.c)
modified for the stm32 family:
- replace Rockchip digital & phy specific extensions with stm32's ones.
- add a bridge

Signed-off-by: Philippe CORNU 
---
 drivers/gpu/drm/stm/Kconfig   |7 +
 drivers/gpu/drm/stm/Makefile  |2 +
 drivers/gpu/drm/stm/dw-mipi-dsi.c | 1197 +
 3 files changed, 1206 insertions(+)
 create mode 100644 drivers/gpu/drm/stm/dw-mipi-dsi.c

diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index 2c4817f..0007789 100644
--- a/drivers/gpu/drm/stm/Kconfig
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -14,3 +14,10 @@ config DRM_STM
  STMicroelectronics STM32 MCUs.
  To compile this driver as a module, choose M here: the module
  will be called stm-drm.
+
+config DRM_STM_DSI
+   tristate "MIPI DSI support for STMicroelectronics SoC"
+   depends on DRM_STM
+   select DRM_MIPI_DSI
+   help
+ Choose this option for MIPI DSI support on STMicroelectronics SoC.
diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile
index e114d45..e448a93 100644
--- a/drivers/gpu/drm/stm/Makefile
+++ b/drivers/gpu/drm/stm/Makefile
@@ -4,4 +4,6 @@ stm-drm-y := \
drv.o \
ltdc.o

+obj-$(CONFIG_DRM_STM_DSI) += dw-mipi-dsi.o
+
 obj-$(CONFIG_DRM_STM) += stm-drm.o
diff --git a/drivers/gpu/drm/stm/dw-mipi-dsi.c 
b/drivers/gpu/drm/stm/dw-mipi-dsi.c
new file mode 100644
index 000..4b7f7b9
--- /dev/null
+++ b/drivers/gpu/drm/stm/dw-mipi-dsi.c



Hi Philippe,

First question, why couldn't this be transformed as a bridge driver along the 
Synopsys DW-HDMI driver ?

Neil


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



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

Re: [PATCH v5 1/2] drm: Add writeback connector type

[Liviu Dudau]

On Mon, May 15, 2017 at 08:30:13PM -0400, Rob Clark wrote:
> On Mon, May 15, 2017 at 1:20 PM, Liviu Dudau  wrote:
> > From: Brian Starkey 
> >
> > Writeback connectors represent writeback engines which can write the
> > CRTC output to a memory framebuffer. Add a writeback connector type and
> > related support functions.
> >
> > Drivers should initialize a writeback connector with
> > drm_writeback_connector_init() which takes care of setting up all the
> > writeback-specific details on top of the normal functionality of
> > drm_connector_init().
> >
> > Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> > output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> > supported writeback formats to userspace.
> >
> > When a framebuffer is attached to a writeback connector with the
> > WRITEBACK_FB_ID property, it is used only once (for the commit in which
> > it was included), and userspace can never read back the value of
> > WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> > attached to a CRTC.
> 
> So one thought.. since rmfb is kinda horrible, I think
> rmfb/drm_framebuffer_remove() probably needs to fish out writeback
> connectors that are using the fb and disable them as well.

Yes, that is a good idea. Will do it in v6.

Thanks for looking over this.

Best regards,
Liviu

> 
> BR,
> -R
> 
> 
> > Changes since v1:
> >  - Added drm_writeback.c + documentation
> >  - Added helper to initialize writeback connector in one go
> >  - Added core checks
> >  - Squashed into a single commit
> >  - Dropped the client cap
> >  - Writeback framebuffers are no longer persistent
> >
> > Changes since v2:
> >  Daniel Vetter:
> >  - Subclass drm_connector to drm_writeback_connector
> >  - Relax check to allow CRTC to be set without an FB
> >  - Add some writeback_ prefixes
> >  - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
> >  Gustavo Padovan:
> >  - Add drm_writeback_job to handle writeback signalling centrally
> >
> > Changes since v3:
> >  - Rebased
> >  - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
> >
> > Chances since v4:
> >  - Embed a drm_encoder inside the drm_writeback_connector to
> >reduce the amount of boilerplate code inside drivers using it.
> >
> > Signed-off-by: Brian Starkey 
> > [rebased and fixed conflicts]
> > Signed-off-by: Mihail Atanassov 
> > Signed-off-by: Liviu Dudau 
> > ---
> >  Documentation/gpu/drm-kms.rst   |   9 ++
> >  drivers/gpu/drm/Makefile|   2 +-
> >  drivers/gpu/drm/drm_atomic.c| 130 ++
> >  drivers/gpu/drm/drm_atomic_helper.c |   6 +
> >  drivers/gpu/drm/drm_connector.c |   4 +-
> >  drivers/gpu/drm/drm_writeback.c | 257 
> > 
> >  include/drm/drm_atomic.h|   3 +
> >  include/drm/drm_connector.h |  13 ++
> >  include/drm/drm_mode_config.h   |  14 ++
> >  include/drm/drm_writeback.h |  88 
> >  include/uapi/drm/drm_mode.h |   1 +
> >  11 files changed, 525 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/gpu/drm/drm_writeback.c
> >  create mode 100644 include/drm/drm_writeback.h
> >
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index bfecd21a8cdf..7a8ef1a4fe17 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -364,6 +364,15 @@ Connector Functions Reference
> >  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > :export:
> >
> > +Writeback Connectors
> > +
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > +  :doc: overview
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > +  :export:
> > +
> >  Encoder Abstraction
> >  ===
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 59f0f9b696eb..99ef500ae8b2 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -16,7 +16,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
> > drm_framebuffer.o drm_connector.o drm_blend.o \
> > drm_encoder.o drm_mode_object.o drm_property.o \
> > drm_plane.o drm_color_mgmt.o drm_print.o \
> > -   drm_dumb_buffers.o drm_mode_config.o
> > +   drm_dumb_buffers.o drm_mode_config.o drm_writeback.o
> >
> >  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> >  drm-$(CONFIG_DRM_VM) += drm_vm.o
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index f32506a7c1d6..317ae625b417 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -31,6 +31,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  #include "drm_crtc_internal.h"
> > @@ -654,6 +655,46 @@ static void 

Re: [radeon-alex:amd-staging-4.11 1061/1085] sparc64-linux-gnu-gcc: error: unrecognized command line option '-msse'; did you mean '-fdse'?

[Christian König]

Am 16.05.2017 um 07:20 schrieb zhoucm1:



On 2017年05月15日 17:52, kbuild test robot wrote:

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11
head:   c285c73f2213f503a93aa142fff186e160b4a371
commit: 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24 [1061/1085] drm/amd: 
fix init order of sched job

config: sparc-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
 wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross 
-O ~/bin/make.cross

 chmod +x ~/bin/make.cross
 git checkout 5f92704d0cc5928824ffa4ff8cec5cd4c0f55b24
 # save the attached .config to linux build tree
 make.cross ARCH=sparc

All errors (new ones prefixed by >>):

sparc64-linux-gnu-gcc: error: unrecognized command line option 
'-msse'; did you mean '-fdse'?
sparc64-linux-gnu-gcc: error: unrecognized command line option 
'-mpreferred-stack-boundary=4'

@@ -460,9 +460,9 @@ int amd_sched_job_init(struct amd_sched_job *job,
job->sched = sched;
job->s_entity = entity;
job->s_fence = amd_sched_fence_create(entity, owner);
-   job->id = atomic64_inc_return(>job_id_count);
if (!job->s_fence)
return -ENOMEM;
+   job->id = atomic64_inc_return(>job_id_count);

INIT_WORK(>finish_work, amd_sched_job_finish);
INIT_LIST_HEAD(>node);

Sorry, I don't know how commit 5f92704 results in your this error.
But from error message, it seems your compiler problems.


Yeah, that looks like a problem with the build bot.

We recently had a couple of those, so guys please fix your bots or 
people will start to ignore such messages.


Regards,
Christian.



Regards,
David Zhou

---
0-DAY kernel test infrastructureOpen Source 
Technology Center

https://lists.01.org/pipermail/kbuild-all Intel Corporation




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

Re: [PATCH] drm/tegra: Check offsets of a submitted command buffer and of relocations

[Erik Faye-Lund]

On Tue, May 16, 2017 at 8:56 AM, Mikko Perttunen  wrote:
> On 14.05.2017 23:47, Dmitry Osipenko wrote:
>>
>> If commands buffer claims a number of words that is higher than its BO can
>> fit, a kernel OOPS will be fired on the out-of-bounds BO access. This was
>> triggered by an opentegra Xorg driver that erroneously pushed too many
>> commands to the pushbuf. The CMDA commands buffer address is 4 bytes
>> aligned, so check the alignment as well.
>>
>> Add a sanity check for the relocations in a same way.
>>
>> [   46.829393] Unable to handle kernel paging request at virtual address
>> f09b2000
>> ...
>> [] (host1x_job_pin) from []
>> (tegra_drm_submit+0x474/0x510)
>> [] (tegra_drm_submit) from [] (tegra_submit+0x50/0x6c)
>> [] (tegra_submit) from [] (drm_ioctl+0x1e4/0x3ec)
>> [] (drm_ioctl) from [] (do_vfs_ioctl+0x9c/0x8e4)
>> [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c)
>> [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c)
>>
>> Signed-off-by: Dmitry Osipenko 
>> Reviewed-by: Erik Faye-Lund 
>> ---
>>  drivers/gpu/drm/tegra/drm.c | 30 ++
>>  drivers/gpu/drm/tegra/gem.c |  5 -
>>  drivers/gpu/drm/tegra/gem.h |  5 +
>>  3 files changed, 35 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
>> index 768750226452..c5844a065681 100644
>> --- a/drivers/gpu/drm/tegra/drm.c
>> +++ b/drivers/gpu/drm/tegra/drm.c
>> @@ -362,6 +362,8 @@ int tegra_drm_submit(struct tegra_drm_context
>> *context,
>> while (num_cmdbufs) {
>> struct drm_tegra_cmdbuf cmdbuf;
>> struct host1x_bo *bo;
>> +   struct tegra_bo *obj;
>> +   u64 offset;
>>
>> if (copy_from_user(, cmdbufs, sizeof(cmdbuf))) {
>> err = -EFAULT;
>> @@ -374,6 +376,14 @@ int tegra_drm_submit(struct tegra_drm_context
>> *context,
>> goto fail;
>> }
>>
>> +   offset = (u64)cmdbuf.offset + (u64)cmdbuf.words *
>> sizeof(u32);
>> +   obj = host1x_to_tegra_bo(bo);
>> +
>> +   if (offset & 3 || offset > obj->gem.size) {
>> +   err = -EINVAL;
>> +   goto fail;
>> +   }
>> +
>> host1x_job_add_gather(job, bo, cmdbuf.words,
>> cmdbuf.offset);
>> num_cmdbufs--;
>> cmdbufs++;
>> @@ -381,11 +391,31 @@ int tegra_drm_submit(struct tegra_drm_context
>> *context,
>>
>> /* copy and resolve relocations from submit */
>> while (num_relocs--) {
>> +   struct host1x_reloc *reloc;
>> +   struct tegra_bo *obj;
>> +
>> err =
>> host1x_reloc_copy_from_user(>relocarray[num_relocs],
>>   [num_relocs],
>> drm,
>>   file);
>> if (err < 0)
>> goto fail;
>> +
>> +   reloc = >relocarray[num_relocs];
>> +   obj = host1x_to_tegra_bo(reloc->cmdbuf.bo);
>> +
>> +   if (reloc->cmdbuf.offset & 3 ||
>> +   reloc->cmdbuf.offset > obj->gem.size) {
>
>
> This could still fail if the bo's size is not divisible by 4, even with >=
> comparison (we would overwrite the buffer by 1 to 3 bytes). I would do the
> same as in the gather case, i.e. find out the address immediately after the
> write and compare using >. Perhaps add a helper function if it makes sense.
> I also don't think the "& 3" checks are needed.

The bo-size is always a multiple of PAGE_SIZE, due to the rounding in
tegra_bo_alloc_object(), so I don't think this actually can fail. But
maybe we want to future-proof this code for a potential future where
this is not the case?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

[Laurent Pinchart]

Hi Eric,

On Monday 15 May 2017 17:03:29 Eric Anholt wrote:
> Laurent Pinchart  writes:
> > On Thursday 11 May 2017 16:56:23 Eric Anholt wrote:
> >> The Raspberry Pi 7" Touchscreen is a DPI touchscreen panel with
> >> DSI->DPI bridge and touchscreen controller integrated, that connects
> >> to the Raspberry Pi through its 15-pin "DSI" connector (some lines are
> >> DSI, some lines are I2C).
> >> 
> >> This device is represented in the DT as three nodes (DSI device, I2C
> >> device, panel).  Input will be left to a separate binding later, as it
> >> will be a basic I2C client device.
> >> 
> >> Signed-off-by: Eric Anholt 
> >> ---
> >> 
> >>  .../raspberrypi,7inch-touchscreen-bridge.txt   | 68 +++
> >>  .../panel/raspberrypi,7inch-touchscreen-panel.txt  |  7 +++
> >>  2 files changed, 75 insertions(+)
> >>  create mode 100644
> >> 
> >> Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touchs
> >> cr
> >> een-bridge.txt create mode 100644
> >> Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchsc
> >> re
> >> en-panel.txt
> >> 
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touc
> >> hs
> >> creen-bridge.txt
> >> b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touc
> >> hs
> >> creen-bridge.txt new file mode 100644
> >> index ..a5669beaf68f
> >> --- /dev/null
> >> +++
> >> b/Documentation/devicetree/bindings/display/bridge/raspberrypi,7inch-touc
> >> hs
> >> creen-bridge.txt @@ -0,0 +1,68 @@
> >> +Official 7" (800x480) Raspberry Pi touchscreen panel's bridge.
> >> +
> >> +This DSI panel contains:
> >> +
> >> +- TC358762 DSI->DPI bridge
> >> +- Atmel microcontroller on I2C for power sequencing the DSI bridge and
> >> +  controlling backlight
> >> +- Touchscreen controller on I2C for touch input
> >> +
> >> +and this covers the TC358762 bridge and Atmel microcontroller, while
> >> +../panel/raspberrypi,7inch-touchscreen-panel.txt covers the panel.
> > 
> > The TC358762 is a standalone bridge that doesn't depend on the ATTiny
> > microcontroller used by the RPI. As it's usable standalone, I believe this
> > binding should be split in two.
> 
> Do you have a plan for how I would implement a driver on top of that
> binding change, though?  Note that we don't program the Toshiba
> directly, we only send commands to the Atmel.

I'm not too familiar with the hardware architecture, let me have a look. Is 
the schematics publicly available somewhere ?

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 00/16] drm/omap: misc cleanups and pixel format change

[Tomi Valkeinen]

On 04/05/17 13:23, Tomi Valkeinen wrote:
> Hi,
> 
> This series has a bunch of cleanups. We drop DMA and VRFB rotation, and RFBI
> output. None of those are supported.
> 
> The latter half is about getting rid of enum omap_color_mode and moving to use
> fourcc pixel formats.
> 
> There should be no functional changes caused by this series.
> 
> This series is based on my earlier "drm/omap: misc changes" series.
> 
>  Tomi
> 
> Tomi Valkeinen (16):
>   drm/omap: fix passing rotation parameter to dispc
>   drm/omap: fix setting & clearing DOUBLESTRIDE
>   drm/omap: remove CLUT
>   drm/omap: ratelimit OCP error
>   drm/omap: remove rfbi
>   drm/omap: remove dma & vrfb rotation
>   drm/omap: cleanup offset calculation
>   drm/omap: add format_is_yuv() helper
>   drm/omap: remove unneeded prototypes
>   drm/omap: remove unused 'supported_modes' field
>   drm/omap: change supported_modes to an array
>   drm/omap: use DRM_FORMAT_* instead of OMAP_DSS_COLOR_*
>   drm/omap: use u32 instead of enum omap_color_mode
>   drm/omap: remove omap_framebuffer_get_formats()
>   drm/omap: cleanup formats array
>   drm/omap: rename color_mode to fourcc

Patches 1 and 5 are not valid anymore. 5 has been already merged via
another series, and I've since reworked 1, which I'll be handling in a
separate tiler rotation series. The rest are still valid.

 Tomi



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