[PATCH] drm/fence: add fence timeline to drm_crtc

[Gustavo Padovan]

From: Gustavo Padovan 

Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.

v2: Comment by Daniel Stone:
- add BUG_ON() to fence_to_crtc() macro

v3: Comment by Ville Syrjälä
- Use more meaningful name as crtc timeline name

v4: Comments by Brian Starkey
- Use even more meaninful name for the crtc timeline
- add doc for timeline_name
Comment by Daniel Vetter
- use in-line style for comments

- rebase after fence -> dma_fence rename

v5: Comment by Daniel Vetter
- Add doc for drm_crtc_fence_ops

v6: Comment by Chris Wilson
- Move fence_to_crtc to drm_crtc.c
- Move export of drm_crtc_fence_ops to drm_crtc_internal.h

- rebase against latest drm-misc

Signed-off-by: Gustavo Padovan 
Reviewed-by: Daniel Vetter  (v5)
Reviewed-by: Sean Paul  (v5)
Tested-by: Robert Foss  (v5)
---
 drivers/gpu/drm/drm_crtc.c  | 38 +
 drivers/gpu/drm/drm_crtc_internal.h |  2 ++
 include/drm/drm_crtc.h  | 29 
 3 files changed, 69 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c19ecc2..02e9451 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -163,6 +164,38 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc)
 #endif
 }

+static struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
+{
+   BUG_ON(fence->ops != _crtc_fence_ops);
+   return container_of(fence->lock, struct drm_crtc, fence_lock);
+}
+
+static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->dev->driver->name;
+}
+
+static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->timeline_name;
+}
+
+static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+const struct dma_fence_ops drm_crtc_fence_ops = {
+   .get_driver_name = drm_crtc_fence_get_driver_name,
+   .get_timeline_name = drm_crtc_fence_get_timeline_name,
+   .enable_signaling = drm_crtc_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
 /**
  * drm_crtc_init_with_planes - Initialise a new CRTC object with
  *specified primary and cursor planes.
@@ -220,6 +253,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
return -ENOMEM;
}

+   crtc->fence_context = dma_fence_context_alloc(1);
+   spin_lock_init(>fence_lock);
+   snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
+"CRTC:%d-%s", crtc->base.id, crtc->name);
+
crtc->base.properties = >properties;

list_add_tail(>head, >crtc_list);
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 64bb3eb..036b972 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -43,6 +43,8 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,

 void drm_fb_release(struct drm_file *file_priv);

+extern const struct dma_fence_ops drm_crtc_fence_ops;
+
 /* IOCTLs */
 int drm_mode_getresources(struct drm_device *dev,
  void *data, struct drm_file *file_priv);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 11780a9..edd2d83 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -739,6 +739,35 @@ struct drm_crtc {
 */
struct drm_crtc_crc crc;
 #endif
+
+   /**
+* @fence_context:
+*
+* timeline context used for fence operations.
+*/
+   unsigned int fence_context;
+
+   /**
+* @fence_lock:
+*
+* spinlock to protect the fences in the fence_context.
+*/
+
+   spinlock_t fence_lock;
+   /**
+* @fence_seqno:
+*
+* Seqno variable used as monotonic counter for the fences
+* created on the CRTC's timeline.
+*/
+   unsigned long fence_seqno;
+
+   /**
+* @timeline_name:
+*
+* The name of the CRTC's fence timeline.
+*/
+   char timeline_name[32];
 };

 /**
-- 
2.5.5

[RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions

[Russell King - ARM Linux]

On Wed, Nov 16, 2016 at 12:23:50AM +0100, Pierre-Hugues Husson wrote:
> Hi,
> 
> 
> 2016-11-14 16:22 GMT+01:00 Hans Verkuil :
> > From: Russell King 
> >
> > We don't need the CEC engine register definitions, so let's remove them.
> >
> > Signed-off-by: Russell King 
> > ---
> >  drivers/gpu/drm/bridge/dw-hdmi.h | 45 
> > 
> >  1 file changed, 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h 
> > b/drivers/gpu/drm/bridge/dw-hdmi.h
> > index fc9a560..26d6845 100644
> > --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> > +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> > @@ -478,51 +478,6 @@
> >  #define HDMI_A_PRESETUP 0x501A
> >  #define HDMI_A_SRM_BASE 0x5020
> >
> > -/* CEC Engine Registers */
> > -#define HDMI_CEC_CTRL   0x7D00
> > -#define HDMI_CEC_STAT   0x7D01
> > -#define HDMI_CEC_MASK   0x7D02
> I don't know if this is relevant for a submission, but the build stops
> working here because of a missing definition HDMI_CEC_MASK
> Perhaps this should be inverted with 3/5 to make bissecting easier?
> I was trying to bissect a kernel panic, and I had to fix this by hand

Doesn't make sense - patch 3 doesn't reference HDMI_CEC_MASK.

Please show the build error in full.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 6/6] drm: drm_irq.h header cleanup

[Daniel Vetter]

On Mon, Nov 14, 2016 at 10:35:23AM -0500, Alex Deucher wrote:
> On Mon, Nov 14, 2016 at 4:02 AM, Daniel Vetter  
> wrote:
> > - Drop extern for functions, it's noise.
> > - Move drm.ko internal parts into drm-internal.h.
> >
> > Signed-off-by: Daniel Vetter 
> 
> For the series:
> Reviewed-by: Alex Deucher 

Thanks for the review, entire series applied to drm-misc.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/drm_internal.h |  8 +++---
> >  include/drm/drm_irq.h  | 60 
> > --
> >  2 files changed, 34 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> > index abd209863ef4..1e29cbc556d5 100644
> > --- a/drivers/gpu/drm/drm_internal.h
> > +++ b/drivers/gpu/drm/drm_internal.h
> > @@ -24,9 +24,6 @@
> >  #define DRM_IF_MAJOR 1
> >  #define DRM_IF_MINOR 4
> >
> > -/* drm_irq.c */
> > -extern unsigned int drm_timestamp_monotonic;
> > -
> >  /* drm_fops.c */
> >  extern struct mutex drm_global_mutex;
> >  void drm_lastclose(struct drm_device *dev);
> > @@ -52,6 +49,11 @@ int drm_clients_info(struct seq_file *m, void* data);
> >  int drm_gem_name_info(struct seq_file *m, void *data);
> >
> >  /* drm_irq.c */
> > +extern unsigned int drm_timestamp_monotonic;
> > +
> > +/* IOCTLS */
> > +int drm_wait_vblank(struct drm_device *dev, void *data,
> > +   struct drm_file *filp);
> >  int drm_control(struct drm_device *dev, void *data,
> > struct drm_file *file_priv);
> >  int drm_modeset_ctl(struct drm_device *dev, void *data,
> > diff --git a/include/drm/drm_irq.h b/include/drm/drm_irq.h
> > index 92e59d0a5ddb..293d08caab60 100644
> > --- a/include/drm/drm_irq.h
> > +++ b/include/drm/drm_irq.h
> > @@ -130,39 +130,37 @@ struct drm_vblank_crtc {
> > bool enabled;
> >  };
> >
> > -extern int drm_irq_install(struct drm_device *dev, int irq);
> > -extern int drm_irq_uninstall(struct drm_device *dev);
> > +int drm_irq_install(struct drm_device *dev, int irq);
> > +int drm_irq_uninstall(struct drm_device *dev);
> >
> > -extern int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs);
> > -extern int drm_wait_vblank(struct drm_device *dev, void *data,
> > -  struct drm_file *filp);
> > -extern u32 drm_crtc_vblank_count(struct drm_crtc *crtc);
> > -extern u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> > - struct timeval *vblanktime);
> > -extern void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> > -  struct drm_pending_vblank_event *e);
> > -extern void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
> > - struct drm_pending_vblank_event *e);
> > -extern bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe);
> > -extern bool drm_crtc_handle_vblank(struct drm_crtc *crtc);
> > -extern int drm_crtc_vblank_get(struct drm_crtc *crtc);
> > -extern void drm_crtc_vblank_put(struct drm_crtc *crtc);
> > -extern void drm_wait_one_vblank(struct drm_device *dev, unsigned int pipe);
> > -extern void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
> > -extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
> > -extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
> > -extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
> > -extern void drm_vblank_cleanup(struct drm_device *dev);
> > -extern u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
> > -extern u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int 
> > pipe);
> > +int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs);
> > +u32 drm_crtc_vblank_count(struct drm_crtc *crtc);
> > +u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> > +  struct timeval *vblanktime);
> > +void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> > +  struct drm_pending_vblank_event *e);
> > +void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
> > + struct drm_pending_vblank_event *e);
> > +bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe);
> > +bool drm_crtc_handle_vblank(struct drm_crtc *crtc);
> > +int drm_crtc_vblank_get(struct drm_crtc *crtc);
> > +void drm_crtc_vblank_put(struct drm_crtc *crtc);
> > +void drm_wait_one_vblank(struct drm_device *dev, unsigned int pipe);
> > +void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
> > +void drm_crtc_vblank_off(struct drm_crtc *crtc);
> > +void drm_crtc_vblank_reset(struct drm_crtc *crtc);
> > +void drm_crtc_vblank_on(struct drm_crtc *crtc);
> > +void drm_vblank_cleanup(struct drm_device *dev);
> > +u32 drm_accurate_vblank_count(struct drm_crtc *crtc);
> > +u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int pipe);
> >
> > -extern int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
> > -unsigned int pipe, int 
> 

[PATCH] drm/nouveau: Use drm_crtc_vblank_off/on

[Daniel Vetter]

On Mon, Nov 14, 2016 at 12:41:01PM +0100, Daniel Vetter wrote:
> With atomic nv50+ is already converted over to them, but the old
> display code is still using it. Found in a 2 year old patch I have
> lying around to un-export these old helpers!
> 
> v2: Drop the hand-rolled versions from resume/suspend code. Now that
> crtc callbacks do this, we don't need a special case for s/r anymore.
> 
> v3: Remove unused variables.
> 
> Cc: Mario Kleiner 
> Cc: Ben Skeggs 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c   |  4 ++--
>  drivers/gpu/drm/nouveau/nouveau_display.c | 11 +--
>  2 files changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index 0cb7a18cde26..59d1d1c5de5f 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -702,7 +702,7 @@ static void nv_crtc_prepare(struct drm_crtc *crtc)
>   if (nv_two_heads(dev))
>   NVSetOwner(dev, nv_crtc->index);
>  
> - drm_vblank_pre_modeset(dev, nv_crtc->index);
> + drm_crtc_vblank_off(crtc);
>   funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
>  
>   NVBlankScreen(dev, nv_crtc->index, true);
> @@ -734,7 +734,7 @@ static void nv_crtc_commit(struct drm_crtc *crtc)
>  #endif
>  
>   funcs->dpms(crtc, DRM_MODE_DPMS_ON);
> - drm_vblank_post_modeset(dev, nv_crtc->index);
> + drm_crtc_vblank_on(crtc);
>  }
>  
>  static void nv_crtc_destroy(struct drm_crtc *crtc)
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 75c90a8da18a..76c342bf047b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -380,15 +380,10 @@ nouveau_display_fini(struct drm_device *dev, bool 
> suspend)
>   struct nouveau_display *disp = nouveau_display(dev);
>   struct nouveau_drm *drm = nouveau_drm(dev);
>   struct drm_connector *connector;
> - int head;
>  
>   if (!suspend)
>   drm_crtc_force_disable_all(dev);
>  
> - /* Make sure that drm and hw vblank irqs get properly disabled. */
> - for (head = 0; head < dev->mode_config.num_crtc; head++)
> - drm_vblank_off(dev, head);
> -

compared with the pre-atomic-rebase patch and realized we still need this
part for pre-nv50, since we don't force-disable all the crtc on suspend.
Atomic otoh does that, so should be all good. With that change it again
matches a patch Mario tested (except for nv50), so figured it should be
safe and applied it to drm-misc.
-Daniel

>   /* disable flip completion events */
>   nvif_notify_put(>flip);
>  
> @@ -723,7 +718,7 @@ nouveau_display_resume(struct drm_device *dev, bool 
> runtime)
>   struct nouveau_display *disp = nouveau_display(dev);
>   struct nouveau_drm *drm = nouveau_drm(dev);
>   struct drm_crtc *crtc;
> - int ret, head;
> + int ret;
>  
>   if (dev->mode_config.funcs->atomic_commit) {
>   nouveau_display_init(dev);
> @@ -777,10 +772,6 @@ nouveau_display_resume(struct drm_device *dev, bool 
> runtime)
>  
>   drm_helper_resume_force_mode(dev);
>  
> - /* Make sure that drm and hw vblank irqs get resumed if needed. */
> - for (head = 0; head < dev->mode_config.num_crtc; head++)
> - drm_vblank_on(dev, head);
> -
>   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
>   struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
>  
> -- 
> 2.10.2
> 

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

[PATCH v2 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers

[Jyri Sarha]

On 11/15/16 19:36, Bartosz Golaszewski wrote:
> 2016-11-14 17:54 GMT+01:00 Jyri Sarha :
>> Adds drm bride support for attaching drm bridge drivers to tilcdc. The
>> decision whether a video port leads to an external encoder or bridge
>> is made simply based on remote device's compatible string. The code
>> has been tested with BeagleBone-Black with and without BeagleBone
>> DVI-D Cape Rev A3 using ti-tfp410 driver.
>>
>> Signed-off-by: Jyri Sarha 
>> ---
> 
> Hi Jyri,
> 
> thanks a lot for doing this.
> 
> One issue I see with this patch is that tilcdc doesn't seem to support
> deferred probe correctly (if modules are built-in). The following
> happens on my setup:
> 
> The dump-vga-dac module is loaded first, but the i2c0 is not ready yet
> - probe returns EPROBE_DEFER and it's propagated to tilcdc probe.
> 
> [drm] Initialized
> dumb-vga-dac vga_bridge: Couldn't retrieve i2c bus
> 
> Then the i2c bus is initialized and dump-vga-dac probe succeeds, but
> the second probe of tilcdc gives me:
> 
> [drm:drm_debugfs_init] *ERROR* Cannot create /sys/kernel/debug/dri/64
> [drm:drm_minor_register] *ERROR* DRM: Failed to initialize
> /sys/kernel/debug/dri.
> tilcdc: probe of da8xx_lcdc.0 failed with error -1
> 
> I was able to work around this issue by loading modules in correct order.
> 

Did you have any conflicts when applying my patch? I have done quite a
few changes lately and especially the initialization sequence and back
off from deferred probe may get broken easily broken if the source base
is not correct. I try to come up with a pull-request candidate branch
soon (hopefully tomorrow) for you to test.

> I then tried testing the patch with a da850-lcdk, but I don't get
> anything on the display (no signal), even though the LCDC seems to
> work fine (modetest and dmesg messages work just like when using the
> tilcdc panel). Also: I see the EDID info is correctly retrieved from
> the display.
> 
> Could you take a look at my DT[1] and see if you find it correct?
> 

It is hard to follow the dts diff, but if it probes and tilcdc is able
to read EDID modes, there should not be anything more to it.

Cheers,
Jyri

> Best regards,
> Bartosz Golaszewski
> 
> [1] http://pastebin.com/dfUX7PyL
> 

[PATCH] dma-buf: Provide wrappers for reservation's lock

[Daniel Vetter]

On Tue, Nov 15, 2016 at 03:46:42PM +, Chris Wilson wrote:
> Joonas complained that writing ww_mutex_lock(>lock, ctx) was too
> intrusive compared to reservation_object_lock(resv, ctx);
> 
> Signed-off-by: Chris Wilson 
> Cc: Sumit Semwal 
> Cc: Joonas Lahtinen 
> ---
>  include/linux/reservation.h | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> index ed238961e1bf..9cfc0d857862 100644
> --- a/include/linux/reservation.h
> +++ b/include/linux/reservation.h
> @@ -129,6 +129,40 @@ reservation_object_fini(struct reservation_object *obj)
>  }
>  
>  /**
> + * reservation_object_lock - lock the reservation object
> + * @obj: the reservation object
> + * @ctx: the locking context
> + *
> + * Locks the reservation object for exclusive access and modification. Note,
> + * that the lock is only against other writers, readers will run concurrently
> + * with a writer under RCU. The seqlock is used to notify readers if they
> + * overlap with a writer.
> + *
> + * As the reservation object may be locked by multiple parties in an
> + * undefined order, a #ww_acquire_ctx is passed to unwind if a cycle

s/#/&/ for struct references. Otherwise the magic hotlink won't appear
(once we get around to pulling all the core docs into the overall sphinx
build). I can fix this while applying if everyone else is ok with the
patch - imo it makes sense.
-Daniel

> + * is detected. See ww_mutex_lock() and ww_acquire_init(). A reservation
> + * object may be locked by itself by passing NULL as @ctx.
> + */
> +static inline int
> +reservation_object_lock(struct reservation_object *obj,
> + struct ww_acquire_ctx *ctx)
> +{
> + return ww_mutex_lock(>lock, ctx);
> +}
> +
> +/**
> + * reservation_object_unlock - unlock the reservation object
> + * @obj: the reservation object
> + *
> + * Unlocks the reservation object following exclusive access.
> + */
> +static inline void
> +reservation_object_unlock(struct reservation_object *obj)
> +{
> + ww_mutex_unlock(>lock);
> +}
> +
> +/**
>   * reservation_object_get_excl - get the reservation object's
>   * exclusive fence, with update-side lock held
>   * @obj: the reservation object
> -- 
> 2.10.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH] drm/color: document NULL values and default settings better

[Daniel Vetter]

On Tue, Nov 15, 2016 at 03:39:01PM +, Lionel Landwerlin wrote:
> Sorry for missing this.
> 
> Reviewed-by: Lionel Landwerlin 

np and thanks a lot for reviewing.
-Daniel

> 
> On 26/09/16 10:04, Daniel Vetter wrote:
> > Brought up in a discussion for enabling gamma on fsl-dcu.
> > 
> > Cc: Ville Syrjälä 
> > Cc: Meng Yi 
> > Cc: Lionel Landwerlin 
> > Signed-off-by: Daniel Vetter 
> > ---
> >   drivers/gpu/drm/drm_color_mgmt.c | 12 
> >   1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> > b/drivers/gpu/drm/drm_color_mgmt.c
> > index d28ffdd2b929..6543ebde501a 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -41,6 +41,10 @@
> >*nor use all the elements of the LUT (for example the hardware 
> > might
> >*choose to interpolate between LUT[0] and LUT[4]).
> >*
> > + * Setting this to NULL (blob property value set to 0) means a
> > + * linear/pass-thru gamma table should be used. This is generally the
> > + * driver boot-up state too.
> > + *
> >* “DEGAMMA_LUT_SIZE”:
> >*Unsinged range property to give the size of the lookup table to 
> > be set
> >*on the DEGAMMA_LUT property (the size depends on the underlying
> > @@ -54,6 +58,10 @@
> >*lookup through the gamma LUT. The data is interpreted as a 
> > struct
> >*_color_ctm.
> >*
> > + * Setting this to NULL (blob property value set to 0) means a
> > + * unit/pass-thru matrix should be used. This is generally the driver
> > + * boot-up state too.
> > + *
> >* “GAMMA_LUT”:
> >*Blob property to set the gamma lookup table (LUT) mapping pixel 
> > data
> >*after the transformation matrix to data sent to the connector. 
> > The
> > @@ -62,6 +70,10 @@
> >*nor use all the elements of the LUT (for example the hardware 
> > might
> >*choose to interpolate between LUT[0] and LUT[4]).
> >*
> > + * Setting this to NULL (blob property value set to 0) means a
> > + * linear/pass-thru gamma table should be used. This is generally the
> > + * driver boot-up state too.
> > + *
> >* “GAMMA_LUT_SIZE”:
> >*Unsigned range property to give the size of the lookup table to 
> > be set
> >*on the GAMMA_LUT property (the size depends on the underlying 
> > hardware).
> 
> 

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

[GIT PULL] sun4i-drm changes for 4.10

[Maxime Ripard]

Hi David,

Please pull the following changes for the next merge window.

Thanks!
Maxime

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git 
tags/sunxi-drm-for-4.10

for you to fetch changes up to 47d7fbb32c57c8d1722a3e9bd21e501e80fd0741:

  drm/sun4i: Add a few formats (2016-11-02 19:37:37 +0100)


sun4i-drm changes for 4.10

Support for the Allwinner A31 SoC display engine using the sun4i-drm
driver.


Chen-Yu Tsai (4):
  drm/sun4i: sun6i-drc: Support DRC on A31 and A31s
  drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure
  drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)
  drm/sun4i: Add compatible strings for A31/A31s display pipelines

Maxime Ripard (1):
  drm/sun4i: Add a few formats

 .../bindings/display/sunxi/sun4i-drm.txt   | 10 -
 drivers/gpu/drm/sun4i/sun4i_backend.c  | 21 +++
 drivers/gpu/drm/sun4i/sun4i_drv.c  |  5 +++
 drivers/gpu/drm/sun4i/sun4i_layer.c|  6 +++
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 43 ++
 drivers/gpu/drm/sun4i/sun4i_tcon.h | 11 --
 drivers/gpu/drm/sun4i/sun6i_drc.c  |  2 +
 7 files changed, 78 insertions(+), 20 deletions(-)

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/70c09aa6/attachment.sig>

[GIT PULL] sun4i-drm fixes for 4.9

[Maxime Ripard]

Hi David,

Please pull the following fixes for the 4.9 cycle.

Thanks!
Maxime

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git 
tags/sunxi-drm-fixes-for-4.9

for you to fetch changes up to 4db069a2bf990e278ea57ff615dcaa89b85376bd:

  drm/sun4i: Propagate error to the caller (2016-11-07 16:09:35 +0100)


sun4i-drm fixes for 4.9

A few patches to fix our error handling and our panel / bridge calls.


Christophe JAILLET (2):
  drm/sun4i: Fix error handling
  drm/sun4i: Propagate error to the caller

Jonathan Liu (1):
  drm/sun4i: rgb: Enable panel after controller

Maxime Ripard (1):
  drm/sun4i: rgb: Remove the bridge enable/disable functions

 drivers/gpu/drm/sun4i/sun4i_drv.c |  4 ++--
 drivers/gpu/drm/sun4i/sun4i_rgb.c | 20 
 2 files changed, 10 insertions(+), 14 deletions(-)

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/d1cebdf5/attachment.sig>

[Bug 98634] Fedora/Ubuntu 32bits is not able to resume from hibernate

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Luis Botello  ---
This issue is also seen on Ubuntu 32 bits an all the platforms, with the
following config:

Software information

Kernel version  : 4.8.0-27-generic
Linux distribution  : Ubuntu 16.10
Architecture: 64-bit
Kernel driver in use: i915
Bios revision   : 144.10
Bios release date   : 06/27/2016
KSC revision: 1.6

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/369f2b87/attachment-0001.html>

[PATCH v12 3/3] drm/fence: add out-fences support

[Gustavo Padovan]

From: Gustavo Padovan 

Support DRM out-fences by creating a sync_file with a fence for each CRTC
that sets the OUT_FENCE_PTR property.

We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
the sync_file fd back to userspace.

The sync_file and fd are allocated/created before commit, but the
fd_install operation only happens after we know that commit succeed.

v2: Comment by Rob Clark:
- Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.

Comment by Daniel Vetter:
- Add clean up code for out_fences

v3: Comments by Daniel Vetter:
- create DRM_MODE_ATOMIC_EVENT_MASK
- userspace should fill out_fences_ptr with the crtc_ids for which
it wants fences back.

v4: Create OUT_FENCE_PTR properties and remove old approach.

v5: Comments by Brian Starkey:
- Remove extra fence_get() in atomic_ioctl()
- Check ret before iterating on the crtc_state
- check ret before fd_install
- set fence_state to NULL at the beginning
- check fence_state->out_fence_ptr before put_user()
- change order of fput() and put_unused_fd() on failure

 - Add access_ok() check to the out_fence_ptr received
 - Rebase after fence -> dma_fence rename
 - Store out_fence_ptr in the drm_atomic_state
 - Split crtc_setup_out_fence()
 - return -1 as out_fence with TEST_ONLY flag

v6: Comments by Daniel Vetter
- Add prepare/unprepare_crtc_signaling()
- move struct drm_out_fence_state to drm_atomic.c
- mark get_crtc_fence() as static

Comments by Brian Starkey
- proper set fence_ptr fence_state array
- isolate fence_idx increment

- improve error handling

v7: Comments by Daniel Vetter
- remove prefix from internal functions
- make out_fence_ptr an s64 pointer
- degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
- fix doc issues
- filter out OUT_FENCE_PTR == NULL and do not fail in this case
- add complete_crtc_signalling()
- krealloc fence_state on demand

Comment by Brian Starkey
- remove unused crtc_state arg from get_out_fence()

v8: Comment by Brian Starkey
- cancel events before check for !fence_state
- convert a few lefovers u64 types for out_fence_ptr
- fix memleak by assign fence_state earlier after realloc
- proper accout num_fences in case of error

v9: Comment by Brian Starkey
- memset last position of fence_state after krealloc
Comments by Sean Paul
- pass install_fds in complete_crtc_signaling() instead of ret

 - put_user(-1, fence_ptr) when decoding props

v10: Comment by Brian Starkey
- remove unneeded num_fences increment on error path
- kfree fence_state after installing fences fd

v11: rebase against latest drm-misc

Signed-off-by: Gustavo Padovan 
Reviewed-by: Brian Starkey 
Tested-by: Robert Foss 
---
 drivers/gpu/drm/drm_atomic.c | 241 +++
 drivers/gpu/drm/drm_crtc.c   |   8 ++
 include/drm/drm_atomic.h |   1 +
 include/drm/drm_crtc.h   |   6 ++
 4 files changed, 211 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3ad780a..d4a92a9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
 }
 EXPORT_SYMBOL(drm_atomic_get_crtc_state);

+static void set_out_fence_for_crtc(struct drm_atomic_state *state,
+  struct drm_crtc *crtc, s64 __user *fence_ptr)
+{
+   state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
+}
+
+static s64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
+  struct drm_crtc *crtc)
+{
+   s64 __user *fence_ptr;
+
+   fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
+   state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
+
+   return fence_ptr;
+}
+
 /**
  * drm_atomic_set_mode_for_crtc - set mode for CRTC
  * @state: the CRTC whose incoming state to update
@@ -494,6 +511,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == config->prop_out_fence_ptr) {
+   s64 __user *fence_ptr = u64_to_user_ptr(val);
+
+   if (!fence_ptr)
+   return 0;
+
+   if (put_user(-1, fence_ptr))
+   return -EFAULT;
+
+   set_out_fence_for_crtc(state->state, crtc, fence_ptr);
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
@@ -536,6 +563,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
 

[PATCH v12 2/3] drm/fence: add fence timeline to drm_crtc

[Gustavo Padovan]

From: Gustavo Padovan 

Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.

v2: Comment by Daniel Stone:
- add BUG_ON() to fence_to_crtc() macro

v3: Comment by Ville Syrjälä
- Use more meaningful name as crtc timeline name

v4: Comments by Brian Starkey
- Use even more meaninful name for the crtc timeline
- add doc for timeline_name
Comment by Daniel Vetter
- use in-line style for comments

- rebase after fence -> dma_fence rename

v5: Comment by Daniel Vetter
- Add doc for drm_crtc_fence_ops

v6: Comment by Chris Wilson
- Move fence_to_crtc to drm_crtc.c
- Move export of drm_crtc_fence_ops to drm_crtc_internal.h

- rebase against latest drm-misc

Signed-off-by: Gustavo Padovan 
Reviewed-by: Daniel Vetter 
Reviewed-by: Sean Paul 
Tested-by: Robert Foss 
---
 drivers/gpu/drm/drm_crtc.c  | 38 +
 drivers/gpu/drm/drm_crtc_internal.h | 10 ++
 include/drm/drm_crtc.h  | 29 
 3 files changed, 77 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c19ecc2..02e9451 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -163,6 +164,38 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc)
 #endif
 }

+static struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
+{
+   BUG_ON(fence->ops != _crtc_fence_ops);
+   return container_of(fence->lock, struct drm_crtc, fence_lock);
+}
+
+static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->dev->driver->name;
+}
+
+static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->timeline_name;
+}
+
+static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+const struct dma_fence_ops drm_crtc_fence_ops = {
+   .get_driver_name = drm_crtc_fence_get_driver_name,
+   .get_timeline_name = drm_crtc_fence_get_timeline_name,
+   .enable_signaling = drm_crtc_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
 /**
  * drm_crtc_init_with_planes - Initialise a new CRTC object with
  *specified primary and cursor planes.
@@ -220,6 +253,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
return -ENOMEM;
}

+   crtc->fence_context = dma_fence_context_alloc(1);
+   spin_lock_init(>fence_lock);
+   snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
+"CRTC:%d-%s", crtc->base.id, crtc->name);
+
crtc->base.properties = >properties;

list_add_tail(>head, >crtc_list);
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 64bb3eb..3130bc3 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -43,6 +43,16 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,

 void drm_fb_release(struct drm_file *file_priv);

+extern const struct dma_fence_ops drm_crtc_fence_ops;
+
+/* dumb buffer support IOCTLs */
+int drm_mode_create_dumb_ioctl(struct drm_device *dev,
+  void *data, struct drm_file *file_priv);
+int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
+int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
+   void *data, struct drm_file *file_priv);
+
 /* IOCTLs */
 int drm_mode_getresources(struct drm_device *dev,
  void *data, struct drm_file *file_priv);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 11780a9..edd2d83 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -739,6 +739,35 @@ struct drm_crtc {
 */
struct drm_crtc_crc crc;
 #endif
+
+   /**
+* @fence_context:
+*
+* timeline context used for fence operations.
+*/
+   unsigned int fence_context;
+
+   /**
+* @fence_lock:
+*
+* spinlock to protect the fences in the fence_context.
+*/
+
+   spinlock_t fence_lock;
+   /**
+* @fence_seqno:
+*
+* Seqno variable used as monotonic counter for the fences
+* created on the CRTC's timeline.
+*/
+   unsigned long fence_seqno;
+
+   /**
+* @timeline_name:
+*
+* The name of the CRTC's fence 

[PATCH v12 1/3] drm/fence: add in-fences support

[Gustavo Padovan]

From: Gustavo Padovan 

There is now a new property called IN_FENCE_FD attached to every plane
state that receives sync_file fds from userspace via the atomic commit
IOCTL.

The fd is then translated to a fence (that may be a fence_array
subclass or just a normal fence) and then used by DRM to fence_wait() for
all fences in the sync_file to signal. So it only commits when all
framebuffers are ready to scanout.

v2: Comments by Daniel Vetter:
- remove set state->fence = NULL in destroy phase
- accept fence -1 as valid and just return 0
- do not call fence_get() - sync_file_fences_get() already calls it
- fence_put() if state->fence is already set, in case userspace
set the property more than once.

v3: WARN_ON if fence is set but state has no FB

v4: Comment from Maarten Lankhorst
- allow set fence with no related fb

v5: rename FENCE_FD to IN_FENCE_FD

v6: Comments by Daniel Vetter:
- rename plane_state->in_fence back to "fence"
- re-introduce WARN_ON if fence set but no fb

 - rebase after fence -> dma_fence rename

v7: Comments by Brian Starkey
- set state->fence to NULL when duplicating the state
- fail if IN_FENCE_FD was already set

v8: rebase against latest drm-misc

Signed-off-by: Gustavo Padovan 
Reviewed-by: Brian Starkey 
Reviewed-by: Sean Paul 
Tested-by: Robert Foss 
---
 drivers/gpu/drm/Kconfig |  1 +
 drivers/gpu/drm/drm_atomic.c| 14 ++
 drivers/gpu/drm/drm_atomic_helper.c |  5 +
 drivers/gpu/drm/drm_crtc.c  |  6 ++
 drivers/gpu/drm/drm_plane.c |  1 +
 include/drm/drm_crtc.h  |  5 +
 6 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 863cdca..95fc041 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+   select SYNC_FILE
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
  introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 57e0a6e9..3ad780a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "drm_crtc_internal.h"

@@ -712,6 +713,17 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
drm_framebuffer_unreference(fb);
+   } else if (property == config->prop_in_fence_fd) {
+   if (state->fence)
+   return -EINVAL;
+
+   if (U642I64(val) == -1)
+   return 0;
+
+   state->fence = sync_file_get_fence(val);
+   if (!state->fence)
+   return -EINVAL;
+
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, val);
return drm_atomic_set_crtc_for_plane(state, crtc);
@@ -773,6 +785,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,

if (property == config->prop_fb_id) {
*val = (state->fb) ? state->fb->base.id : 0;
+   } else if (property == config->prop_in_fence_fd) {
+   *val = -1;
} else if (property == config->prop_crtc_id) {
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->prop_crtc_x) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 5007796..0b16587 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3072,6 +3072,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,

if (state->fb)
drm_framebuffer_reference(state->fb);
+
+   state->fence = NULL;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);

@@ -3110,6 +3112,9 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 {
if (state->fb)
drm_framebuffer_unreference(state->fb);
+
+   if (state->fence)
+   dma_fence_put(state->fence);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b082763..c19ecc2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -395,6 +395,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_fb_id = prop;

+   prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC,
+   "IN_FENCE_FD", -1, INT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   

[PATCH v12 0/3] drm: add explicit fencing

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

Yet another iteration, v12 now after working on the changes proposed by Chris
Wilson.

Robert Foss managed to port Android's drm_hwcomposer to the new HWC2 API and
added support to fences. Current patches can be seen here:

https://git.collabora.com/cgit/user/robertfoss/drm_hwcomposer.git/log/?h=hwc2_fence_v1

He ran AOSP on top of padovan/fences kernel branch with full fence support on
qemu/virgl and msm db410c. That means we already have a working open source
userspace using the explicit fencing implementation.

Also i-g-t testing are available with all tests suggested in v7 included:

https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/log/

Please review!

Gustavo

[1] https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1253822.html

Gustavo Padovan (3):
  drm/fence: add in-fences support
  drm/fence: add fence timeline to drm_crtc
  drm/fence: add out-fences support

 drivers/gpu/drm/Kconfig |   1 +
 drivers/gpu/drm/drm_atomic.c| 255 +---
 drivers/gpu/drm/drm_atomic_helper.c |   5 +
 drivers/gpu/drm/drm_crtc.c  |  52 
 drivers/gpu/drm/drm_crtc_internal.h |  10 ++
 drivers/gpu/drm/drm_plane.c |   1 +
 include/drm/drm_atomic.h|   1 +
 include/drm/drm_crtc.h  |  40 ++
 8 files changed, 320 insertions(+), 45 deletions(-)

-- 
2.5.5

[Bug 98634] Fedora/Ubuntu 32bits is not able to resume from hibernate

[bugzilla-dae...@freedesktop.org]

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

Luis Botello  changed:

   What|Removed |Added

Summary|Fedora 32bits kernel|Fedora/Ubuntu 32bits is not
   |4.8.4-200.fc24.i686+PAE is  |able to resume from
   |not able to resume from |hibernate
   |hibernate   |

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/1fec9d13/attachment.html>

[RFCv2 PATCH 1/5] video: add HDMI state notifier support

[Hans Verkuil]

Hi Philipp,

On 11/15/2016 07:24 PM, Philipp Zabel wrote:
> Hi Hans,
> 
> Am Montag, den 14.11.2016, 16:22 +0100 schrieb Hans Verkuil:
>> From: Hans Verkuil 
>>
>> Add support for HDMI hotplug and EDID notifiers, which is used to convey
>> information from HDMI drivers to their CEC and audio counterparts.
>>
>> Based on an earlier version from Russell King:
>>
>> https://patchwork.kernel.org/patch/9277043/
>>
>> The hdmi_notifier is a reference counted object containing the HDMI state
>> of an HDMI device.
>>
>> When a new notifier is registered the current state will be reported to
>> that notifier at registration time.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  drivers/video/Kconfig |   3 +
>>  drivers/video/Makefile|   1 +
>>  drivers/video/hdmi-notifier.c | 136 
>> ++
>>  include/linux/hdmi-notifier.h |  43 +
>>  4 files changed, 183 insertions(+)
>>  create mode 100644 drivers/video/hdmi-notifier.c
>>  create mode 100644 include/linux/hdmi-notifier.h
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 3c20af9..1ee7b9f 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
>>  config HDMI
>>  bool
>>  
>> +config HDMI_NOTIFIERS
>> +bool
>> +
>>  if VT
>>  source "drivers/video/console/Kconfig"
>>  endif
>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>> index 9ad3c17..65f5649 100644
>> --- a/drivers/video/Makefile
>> +++ b/drivers/video/Makefile
>> @@ -1,5 +1,6 @@
>>  obj-$(CONFIG_VGASTATE)+= vgastate.o
>>  obj-$(CONFIG_HDMI)+= hdmi.o
>> +obj-$(CONFIG_HDMI_NOTIFIERS)  += hdmi-notifier.o
>>  
>>  obj-$(CONFIG_VT)  += console/
>>  obj-$(CONFIG_LOGO)+= logo/
>> diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
>> new file mode 100644
>> index 000..c2a4f1b
>> --- /dev/null
>> +++ b/drivers/video/hdmi-notifier.c
>> @@ -0,0 +1,136 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct hdmi_notifiers {
>> +struct list_head head;
>> +struct device *dev;
>> +struct hdmi_notifier *n;
>> +};
> 
> This struct is not used, can be removed.

Indeed.

> 
>> +static LIST_HEAD(hdmi_notifiers);
>> +static DEFINE_MUTEX(hdmi_notifiers_lock);
>> +
>> +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
>> +{
>> +struct hdmi_notifier *n;
>> +
>> +mutex_lock(_notifiers_lock);
>> +list_for_each_entry(n, _notifiers, head) {
>> +if (n->dev == dev) {
>> +mutex_unlock(_notifiers_lock);
>> +kref_get(>kref);
>> +return n;
>> +}
>> +}
>> +n = kzalloc(sizeof(*n), GFP_KERNEL);
>> +if (!n)
>> +goto unlock;
>> +mutex_init(>lock);
>> +BLOCKING_INIT_NOTIFIER_HEAD(>notifiers);
>> +kref_init(>kref);
> 
> + n->dev = dev;
> 
> Currently n->dev is never set, so every caller of this function gets its
> own hdmi_notifier.

Oops! Well, I did say it was compile-tested only :-)

> 
>> +list_add_tail(>head, _notifiers);
>> +unlock:
>> +mutex_unlock(_notifiers_lock);
>> +return n;
>> +}
>> +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
>> +
>> +static void hdmi_notifier_release(struct kref *kref)
>> +{
>> +struct hdmi_notifier *n =
>> +container_of(kref, struct hdmi_notifier, kref);
>> +
>> +kfree(n->edid);
>> +kfree(n);
>> +}
>> +
>> +void hdmi_notifier_put(struct hdmi_notifier *n)
>> +{
>> +kref_put(>kref, hdmi_notifier_release);
>> +}
>> +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
>> +
>> +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block 
>> *nb)
>> +{
>> +int ret = blocking_notifier_chain_register(>notifiers, nb);
>> +
>> +if (ret)
>> +return ret;
>> +kref_get(>kref);
>> +mutex_lock(>lock);
>> +if (n->connected) {
>> +blocking_notifier_call_chain(>notifiers, HDMI_CONNECTED, n);
>> +if (n->edid_size)
>> +blocking_notifier_call_chain(>notifiers, 
>> HDMI_NEW_EDID, n);
>> +if (n->has_eld)
>> +blocking_notifier_call_chain(>notifiers, 
>> HDMI_NEW_ELD, n);
>> +}
>> +mutex_unlock(>lock);
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
>> +
>> +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block 
>> *nb)
>> +{
>> +int ret = blocking_notifier_chain_unregister(>notifiers, nb);
>> +
>> +if (ret == 0)
>> +hdmi_notifier_put(n);
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
>> +
>> +void hdmi_event_connect(struct hdmi_notifier *n)
>> +{
>> +mutex_lock(>lock);
>> +n->connected = true;
>> +blocking_notifier_call_chain(>notifiers, HDMI_CONNECTED, n);
>> +mutex_unlock(>lock);
>> +}
>> +EXPORT_SYMBOL_GPL(hdmi_event_connect);
>> +
>> +void 

[GIT PULL FOR v4.10] Renesas R-Car DU changes

[Laurent Pinchart]

Hi Dave,

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

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

for you to fetch changes up to 85e8f8d175caa6a39f4c4e11dd4d0ab038f43324:

  drm: rcar-du: Fix LVDS start sequence on Gen3 (2016-11-15 01:44:51 +0200)

Please note that the first patch ("video: of: Constify node argument to 
display timing functions") has been acked by Tomi for merged through your 
tree.


Koji Matsuoka (3):
  drm: rcar-du: Fix display timing controller parameter
  drm: rcar-du: Fix H/V sync signal polarity configuration
  drm: rcar-du: Fix LVDS start sequence on Gen3

Laurent Pinchart (9):
  video: of: Constify node argument to display timing functions
  drm: rcar-du: Constify node argument to rcar_du_lvds_connector_init()
  drm: rcar-du: Bring HDMI encoder comments in line with the driver
  drm: rcar-du: Remove test for impossible error condition
  drm: rcar-du: Remove memory allocation error message
  drm: rcar-du: Fix crash in encoder failure error path
  drm: rcar-du: Simplify and fix probe error handling
  drm: rcar-du: Add R8A7796 support
  drm: rcar-du: Fix dot clock routing configuration

Sergei Shtylyov (1):
  drm: rcar-du: Add R8A7792 support

 .../devicetree/bindings/display/renesas,du.txt  | 12 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  6 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 83 +++-
 drivers/gpu/drm/rcar-du/rcar_du_group.c | 22 ---
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c   |  4 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 17 +++--
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c   | 19 +++---
 drivers/video/of_display_timing.c   |  6 +-
 include/video/of_display_timing.h   | 15 ++---
 11 files changed, 117 insertions(+), 71 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

I guess Daniel has already reverted the patches.

Now many I know who is going to define on what should be the right way 
to handle aspect ratios ?

Regards
Shashank
On 11/15/2016 7:48 PM, Ville Syrjälä wrote:
> On Tue, Nov 15, 2016 at 01:48:04PM +, Jose Abreu wrote:
>> Hi,
>>
>>
>>
>> On 15-11-2016 10:52, Daniel Vetter wrote:
>>> On Tue, Nov 15, 2016 at 03:36:02PM +0530, Sharma, Shashank wrote:
 On 11/15/2016 3:30 PM, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
>> On 11/15/2016 2:21 PM, Daniel Vetter wrote:
>>> On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
 In any case, I guess addition of a cap for aspect ratio should fix the
 current objections for this implementation.

 And I will keep it 0 by default, so that no aspect ratio information is
 added until userspace sets the cap to 1 on its own.
>>> Note that cap = needs new userspace.
>>> -Daniel
>> I guess you mean a new libdrm, so yes, I will add this new cap in libdrm.
>> Is that what you mean ?
> Full stack solution, including enabling in an Xorg driver (or somewhere
> else, we also have drm_hwcomposer as an option).
>
> And because that's probably going to take forever I'm leaning towards
> revert again. Ville?
 Not really, with a kernel cap implementation, the code will be as it was
 before this patch series ( as good as revert )
 And then when we want to enable it, we can add the corresponding Xserver
 patch.

 I guess the current problem is if is breaks something in some userspace, 
 but
 if I am loading the flags only when the cap is set, we should be good.
>>> This is not how new uabi gets merged, see:
>>>
>>> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>>>
>>> Userspace must be ready, or it will not land. The entire point of my
>>> suggestion to just extend the display modes was to avoid the need for
>>> userspace, but since existing userspace tries to be too clever already,
>>> that didn't work out.
>>> Thanks, Daniel
>> @Ville
>>
>> I gave my tested by to these patches because I was facing the
>> same scenario as Shashank: HDMI compliance. I believe we need to
>> find a better way to handle this instead of just reverting. The
>> HDMI spec is evolving so we also need to evolve. Of course that
>> if this is breaking user space then we can revert and wait until
>> we figure the best way to implement this.
>>
>> Anyway, this is a wild guess but I think the reason you are
>> loosing modes may be because of
>> drm_mode_equal_no_clocks_no_stereo() which is always expecting a
>> aspect ratio flag to be defined. If there isn't one defined then
>> it will unconditionally return false, even if the modes are
>> equal.
> I am well aware why we're losing modes. One reason is the mode equal
> checks in the kernel as you suspect, the other is simply userspace
> rejecting everything with the aspect ratio defined.
>
>> Can you please test this patch and see if it fixes on your
>> side? WARNING: Not compile tested
> I already did something like that earlier, except I rewrote the
> entire messy mode matching code to use a cleaner flag based approach:
>
> git://github.com/vsyrjala/linux.git cea_f_vics
>
> But that doesn't solve the userspace ABI issue, and there are still a
> lot of unanswered questions like:
>
> - Should we define aspect ratios for modes not directly coming from
>edid_cea_modes[]?
>
>I beleive the answer must be "yes" at least in the cases where the
>EDID lists the VIC even if we then skip adding the mode due to
>already having it on the list via from another source. Perhaps we
>want the aspect ratio even if the VIC wasn't directly specified?
>
> - Should we or should we not specify a VIC in the AVI infoframe
>when the userspace doesn't support aspect ratio flags?
>
>I would guess the answer is again "yes", and we should just pick the
>preferred aspect ratio for the mode. At least that's closer to what
>we've been doing up to now (except we just picked the first VIC, so
>we might have picked the non-preferred aspect ratio actually). At
>least having the VIC in the infoframe would seem like a safer option
>than not having it, in case there's some cheap ass hardware that
>can't do anything sensible without being hand fed a VIC.
>
> - How we should handle the aspect ratio in mode sorting?
>
>I think we want some sensible sorting order for these. Preferred
>aspect ratio first would seem like the obvious choice. I do realize
>that we don't sort based on 3D stereo flags either, but I thinking we
>probably should.
>

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

Regards
Shashank
On 11/15/2016 7:48 PM, Ville Syrjälä wrote:
> On Tue, Nov 15, 2016 at 01:48:04PM +, Jose Abreu wrote:
>> Hi,
>>
>>
>>
>> On 15-11-2016 10:52, Daniel Vetter wrote:
>>> On Tue, Nov 15, 2016 at 03:36:02PM +0530, Sharma, Shashank wrote:
 On 11/15/2016 3:30 PM, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
>> On 11/15/2016 2:21 PM, Daniel Vetter wrote:
>>> On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
 In any case, I guess addition of a cap for aspect ratio should fix the
 current objections for this implementation.

 And I will keep it 0 by default, so that no aspect ratio information is
 added until userspace sets the cap to 1 on its own.
>>> Note that cap = needs new userspace.
>>> -Daniel
>> I guess you mean a new libdrm, so yes, I will add this new cap in libdrm.
>> Is that what you mean ?
> Full stack solution, including enabling in an Xorg driver (or somewhere
> else, we also have drm_hwcomposer as an option).
>
> And because that's probably going to take forever I'm leaning towards
> revert again. Ville?
 Not really, with a kernel cap implementation, the code will be as it was
 before this patch series ( as good as revert )
 And then when we want to enable it, we can add the corresponding Xserver
 patch.

 I guess the current problem is if is breaks something in some userspace, 
 but
 if I am loading the flags only when the cap is set, we should be good.
>>> This is not how new uabi gets merged, see:
>>>
>>> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>>>
>>> Userspace must be ready, or it will not land. The entire point of my
>>> suggestion to just extend the display modes was to avoid the need for
>>> userspace, but since existing userspace tries to be too clever already,
>>> that didn't work out.
>>> Thanks, Daniel
>> @Ville
>>
>> I gave my tested by to these patches because I was facing the
>> same scenario as Shashank: HDMI compliance. I believe we need to
>> find a better way to handle this instead of just reverting. The
>> HDMI spec is evolving so we also need to evolve. Of course that
>> if this is breaking user space then we can revert and wait until
>> we figure the best way to implement this.
>>
>> Anyway, this is a wild guess but I think the reason you are
>> loosing modes may be because of
>> drm_mode_equal_no_clocks_no_stereo() which is always expecting a
>> aspect ratio flag to be defined. If there isn't one defined then
>> it will unconditionally return false, even if the modes are
>> equal.
> I am well aware why we're losing modes. One reason is the mode equal
> checks in the kernel as you suspect, the other is simply userspace
> rejecting everything with the aspect ratio defined.
>
>> Can you please test this patch and see if it fixes on your
>> side? WARNING: Not compile tested
> I already did something like that earlier, except I rewrote the
> entire messy mode matching code to use a cleaner flag based approach:
>
> git://github.com/vsyrjala/linux.git cea_f_vics
>
> But that doesn't solve the userspace ABI issue, and there are still a
> lot of unanswered questions like:
>
> - Should we define aspect ratios for modes not directly coming from
>edid_cea_modes[]?
>
>I beleive the answer must be "yes" at least in the cases where the
>EDID lists the VIC even if we then skip adding the mode due to
>already having it on the list via from another source. Perhaps we
>want the aspect ratio even if the VIC wasn't directly specified?
Wouldn't this break the whole concept of VIC, which is supposed to point 
to a unique mode ?
> - Should we or should we not specify a VIC in the AVI infoframe
>when the userspace doesn't support aspect ratio flags?
This is a requirement of HDMI compliance tests, if userspace 
supports/handles aspect ratio, it should set cap, and it will be set in 
kernel flags
and we should load that in AV IF.  Are you planning to suggest a better 
way, in which this can be done ?
>I would guess the answer is again "yes", and we should just pick the
>preferred aspect ratio for the mode. At least that's closer to what
>we've been doing up to now (except we just picked the first VIC, so
>we might have picked the non-preferred aspect ratio actually). At
>least having the VIC in the infoframe would seem like a safer option
>than not having it, in case there's some cheap ass hardware that
>can't do anything sensible without being hand fed a VIC.
>
> - How we should handle the aspect ratio in mode sorting?
>
>I think we want some sensible sorting order for these. Preferred
>aspect ratio first would seem like the obvious choice. I do realize
>that we don't sort based on 3D stereo flags either, but I thinking we
>probably should.
What is the need of this sorting ? None of 

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-dae...@freedesktop.org]

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

--- Comment #46 from George Billios  ---
This is also valid for Trine 3.

Big delay to start ~5mins
setting MESA_SHADER_CAPTURE_PATH results in about 16k files!!!

specs
i7 860
Fury R9

4.7-staging kernel 
mesa-git Mesa 13.1.0-devel (git-151aeca)
llvm 3.9.0

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/1ca330f8/attachment.html>

[Bug 98743] Incorrect colormapping in Verdun game

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98743
   Summary: Incorrect colormapping in Verdun game
   Product: Mesa
   Version: 13.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: piejacker875 at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Dirt appears red in every map. Everything else renders as it should.
http://images.akamai.steamusercontent.com/ugc/273986542686866042/F6D200B760FD4C89C1DB158E8BED02B3D2FC9868/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/bb2e19f9/attachment-0001.html>

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

[bugzilla-dae...@freedesktop.org]

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

--- Comment #61 from hofmann.zachary at gmail.com ---
I haven't seen anything to rule out it being a hardware problem, but Valve's
overwhelming silence on the matter isn't exactly helpful.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/27507c10/attachment.html>

[Bug 98578] AMDGPU white glitches in some games

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Lukas Jirkovsky  ---
Nicolai, you are awesome! I tried the patch and haven't seen a single glitch in
The Vanishing of Ethan Carter.

I noticed one interesting thing. With current llvm (r286840), I got glitches
all over the screen making the game absolutely unplayable. However, with your
patch, all glitches (both old and the new) are fixed.

I tried Dreamfall Chapters, too. However, it's seriously broken with current
llvm, so I can't provide any results. But given the fact Ethan Carter works
fine with the patch, it's likely it's a different issue after all.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/eab595ed/attachment.html>

[PATCH] drm/mediatek: use HDMI state notifier support

[Philipp Zabel]

Issue hot-plug detection, EDID update, and ELD update notifications
from the CEC and HDMI drivers using the HDMI state notifier support.

Signed-off-by: Philipp Zabel 
---
This patch depends on the "video: add HDMI state notifier support" patch [1] by
Hans Verkuil, based on Russell King's earlier version. With this we can replace
the custom callback interface between HDMI and CEC drivers with a common
mechanism. It will also allow other drivers such as hdmi-codec to react to the
emitted events.

[1] https://patchwork.linuxtv.org/patch/38109/
---
 drivers/gpu/drm/mediatek/mtk_cec.c  | 56 +++--
 drivers/gpu/drm/mediatek/mtk_cec.h  | 26 -
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 46 ++
 3 files changed, 44 insertions(+), 84 deletions(-)
 delete mode 100644 drivers/gpu/drm/mediatek/mtk_cec.h

diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c 
b/drivers/gpu/drm/mediatek/mtk_cec.c
index 7a3eb8c..9a1807b 100644
--- a/drivers/gpu/drm/mediatek/mtk_cec.c
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -13,12 +13,11 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

-#include "mtk_cec.h"
-
 #define TR_CONFIG  0x00
 #define CLEAR_CEC_IRQ  BIT(15)

@@ -55,12 +54,9 @@

 struct mtk_cec {
void __iomem *regs;
+   struct hdmi_notifier *notifier;
struct clk *clk;
int irq;
-   bool hpd;
-   void (*hpd_event)(bool hpd, struct device *dev);
-   struct device *hdmi_dev;
-   spinlock_t lock;
 };

 static void mtk_cec_clear_bits(struct mtk_cec *cec, unsigned int offset,
@@ -94,20 +90,7 @@ static void mtk_cec_mask(struct mtk_cec *cec, unsigned int 
offset,
writel(val, cec->regs + offset);
 }

-void mtk_cec_set_hpd_event(struct device *dev,
-  void (*hpd_event)(bool hpd, struct device *dev),
-  struct device *hdmi_dev)
-{
-   struct mtk_cec *cec = dev_get_drvdata(dev);
-   unsigned long flags;
-
-   spin_lock_irqsave(>lock, flags);
-   cec->hdmi_dev = hdmi_dev;
-   cec->hpd_event = hpd_event;
-   spin_unlock_irqrestore(>lock, flags);
-}
-
-bool mtk_cec_hpd_high(struct device *dev)
+static bool mtk_cec_hpd_high(struct device *dev)
 {
struct mtk_cec *cec = dev_get_drvdata(dev);
unsigned int status;
@@ -152,21 +135,6 @@ static void mtk_cec_clear_htplg_irq(struct mtk_cec *cec)
   RX_INT_32K_CLR | HDMI_HTPLG_INT_32K_CLR);
 }

-static void mtk_cec_hpd_event(struct mtk_cec *cec, bool hpd)
-{
-   void (*hpd_event)(bool hpd, struct device *dev);
-   struct device *hdmi_dev;
-   unsigned long flags;
-
-   spin_lock_irqsave(>lock, flags);
-   hpd_event = cec->hpd_event;
-   hdmi_dev = cec->hdmi_dev;
-   spin_unlock_irqrestore(>lock, flags);
-
-   if (hpd_event)
-   hpd_event(hpd, hdmi_dev);
-}
-
 static irqreturn_t mtk_cec_htplg_isr_thread(int irq, void *arg)
 {
struct device *dev = arg;
@@ -176,11 +144,13 @@ static irqreturn_t mtk_cec_htplg_isr_thread(int irq, void 
*arg)
mtk_cec_clear_htplg_irq(cec);
hpd = mtk_cec_hpd_high(dev);

-   if (cec->hpd != hpd) {
+   if (cec->notifier->connected != hpd) {
dev_dbg(dev, "hotplug event! cur hpd = %d, hpd = %d\n",
-   cec->hpd, hpd);
-   cec->hpd = hpd;
-   mtk_cec_hpd_event(cec, hpd);
+   cec->notifier->connected, hpd);
+   if (hpd)
+   hdmi_event_connect(cec->notifier);
+   else
+   hdmi_event_disconnect(cec->notifier);
}
return IRQ_HANDLED;
 }
@@ -197,7 +167,6 @@ static int mtk_cec_probe(struct platform_device *pdev)
return -ENOMEM;

platform_set_drvdata(pdev, cec);
-   spin_lock_init(>lock);

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
cec->regs = devm_ioremap_resource(dev, res);
@@ -220,6 +189,12 @@ static int mtk_cec_probe(struct platform_device *pdev)
return cec->irq;
}

+   cec->notifier = hdmi_notifier_get(dev);
+   if (!cec->notifier) {
+   clk_disable_unprepare(cec->clk);
+   return -ENOMEM;
+   }
+
ret = devm_request_threaded_irq(dev, cec->irq, NULL,
mtk_cec_htplg_isr_thread,
IRQF_SHARED | IRQF_TRIGGER_LOW |
@@ -245,6 +220,7 @@ static int mtk_cec_remove(struct platform_device *pdev)
 {
struct mtk_cec *cec = platform_get_drvdata(pdev);

+   hdmi_notifier_put(cec->notifier);
mtk_cec_htplg_irq_disable(cec);
clk_disable_unprepare(cec->clk);
return 0;
diff --git a/drivers/gpu/drm/mediatek/mtk_cec.h 
b/drivers/gpu/drm/mediatek/mtk_cec.h
deleted file mode 100644
index 10057b7..000
--- a/drivers/gpu/drm/mediatek/mtk_cec.h
+++ /dev/null
@@ -1,26 +0,0 

[RFCv2 PATCH 1/5] video: add HDMI state notifier support

[Philipp Zabel]

Hi Hans,

Am Montag, den 14.11.2016, 16:22 +0100 schrieb Hans Verkuil:
> From: Hans Verkuil 
> 
> Add support for HDMI hotplug and EDID notifiers, which is used to convey
> information from HDMI drivers to their CEC and audio counterparts.
> 
> Based on an earlier version from Russell King:
> 
> https://patchwork.kernel.org/patch/9277043/
> 
> The hdmi_notifier is a reference counted object containing the HDMI state
> of an HDMI device.
> 
> When a new notifier is registered the current state will be reported to
> that notifier at registration time.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/video/Kconfig |   3 +
>  drivers/video/Makefile|   1 +
>  drivers/video/hdmi-notifier.c | 136 
> ++
>  include/linux/hdmi-notifier.h |  43 +
>  4 files changed, 183 insertions(+)
>  create mode 100644 drivers/video/hdmi-notifier.c
>  create mode 100644 include/linux/hdmi-notifier.h
> 
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 3c20af9..1ee7b9f 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
>  config HDMI
>   bool
>  
> +config HDMI_NOTIFIERS
> + bool
> +
>  if VT
>   source "drivers/video/console/Kconfig"
>  endif
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 9ad3c17..65f5649 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_VGASTATE)+= vgastate.o
>  obj-$(CONFIG_HDMI)+= hdmi.o
> +obj-$(CONFIG_HDMI_NOTIFIERS)  += hdmi-notifier.o
>  
>  obj-$(CONFIG_VT)   += console/
>  obj-$(CONFIG_LOGO) += logo/
> diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> new file mode 100644
> index 000..c2a4f1b
> --- /dev/null
> +++ b/drivers/video/hdmi-notifier.c
> @@ -0,0 +1,136 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct hdmi_notifiers {
> + struct list_head head;
> + struct device *dev;
> + struct hdmi_notifier *n;
> +};

This struct is not used, can be removed.

> +static LIST_HEAD(hdmi_notifiers);
> +static DEFINE_MUTEX(hdmi_notifiers_lock);
> +
> +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> +{
> + struct hdmi_notifier *n;
> +
> + mutex_lock(_notifiers_lock);
> + list_for_each_entry(n, _notifiers, head) {
> + if (n->dev == dev) {
> + mutex_unlock(_notifiers_lock);
> + kref_get(>kref);
> + return n;
> + }
> + }
> + n = kzalloc(sizeof(*n), GFP_KERNEL);
> + if (!n)
> + goto unlock;
> + mutex_init(>lock);
> + BLOCKING_INIT_NOTIFIER_HEAD(>notifiers);
> + kref_init(>kref);

+   n->dev = dev;

Currently n->dev is never set, so every caller of this function gets its
own hdmi_notifier.

> + list_add_tail(>head, _notifiers);
> +unlock:
> + mutex_unlock(_notifiers_lock);
> + return n;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> +
> +static void hdmi_notifier_release(struct kref *kref)
> +{
> + struct hdmi_notifier *n =
> + container_of(kref, struct hdmi_notifier, kref);
> +
> + kfree(n->edid);
> + kfree(n);
> +}
> +
> +void hdmi_notifier_put(struct hdmi_notifier *n)
> +{
> + kref_put(>kref, hdmi_notifier_release);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
> +
> +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block 
> *nb)
> +{
> + int ret = blocking_notifier_chain_register(>notifiers, nb);
> +
> + if (ret)
> + return ret;
> + kref_get(>kref);
> + mutex_lock(>lock);
> + if (n->connected) {
> + blocking_notifier_call_chain(>notifiers, HDMI_CONNECTED, n);
> + if (n->edid_size)
> + blocking_notifier_call_chain(>notifiers, 
> HDMI_NEW_EDID, n);
> + if (n->has_eld)
> + blocking_notifier_call_chain(>notifiers, 
> HDMI_NEW_ELD, n);
> + }
> + mutex_unlock(>lock);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
> +
> +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block 
> *nb)
> +{
> + int ret = blocking_notifier_chain_unregister(>notifiers, nb);
> +
> + if (ret == 0)
> + hdmi_notifier_put(n);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
> +
> +void hdmi_event_connect(struct hdmi_notifier *n)
> +{
> + mutex_lock(>lock);
> + n->connected = true;
> + blocking_notifier_call_chain(>notifiers, HDMI_CONNECTED, n);
> + mutex_unlock(>lock);
> +}
> +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> +
> +void hdmi_event_disconnect(struct hdmi_notifier *n)
> +{
> + mutex_lock(>lock);
> + n->connected = false;
> + n->has_eld = false;
> + n->edid_size = 0;
> + blocking_notifier_call_chain(>notifiers, HDMI_DISCONNECTED, n);
> + 

[Bug 98645] X Freeze while rendering video with multiple displays and TearFree enabled

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Josep Torra  ---
It's most often reproduced in the Dell T5600 systems with "Intel Corporation
C600/X79 series chipset" and FirePro W9000.

But we also reproduced it few other systems based on chipset "Intel Corporation
C610/X99 series chipset" and FirePro W600.

Not reproducible so far with an Intel Skylake system, Asus Z170 Pro gaming
motherboard, with FirePro W600.

In the Dell T5600 the issue becomes hidden with the drm debug enabled in the
following way.

echo 0xf > /sys/module/drm/parameters/debug

It's still triggered with 0xe instead of 0xf.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/3254c7a8/attachment.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #12 from Emil Velikov  ---
Hello there, a couple of suggestions to make dev's life easier and get things
resolved a bit faster. It's unlikely that I will look into the issue itself.

Try to track down the version of
 - Xorg radeon DDX (xf86-video-ati)
 - Mesa
 - Linux Kernel
 - libdrm/libdrm_radeon

Rebuilding/installing the debug symbols (mesa, kodi, others?) is a good idea
;-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/dcbe9464/attachment-0001.html>

[PATCH v2 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers

[Bartosz Golaszewski]

2016-11-14 17:54 GMT+01:00 Jyri Sarha :
> Adds drm bride support for attaching drm bridge drivers to tilcdc. The
> decision whether a video port leads to an external encoder or bridge
> is made simply based on remote device's compatible string. The code
> has been tested with BeagleBone-Black with and without BeagleBone
> DVI-D Cape Rev A3 using ti-tfp410 driver.
>
> Signed-off-by: Jyri Sarha 
> ---

Hi Jyri,

thanks a lot for doing this.

One issue I see with this patch is that tilcdc doesn't seem to support
deferred probe correctly (if modules are built-in). The following
happens on my setup:

The dump-vga-dac module is loaded first, but the i2c0 is not ready yet
- probe returns EPROBE_DEFER and it's propagated to tilcdc probe.

[drm] Initialized
dumb-vga-dac vga_bridge: Couldn't retrieve i2c bus

Then the i2c bus is initialized and dump-vga-dac probe succeeds, but
the second probe of tilcdc gives me:

[drm:drm_debugfs_init] *ERROR* Cannot create /sys/kernel/debug/dri/64
[drm:drm_minor_register] *ERROR* DRM: Failed to initialize
/sys/kernel/debug/dri.
tilcdc: probe of da8xx_lcdc.0 failed with error -1

I was able to work around this issue by loading modules in correct order.

I then tried testing the patch with a da850-lcdk, but I don't get
anything on the display (no signal), even though the LCDC seems to
work fine (modetest and dmesg messages work just like when using the
tilcdc panel). Also: I see the EDID info is correctly retrieved from
the display.

Could you take a look at my DT[1] and see if you find it correct?

Best regards,
Bartosz Golaszewski

[1] http://pastebin.com/dfUX7PyL

[PATCH 09/10] arm64: dts: r8a7795: add HDMI support to DU

[Sergei Shtylyov]

Hello.

On 11/11/2016 08:07 PM, Ulrich Hecht wrote:

> Signed-off-by: Ulrich Hecht 
> ---
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 34 
> ++--
>  1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index 811c32e..d9e5706 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -147,6 +147,30 @@
>   clock-frequency = <0>;
>   };
>
> + programmable_clk0: clock_out0 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <0>;
> + };
> +
> + x21_clk: x21-clock {

Please name it just x21 to math the documentation -- this will be 
reflected in the output clock name.

> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <0>;
> + };
> +
> + x22_clk: x22-clock {

Same here.

> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <0>;
> + };
> +
> + programmable_clk1: clock_out1 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <0>;
> + };
> +
>   soc {
>   compatible = "simple-bus";
>   interrupt-parent = <>;
[...]

MBR, Sergei

[PATCH V2 2/3] dt-bindings: mxsfb: Add new bindings for the MXSFB driver

[Rob Herring]

On Mon, Nov 14, 2016 at 11:10:35AM +0100, Marek Vasut wrote:
> Add new DT bindings for new MXSFB driver that is using the
> OF graph to parse the video output structure instead of
> hard-coding the display properties into the MXSFB node.
> The old MXSFB fbdev driver bindings are preserved in the
> same file in the "Old bindings" section.
> 
> Signed-off-by: Marek Vasut 
> Cc: Rob Herring 
> Cc: Lucas Stach 
> Cc: Fabio Estevam 
> Cc: Shawn Guo 
> Cc: Daniel Vetter 
> Cc: devicetree at vger.kernel.org
> --
> V2: - Merge the new bindings into mxsfb.txt file instead of keeping
>   them in separate mxsfb-drm.txt file.
> - Add dedicated compatible for i.MX6SX
> - Drop all references to DRM/KMS
> - Repair the required bits in clock node
> ---
>  .../devicetree/bindings/display/mxsfb.txt  | 37 
> ++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt 
> b/Documentation/devicetree/bindings/display/mxsfb.txt
> index a4431f2..6e92593 100644
> --- a/Documentation/devicetree/bindings/display/mxsfb.txt
> +++ b/Documentation/devicetree/bindings/display/mxsfb.txt
> @@ -1,5 +1,42 @@
>  * Freescale MXS LCD Interface (LCDIF)
>  
> +New bindings:
> +=
> +Required properties:
> +- compatible:Should be "fsl,imx23-lcdif" for i.MX23.
> + Should be "fsl,imx28-lcdif" for i.MX28.
> + Should be "fsl,imx6sx-lcdif" for i.MX6SX.
> +- reg:   Address and length of the register set for lcdif

s/lcdif/LCDIF/

> +- interrupts:Should contain lcdif interrupts

How many? 

> +- clocks:A list of phandle + clock-specifier pairs, one for each
> + entry in 'clock-names'.
> +- clock-names:   A list of clock names. For MXSFB it should contain:
> +- "pix" for the MXSFB block clock

MXSFB is not a h/w block. LCDIF is the name.

> +- (MX6SX-only) "axi", "disp_axi" for the bus interface clock
> +
> +Required sub-nodes:
> +  - port: The connection to an encoder chip.
> +
> +Example:
> +
> + lcdif1: lcdif at 0222 {

display-controller at ...

Drop the leading 0 too.

> + compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";

I'm not sure compatibility with mx28 is appropriate since you have the 
extra clocks. I guess if they don't need to be managed then it's okay.

> + reg = <0x0222 0x4000>;
> + interrupts = ;
> + clocks = < IMX6SX_CLK_LCDIF1_PIX>,
> +  < IMX6SX_CLK_LCDIF_APB>,
> +  < IMX6SX_CLK_DISPLAY_AXI>;
> + clock-names = "pix", "axi", "disp_axi";
> +
> + port {
> + parallel_out: endpoint {
> + remote-endpoint = <_in_parallel>;
> + };
> + };
> + };
> +
> +Old bindings:

s/Old/Deprecated/

> +=
>  Required properties:
>  - compatible:Should be "fsl,imx23-lcdif" for i.MX23.
>   Should be "fsl,imx28-lcdif" for i.MX28.
> -- 
> 2.10.2
> 

[PATCH 1/3] dt-bindings: mxsfb: Indentation cleanup

[Rob Herring]

On Mon, Nov 14, 2016 at 11:10:34AM +0100, Marek Vasut wrote:
> Clean up the ad-hoc indentation in the documentation, no functional change.
> 
> Signed-off-by: Marek Vasut 
> Cc: Rob Herring 
> Cc: Lucas Stach 
> Cc: Fabio Estevam 
> Cc: Shawn Guo 
> Cc: Daniel Vetter 
> Cc: devicetree at vger.kernel.org
> ---
>  Documentation/devicetree/bindings/display/mxsfb.txt | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Acked-by: Rob Herring 

[PATCH v2 2/5] drm: Set DRM connector link status property

[Manasi Navare]

In the usual working scenarios, this property is "Good".
If something fails during modeset, the DRM driver can
set the link status to "Bad", prune the mode list based on the
link rate/lane count fallback values and send  hotplug uevent
so that userspace that is aware of this property can take an
appropriate action by reprobing connectors and re triggering
a modeset to improve user experience and avoid black screens.
In case of userspace that is not aware of this link status
property, the user experience will be unchanged.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

v2:
* Update kernel doc, add lockdep_assert_held (Daniel Vetter)
Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_connector.c | 36 
 include/drm/drm_connector.h |  2 ++
 2 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d4e852f..b942d67 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -968,6 +968,42 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);

+/**
+ * drm_mode_connector_set_link_status_property - Set link status property of a 
connector
+ * @connector: drm connector
+ * @link_status: new value of link status property (0: Good, 1: Bad)
+ *
+ * In usual working scenario, this link status property will always be set to
+ * "GOOD". If something fails during or after a mode set, the kernel driver 
should
+ * prune the mode list based on new information, set this link status property 
to
+ * "BAD". The caller then needs to send a hotplug uevent for userspace to 
re-check
+ * the valid modes through GET_CONNECTOR_IOCTL and retry modeset.
+ *
+ * Note that a lot of existing userspace do not handle this property.
+ * If userspace is not aware of this property, the user experience is the same
+ * as it currently is. If the userspace is aware of the property, it has a 
chance
+ * to improve user experience by handling link training failures, avoiding 
black
+ * screens. The DRM driver can chose to not modify property and keep link 
status
+ * as "GOOD" always to keep the user experience same as it currently is.
+ *
+ * The reason for adding this property is to handle link training failures, but
+ * it is not limited to DP or link training. For example, if we implement
+ * asynchronous setcrtc, this property can be used to report any failures in 
that.
+ */
+void drm_mode_connector_set_link_status_property(struct drm_connector 
*connector,
+uint64_t link_status)
+{
+   struct drm_device *dev = connector->dev;
+
+   /* Make sure the mutex is grabbed */
+   lockdep_assert_held(>mode_config.mutex);
+   connector->link_status = link_status;
+   drm_object_property_set_value(>base,
+ dev->mode_config.link_status_property,
+ link_status);
+}
+EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
+
 int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
struct drm_property *property,
uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ad5c8b0..b7e2658 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
 int drm_mode_connector_update_edid_property(struct drm_connector *connector,
const struct edid *edid);
+void drm_mode_connector_set_link_status_property(struct drm_connector 
*connector,
+uint64_t link_status);

 /**
  * drm_for_each_connector - iterate over all connectors
-- 
1.9.1

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #11 from blffkyzp at sharklasers.com ---
Created attachment 127993
  --> https://bugs.freedesktop.org/attachment.cgi?id=127993=edit
crashlog 20160923

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/5e0d483d/attachment.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #10 from blffkyzp at sharklasers.com ---
Created attachment 127992
  --> https://bugs.freedesktop.org/attachment.cgi?id=127992=edit
crashlog 20160928

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/9676c38e/attachment.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from blffkyzp at sharklasers.com ---
Created attachment 127991
  --> https://bugs.freedesktop.org/attachment.cgi?id=127991=edit
crashlog 20161006

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/f197aeb3/attachment-0001.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from blffkyzp at sharklasers.com ---
Created attachment 127990
  --> https://bugs.freedesktop.org/attachment.cgi?id=127990=edit
crashlog 20161007

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/d913c9e3/attachment.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #7 from blffkyzp at sharklasers.com ---
Created attachment 127989
  --> https://bugs.freedesktop.org/attachment.cgi?id=127989=edit
crashlog 20161010

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/00b05603/attachment.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #6 from blffkyzp at sharklasers.com ---
Created attachment 127988
  --> https://bugs.freedesktop.org/attachment.cgi?id=127988=edit
crashlog 20161011

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/24b87519/attachment.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from blffkyzp at sharklasers.com ---
Created attachment 127987
  --> https://bugs.freedesktop.org/attachment.cgi?id=127987=edit
crashlog 20161025

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/6ce0db9a/attachment.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #4 from blffkyzp at sharklasers.com ---
Created attachment 127985
  --> https://bugs.freedesktop.org/attachment.cgi?id=127985=edit
crashlog 20161027

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/7518c2b3/attachment.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from blffkyzp at sharklasers.com ---
Created attachment 127984
  --> https://bugs.freedesktop.org/attachment.cgi?id=127984=edit
crashlog 20161107

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/aa6dd96f/attachment.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from blffkyzp at sharklasers.com ---
Created attachment 127983
  --> https://bugs.freedesktop.org/attachment.cgi?id=127983=edit
crashlog 20161115

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/cd3d7eb1/attachment-0001.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from blffkyzp at sharklasers.com ---
Created attachment 127982
  --> https://bugs.freedesktop.org/attachment.cgi?id=127982=edit
xorg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/b1fae5ac/attachment.html>

[Bug 98738] AMD E450| HD 6320 - crashing playback with kodi, maybe vdpau problem, mesa, r600

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98738
   Summary: AMD E450| HD 6320 - crashing playback with kodi, maybe
vdpau problem, mesa, r600
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: blffkyzp at sharklasers.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 127981
  --> https://bugs.freedesktop.org/attachment.cgi?id=127981=edit
dmesg

Since many kernel versions there is this one bug that happens irregular.
When wathcing live-tv on kodi with tv-headend and the TV-Channel changes the
frequency by itself and the live-tv follows (nothing that special in many
countries) then whole system crashes and kodi restarts.

I attached all logfiles i have saved. The last 2-3 ones (date in logfile) are
100% shure from this bug. The other ones "could" be from some other error, but
are most likely also from this bug.
xorg and dmesg logfiles are from lastest crash log.

Hardware is AMD E450 with build in HD6320 GPU.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/e3cad985/attachment.html>

[PATCH v11 2/3] drm/fence: add fence timeline to drm_crtc

[Gustavo Padovan]

2016-11-15 Chris Wilson :

> On Tue, Nov 15, 2016 at 10:57:35AM +0900, Gustavo Padovan wrote:
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 11780a9..0870de1 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -32,6 +32,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -739,9 +741,52 @@ struct drm_crtc {
> >  */
> > struct drm_crtc_crc crc;
> >  #endif
> > +
> > +   /**
> > +* @fence_context:
> > +*
> > +* timeline context used for fence operations.
> > +*/
> > +   unsigned int fence_context;
> > +
> > +   /**
> > +* @fence_lock:
> > +*
> > +* spinlock to protect the fences in the fence_context.
> > +*/
> > +
> > +   spinlock_t fence_lock;
> > +   /**
> > +* @fence_seqno:
> > +*
> > +* Seqno variable used as monotonic counter for the fences
> > +* created on the CRTC's timeline.
> > +*/
> > +   unsigned long fence_seqno;
> > +
> > +   /**
> > +* @timeline_name:
> > +*
> > +* The name of the CRTC's fence timeline.
> > +*/
> > +   char timeline_name[32];
> >  };
> >  
> >  /**
> > + * dma_crtc_fence_ops - fence ops for the drm_crtc timeline
> > + *
> > + * It contains the dma_fence_ops that should be called by the dma_fence
> > + * code. CRTC core should use this ops when initializing fences.
> > + */
> > +extern const struct dma_fence_ops drm_crtc_fence_ops;
> > +
> > +static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
> > +{
> > +   BUG_ON(fence->ops != _crtc_fence_ops);
> > +   return container_of(fence->lock, struct drm_crtc, fence_lock);
> > +}
> 
> If you are planning to export this for use by drivers, you are missing
> the EXPORT_SYMBOL(drm_crtc_fence_ops).

Drivers should not be using this, at least for now.

Gustavo

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-dae...@freedesktop.org]

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

--- Comment #45 from Gregor Münch  ---
No change with GIT of today. Slowdowns remain the same.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/c6489c6a/attachment.html>

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Tue, Nov 15, 2016 at 08:40:01PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
> On 11/15/2016 7:48 PM, Ville Syrjälä wrote:
> > On Tue, Nov 15, 2016 at 01:48:04PM +, Jose Abreu wrote:
> >> Hi,
> >>
> >>
> >>
> >> On 15-11-2016 10:52, Daniel Vetter wrote:
> >>> On Tue, Nov 15, 2016 at 03:36:02PM +0530, Sharma, Shashank wrote:
>  On 11/15/2016 3:30 PM, Daniel Vetter wrote:
> > On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
> >> On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> >>> On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
>  In any case, I guess addition of a cap for aspect ratio should fix 
>  the
>  current objections for this implementation.
> 
>  And I will keep it 0 by default, so that no aspect ratio information 
>  is
>  added until userspace sets the cap to 1 on its own.
> >>> Note that cap = needs new userspace.
> >>> -Daniel
> >> I guess you mean a new libdrm, so yes, I will add this new cap in 
> >> libdrm.
> >> Is that what you mean ?
> > Full stack solution, including enabling in an Xorg driver (or somewhere
> > else, we also have drm_hwcomposer as an option).
> >
> > And because that's probably going to take forever I'm leaning towards
> > revert again. Ville?
>  Not really, with a kernel cap implementation, the code will be as it was
>  before this patch series ( as good as revert )
>  And then when we want to enable it, we can add the corresponding Xserver
>  patch.
> 
>  I guess the current problem is if is breaks something in some userspace, 
>  but
>  if I am loading the flags only when the cap is set, we should be good.
> >>> This is not how new uabi gets merged, see:
> >>>
> >>> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> >>>
> >>> Userspace must be ready, or it will not land. The entire point of my
> >>> suggestion to just extend the display modes was to avoid the need for
> >>> userspace, but since existing userspace tries to be too clever already,
> >>> that didn't work out.
> >>> Thanks, Daniel
> >> @Ville
> >>
> >> I gave my tested by to these patches because I was facing the
> >> same scenario as Shashank: HDMI compliance. I believe we need to
> >> find a better way to handle this instead of just reverting. The
> >> HDMI spec is evolving so we also need to evolve. Of course that
> >> if this is breaking user space then we can revert and wait until
> >> we figure the best way to implement this.
> >>
> >> Anyway, this is a wild guess but I think the reason you are
> >> loosing modes may be because of
> >> drm_mode_equal_no_clocks_no_stereo() which is always expecting a
> >> aspect ratio flag to be defined. If there isn't one defined then
> >> it will unconditionally return false, even if the modes are
> >> equal.
> > I am well aware why we're losing modes. One reason is the mode equal
> > checks in the kernel as you suspect, the other is simply userspace
> > rejecting everything with the aspect ratio defined.
> >
> >> Can you please test this patch and see if it fixes on your
> >> side? WARNING: Not compile tested
> > I already did something like that earlier, except I rewrote the
> > entire messy mode matching code to use a cleaner flag based approach:
> >
> > git://github.com/vsyrjala/linux.git cea_f_vics
> >
> > But that doesn't solve the userspace ABI issue, and there are still a
> > lot of unanswered questions like:
> >
> > - Should we define aspect ratios for modes not directly coming from
> >edid_cea_modes[]?
> >
> >I beleive the answer must be "yes" at least in the cases where the
> >EDID lists the VIC even if we then skip adding the mode due to
> >already having it on the list via from another source. Perhaps we
> >want the aspect ratio even if the VIC wasn't directly specified?
> Wouldn't this break the whole concept of VIC, which is supposed to point 
> to a unique mode ?

Not sure what you're asking. We're already filtering out duplicates.

> > - Should we or should we not specify a VIC in the AVI infoframe
> >when the userspace doesn't support aspect ratio flags?
> This is a requirement of HDMI compliance tests, if userspace 
> supports/handles aspect ratio, it should set cap, and it will be set in 
> kernel flags
> and we should load that in AV IF.  Are you planning to suggest a better 
> way, in which this can be done ?

I was asking for the case where userspace doesn't specify the aspect
ratio on account of not understanding what aspect ratios are.

> >I would guess the answer is again "yes", and we should just pick the
> >preferred aspect ratio for the mode. At least that's closer to what
> >we've been doing up to now (except we just picked the first VIC, so
> >we might have picked the non-preferred aspect ratio actually). At
> >least having the VIC in the infoframe would seem like 

[Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

[Manasi Navare]

On Tue, Nov 15, 2016 at 08:53:27AM +0100, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> > In the usual working scenarios, this property is "Good".
> > If something fails during modeset, the DRM driver can
> > set the link status to "Bad", prune the mode list based on the
> > link rate/lane count fallback values and send  hotplug uevent
> > so that userspace that is aware of this property can take an
> > appropriate action by reprobing connectors and re triggering
> > a modeset to improve user experience and avoid black screens.
> > In case of userspace that is not aware of this link status
> > property, the user experience will be unchanged.
> > 
> > The reason for adding the property is to handle link training failures,
> > but it is not limited to DP or link training. For example, if we
> > implement asynchronous setcrtc, we can use this to report any failures
> > in that.
> > 
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> 
> One more thing I've forgotten: Just adding the kernel-doc isn't enough
> yet, we need to link this new property into the overall property
> documentations.
> 
> We already have a section "KMS Properties" in
> Documentation/gpu/drm-kms.rst, I think adding a new sub-section called
> "Standard Connector Properties" there with a definition list pointing to
> this function here would be best.
> -Daniel
>

What about other standard proprties like EDID etc? And could you give an
example for writing out a definition list there pointing to this function?
This .rst file currently consists of kernel::doc:: and paths for .h files

Manasi
> > ---
> >  drivers/gpu/drm/drm_connector.c | 38 ++
> >  include/drm/drm_connector.h |  2 ++
> >  2 files changed, 40 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index d4e852f..09f4093 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -968,6 +968,44 @@ int drm_mode_connector_update_edid_property(struct 
> > drm_connector *connector,
> >  }
> >  EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
> >  
> > +/**
> > + * drm_mode_connector_set_link_status_property - Set the link status 
> > property of
> > + * a connector to indicate status of link as a result of link training.
> > + * @connector: drm connector
> > + * @link_status: new value of link status property (0: Good, 1: Bad)
> > + *
> > + * In usual working scenario, this link status property will always be set 
> > to
> > + * "GOOD".
> > + * If something fails during or after a mode set, the kernel driver can 
> > set this
> > + * link status to "BAD", prune the mode list based on new information and 
> > send a
> > + * hotplug uevent for userspace to have it re-check the valid modes through
> > + * Get_connector and try again.
> > + *
> > + * If userspace is not aware of this property, the user experience is the 
> > same
> > + * as it currently is. If the userspace is aware of the property, it has a 
> > chance
> > + * to improve user experience by handling link training failures, avoiding 
> > black
> > + * screens. The DRM driver can chose to not modify property and keep link 
> > status
> > + * as "GOOD" always to keep the user experience same as it currently is.
> > + *
> > + * The reason for adding this property is to handle link training 
> > failures, but
> > + * it is not limited to DP or link training. For example, if we implement
> > + * asynchronous setcrtc, this property can be used to reportany failures 
> > in that.
> > + *
> > + * This function must be called from asynchronous work item.
> > + * Returns zero on success and negative errrno on failure.
> > + */
> > +int drm_mode_connector_set_link_status_property(struct drm_connector 
> > *connector,
> > +   uint64_t link_status)
> > +{
> > +   struct drm_device *dev = connector->dev;
> > +
> > +   connector->link_status = link_status;
> > +   return drm_object_property_set_value(>base,
> > +
> > dev->mode_config.link_status_property,
> > +link_status);
> > +}
> > +EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
> > +
> >  int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
> > struct drm_property *property,
> > uint64_t value)
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index ad5c8b0..ac76469 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct 
> > drm_connector *connector,
> >  int drm_mode_connector_set_tile_property(struct drm_connector *connector);
> >  int 

[Bug 97403] AMDGPU/Iceland Strange warnings on drm-next-4.9-wip

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Armin K  ---
(In reply to rezhu from comment #5)
> sorry, maybe the adaptor number is not 0 in your machine.
> can you just try the command:
> ./atiflash -ai
> 
> on my end: the result is 
> /home# ./atiflash -ai
> Adapter  0(BN=01, DN=00, PCIID=69011002, SSID=01341002)
> Asic Family:  Iceland
>  
> if you can get the adapter number,
> then try to save the atom bios by
> ./atiflash -s number file.name

OK, now I feel stupid. Your command is ran as root, I wasn't doing that.
However, there's another problem now:

# ./atiflash -ai
Adapter  0(BN=01, DN=00, PCIID=69001002, SSID=811C103C)
Asic Family:  Iceland
Flash Type :  R600 SPI(64 KB)
No VBIOS

# ./atiflash -s 0 hpatombios.bin
Failed to read ROM

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/e43d14f9/attachment.html>

[Bug 97403] AMDGPU/Iceland Strange warnings on drm-next-4.9-wip

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Armin K  ---
(In reply to rezhu from comment #5)
> sorry, maybe the adaptor number is not 0 in your machine.
> can you just try the command:
> ./atiflash -ai
> 
> on my end: the result is 
> /home# ./atiflash -ai
> Adapter  0(BN=01, DN=00, PCIID=69011002, SSID=01341002)
> Asic Family:  Iceland
>  
> if you can get the adapter number,
> then try to save the atom bios by
> ./atiflash -s number file.name

Hm, I'm currently on 4.8.6, does that matter? 4.9 is unusable right now, see
#98417

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/9c7ef853/attachment.html>

[drm-intel:topic/drm-misc 23/26] include/drm/drm_fb_cma_helper.h:45:13: warning: 'struct drm_plane_state' declared inside parameter list will not be visible outside of this definition or declaration

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
head:   35cf03508d8466ecc5199c9d609e74e85bec785b
commit: 14d7f96f90fb65c2ca0e0ac7df237e06ff001c29 [23/26] drm/fb_cma_helper: Add 
drm_fb_cma_prepare_fb() helper
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 14d7f96f90fb65c2ca0e0ac7df237e06ff001c29
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/vc4/vc4_drv.c:18:0:
>> include/drm/drm_fb_cma_helper.h:45:13: warning: 'struct drm_plane_state' 
>> declared inside parameter list will not be visible outside of this 
>> definition or declaration
 struct drm_plane_state *state);
^~~
>> include/drm/drm_fb_cma_helper.h:44:34: warning: 'struct drm_plane' declared 
>> inside parameter list will not be visible outside of this definition or 
>> declaration
int drm_fb_cma_prepare_fb(struct drm_plane *plane,
 ^

vim +45 include/drm/drm_fb_cma_helper.h

38  struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
39  struct drm_file *file_priv, const struct drm_mode_fb_cmd2 
*mode_cmd);
40  
41  struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct 
drm_framebuffer *fb,
42  unsigned int plane);
43  
  > 44  int drm_fb_cma_prepare_fb(struct drm_plane *plane,
  > 45struct drm_plane_state *state);
46  
47  #ifdef CONFIG_DEBUG_FS
48  struct seq_file;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 56846 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/0fcc9071/attachment-0001.gz>

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Tue, Nov 15, 2016 at 09:18:03AM -0500, Alex Deucher wrote:
> On Tue, Nov 15, 2016 at 9:03 AM, Daniel Vetter  wrote:
> > On Tue, Nov 15, 2016 at 03:54:42PM +0200, Ville Syrjälä wrote:
> >> On Tue, Nov 15, 2016 at 11:00:04AM +0100, Daniel Vetter wrote:
> >> > On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
> >> > > On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> >> > > > On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
> >> > > > > In any case, I guess addition of a cap for aspect ratio should fix 
> >> > > > > the
> >> > > > > current objections for this implementation.
> >> > > > >
> >> > > > > And I will keep it 0 by default, so that no aspect ratio 
> >> > > > > information is
> >> > > > > added until userspace sets the cap to 1 on its own.
> >> > > > Note that cap = needs new userspace.
> >> > > > -Daniel
> >> > > I guess you mean a new libdrm, so yes, I will add this new cap in 
> >> > > libdrm.
> >> > > Is that what you mean ?
> >> >
> >> > Full stack solution, including enabling in an Xorg driver (or somewhere
> >> > else, we also have drm_hwcomposer as an option).
> >> >
> >> > And because that's probably going to take forever I'm leaning towards
> >> > revert again. Ville?
> >>
> >> Yeah I guess we'll need to push the revert to avoid the regression.
> >> Trying to put in new client caps and whatnot after -rc5 doesn't seem
> >> like a viable option to me.
> >
> > Yeah, a few days left to get userspace in line is just not enough. Agreed
> > and reverts applied.
> >
> 
> Is there any way we can add the new CEA modes and worry about handling
> the aspect ratio stuff later?

I don't think there's any dependency between the two. Or am I
overlooking something?

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it

[Deucher, Alexander]

> -Original Message-
> From: Colin Ian King [mailto:colin.king at canonical.com]
> Sent: Tuesday, November 15, 2016 11:09 AM
> To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis,
> Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri-
> devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Subject: Re: [PATCH] drm/amd/powerplay: check if table_info is NULL before
> dereferencing it
> 
> On 15/11/16 15:49, Deucher, Alexander wrote:
> >> -Original Message-
> >> From: Colin King [mailto:colin.king at canonical.com]
> >> Sent: Tuesday, November 15, 2016 7:55 AM
> >> To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis,
> >> Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri-
> >> devel at lists.freedesktop.org
> >> Cc: linux-kernel at vger.kernel.org
> >> Subject: [PATCH] drm/amd/powerplay: check if table_info is NULL before
> >> dereferencing it
> >>
> >> From: Colin Ian King 
> >>
> >> table_info is being dereferenced before a null check, which implies
> >> a potential null pointer deference error.  Fix this by moving the null
> >> check of table_info to the start of smu7_get_evv_voltages to avoid
> >> potential null pointer deferencing.
> >>
> >> Found with static analysis by CoverityScan, CID 1377752
> >>
> >> Signed-off-by: Colin Ian King 
> >
> > NACK, this effectively reverts the patch.  This causes the function to exit
> early on asics where the table it NULL which is not what we want.  Whether
> the table exists or not is dependent on the table version and the feature
> caps for the chip which are checked before the table is dereferenced.  The
> NULL check in the top if clause is not strictly necessary and could be
> removed.
> >
> > Alex
> 
> OK, understood.  The part I'm missing is that we dereference table_info
> at the following statement:
> 
> if ((hwmgr->pp_table_version == PP_TABLE_V1)
> && !phm_get_sclk_for_voltage_evv(hwmgr,
> table_info->vddgfx_lookup_table, vv_id, ))
> 
> and later check if it is NULL. So, I can't see where table_info is being
> set other than the start of the function, so, either it can be null and
> hence we have a null ptr deference, or it's never null, in which case
> the check for NULL is redundant.

Yes, that check is redundant.  That is was I was referring to above.

Alex

> 
> Colin
> >
> >> ---
> >>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 ++
> >>  1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> index 28e748d..6798067 100644
> >> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> >> @@ -1473,6 +1473,8 @@ static int smu7_get_evv_voltages(struct
> pp_hwmgr
> >> *hwmgr)
> >>(struct phm_ppt_v1_information *)hwmgr->pptable;
> >>struct phm_ppt_v1_clock_voltage_dependency_table *sclk_table =
> >> NULL;
> >>
> >> +  if (table_info == NULL)
> >> +  return -EINVAL;
> >>
> >>for (i = 0; i < SMU7_MAX_LEAKAGE_COUNT; i++) {
> >>vv_id = ATOM_VIRTUAL_VOLTAGE_ID0 + i;
> >> @@ -1483,8 +1485,6 @@ static int smu7_get_evv_voltages(struct
> pp_hwmgr
> >> *hwmgr)
> >>table_info-
> >>> vddgfx_lookup_table, vv_id, )) {
> >>if (phm_cap_enabled(hwmgr-
> >>> platform_descriptor.platformCaps,
> >>
> >>PHM_PlatformCaps_ClockStretcher)) {
> >> -  if (table_info == NULL)
> >> -  return -EINVAL;
> >>sclk_table = table_info-
> >>> vdd_dep_on_sclk;
> >>
> >>for (j = 1; j < sclk_table->count; j++) 
> >> {
> >> @@ -1517,8 +1517,6 @@ static int smu7_get_evv_voltages(struct
> pp_hwmgr
> >> *hwmgr)
> >>table_info->vddc_lookup_table,
> >> vv_id, )) {
> >>if (phm_cap_enabled(hwmgr-
> >>> platform_descriptor.platformCaps,
> >>
> >>PHM_PlatformCaps_ClockStretcher)) {
> >> -  if (table_info == NULL)
> >> -  return -EINVAL;
> >>sclk_table = table_info-
> >>> vdd_dep_on_sclk;
> >>
> >>for (j = 1; j < sclk_table->count; j++) 
> >> {
> >> --
> >> 2.10.2
> >

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Tue, Nov 15, 2016 at 01:48:04PM +, Jose Abreu wrote:
> Hi,
> 
> 
> 
> On 15-11-2016 10:52, Daniel Vetter wrote:
> > On Tue, Nov 15, 2016 at 03:36:02PM +0530, Sharma, Shashank wrote:
> >> On 11/15/2016 3:30 PM, Daniel Vetter wrote:
> >>> On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
>  On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> > On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
> >> In any case, I guess addition of a cap for aspect ratio should fix the
> >> current objections for this implementation.
> >>
> >> And I will keep it 0 by default, so that no aspect ratio information is
> >> added until userspace sets the cap to 1 on its own.
> > Note that cap = needs new userspace.
> > -Daniel
>  I guess you mean a new libdrm, so yes, I will add this new cap in libdrm.
>  Is that what you mean ?
> >>> Full stack solution, including enabling in an Xorg driver (or somewhere
> >>> else, we also have drm_hwcomposer as an option).
> >>>
> >>> And because that's probably going to take forever I'm leaning towards
> >>> revert again. Ville?
> >> Not really, with a kernel cap implementation, the code will be as it was
> >> before this patch series ( as good as revert )
> >> And then when we want to enable it, we can add the corresponding Xserver
> >> patch.
> >>
> >> I guess the current problem is if is breaks something in some userspace, 
> >> but
> >> if I am loading the flags only when the cap is set, we should be good.
> > This is not how new uabi gets merged, see:
> >
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> >
> > Userspace must be ready, or it will not land. The entire point of my
> > suggestion to just extend the display modes was to avoid the need for
> > userspace, but since existing userspace tries to be too clever already,
> > that didn't work out.
> > Thanks, Daniel
> 
> @Ville
> 
> I gave my tested by to these patches because I was facing the
> same scenario as Shashank: HDMI compliance. I believe we need to
> find a better way to handle this instead of just reverting. The
> HDMI spec is evolving so we also need to evolve. Of course that
> if this is breaking user space then we can revert and wait until
> we figure the best way to implement this.
> 
> Anyway, this is a wild guess but I think the reason you are
> loosing modes may be because of
> drm_mode_equal_no_clocks_no_stereo() which is always expecting a
> aspect ratio flag to be defined. If there isn't one defined then
> it will unconditionally return false, even if the modes are
> equal.

I am well aware why we're losing modes. One reason is the mode equal
checks in the kernel as you suspect, the other is simply userspace
rejecting everything with the aspect ratio defined.

> Can you please test this patch and see if it fixes on your
> side? WARNING: Not compile tested

I already did something like that earlier, except I rewrote the
entire messy mode matching code to use a cleaner flag based approach:

git://github.com/vsyrjala/linux.git cea_f_vics

But that doesn't solve the userspace ABI issue, and there are still a
lot of unanswered questions like:

- Should we define aspect ratios for modes not directly coming from
  edid_cea_modes[]?

  I beleive the answer must be "yes" at least in the cases where the
  EDID lists the VIC even if we then skip adding the mode due to
  already having it on the list via from another source. Perhaps we
  want the aspect ratio even if the VIC wasn't directly specified?

- Should we or should we not specify a VIC in the AVI infoframe
  when the userspace doesn't support aspect ratio flags?

  I would guess the answer is again "yes", and we should just pick the
  preferred aspect ratio for the mode. At least that's closer to what
  we've been doing up to now (except we just picked the first VIC, so
  we might have picked the non-preferred aspect ratio actually). At
  least having the VIC in the infoframe would seem like a safer option
  than not having it, in case there's some cheap ass hardware that
  can't do anything sensible without being hand fed a VIC.

- How we should handle the aspect ratio in mode sorting?

  I think we want some sensible sorting order for these. Preferred
  aspect ratio first would seem like the obvious choice. I do realize
  that we don't sort based on 3D stereo flags either, but I thinking we
  probably should.

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it

[Colin Ian King]

On 15/11/16 15:49, Deucher, Alexander wrote:
>> -Original Message-
>> From: Colin King [mailto:colin.king at canonical.com]
>> Sent: Tuesday, November 15, 2016 7:55 AM
>> To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis,
>> Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri-
>> devel at lists.freedesktop.org
>> Cc: linux-kernel at vger.kernel.org
>> Subject: [PATCH] drm/amd/powerplay: check if table_info is NULL before
>> dereferencing it
>>
>> From: Colin Ian King 
>>
>> table_info is being dereferenced before a null check, which implies
>> a potential null pointer deference error.  Fix this by moving the null
>> check of table_info to the start of smu7_get_evv_voltages to avoid
>> potential null pointer deferencing.
>>
>> Found with static analysis by CoverityScan, CID 1377752
>>
>> Signed-off-by: Colin Ian King 
> 
> NACK, this effectively reverts the patch.  This causes the function to exit 
> early on asics where the table it NULL which is not what we want.  Whether 
> the table exists or not is dependent on the table version and the feature 
> caps for the chip which are checked before the table is dereferenced.  The 
> NULL check in the top if clause is not strictly necessary and could be 
> removed.
> 
> Alex

OK, understood.  The part I'm missing is that we dereference table_info
at the following statement:

if ((hwmgr->pp_table_version == PP_TABLE_V1)
&& !phm_get_sclk_for_voltage_evv(hwmgr,
table_info->vddgfx_lookup_table, vv_id, ))

and later check if it is NULL. So, I can't see where table_info is being
set other than the start of the function, so, either it can be null and
hence we have a null ptr deference, or it's never null, in which case
the check for NULL is redundant.

Colin
> 
>> ---
>>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> index 28e748d..6798067 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
>> @@ -1473,6 +1473,8 @@ static int smu7_get_evv_voltages(struct pp_hwmgr 
>> *hwmgr)
>>  (struct phm_ppt_v1_information *)hwmgr->pptable;
>>  struct phm_ppt_v1_clock_voltage_dependency_table *sclk_table =
>> NULL;
>>
>> +if (table_info == NULL)
>> +return -EINVAL;
>>
>>  for (i = 0; i < SMU7_MAX_LEAKAGE_COUNT; i++) {
>>  vv_id = ATOM_VIRTUAL_VOLTAGE_ID0 + i;
>> @@ -1483,8 +1485,6 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
>> *hwmgr)
>>  table_info-
>>> vddgfx_lookup_table, vv_id, )) {
>>  if (phm_cap_enabled(hwmgr-
>>> platform_descriptor.platformCaps,
>>
>>  PHM_PlatformCaps_ClockStretcher)) {
>> -if (table_info == NULL)
>> -return -EINVAL;
>>  sclk_table = table_info-
>>> vdd_dep_on_sclk;
>>
>>  for (j = 1; j < sclk_table->count; j++) 
>> {
>> @@ -1517,8 +1517,6 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
>> *hwmgr)
>>  table_info->vddc_lookup_table,
>> vv_id, )) {
>>  if (phm_cap_enabled(hwmgr-
>>> platform_descriptor.platformCaps,
>>
>>  PHM_PlatformCaps_ClockStretcher)) {
>> -if (table_info == NULL)
>> -return -EINVAL;
>>  sclk_table = table_info-
>>> vdd_dep_on_sclk;
>>
>>  for (j = 1; j < sclk_table->count; j++) 
>> {
>> --
>> 2.10.2
> 

[Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

[Manasi Navare]

On Tue, Nov 15, 2016 at 08:49:21AM +0100, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> > In the usual working scenarios, this property is "Good".
> > If something fails during modeset, the DRM driver can
> > set the link status to "Bad", prune the mode list based on the
> > link rate/lane count fallback values and send  hotplug uevent
> > so that userspace that is aware of this property can take an
> > appropriate action by reprobing connectors and re triggering
> > a modeset to improve user experience and avoid black screens.
> > In case of userspace that is not aware of this link status
> > property, the user experience will be unchanged.
> > 
> > The reason for adding the property is to handle link training failures,
> > but it is not limited to DP or link training. For example, if we
> > implement asynchronous setcrtc, we can use this to report any failures
> > in that.
> > 
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/drm_connector.c | 38 ++
> >  include/drm/drm_connector.h |  2 ++
> >  2 files changed, 40 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index d4e852f..09f4093 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -968,6 +968,44 @@ int drm_mode_connector_update_edid_property(struct 
> > drm_connector *connector,
> >  }
> >  EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
> >  
> > +/**
> > + * drm_mode_connector_set_link_status_property - Set the link status 
> > property of
> > + * a connector to indicate status of link as a result of link training.
> 
> iirc this continuation upsets kernel-doc. Did you build the docs and
> review them? You need to indent the 2nd line.
>

I built the docs and didnt see any issue with the docs, but I will shorten
the description.


> Also, might just shorten it to "set link status for a connector", details
> are for the text below.
> 
> > + * @connector: drm connector
> > + * @link_status: new value of link status property (0: Good, 1: Bad)
> > + *
> > + * In usual working scenario, this link status property will always be set 
> > to
> > + * "GOOD".
> 
> Unecessary linebbreak. Either make a full paragraph (empty line) or
> reflow, this here won't survivie kernel-doc formatting.
>

Agree, will fix this.


> > + * If something fails during or after a mode set, the kernel driver can 
> > set this
> > + * link status to "BAD", prune the mode list based on new information and 
> > send a
> 
> First need to prune the mode list, then set the property. Please reorder
> in your text.
> 
> > + * hotplug uevent for userspace to have it re-check the valid modes through
> > + * Get_connector and try again.
> 
> s/Get_connector/GET_CONNECTOR IOCTL/ is the more usual style.
> 
> > + *
> > + * If userspace is not aware of this property, the user experience is the 
> > same
> > + * as it currently is. If the userspace is aware of the property, it has a 
> > chance
> > + * to improve user experience by handling link training failures, avoiding 
> > black
> > + * screens. The DRM driver can chose to not modify property and keep link 
> > status
> > + * as "GOOD" always to keep the user experience same as it currently is.
> 
> Imo this paragraph isn't needed. Maybe just mention that old userspace
> exists:
>

I think keeping this paragraph is important to give the readers good idea of 
how this
will affect the user experience.

> "Note that a lot of existing userspace doesn't handle this property.
> Drivers can therefore not rely on userspace to fix up everything and
> should try to handle issues (like just re-training a link) without
> userspace's intervention. This should only be used when the current mode
> doesn't work any more, and userspace must select a different display
> mode."
>

But atleast the way i915 uses this is in both cases where current mode
does not get pruned but need sto be retried and also when current mode
is no longer valid and gets pruned and modeset is done at a lower mode.
But in either case if link training fails, this property is set to BAD.

Manasi 
> > + *
> > + * The reason for adding this property is to handle link training 
> > failures, but
> > + * it is not limited to DP or link training. For example, if we implement
> > + * asynchronous setcrtc, this property can be used to reportany failures 
> > in that.
> 
> s/reportany/report/
> 
> > + *
> > + * This function must be called from asynchronous work item.
> 
> This isn't true - it doesn't require an asynchronous work item, but the
> locking rules mean that it.
> 
> > + * Returns zero on success and negative errrno on failure.
> 
> Hm, why can this ever fail? Intuitively this should never fail, and hence
> we shouldn't need an error return value.
> 

Ok, yes agree 

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Tue, Nov 15, 2016 at 11:00:04AM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
> > On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> > > On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
> > > > In any case, I guess addition of a cap for aspect ratio should fix the
> > > > current objections for this implementation.
> > > > 
> > > > And I will keep it 0 by default, so that no aspect ratio information is
> > > > added until userspace sets the cap to 1 on its own.
> > > Note that cap = needs new userspace.
> > > -Daniel
> > I guess you mean a new libdrm, so yes, I will add this new cap in libdrm.
> > Is that what you mean ?
> 
> Full stack solution, including enabling in an Xorg driver (or somewhere
> else, we also have drm_hwcomposer as an option).
> 
> And because that's probably going to take forever I'm leaning towards
> revert again. Ville?

Yeah I guess we'll need to push the revert to avoid the regression.
Trying to put in new client caps and whatnot after -rc5 doesn't seem
like a viable option to me.

-- 
Ville Syrjälä
Intel OTC

[bug report] drm/amd/powerplay/smu7: fix checks in smu7_get_evv_voltages (v2)

[Dan Carpenter]

Hello Alex Deucher,

This is a semi-automatic email about new static checker warnings.

The patch 0f12f73c5175: "drm/amd/powerplay/smu7: fix checks in 
smu7_get_evv_voltages (v2)" from Nov 9, 2016, leads to the following 
Smatch complaint:

drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:1486 
smu7_get_evv_voltages()
 warn: variable dereferenced before check 'table_info' (see line 1483)

drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c
  1482  && !phm_get_sclk_for_voltage_evv(hwmgr,
  1483  
table_info->vddgfx_lookup_table, vv_id, )) {

^^^
  1484  if 
(phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
  1485  
PHM_PlatformCaps_ClockStretcher)) {
  1486  if (table_info == NULL)
^^
We can't reach this check unless we have already dereferenced
"table_info" so something must be wrong.

  1487  return -EINVAL;
  1488  sclk_table = 
table_info->vdd_dep_on_sclk;

regards,
dan carpenter

[PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it

[Deucher, Alexander]

> -Original Message-
> From: Colin King [mailto:colin.king at canonical.com]
> Sent: Tuesday, November 15, 2016 7:55 AM
> To: Deucher, Alexander; Koenig, Christian; David Airlie; Zhu, Rex; StDenis,
> Tom; Huang, Ray; Nils Wallménius; Baoyou Xie; dri-
> devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Subject: [PATCH] drm/amd/powerplay: check if table_info is NULL before
> dereferencing it
> 
> From: Colin Ian King 
> 
> table_info is being dereferenced before a null check, which implies
> a potential null pointer deference error.  Fix this by moving the null
> check of table_info to the start of smu7_get_evv_voltages to avoid
> potential null pointer deferencing.
> 
> Found with static analysis by CoverityScan, CID 1377752
> 
> Signed-off-by: Colin Ian King 

NACK, this effectively reverts the patch.  This causes the function to exit 
early on asics where the table it NULL which is not what we want.  Whether the 
table exists or not is dependent on the table version and the feature caps for 
the chip which are checked before the table is dereferenced.  The NULL check in 
the top if clause is not strictly necessary and could be removed.

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> index 28e748d..6798067 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> @@ -1473,6 +1473,8 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
> *hwmgr)
>   (struct phm_ppt_v1_information *)hwmgr->pptable;
>   struct phm_ppt_v1_clock_voltage_dependency_table *sclk_table =
> NULL;
> 
> + if (table_info == NULL)
> + return -EINVAL;
> 
>   for (i = 0; i < SMU7_MAX_LEAKAGE_COUNT; i++) {
>   vv_id = ATOM_VIRTUAL_VOLTAGE_ID0 + i;
> @@ -1483,8 +1485,6 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
> *hwmgr)
>   table_info-
> >vddgfx_lookup_table, vv_id, )) {
>   if (phm_cap_enabled(hwmgr-
> >platform_descriptor.platformCaps,
> 
>   PHM_PlatformCaps_ClockStretcher)) {
> - if (table_info == NULL)
> - return -EINVAL;
>   sclk_table = table_info-
> >vdd_dep_on_sclk;
> 
>   for (j = 1; j < sclk_table->count; j++) 
> {
> @@ -1517,8 +1517,6 @@ static int smu7_get_evv_voltages(struct pp_hwmgr
> *hwmgr)
>   table_info->vddc_lookup_table,
> vv_id, )) {
>   if (phm_cap_enabled(hwmgr-
> >platform_descriptor.platformCaps,
> 
>   PHM_PlatformCaps_ClockStretcher)) {
> - if (table_info == NULL)
> - return -EINVAL;
>   sclk_table = table_info-
> >vdd_dep_on_sclk;
> 
>   for (j = 1; j < sclk_table->count; j++) 
> {
> --
> 2.10.2

[PATCH] dma-buf: Provide wrappers for reservation's lock

[Chris Wilson]

Joonas complained that writing ww_mutex_lock(>lock, ctx) was too
intrusive compared to reservation_object_lock(resv, ctx);

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Joonas Lahtinen 
---
 include/linux/reservation.h | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index ed238961e1bf..9cfc0d857862 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -129,6 +129,40 @@ reservation_object_fini(struct reservation_object *obj)
 }

 /**
+ * reservation_object_lock - lock the reservation object
+ * @obj: the reservation object
+ * @ctx: the locking context
+ *
+ * Locks the reservation object for exclusive access and modification. Note,
+ * that the lock is only against other writers, readers will run concurrently
+ * with a writer under RCU. The seqlock is used to notify readers if they
+ * overlap with a writer.
+ *
+ * As the reservation object may be locked by multiple parties in an
+ * undefined order, a #ww_acquire_ctx is passed to unwind if a cycle
+ * is detected. See ww_mutex_lock() and ww_acquire_init(). A reservation
+ * object may be locked by itself by passing NULL as @ctx.
+ */
+static inline int
+reservation_object_lock(struct reservation_object *obj,
+   struct ww_acquire_ctx *ctx)
+{
+   return ww_mutex_lock(>lock, ctx);
+}
+
+/**
+ * reservation_object_unlock - unlock the reservation object
+ * @obj: the reservation object
+ *
+ * Unlocks the reservation object following exclusive access.
+ */
+static inline void
+reservation_object_unlock(struct reservation_object *obj)
+{
+   ww_mutex_unlock(>lock);
+}
+
+/**
  * reservation_object_get_excl - get the reservation object's
  * exclusive fence, with update-side lock held
  * @obj: the reservation object
-- 
2.10.2

[PATCH 2/2] ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers

[Sekhar Nori]

On Monday 14 November 2016 11:02 PM, Bartosz Golaszewski wrote:
> With the da8xx memory controller and master peripheral priority
> drivers merged and corresponding device tree changes in place we can
> now enable appropriate options by default.
> 
> Signed-off-by: Bartosz Golaszewski 

Applied to v4.10/defconfig

Thanks,
Sekhar

[PATCH] drm/color: document NULL values and default settings better

[Lionel Landwerlin]

Sorry for missing this.

Reviewed-by: Lionel Landwerlin 

On 26/09/16 10:04, Daniel Vetter wrote:
> Brought up in a discussion for enabling gamma on fsl-dcu.
>
> Cc: Ville Syrjälä 
> Cc: Meng Yi 
> Cc: Lionel Landwerlin 
> Signed-off-by: Daniel Vetter 
> ---
>   drivers/gpu/drm/drm_color_mgmt.c | 12 
>   1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index d28ffdd2b929..6543ebde501a 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -41,6 +41,10 @@
>*  nor use all the elements of the LUT (for example the hardware might
>*  choose to interpolate between LUT[0] and LUT[4]).
>*
> + *   Setting this to NULL (blob property value set to 0) means a
> + *   linear/pass-thru gamma table should be used. This is generally the
> + *   driver boot-up state too.
> + *
>* “DEGAMMA_LUT_SIZE”:
>*  Unsinged range property to give the size of the lookup table to be set
>*  on the DEGAMMA_LUT property (the size depends on the underlying
> @@ -54,6 +58,10 @@
>*  lookup through the gamma LUT. The data is interpreted as a struct
>*  _color_ctm.
>*
> + *   Setting this to NULL (blob property value set to 0) means a
> + *   unit/pass-thru matrix should be used. This is generally the driver
> + *   boot-up state too.
> + *
>* “GAMMA_LUT”:
>*  Blob property to set the gamma lookup table (LUT) mapping pixel data
>*  after the transformation matrix to data sent to the connector. The
> @@ -62,6 +70,10 @@
>*  nor use all the elements of the LUT (for example the hardware might
>*  choose to interpolate between LUT[0] and LUT[4]).
>*
> + *   Setting this to NULL (blob property value set to 0) means a
> + *   linear/pass-thru gamma table should be used. This is generally the
> + *   driver boot-up state too.
> + *
>* “GAMMA_LUT_SIZE”:
>*  Unsigned range property to give the size of the lookup table to be set
>*  on the GAMMA_LUT property (the size depends on the underlying hardware).

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

Regards

Shashank


On 11/15/2016 3:30 PM, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
>> On 11/15/2016 2:21 PM, Daniel Vetter wrote:
>>> On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
 In any case, I guess addition of a cap for aspect ratio should fix the
 current objections for this implementation.

 And I will keep it 0 by default, so that no aspect ratio information is
 added until userspace sets the cap to 1 on its own.
>>> Note that cap = needs new userspace.
>>> -Daniel
>> I guess you mean a new libdrm, so yes, I will add this new cap in libdrm.
>> Is that what you mean ?
> Full stack solution, including enabling in an Xorg driver (or somewhere
> else, we also have drm_hwcomposer as an option).
>
> And because that's probably going to take forever I'm leaning towards
> revert again. Ville?
Not really, with a kernel cap implementation, the code will be as it was 
before this patch series ( as good as revert )
And then when we want to enable it, we can add the corresponding Xserver 
patch.

I guess the current problem is if is breaks something in some userspace, 
but if I am loading the flags only when the cap is set, we should be good.

Regards
Shashank
> -Daniel

[PATCH 1/2] ARM: dts: da850: add the mstpri and ddrctl nodes

[Sekhar Nori]

On Monday 14 November 2016 11:02 PM, Bartosz Golaszewski wrote:
> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
> controller drivers to da850.dtsi.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  arch/arm/boot/dts/da850.dtsi | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 1bb1f6d..1635218 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -440,6 +440,11 @@
>   interrupts = <52>;
>   status = "disabled";
>   };
> +
> + mstpri: mstpri at 14110 {
> + compatible = "ti,da850-mstpri";
> + reg = <0x14110 0x0c>;
> + };

Instead of adding the node to the end, can you place it above the
cfgchip node to keep it sorted by reg. We have not really followed that
in this file. May be we should have. But lets start with this.

>   };
>   aemif: aemif at 6800 {
>   compatible = "ti,da850-aemif";
> @@ -451,4 +456,8 @@
> 1 0 0x6800 0x8000>;
>   status = "disabled";
>   };
> + ddrctl: ddrctl at b000 {
> + compatible = "ti,da850-ddr-controller";
> + reg = <0xb000 0xe8>;
> + };

Can you name the node memory-controller at b000? Thats the generic name
suggested by ePAPR 1.1 for memory controllers.

I could not find any naming suggestions for the bus master priority
controller above, but based on the pattern used for other controllers,
may be it should be called priority-controller at 14110 instead of mstpri at 
14110

Thanks,
Sekhar

[Intel-gfx] [PATCH 08/10] drm: Extract drm_mode_config.[hc]

[Daniel Vetter]

On Tue, Nov 15, 2016 at 10:32:14AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:23PM +0100, Daniel Vetter wrote:
> > And shuffle the kernel-doc structure a bit since drm_crtc.[hc] now
> > only contains CRTC-related functions and structures.
> > 
> > Signed-off-by: Daniel Vetter 
> > diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> > b/drivers/gpu/drm/drm_crtc_internal.h
> > index 3d23a473ec35..dad212140d56 100644
> > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > @@ -40,18 +40,25 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
> > int x, int y,
> > const struct drm_display_mode *mode,
> > const struct drm_framebuffer *fb);
> > -
> > -void drm_fb_release(struct drm_file *file_priv);
> > +int drm_crtc_register_all(struct drm_device *dev);
> > +void drm_crtc_unregister_all(struct drm_device *dev);
> >  
> >  /* IOCTLs */
> > -int drm_mode_getresources(struct drm_device *dev,
> > - void *data, struct drm_file *file_priv);
> >  int drm_mode_getcrtc(struct drm_device *dev,
> >  void *data, struct drm_file *file_priv);
> >  int drm_mode_setcrtc(struct drm_device *dev,
> >  void *data, struct drm_file *file_priv);
> >  
> > +
> > +/* drm_mode_config.c */
> > +/* IOCTLs */
> > +int drm_mode_getresources(struct drm_device *dev,
> > + void *data, struct drm_file *file_priv);
> > +
> > +
> >  /* drm_dumb_buffers.c */
> > +int drm_modeset_register_all(struct drm_device *dev);
> > +void drm_modeset_unregister_all(struct drm_device *dev);
> >  
> 
> I was worried for a moment.

Oops, fixed up while applying. Also noticed that I've forgotten to move
drm_mode_config_cleanup (besides moving it in headers). Chris was still
happy with the revised patch after checking some silliness on irc.
-Daniel

> 
> Reviewed-by: Chris Wilson 
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

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

[PATCH 02/10] drm/i915: Fixup kerneldoc includes

[Daniel Vetter]

On Tue, Nov 15, 2016 at 10:44:29AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:17PM +0100, Daniel Vetter wrote:
> > Would be great if everony could add
> 
> everyone
> 
> > $ make DOCBOOKS="" htmldocs
> > 
> > to their build scripts to catch these. 0day should also report them,
> > not sure why it failed to spot this.
> 
> "make IGNORE_DOCBOOKS=1 SPHINXOPTS=-W htmldocs" is that outdated?

IGNORE_DOCBOOKS=1 was renamed to DOCBOOKS="". And incremental builds (at
least in my experience here) are really fast with sphinx (a few seconds at
most). So should be good enough for a git rebase -x type checking.

> I don't often run it since it is too slow when checking hundreds of
> patches. Any chance of an incremental patch checker?

As long as you make sure you entirely avoid the old docbook horror show,
incremental builds should be real fast. The initial build can take a
while, but again if you avoid docbook it's reasonable fast imo. Full
kernel rebuilds are still much worse.
-Daniel

> > Fixes: b42fe9ca0a1e ("drm/i915: Split out i915_vma.c")
> > Cc: Tvrtko Ursulin 
> > Cc: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Signed-off-by: Daniel Vetter 
> Reviewed-by: Chris Wilson 
> 
> (I'm not even going to ask how it appears three times in the docs and
> how that all works :)
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCHv2 2/2] v4l: vsp1: Provide a writeback video device

[Geert Uytterhoeven]

On Fri, Nov 4, 2016 at 6:53 PM, Kieran Bingham
 wrote:
> --- a/drivers/media/platform/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/vsp1/vsp1_video.c

> +static void vsp1_video_wb_process_buffer(struct vsp1_video *video)
> +{

> +   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 };

drivers/media/platform/vsp1/vsp1_video.c:946:30: warning: missing
braces around initializer [-Wmissing-braces]
   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 };

drivers/media/platform/vsp1/vsp1_video.c:1008:22: warning: missing
braces around initializer [-Wmissing-braces]
  rwpf->mem = (struct vsp1_rwpf_memory) { 0 };

Either drop the "0":

mem = (struct vsp1_rwpf_memory) { };

or add an additional pair of braces:

mem = (struct vsp1_rwpf_memory) { { 0 } };

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
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

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Daniel Vetter]

On Tue, Nov 15, 2016 at 09:18:03AM -0500, Alex Deucher wrote:
> On Tue, Nov 15, 2016 at 9:03 AM, Daniel Vetter  wrote:
> > On Tue, Nov 15, 2016 at 03:54:42PM +0200, Ville Syrjälä wrote:
> >> On Tue, Nov 15, 2016 at 11:00:04AM +0100, Daniel Vetter wrote:
> >> > On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
> >> > > On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> >> > > > On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
> >> > > > > In any case, I guess addition of a cap for aspect ratio should fix 
> >> > > > > the
> >> > > > > current objections for this implementation.
> >> > > > >
> >> > > > > And I will keep it 0 by default, so that no aspect ratio 
> >> > > > > information is
> >> > > > > added until userspace sets the cap to 1 on its own.
> >> > > > Note that cap = needs new userspace.
> >> > > > -Daniel
> >> > > I guess you mean a new libdrm, so yes, I will add this new cap in 
> >> > > libdrm.
> >> > > Is that what you mean ?
> >> >
> >> > Full stack solution, including enabling in an Xorg driver (or somewhere
> >> > else, we also have drm_hwcomposer as an option).
> >> >
> >> > And because that's probably going to take forever I'm leaning towards
> >> > revert again. Ville?
> >>
> >> Yeah I guess we'll need to push the revert to avoid the regression.
> >> Trying to put in new client caps and whatnot after -rc5 doesn't seem
> >> like a viable option to me.
> >
> > Yeah, a few days left to get userspace in line is just not enough. Agreed
> > and reverts applied.
> >
> 
> Is there any way we can add the new CEA modes and worry about handling
> the aspect ratio stuff later?

The two reverts from Ville are just for the aspect ratio pass-thru stuff,
new cea modes should still be around. So exactly what you're asking for.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Daniel Vetter]

On Tue, Nov 15, 2016 at 03:54:42PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 15, 2016 at 11:00:04AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
> > > On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> > > > On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
> > > > > In any case, I guess addition of a cap for aspect ratio should fix the
> > > > > current objections for this implementation.
> > > > > 
> > > > > And I will keep it 0 by default, so that no aspect ratio information 
> > > > > is
> > > > > added until userspace sets the cap to 1 on its own.
> > > > Note that cap = needs new userspace.
> > > > -Daniel
> > > I guess you mean a new libdrm, so yes, I will add this new cap in libdrm.
> > > Is that what you mean ?
> > 
> > Full stack solution, including enabling in an Xorg driver (or somewhere
> > else, we also have drm_hwcomposer as an option).
> > 
> > And because that's probably going to take forever I'm leaning towards
> > revert again. Ville?
> 
> Yeah I guess we'll need to push the revert to avoid the regression.
> Trying to put in new client caps and whatnot after -rc5 doesn't seem
> like a viable option to me.

Yeah, a few days left to get userspace in line is just not enough. Agreed
and reverts applied.

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

[PATCH v9 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[sourab gupta]

On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> Gen graphics hardware can be set up to periodically write snapshots of
> performance counters into a circular buffer via its Observation
> Architecture and this patch exposes that capability to userspace via
> the
> i915 perf interface.
> 
> v2:
>Make sure to initialize ->specific_ctx_id when opening, without
>relying on _pin_notify hook, in case ctx already pinned.
> v3:
>Revert back to pinning ctx upfront when opening stream, removing
>need to hook in to pinning and to update OACONTROL on the fly.
> 
> Signed-off-by: Robert Bragg 
> Signed-off-by: Zhenyu Wang 
> Cc: Chris Wilson 
> Reviewed-by: Matthew Auld 
Have been working for quite some time on extending the interfaces per
the usecase of multiple concurrent streams (on different engines), and
infrastructure fits quite well for these usecases. With Chris' comments
addressed, the patch can have my r-b.
Reviewed-by: Sourab Gupta 

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

Regards

Shashank


On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
>> On 11/14/2016 10:15 PM, Ville Syrjälä wrote:
>>> On Mon, Nov 14, 2016 at 10:12:04PM +0530, Sharma, Shashank wrote:
 Regards

 Shashank


 On 11/14/2016 9:50 PM, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 09:37:18PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
>>> On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
 Regards
 Shashank
> the revert:
>
>   HDMI2 connected 1920x1080+0+0 (normal left inverted right x 
> axis y axis) 700mm x 390mm
> -   1920x1080 60.00*+
> -   1920x1080i60.0050.00
> +   1920x1080 60.00*+  50.0059.9430.0025.0024.00  
>   29.9723.98
> +   1920x1080i60.0050.0059.94
>  1600x1200 60.00
>  1680x1050 59.88
>  1280x1024 75.0260.02
> @@ -13,30 +13,29 @@
>  1360x768  60.02
>  1280x800  59.91
>  1152x864  75.00
> -   1280x720  60.0050.00
> +   1280x720  60.0050.0059.94
>  1024x768  75.0370.0760.00
>  832x624   74.55
>  800x600   72.1975.0060.32
> -   640x480   75.0072.8166.6759.94
> +   720x576   50.00
> +   720x480   60.0059.94
> +   640x480   75.0072.8166.6760.0059.94
>  720x400   70.08
 None of these aspect ratios are new modes / new aspect ratios from HDMI
 2.0/CEA-861-F
 These are the existing modes, and should be independent of reverted
 patches.
>>> They're affected because your patches changed them by adding the aspect
>>> ratio flags to them.
>> Yes, But they are independent of reverted patch, which adds aspect ratio
>> for HDMI 2.0 ratios (64:27 and 256:135)
> The second patch had to be reverted so that the first patch would revert
> cleanly.
>
> This was with sna, which does this:
>   #define KNOWN_MODE_FLAGS ((1<<14)-1)
>   if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
>   mode->status = MODE_BAD; /* unknown flags => unhandled 
> */
> so all the modes with an aspect ratio just vanished.
>
> -modesetting and -ati on the other hand just copy over the unknown
> bits into the xrandr mode structure, which sounds dubious at best:
>   mode->Flags = kmode->flags; //& FLAG_BITS;
> I've not checked what damage it can actually cause.
>
>
> It looks like a few modes disappeared from the kernel's mode list
> as well, presumably because some cea modes in the list originated from
> DTDs and whanot so they don't have an aspect ratio and that causes
> add_alternate_cea_modes() to ignore them. So not populating an aspect
> ratio for cea modes originating from a source other than
> edid_cea_modes[] looks like another bug to me as well.
 I am writing a patch series to cap the aspect ratio implementation 
 under
 a drm_cap_hdmi2_aspect_ratios
 This is how its going to work (inspired from the 2D/stereo series from
 damien L)

 - Add a new capability hdmi2_ar
>>> It should be just a generic "expose aspect ratio flags to userspace?"
>> Makes sense, in this way we can even revert the aspect_ratio property
>> for HDMI connector, as discussed during
>> the code review sessions of this patch series. In this way, when kernel
>> will expose the aspect ratios, it will either
>> do the aspect ratios as per EDID, or wont.
 - by default parsing the new hdmi 2.0 aspect ratio will be disabled
 under check of this cap
 - during bootup time, while initializing the display, a userspace can
 get_cap on the hdmi2_aspect_ratio
 - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
 kernel will expose these aspect ratios
> Another bug I think might be the ordering of the modes with aspect 
> ratio
> specified. IIRC the spec says that the preferred aspect ratio should 
> be
> listed first in the EDID, but I don't think we preserve that ordering
> in the final mode list. I guess we could fix that by somehow noting
> which aspect ratio is preferred and sort based on that, or we try to
> preserve the order from the EDID until we're ready to sort, and then 
> do
> the sorting with a stable algorithm.

[Intel-gfx] [PATCH 02/12] tests/kms_atomic_transition: don't assume max pipes

[Tomeu Vizoso]

On 15 November 2016 at 09:01, Daniel Vetter  wrote:
> On Mon, Nov 14, 2016 at 06:59:16PM +0900, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> Signed-off-by: Gustavo Padovan 
>> ---
>>  tests/kms_atomic_transition.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
>> index e693c88..8b26b53 100644
>> --- a/tests/kms_atomic_transition.c
>> +++ b/tests/kms_atomic_transition.c
>> @@ -404,7 +404,7 @@ static void run_modeset_tests(igt_display_t *display, 
>> int howmany, bool nonblock
>>  {
>>   struct igt_fb fbs[2];
>>   int i, j;
>> - unsigned iter_max = 1 << I915_MAX_PIPES;
>> + unsigned iter_max = 1 << display->n_pipes;
>
> Didn't Tomeu have some patch series to fix these all up?

Don't remember, and couldn't find any within my local branches. Maybe
Robert? But I'm adding it to my backlog anyway.

Regards,

Tomeu

> -Daniel
>
>>   igt_pipe_crc_t *pipe_crcs[I915_MAX_PIPES];
>>   igt_output_t *output;
>>   unsigned width = 0, height = 0;
>> --
>> 2.5.5
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98645] X Freeze while rendering video with multiple displays and TearFree enabled

[bugzilla-dae...@freedesktop.org]

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

--- Comment #7 from Alex Deucher  ---
MSI problems tend to be platform problems.  What system is this?  What system
chipset?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/46691c55/attachment.html>

[PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels

[Rob Herring]

On Mon, Nov 14, 2016 at 8:11 PM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Monday 14 Nov 2016 19:40:26 Rob Herring wrote:
>> On Mon, Oct 17, 2016 at 7:42 AM, Laurent Pinchart wrote:
>> > On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
>> >> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
>> >>> On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
>>  On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
>> > LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>> > Multiple incompatible data link layers have been used over time to
>> > transmit image data to LVDS panels. This binding supports display
>> > panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
>> > specifications.

[...]

>> >>> Furthermore, LVDS data organization is controlled by the combination of
>> >>> both data-mapping and data-mirror. It makes little sense from my point
>> >>> of view to handle one as part of the compatible string and the other one
>> >>> as a separate property.
>> >>>
>>  > +Optional properties:
>>  > +- label: a symbolic name for the panel
>> 
>>  Could be for any panel or display connector.
>> >>>
>> >>> Yes, but I'm not sure to understand how that's relevant :-)
>> >>
>> >> Meaning it should be a common property.
>> >
>> > Sure. So you expect me to reorganize all the panels and connectors DT
>> > bindings in order to get this one merged ? :-)
>>
>> No, because I don't think label is widely defined. Just put it in a
>> common place and reference it. Any other panels can be fixed later.
>> Really, the "simple panel" binding should probably morph into the
>> common binding.
>
> The "label" property is actually defined in the "Devicetree Specification,

Yes, so is reg, interrupts, etc. but we still list when those are used.

> Release 0.1" as recently published on devicetree.org. Where would you like me
> to define it in the bindings ?

Just split things into 2 files. Move everything that's used in other
panel bindings (label, width-mm, ports, etc.) to a panel/common.txt.
Then in lvds-panel.txt, it just refers to common.txt and is just the
LVDS specific things. Bonus points if simple-panel (should just go
away), panel-dpi, panel-dsi-cm are converted.

>> > +- avdd-supply: reference to the regulator that powers the panel
>> > analog supply
>> > +- dvdd-supply: reference to the regulator that powers the panel
>> > digital supply

I would not be against these being common either. It's somewhat better
than simple-panel's "power-supply" property.

>> 
>>  Which one has to be powered on first, what voltage, and with what time
>>  in between? This is why "generic" or "simple" bindings don't work.
>> >>>
>> >>> The above-mentioned specifications also define connectors, pinouts and
>> >>> power supplies, but many LVDS panels compatible with the LVDS physical
>> >>> and data layers use a different connector with small differences in
>> >>> power supplies.
>> >>>
>> >>> I believe the voltage is irrelevant here, it doesn't need to be
>> >>> controlled by the operating system. Power supplies order and timing is
>> >>> relevant, I'll investigate the level of differences between panels. I'm
>> >>> also fine with dropping those properties for now.
>> >>
>> >> Whether you have control of the supplies is dependent on the board.
>> >> Dropping them is just puts us in the simple binding trap. The simple
>> >> bindings start out that way and then people keep adding to them.
>> >
>> > Damn, you can't be fooled easily ;-)
>>
>> I guess you can count all the simple bindings to see how many times I
>> can be fooled. :)
>>
>> > On a more serious note, I'd like to design the bindings in a way that
>> > wouldn't require adding device-specific code in the driver for each panel
>> > model, given that in most cases power supply handling will be generic.
>> > What's your opinion about a generic power supply model that would be used
>> > in the default case, with the option to override it with device-specific
>> > code when needed ?
>>
>> I don't agree. Read Thierry's post on the subject[1].
>
> I'm not sure you understood me correctly (and writing a clarification at
> 4:00am might not help :-)). My point here is that a fair number of panels
> don't care about power sequencing and have no control GPIOs (that's certainly
> the case of the two Mitsubishi panels I use here that have a single power
> supply - good luck trying to convince me that this needs to be sequenced :-) -
> and no enable or reset control pin). This kind of panel should obviously be
> modelled in DT with both a specific and a generic ("panel-lvds") compatible
> string, to ensure that we'll have enough information available on the
> operating system side to control the panel properly. The power supply(ies)
> should be documented in relation to the specific compatible string and not
> mentioned by the generic bindings (whether that should go in one or multiple
> text 

[Bug 98492] X-Plane 10 Core Dumping when using Real-Weather or any clouds

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Nicolai Hähnle  ---
So I'm confused, you're seeing hangs now?

Judging by another X-Plane 10-related bug report, you should run with the
MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory environment variable setting.

If you're still seeing crashes, please install debug symbols for the radeonsi
driver and run in gdb. I.e.: `MESA_EXTENSION_OVERRIDE=-GL_AMD_pinned_memory gdb
X-Plane-x86_64`, and then `run --force_run`.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/d2a5fc78/attachment.html>

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Jose Abreu]

Hi,



On 15-11-2016 10:52, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 03:36:02PM +0530, Sharma, Shashank wrote:
>> On 11/15/2016 3:30 PM, Daniel Vetter wrote:
>>> On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
 On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
>> In any case, I guess addition of a cap for aspect ratio should fix the
>> current objections for this implementation.
>>
>> And I will keep it 0 by default, so that no aspect ratio information is
>> added until userspace sets the cap to 1 on its own.
> Note that cap = needs new userspace.
> -Daniel
 I guess you mean a new libdrm, so yes, I will add this new cap in libdrm.
 Is that what you mean ?
>>> Full stack solution, including enabling in an Xorg driver (or somewhere
>>> else, we also have drm_hwcomposer as an option).
>>>
>>> And because that's probably going to take forever I'm leaning towards
>>> revert again. Ville?
>> Not really, with a kernel cap implementation, the code will be as it was
>> before this patch series ( as good as revert )
>> And then when we want to enable it, we can add the corresponding Xserver
>> patch.
>>
>> I guess the current problem is if is breaks something in some userspace, but
>> if I am loading the flags only when the cap is set, we should be good.
> This is not how new uabi gets merged, see:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
>
> Userspace must be ready, or it will not land. The entire point of my
> suggestion to just extend the display modes was to avoid the need for
> userspace, but since existing userspace tries to be too clever already,
> that didn't work out.
> Thanks, Daniel

@Ville

I gave my tested by to these patches because I was facing the
same scenario as Shashank: HDMI compliance. I believe we need to
find a better way to handle this instead of just reverting. The
HDMI spec is evolving so we also need to evolve. Of course that
if this is breaking user space then we can revert and wait until
we figure the best way to implement this.

Anyway, this is a wild guess but I think the reason you are
loosing modes may be because of
drm_mode_equal_no_clocks_no_stereo() which is always expecting a
aspect ratio flag to be defined. If there isn't one defined then
it will unconditionally return false, even if the modes are
equal. Can you please test this patch and see if it fixes on your
side? WARNING: Not compile tested

Best regards,
Jose Miguel Abreu

diff --git a/drivers/gpu/drm/drm_modes.c
b/drivers/gpu/drm/drm_modes.c
index ce6eeda..a7973a9 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -971,6 +971,27 @@ bool drm_mode_equal_no_clocks(const struct
drm_display_mode *mode1, const struct
 }
 EXPORT_SYMBOL(drm_mode_equal_no_clocks);

+static bool drm_mode_par_valid(const struct drm_display_mode *mode)
+{
+   switch (mode->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   case HDMI_PICTURE_ASPECT_16_9:
+   case HDMI_PICTURE_ASPECT_64_27:
+   case HDMI_PICTURE_ASPECT_256_135:
+   return true;
+   default:
+   return false;
+   }
+}
+
+static bool drm_mode_equal_par(const struct drm_display_mode *mode1,
+  const struct drm_display_mode *mode2)
+{
+   if (!drm_mode_par_valid(mode1) || !drm_mode_par_valid(mode2))
+   return true;
+   return mode1->picture_aspect_ratio ==
mode2->picture_aspect_ratio;
+}
+
 /**
  * drm_mode_equal_no_clocks_no_stereo - test modes for equality
  * @mode1: first mode
@@ -995,7 +1016,7 @@ bool
drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode
*mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
-   mode1->picture_aspect_ratio ==
mode2->picture_aspect_ratio &&
+   drm_mode_equal_par(mode1, mode2) &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;

[Bug 97980] [amdgpu] New kernel warning during shutdown

[bugzilla-dae...@freedesktop.org]

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

--- Comment #14 from Mike Lothian  ---
I've tested this again with the latest drm-next-4.10-wip branch and I still get
the same errors

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/29745a90/attachment.html>

[Intel-gfx] [PATCH 07/10] drm/print: Move kerneldoc next to definition

[Daniel Vetter]

On Tue, Nov 15, 2016 at 12:53:48PM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 10:37:26AM +, Chris Wilson wrote:
> > On Mon, Nov 14, 2016 at 12:58:22PM +0100, Daniel Vetter wrote:
> > > kerneldoc expects the comment next to definitions, otherwise it can't
> > > pick up exported vs. internal stuff.
> > > 
> > > This fixes a warning from the doc build done with:
> > > 
> > > $ make DOCBOOKS="" htmldocs
> > > 
> > > Fixes: d8187177b0b1 ("drm: add helper for printing to log or seq_file")
> > > Cc: Rob Clark 
> > > Cc: Sean Paul 
> > > Signed-off-by: Daniel Vetter 
> > 
> > Oh well, I liked the practice of having interface descriptions in the
> > headers. If they are in the body, I may as well just read the code.
> 
> I'm divided. On one hand it makes it more easily readable for users of the
> code Otoh having it closer might increase the odds that it's
> not forgotten when the semantics change. Personally I just have lots of
> windows open, with both code and rendered docs ...

And merged up to this one, with addressing your feedback re copyright
notices. Somehow there's a nasty conflict with the extraction in patch 8
that I haven't figured out yet, needs more coffee. Thanks for your review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/amd/powerplay: check if table_info is NULL before dereferencing it

[Colin King]

From: Colin Ian King 

table_info is being dereferenced before a null check, which implies
a potential null pointer deference error.  Fix this by moving the null
check of table_info to the start of smu7_get_evv_voltages to avoid
potential null pointer deferencing.

Found with static analysis by CoverityScan, CID 1377752

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 28e748d..6798067 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -1473,6 +1473,8 @@ static int smu7_get_evv_voltages(struct pp_hwmgr *hwmgr)
(struct phm_ppt_v1_information *)hwmgr->pptable;
struct phm_ppt_v1_clock_voltage_dependency_table *sclk_table = NULL;

+   if (table_info == NULL)
+   return -EINVAL;

for (i = 0; i < SMU7_MAX_LEAKAGE_COUNT; i++) {
vv_id = ATOM_VIRTUAL_VOLTAGE_ID0 + i;
@@ -1483,8 +1485,6 @@ static int smu7_get_evv_voltages(struct pp_hwmgr *hwmgr)

table_info->vddgfx_lookup_table, vv_id, )) {
if 
(phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,

PHM_PlatformCaps_ClockStretcher)) {
-   if (table_info == NULL)
-   return -EINVAL;
sclk_table = 
table_info->vdd_dep_on_sclk;

for (j = 1; j < sclk_table->count; j++) 
{
@@ -1517,8 +1517,6 @@ static int smu7_get_evv_voltages(struct pp_hwmgr *hwmgr)
table_info->vddc_lookup_table, vv_id, 
)) {
if 
(phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,

PHM_PlatformCaps_ClockStretcher)) {
-   if (table_info == NULL)
-   return -EINVAL;
sclk_table = 
table_info->vdd_dep_on_sclk;

for (j = 1; j < sclk_table->count; j++) 
{
-- 
2.10.2

[Intel-gfx] [PATCH 07/10] drm/print: Move kerneldoc next to definition

[Daniel Vetter]

On Tue, Nov 15, 2016 at 10:37:26AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:22PM +0100, Daniel Vetter wrote:
> > kerneldoc expects the comment next to definitions, otherwise it can't
> > pick up exported vs. internal stuff.
> > 
> > This fixes a warning from the doc build done with:
> > 
> > $ make DOCBOOKS="" htmldocs
> > 
> > Fixes: d8187177b0b1 ("drm: add helper for printing to log or seq_file")
> > Cc: Rob Clark 
> > Cc: Sean Paul 
> > Signed-off-by: Daniel Vetter 
> 
> Oh well, I liked the practice of having interface descriptions in the
> headers. If they are in the body, I may as well just read the code.

I'm divided. On one hand it makes it more easily readable for users of the
code Otoh having it closer might increase the odds that it's
not forgotten when the semantics change. Personally I just have lots of
windows open, with both code and rendered docs ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[patch] drm: zte: checking for NULL instead of IS_ERR()

[Dan Carpenter]

drm_dev_alloc() never returns NULL, it only returns error pointers on
error.

Fixes: 0a886f59528a ("drm: zte: add initial vou drm driver")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index abc8099..3e76f72 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -107,8 +107,8 @@ static int zx_drm_bind(struct device *dev)
return -ENOMEM;

drm = drm_dev_alloc(_drm_driver, dev);
-   if (!drm)
-   return -ENOMEM;
+   if (IS_ERR(drm))
+   return PTR_ERR(drm);

drm->dev_private = priv;
dev_set_drvdata(dev, drm);

[Intel-gfx] [PATCH 01/10] drm: Extract drm_dumb_buffers.c

[Daniel Vetter]

On Tue, Nov 15, 2016 at 10:42:08AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:16PM +0100, Daniel Vetter wrote:
> > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c 
> > b/drivers/gpu/drm/drm_dumb_buffers.c
> > new file mode 100644
> > index ..4b4364b61c8d
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> > @@ -0,0 +1,135 @@
> > +/*
> > + * Copyright (c) 2016 Intel Corporation
> 
> I've mentioned this elsewhere, but we should also retain the original
> copyright statements for the code we are copying.

Given that we're super-not-dutiful with updating them I figured point at
git log with rename detection is good enough. But fixed (same for the
later ones).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/fb_cma_helper: Add missing forward declaration

[Daniel Vetter]

On Tue, Nov 15, 2016 at 11:55:29AM +0100, Marek Vasut wrote:
> Add missing forward declaration for struct drm_plane and drm_plane_state,
> which causes the following warning in the VC4 driver (can be replicated
> by building using bcm2835_defconfig):
> 
> In file included from drivers/gpu/drm/vc4/vc4_drv.c:18:0:
> include/drm/drm_fb_cma_helper.h:45:13: warning: ‘struct drm_plane_state’ 
> declared inside parameter list will not be visible outside of this definition 
> or declaration
>   struct drm_plane_state *state);
>  ^~~
> include/drm/drm_fb_cma_helper.h:44:34: warning: ‘struct drm_plane’ 
> declared inside parameter list will not be visible outside of this definition 
> or declaration
>  int drm_fb_cma_prepare_fb(struct drm_plane *plane,
> 
> Signed-off-by: Marek Vasut 
> Cc: Daniel Vetter 

Applied to drm-misc, thx for the quick fixup.
-Daniel

> ---
>  include/drm/drm_fb_cma_helper.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
> index cc82c73..3b00f64 100644
> --- a/include/drm/drm_fb_cma_helper.h
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -12,6 +12,8 @@ struct drm_fb_helper;
>  struct drm_device;
>  struct drm_file;
>  struct drm_mode_fb_cmd2;
> +struct drm_plane;
> +struct drm_plane_state;
>  
>  struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
>   unsigned int preferred_bpp, unsigned int num_crtc,
> -- 
> 2.10.2
> 

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

[PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes

[Bartosz Golaszewski]

Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
controller drivers to da850.dtsi.

Signed-off-by: Bartosz Golaszewski 
---
v1 -> v2:
- moved the priority controller node above the cfgchip node
- renamed added nodes to better reflect their purpose

 arch/arm/boot/dts/da850.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1bb1f6d..412eec6 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -210,6 +210,10 @@
};

};
+   prictrl: priority-controller at 14110 {
+   compatible = "ti,da850-mstpri";
+   reg = <0x14110 0x0c>;
+   };
cfgchip: chip-controller at 1417c {
compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
reg = <0x1417c 0x14>;
@@ -451,4 +455,8 @@
  1 0 0x6800 0x8000>;
status = "disabled";
};
+   memctrl: memory-controller at b000 {
+   compatible = "ti,da850-ddr-controller";
+   reg = <0xb000 0xe8>;
+   };
 };
-- 
2.9.3

[Intel-gfx] [PATCH 01/10] drm: Extract drm_dumb_buffers.c

[Chris Wilson]

On Tue, Nov 15, 2016 at 12:47:31PM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 10:42:08AM +, Chris Wilson wrote:
> > On Mon, Nov 14, 2016 at 12:58:16PM +0100, Daniel Vetter wrote:
> > > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c 
> > > b/drivers/gpu/drm/drm_dumb_buffers.c
> > > new file mode 100644
> > > index ..4b4364b61c8d
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> > > @@ -0,0 +1,135 @@
> > > +/*
> > > + * Copyright (c) 2016 Intel Corporation
> > 
> > I've mentioned this elsewhere, but we should also retain the original
> > copyright statements for the code we are copying.
> 
> Given that we're super-not-dutiful with updating them I figured point at
> git log with rename detection is good enough. But fixed (same for the
> later ones).

I agree that git gives more traceablity to authorship (if not
necessarily to whom that author has transfered the copyright for the work),
but I feel if we are adding a blanket copyright clause we should
recognise the validity of the earlier ones as well.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 02/10] drm/i915: Fixup kerneldoc includes

[Daniel Vetter]

On Tue, Nov 15, 2016 at 10:44:29AM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 12:58:17PM +0100, Daniel Vetter wrote:
> > Would be great if everony could add
> 
> everyone
> 
> > $ make DOCBOOKS="" htmldocs
> > 
> > to their build scripts to catch these. 0day should also report them,
> > not sure why it failed to spot this.
> 
> "make IGNORE_DOCBOOKS=1 SPHINXOPTS=-W htmldocs" is that outdated?

IGNORE_DOCBOOKS=1 was renamed to DOCBOOKS="". And incremental builds (at
least in my experience here) are really fast with sphinx (a few seconds at
most). So should be good enough for a git rebase -x type checking.

> I don't often run it since it is too slow when checking hundreds of
> patches. Any chance of an incremental patch checker?

As long as you make sure you entirely avoid the old docbook horror show,
incremental builds should be real fast. The initial build can take a
while, but again if you avoid docbook it's reasonable fast imo. Full
kernel rebuilds are still much worse.

> > Fixes: b42fe9ca0a1e ("drm/i915: Split out i915_vma.c")
> > Cc: Tvrtko Ursulin 
> > Cc: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > Signed-off-by: Daniel Vetter 
> Reviewed-by: Chris Wilson 
> 
> (I'm not even going to ask how it appears three times in the docs and
> how that all works :)

The follow-up paramaters are crucial: First one pulls in function
kernel-docs only, other 2 pull in specific DOC: comment sections.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 185681] amdgpu: powerplay initialization failed

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #18 from René Linder  ---
Created attachment 244601
  --> https://bugzilla.kernel.org/attachment.cgi?id=244601=edit
Teted with latest Patches on 4.9rc4

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 185681] amdgpu: powerplay initialization failed

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #17 from René Linder  ---
For Me the new Patches works fine ... except the message it didn't found
default frequency see dmesg log. But re clocking and everything i have on my
notebook works fine.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/fb_cma_helper: Add missing forward declaration

[Marek Vasut]

Add missing forward declaration for struct drm_plane and drm_plane_state,
which causes the following warning in the VC4 driver (can be replicated
by building using bcm2835_defconfig):

In file included from drivers/gpu/drm/vc4/vc4_drv.c:18:0:
include/drm/drm_fb_cma_helper.h:45:13: warning: ‘struct drm_plane_state’ 
declared inside parameter list will not be visible outside of this definition 
or declaration
  struct drm_plane_state *state);
 ^~~
include/drm/drm_fb_cma_helper.h:44:34: warning: ‘struct drm_plane’ declared 
inside parameter list will not be visible outside of this definition or 
declaration
 int drm_fb_cma_prepare_fb(struct drm_plane *plane,

Signed-off-by: Marek Vasut 
Cc: Daniel Vetter 
---
 include/drm/drm_fb_cma_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index cc82c73..3b00f64 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -12,6 +12,8 @@ struct drm_fb_helper;
 struct drm_device;
 struct drm_file;
 struct drm_mode_fb_cmd2;
+struct drm_plane;
+struct drm_plane_state;

 struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
unsigned int preferred_bpp, unsigned int num_crtc,
-- 
2.10.2

[drm-intel:topic/drm-misc 23/26] include/drm/drm_fb_cma_helper.h:45:13: warning: 'struct drm_plane_state' declared inside parameter list will not be visible outside of this definition or declaration

[Marek Vasut]

On 11/15/2016 11:02 AM, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 09:47:31AM +0100, Daniel Vetter wrote:
>> On Tue, Nov 15, 2016 at 04:29:04PM +0800, kbuild test robot wrote:
>>> tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
>>> head:   35cf03508d8466ecc5199c9d609e74e85bec785b
>>> commit: 14d7f96f90fb65c2ca0e0ac7df237e06ff001c29 [23/26] drm/fb_cma_helper: 
>>> Add drm_fb_cma_prepare_fb() helper
>>> config: i386-allmodconfig (attached as .config)
>>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>>> reproduce:
>>> git checkout 14d7f96f90fb65c2ca0e0ac7df237e06ff001c29
>>> # save the attached .config to linux build tree
>>> make ARCH=i386 
>>>
>>> All warnings (new ones prefixed by >>):
>>>
>>>In file included from drivers/gpu/drm/vc4/vc4_drv.c:18:0:
> include/drm/drm_fb_cma_helper.h:45:13: warning: 'struct drm_plane_state' 
> declared inside parameter list will not be visible outside of this 
> definition or declaration
>>>  struct drm_plane_state *state);
>>> ^~~
> include/drm/drm_fb_cma_helper.h:44:34: warning: 'struct drm_plane' 
> declared inside parameter list will not be visible outside of this 
> definition or declaration
>>> int drm_fb_cma_prepare_fb(struct drm_plane *plane,
>>>  ^
>>
>> Oops, didn't noticed this compiler warning before pushing. Since drm-misc
>> is non-rebasing, can you pls supply a full fixup patch Marek?
> 
> Probably just need an #include  in drm_fb_cma_helper.h.

Actually, just a forward declaration of the struct drm_plane and
drm_plane_state is what is needed, it's already done for the other
structures there. Patch is coming.

-- 
Best regards,
Marek Vasut

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Daniel Vetter]

On Tue, Nov 15, 2016 at 03:36:02PM +0530, Sharma, Shashank wrote:
> On 11/15/2016 3:30 PM, Daniel Vetter wrote:
> > On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
> > > On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> > > > On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
> > > > > In any case, I guess addition of a cap for aspect ratio should fix the
> > > > > current objections for this implementation.
> > > > > 
> > > > > And I will keep it 0 by default, so that no aspect ratio information 
> > > > > is
> > > > > added until userspace sets the cap to 1 on its own.
> > > > Note that cap = needs new userspace.
> > > > -Daniel
> > > I guess you mean a new libdrm, so yes, I will add this new cap in libdrm.
> > > Is that what you mean ?
> > Full stack solution, including enabling in an Xorg driver (or somewhere
> > else, we also have drm_hwcomposer as an option).
> > 
> > And because that's probably going to take forever I'm leaning towards
> > revert again. Ville?
> Not really, with a kernel cap implementation, the code will be as it was
> before this patch series ( as good as revert )
> And then when we want to enable it, we can add the corresponding Xserver
> patch.
> 
> I guess the current problem is if is breaks something in some userspace, but
> if I am loading the flags only when the cap is set, we should be good.

This is not how new uabi gets merged, see:

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

Userspace must be ready, or it will not land. The entire point of my
suggestion to just extend the display modes was to avoid the need for
userspace, but since existing userspace tries to be too clever already,
that didn't work out.
Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH libdrm] automake: make the build less chatty

[Emil Velikov]

Having the "Entering|Leaving directory X" messages it not required nor
useful in vast majority of the cases.

One can always have them printed by `make -w' or by overriding the
AM_MAKEFLAGS variable.

Signed-off-by: Emil Velikov 
---
 Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile.am b/Makefile.am
index 2e46bde..dfb8fcd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -22,6 +22,7 @@ include Makefile.sources

 ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}

+AM_MAKEFLAGS = -s
 AM_DISTCHECK_CONFIGURE_FLAGS = \
--enable-udev \
--enable-libkms \
-- 
2.10.2

[PATCH v18 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Archit Taneja]

Hi,

On 11/14/2016 07:11 PM, Jitao Shi wrote:
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Thanks for the incorporating the fixes. I have commented on one issue
below.


The only thing that seems to be left now is the firmware update bits, right?

Can we get the firmware pushed on the linux-firmware git repo [1]?

Or

Remove the firmware update parts for now (including the SPI stuff,
since that seems to be only used for writing fw)?

[1] http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/

Thanks,
Archit

>
> Signed-off-by: Jitao Shi 
> Reviewed-by: Daniel Kurtz 
> Reviewed-by: Enric Balletbo i Serra 
> ---
> Changes since v17:
>  - remove some unused head files.
>  - add macros for ps8640 pages.
>  - remove ddc_i2c client
>  - add mipi_dsi_device_register_full
>  - remove the manufacturer from the name and i2c_device_id
>
> Changes since v16:
>  - Disable ps8640 DSI MCS Function.
>  - Rename gpios name more clearly.
>  - Tune the ps8640 power on sequence.
>
> Changes since v15:
>  - Drop drm_connector_(un)register calls from parade ps8640.
>The main DRM driver mtk_drm_drv now calls
>drm_connector_register_all() after drm_dev_register() in the
>mtk_drm_bind() function. That function should iterate over all
>connectors and call drm_connector_register() for each of them.
>So, remove drm_connector_(un)register calls from parade ps8640.
>
> Changes since v14:
>  - update copyright info.
>  - change bridge_to_ps8640 and connector_to_ps8640 to inline function.
>  - fix some coding style.
>  - use sizeof as array counter.
>  - use drm_get_edid when read edid.
>  - add mutex when firmware updating.
>
> Changes since v13:
>  - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 
> *data, u16 data_len)
>  - fix PAGE2_SW_REST tyro.
>  - move the buf[3] init to entrance of the function.
>
> Changes since v12:
>  - fix hw_chip_id build warning
>
> Changes since v11:
>  - Remove depends on I2C, add DRM depends
>  - Reuse ps8640_write_bytes() in ps8640_write_byte()
>  - Use timer check for polling like the routines in 
>  - Fix no drm_connector_unregister/drm_connector_cleanup when 
> ps8640_bridge_attach fail
>  - Check the ps8640 hardware id in ps8640_validate_firmware
>  - Remove fw_version check
>  - Move ps8640_validate_firmware before ps8640_enter_bl
>  - Add ddc_i2c unregister when probe fail and ps8640_remove
> ---
>  drivers/gpu/drm/bridge/Kconfig |   12 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/parade-ps8640.c | 1079 
> 
>  3 files changed, 1092 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 10e12e7..7f41bbc 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -57,6 +57,18 @@ config DRM_PARADE_PS8622
>   ---help---
> Parade eDP-LVDS bridge chip driver.
>
> +config DRM_PARADE_PS8640
> + tristate "Parade PS8640 MIPI DSI to eDP Converter"
> + depends on DRM
> + depends on OF
> + select DRM_KMS_HELPER
> + select DRM_MIPI_DSI
> + select DRM_PANEL
> + ---help---
> +   Choose this option if you have PS8640 for display
> +   The PS8640 is a high-performance and low-power
> +   MIPI DSI to eDP converter
> +
>  config DRM_SII902X
>   tristate "Silicon Image sii902x RGB/HDMI bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index cdf3a3c..7d93d40 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> new file mode 100644
> index 000..2d9c337
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -0,0 +1,1079 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

[Bug 98629] OpenGL applications warns "MESA-LOADER: failed to retrieve device information"

[bugzilla-dae...@freedesktop.org]

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

Emil Velikov  changed:

   What|Removed |Added

Product|Mesa|DRI
 Resolution|--- |FIXED
   Assignee|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
 Status|NEW |RESOLVED
  Component|Mesa core   |libdrm
Version|13.0|unspecified
 QA Contact|mesa-dev at lists.freedesktop. |
   |org |

--- Comment #6 from Emil Velikov  ---
Fixed with the following commit, which is part of libdrm 2.4.73.
Thanks for the report and testing !

commit f53d3542c1dfa2a1c1a5a7155d058df9a6bcce7b
Author: Emil Velikov 
Date:   Fri Nov 11 19:04:11 2016 +

xd86drm: read more than 128 bytes of uevent in drmParsePciBusInfo

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161115/0d1db750/attachment.html>

[drm-intel:topic/drm-misc 23/26] include/drm/drm_fb_cma_helper.h:45:13: warning: 'struct drm_plane_state' declared inside parameter list will not be visible outside of this definition or declaration

[Daniel Vetter]

On Tue, Nov 15, 2016 at 09:47:31AM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 04:29:04PM +0800, kbuild test robot wrote:
> > tree:   git://anongit.freedesktop.org/drm-intel topic/drm-misc
> > head:   35cf03508d8466ecc5199c9d609e74e85bec785b
> > commit: 14d7f96f90fb65c2ca0e0ac7df237e06ff001c29 [23/26] drm/fb_cma_helper: 
> > Add drm_fb_cma_prepare_fb() helper
> > config: i386-allmodconfig (attached as .config)
> > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> > reproduce:
> > git checkout 14d7f96f90fb65c2ca0e0ac7df237e06ff001c29
> > # save the attached .config to linux build tree
> > make ARCH=i386 
> > 
> > All warnings (new ones prefixed by >>):
> > 
> >In file included from drivers/gpu/drm/vc4/vc4_drv.c:18:0:
> > >> include/drm/drm_fb_cma_helper.h:45:13: warning: 'struct drm_plane_state' 
> > >> declared inside parameter list will not be visible outside of this 
> > >> definition or declaration
> >  struct drm_plane_state *state);
> > ^~~
> > >> include/drm/drm_fb_cma_helper.h:44:34: warning: 'struct drm_plane' 
> > >> declared inside parameter list will not be visible outside of this 
> > >> definition or declaration
> > int drm_fb_cma_prepare_fb(struct drm_plane *plane,
> >  ^
> 
> Oops, didn't noticed this compiler warning before pushing. Since drm-misc
> is non-rebasing, can you pls supply a full fixup patch Marek?

Probably just need an #include  in drm_fb_cma_helper.h.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[patch] drm: zte: checking for NULL instead of IS_ERR()

[Daniel Vetter]

On Tue, Nov 15, 2016 at 12:53:01PM +0300, Dan Carpenter wrote:
> drm_dev_alloc() never returns NULL, it only returns error pointers on
> error.
> 
> Fixes: 0a886f59528a ("drm: zte: add initial vou drm driver")
> Signed-off-by: Dan Carpenter 

Applied, thx.
-Daniel

> 
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c 
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index abc8099..3e76f72 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -107,8 +107,8 @@ static int zx_drm_bind(struct device *dev)
>   return -ENOMEM;
>  
>   drm = drm_dev_alloc(_drm_driver, dev);
> - if (!drm)
> - return -ENOMEM;
> + if (IS_ERR(drm))
> + return PTR_ERR(drm);
>  
>   drm->dev_private = priv;
>   dev_set_drvdata(dev, drm);
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Daniel Vetter]

On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
> On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> > On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
> > > In any case, I guess addition of a cap for aspect ratio should fix the
> > > current objections for this implementation.
> > > 
> > > And I will keep it 0 by default, so that no aspect ratio information is
> > > added until userspace sets the cap to 1 on its own.
> > Note that cap = needs new userspace.
> > -Daniel
> I guess you mean a new libdrm, so yes, I will add this new cap in libdrm.
> Is that what you mean ?

Full stack solution, including enabling in an Xorg driver (or somewhere
else, we also have drm_hwcomposer as an option).

And because that's probably going to take forever I'm leaning towards
revert again. Ville?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[linux-sunxi] Re: [PATCH v3 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply

[Chen-Yu Tsai]

Hi,

On Wed, Nov 2, 2016 at 9:33 AM, Chen-Yu Tsai  wrote:
> On Mon, Oct 31, 2016 at 2:28 PM, Rob Herring  wrote:
>> On Sat, Oct 29, 2016 at 07:06:10PM +0800, Chen-Yu Tsai wrote:
>>> Some dumb VGA DACs are active components which require external power.
>>> Add support for specifying a regulator as its power supply.
>>>
>>> Signed-off-by: Chen-Yu Tsai 
>>> ---
>>>  .../bindings/display/bridge/dumb-vga-dac.txt   |  2 ++
>>
>> For the binding,
>>
>> Acked-by: Rob Herring 

Any comments on this patch from the DRM people?

ChenYu

>>
>> One code comment below...
>>
>>>  drivers/gpu/drm/bridge/dumb-vga-dac.c  | 35 
>>> ++
>>>  2 files changed, 37 insertions(+)
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt 
>>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> index 003bc246a270..164cbb15f04c 100644
>>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>> @@ -16,6 +16,8 @@ graph bindings specified in 
>>> Documentation/devicetree/bindings/graph.txt.
>>>  - Video port 0 for RGB input
>>>  - Video port 1 for VGA output
>>>
>>> +Optional properties:
>>> +- vdd-supply: Power supply for DAC
>>>
>>>  Example
>>>  ---
>>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
>>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> index afec232185a7..59781e031220 100644
>>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>> @@ -12,6 +12,7 @@
>>>
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  #include 
>>>  #include 
>>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>>   struct drm_connectorconnector;
>>>
>>>   struct i2c_adapter  *ddc;
>>> + struct regulator*vdd;
>>>  };
>>>
>>>  static inline struct dumb_vga *
>>> @@ -124,8 +126,33 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>>>   return 0;
>>>  }
>>>
>>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> + int ret;
>>> +
>>> + if (!IS_ERR(vga->vdd)) {
>>
>> if (IS_ERR())
>> return;
>>
>> ...will save some intentation.
>
> I thought about that, though if someone were to add more stuff to
> this, such as an enable GPIO, they might have to rework it. A standalone
> block of code would be easier to work with. I'm OK either way though.
>
> ChenYu
>
>>
>>> + ret = regulator_enable(vga->vdd);
>>> +
>>> + if (ret) {
>>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", 
>>> ret);
>>> + return;
>>> + }
>>> + }
>>> +}
>>> +
>>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>>> +{
>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>> +
>>> + if (!IS_ERR(vga->vdd))
>>> + regulator_disable(vga->vdd);
>>> +}
>>> +
>>>  static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>>>   .attach = dumb_vga_attach,
>>> + .enable = dumb_vga_enable,
>>> + .disable= dumb_vga_disable,
>>>  };
>>>
>>>  static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>>> @@ -169,6 +196,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
>>>   return -ENOMEM;
>>>   platform_set_drvdata(pdev, vga);
>>>
>>> + vga->vdd = devm_regulator_get_optional(>dev, "vdd");
>>> + if (IS_ERR(vga->vdd)) {
>>> + ret = PTR_ERR(vga->vdd);
>>> + if (ret == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>> + dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
>>> + }
>>> +
>>>   vga->ddc = dumb_vga_retrieve_ddc(>dev);
>>>   if (IS_ERR(vga->ddc)) {
>>>   if (PTR_ERR(vga->ddc) == -ENODEV) {
>>> --
>>> 2.9.3
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

[PATCH v11 3/3] drm/fence: add out-fences support

[Gustavo Padovan]

From: Gustavo Padovan 

Support DRM out-fences by creating a sync_file with a fence for each CRTC
that sets the OUT_FENCE_PTR property.

We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
the sync_file fd back to userspace.

The sync_file and fd are allocated/created before commit, but the
fd_install operation only happens after we know that commit succeed.

v2: Comment by Rob Clark:
- Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.

Comment by Daniel Vetter:
- Add clean up code for out_fences

v3: Comments by Daniel Vetter:
- create DRM_MODE_ATOMIC_EVENT_MASK
- userspace should fill out_fences_ptr with the crtc_ids for which
it wants fences back.

v4: Create OUT_FENCE_PTR properties and remove old approach.

v5: Comments by Brian Starkey:
- Remove extra fence_get() in atomic_ioctl()
- Check ret before iterating on the crtc_state
- check ret before fd_install
- set fence_state to NULL at the beginning
- check fence_state->out_fence_ptr before put_user()
- change order of fput() and put_unused_fd() on failure

 - Add access_ok() check to the out_fence_ptr received
 - Rebase after fence -> dma_fence rename
 - Store out_fence_ptr in the drm_atomic_state
 - Split crtc_setup_out_fence()
 - return -1 as out_fence with TEST_ONLY flag

v6: Comments by Daniel Vetter
- Add prepare/unprepare_crtc_signaling()
- move struct drm_out_fence_state to drm_atomic.c
- mark get_crtc_fence() as static

Comments by Brian Starkey
- proper set fence_ptr fence_state array
- isolate fence_idx increment

- improve error handling

v7: Comments by Daniel Vetter
- remove prefix from internal functions
- make out_fence_ptr an s64 pointer
- degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
- fix doc issues
- filter out OUT_FENCE_PTR == NULL and do not fail in this case
- add complete_crtc_signalling()
- krealloc fence_state on demand

Comment by Brian Starkey
- remove unused crtc_state arg from get_out_fence()

v8: Comment by Brian Starkey
- cancel events before check for !fence_state
- convert a few lefovers u64 types for out_fence_ptr
- fix memleak by assign fence_state earlier after realloc
- proper accout num_fences in case of error

v9: Comment by Brian Starkey
- memset last position of fence_state after krealloc
Comments by Sean Paul
- pass install_fds in complete_crtc_signaling() instead of ret

 - put_user(-1, fence_ptr) when decoding props

v10: Comment by Brian Starkey
- remove unneeded num_fences increment on error path
- kfree fence_state after installing fences fd

Signed-off-by: Gustavo Padovan 
Reviewed-by: Brian Starkey 
Tested-by: Robert Foss 
---
 drivers/gpu/drm/drm_atomic.c | 241 +++
 drivers/gpu/drm/drm_crtc.c   |   8 ++
 include/drm/drm_atomic.h |   1 +
 include/drm/drm_crtc.h   |   6 ++
 4 files changed, 211 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3ad780a..d4a92a9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
 }
 EXPORT_SYMBOL(drm_atomic_get_crtc_state);

+static void set_out_fence_for_crtc(struct drm_atomic_state *state,
+  struct drm_crtc *crtc, s64 __user *fence_ptr)
+{
+   state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
+}
+
+static s64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
+  struct drm_crtc *crtc)
+{
+   s64 __user *fence_ptr;
+
+   fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
+   state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
+
+   return fence_ptr;
+}
+
 /**
  * drm_atomic_set_mode_for_crtc - set mode for CRTC
  * @state: the CRTC whose incoming state to update
@@ -494,6 +511,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == config->prop_out_fence_ptr) {
+   s64 __user *fence_ptr = u64_to_user_ptr(val);
+
+   if (!fence_ptr)
+   return 0;
+
+   if (put_user(-1, fence_ptr))
+   return -EFAULT;
+
+   set_out_fence_for_crtc(state->state, crtc, fence_ptr);
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
@@ -536,6 +563,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->ctm) ? 

[PATCH v11 2/3] drm/fence: add fence timeline to drm_crtc

[Gustavo Padovan]

From: Gustavo Padovan 

Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.

v2: Comment by Daniel Stone:
- add BUG_ON() to fence_to_crtc() macro

v3: Comment by Ville Syrjälä
- Use more meaningful name as crtc timeline name

v4: Comments by Brian Starkey
- Use even more meaninful name for the crtc timeline
- add doc for timeline_name
Comment by Daniel Vetter
- use in-line style for comments

- rebase after fence -> dma_fence rename

v5: Comment by Daniel Vetter
- Add doc for drm_crtc_fence_ops

Signed-off-by: Gustavo Padovan 
Reviewed-by: Daniel Vetter 
Reviewed-by: Sean Paul 
Tested-by: Robert Foss 
---
 drivers/gpu/drm/drm_crtc.c | 31 +++
 include/drm/drm_crtc.h | 45 +
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f6d1b38..20ddaff 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -165,6 +165,32 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc)
 #endif
 }

+static const char *drm_crtc_fence_get_driver_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->dev->driver->name;
+}
+
+static const char *drm_crtc_fence_get_timeline_name(struct dma_fence *fence)
+{
+   struct drm_crtc *crtc = fence_to_crtc(fence);
+
+   return crtc->timeline_name;
+}
+
+static bool drm_crtc_fence_enable_signaling(struct dma_fence *fence)
+{
+   return true;
+}
+
+const struct dma_fence_ops drm_crtc_fence_ops = {
+   .get_driver_name = drm_crtc_fence_get_driver_name,
+   .get_timeline_name = drm_crtc_fence_get_timeline_name,
+   .enable_signaling = drm_crtc_fence_enable_signaling,
+   .wait = dma_fence_default_wait,
+};
+
 /**
  * drm_crtc_init_with_planes - Initialise a new CRTC object with
  *specified primary and cursor planes.
@@ -222,6 +248,11 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
return -ENOMEM;
}

+   crtc->fence_context = dma_fence_context_alloc(1);
+   spin_lock_init(>fence_lock);
+   snprintf(crtc->timeline_name, sizeof(crtc->timeline_name),
+"CRTC:%d-%s", crtc->base.id, crtc->name);
+
crtc->base.properties = >properties;

list_add_tail(>head, >crtc_list);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 11780a9..0870de1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -32,6 +32,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -739,9 +741,52 @@ struct drm_crtc {
 */
struct drm_crtc_crc crc;
 #endif
+
+   /**
+* @fence_context:
+*
+* timeline context used for fence operations.
+*/
+   unsigned int fence_context;
+
+   /**
+* @fence_lock:
+*
+* spinlock to protect the fences in the fence_context.
+*/
+
+   spinlock_t fence_lock;
+   /**
+* @fence_seqno:
+*
+* Seqno variable used as monotonic counter for the fences
+* created on the CRTC's timeline.
+*/
+   unsigned long fence_seqno;
+
+   /**
+* @timeline_name:
+*
+* The name of the CRTC's fence timeline.
+*/
+   char timeline_name[32];
 };

 /**
+ * dma_crtc_fence_ops - fence ops for the drm_crtc timeline
+ *
+ * It contains the dma_fence_ops that should be called by the dma_fence
+ * code. CRTC core should use this ops when initializing fences.
+ */
+extern const struct dma_fence_ops drm_crtc_fence_ops;
+
+static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
+{
+   BUG_ON(fence->ops != _crtc_fence_ops);
+   return container_of(fence->lock, struct drm_crtc, fence_lock);
+}
+
+/**
  * struct drm_mode_set - new values for a CRTC config change
  * @fb: framebuffer to use for new config
  * @crtc: CRTC whose configuration we're about to change
-- 
2.5.5