Re: [Intel-gfx] [PATCH 4/7] drm/i915: PSR VLV: Add single frame update.

[Pandiyan, Dhinakaran]

Reviewed by: Dhinakaran Pandiyan dhinakaran.pandiyan at intel.com
Tested by: Dhinakaran Pandiyan dhinakaran.pandiyan at intel.com

The screen update lag that was earlier seen on BSW is fixed by this patch.

From: Vivi, Rodrigo
Sent: Friday, February 27, 2015 5:26 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; Pandiyan, Dhinakaran
Subject: [PATCH 4/7] drm/i915: PSR VLV: Add single frame update.

According to spec: In PSR HW or SW mode, SW set this bit before writing
registers for a flip. It will be self-clear when it gets to the PSR
active state.

Some versions of spec mention that this is needed when in
Persistent mode but define it as same as SW mode. Since this
fix the page flip case let's assume this is exactly what we need.

Cc: Dhinakaran Pandiyan dhinakaran.pandi...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_frontbuffer.c |  2 ++
 drivers/gpu/drm/i915/intel_psr.c | 42 
 3 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1fb1529..55ece8f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1182,6 +1182,7 @@ void intel_psr_invalidate(struct drm_device *dev,
 void intel_psr_flush(struct drm_device *dev,
 unsigned frontbuffer_bits);
 void intel_psr_init(struct drm_device *dev);
+void intel_psr_single_frame_update(struct drm_device *dev);

 /* intel_runtime_pm.c */
 int intel_power_domains_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/intel_frontbuffer.c
index 73cb6e0..2094c06 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -254,6 +254,8 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev,
/* Remove stale busy bits due to the old buffer. */
dev_priv-fb_tracking.busy_bits = ~frontbuffer_bits;
mutex_unlock(dev_priv-fb_tracking.lock);
+
+   intel_psr_single_frame_update(dev);
 }

 /**
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index d2ff87d..c1ca923 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -553,6 +553,48 @@ static void intel_psr_exit(struct drm_device *dev)
 }

 /**
+ * intel_psr_single_frame_update - Single Frame Update
+ * @dev: DRM device
+ *
+ * Some platforms support a single frame update feature that is used to
+ * send and update only one frame on Remote Frame Buffer.
+ * So far it is only implemented for Valleyview and Cherryview because
+ * hardware requires this to be done before a page flip.
+ */
+void intel_psr_single_frame_update(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   struct drm_crtc *crtc;
+   enum pipe pipe;
+   u32 val;
+
+   /*
+* Single frame update is already supported on BDW+ but it requires
+* many W/A and it isn't really needed.
+*/
+   if (!IS_VALLEYVIEW(dev))
+   return;
+
+   mutex_lock(dev_priv-psr.lock);
+   if (!dev_priv-psr.enabled) {
+   mutex_unlock(dev_priv-psr.lock);
+   return;
+   }
+
+   crtc = dp_to_dig_port(dev_priv-psr.enabled)-base.base.crtc;
+   pipe = to_intel_crtc(crtc)-pipe;
+   val = I915_READ(VLV_PSRCTL(pipe));
+
+   /*
+* We need to set this bit before writing registers for a flip.
+* This bit will be self-clear when it gets to the PSR active state.
+*/
+   I915_WRITE(VLV_PSRCTL(pipe), val | VLV_EDP_PSR_SINGLE_FRAME_UPDATE);
+
+   mutex_unlock(dev_priv-psr.lock);
+}
+
+/**
  * intel_psr_invalidate - Invalidade PSR
  * @dev: DRM device
  * @frontbuffer_bits: frontbuffer plane tracking bits
--
1.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915/psr: Do not activate PSR when vblank interrupts are enabled

[Pandiyan, Dhinakaran]

On Tue, 2016-06-14 at 00:09 +, Vivi, Rodrigo wrote:
> On Wed, 2016-06-08 at 18:46 -0700, Dhinakaran Pandiyan wrote:
> > PSR in CHV, unlike HSW, can get activated even if vblanks interrupts
> > are
> > enabled. But, the pipe is not expected to generate timings signals
> > when PSR is active. Specifically, we do not get vblank interrupts in
> > CHV
> > if PSR becomes active. This has led to drm_wait_vblank timing out.
> > 
> > Let's disable PSR using the vblank prepare hook that gets called
> > before
> > enabling vblank interrupts and keep it disabled until the interrupts
> > are
> > not needed.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >  drivers/gpu/drm/i915/i915_irq.c  | 12 
> >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c | 61
> > +++-
> >  4 files changed, 75 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index e4c8e34..03f311e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -994,6 +994,7 @@ struct i915_psr {
> > bool psr2_support;
> > bool aux_frame_sync;
> > bool link_standby;
> > +   bool vlv_src_timing;
> >  };
> >  
> >  enum intel_pch {
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index caaf1e2..77f3d76 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2790,6 +2790,16 @@ static int gen8_enable_vblank(struct
> > drm_device *dev, unsigned int pipe)
> > return 0;
> >  }
> >  
> > +static void valleyview_prepare_vblank(struct drm_device *dev,
> > unsigned int pipe)
> > +{
> 
> shouldn't we force psr_exit here? What if vblank is enabled after psr
> is already in active mode?
> 

vlv_psr_src_timing_get calls intel_psr_exit if PSR is already active.

> > +   vlv_psr_src_timing_get(dev);
> > +}
> > +
> > +static void valleyview_unprepare_vblank(struct drm_device *dev,
> > unsigned int pipe){
> > +
> > +   vlv_psr_src_timing_put(dev);
> > +}
> > +
> >  /* Called from drm generic code, passed 'crtc' which
> >   * we use as a pipe index
> >   */
> > @@ -4610,6 +4620,8 @@ void intel_irq_init(struct drm_i915_private
> > *dev_priv)
> > dev->driver->irq_uninstall =
> > cherryview_irq_uninstall;
> > dev->driver->enable_vblank =
> > valleyview_enable_vblank;
> > dev->driver->disable_vblank =
> > valleyview_disable_vblank;
> > +   dev->driver->prepare_vblank =
> > valleyview_prepare_vblank;
> > +   dev->driver->unprepare_vblank =
> > valleyview_unprepare_vblank;
> > dev_priv->display.hpd_irq_setup =
> > i915_hpd_irq_setup;
> > } else if (IS_VALLEYVIEW(dev_priv)) {
> > dev->driver->irq_handler = valleyview_irq_handler;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 9b5f663..e2078fd 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1511,6 +1511,8 @@ void intel_psr_flush(struct drm_device *dev,
> >  void intel_psr_init(struct drm_device *dev);
> >  void intel_psr_single_frame_update(struct drm_device *dev,
> >unsigned frontbuffer_bits);
> > +void vlv_psr_src_timing_get(struct drm_device *dev);
> > +void vlv_psr_src_timing_put(struct drm_device *dev);
> >  
> >  /* intel_runtime_pm.c */
> >  int intel_power_domains_init(struct drm_i915_private *);
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 29a09bf..c95e680 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -462,6 +462,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
> >  
> > /* Enable PSR on the panel */
> > vlv_psr_enable_sink(intel_dp);
> > +   dev_priv->psr.vlv_src_timing = false;
> >  
> > /* On HSW+ enable_source also means go to PSR
> > entry/active
> >  * state as soon as idle_frame achieved and here
> > would be
> > @@ -608,8 +609,10 @@ static void intel_psr_work(struct work_struct
> > *work)
> >  * The delayed work can race with an invalidate hence we
> > need to
> >  * recheck. Since psr_flush first clears this and then
> > reschedules we
> >  * won't ever miss a flush when bailing out here.
> > +* Also, do not enable PSR if source is required to generate
> > timing
> > +* signals like vblanks.
> >  */
> > -   if (dev_priv->psr.busy_frontbuffer_bits)
> > +   if (dev_priv->psr.busy_frontbuffer_bits || dev_priv
> > ->psr.vlv_src_timing)
> > goto unlock;
> 
> I wonder if in this vlv_src_timing case the work should re-schedule
> itself... otherwise we have the risk of psr staying disabled forever
> right?
> 
> 
intel_psr_work gets rescheduled when 

Re: [Intel-gfx] [PATCH 3/3] drm/i915/psr: Do not activate PSR when vblank interrupts are enabled

[Pandiyan, Dhinakaran]

On Wed, 2016-06-15 at 21:44 +, Vivi, Rodrigo wrote:
> On Wed, 2016-06-15 at 01:02 +0000, Pandiyan, Dhinakaran wrote:
> > On Tue, 2016-06-14 at 00:09 +, Vivi, Rodrigo wrote:
> > > On Wed, 2016-06-08 at 18:46 -0700, Dhinakaran Pandiyan wrote:
> > > > PSR in CHV, unlike HSW, can get activated even if vblanks
> > > > interrupts
> > > > are
> > > > enabled. But, the pipe is not expected to generate timings
> > > > signals
> > > > when PSR is active. Specifically, we do not get vblank interrupts
> > > > in
> > > > CHV
> > > > if PSR becomes active. This has led to drm_wait_vblank timing
> > > > out.
> > > > 
> > > > Let's disable PSR using the vblank prepare hook that gets called
> > > > before
> > > > enabling vblank interrupts and keep it disabled until the
> > > > interrupts
> > > > are
> > > > not needed.
> > > > 
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com
> > > > >
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > > >  drivers/gpu/drm/i915/i915_irq.c  | 12 
> > > >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> > > >  drivers/gpu/drm/i915/intel_psr.c | 61
> > > > +++-
> > > >  4 files changed, 75 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index e4c8e34..03f311e 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -994,6 +994,7 @@ struct i915_psr {
> > > > bool psr2_support;
> > > > bool aux_frame_sync;
> > > > bool link_standby;
> > > > +   bool vlv_src_timing;
> > > >  };
> > > >  
> > > >  enum intel_pch {
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index caaf1e2..77f3d76 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -2790,6 +2790,16 @@ static int gen8_enable_vblank(struct
> > > > drm_device *dev, unsigned int pipe)
> > > > return 0;
> > > >  }
> > > >  
> > > > +static void valleyview_prepare_vblank(struct drm_device *dev,
> > > > unsigned int pipe)
> > > > +{
> > > 
> > > shouldn't we force psr_exit here? What if vblank is enabled after
> > > psr
> > > is already in active mode?
> > > 
> > 
> > vlv_psr_src_timing_get calls intel_psr_exit if PSR is already active.
> 
> oh it is already there indeed...
> i'm crazy, sorry...
> 
> I liked the solution... really simple and straightforward... so simple
> that confused me hehe
> 
> > 
> > > > +   vlv_psr_src_timing_get(dev);
> > > > +}
> > > > +
> > > > +static void valleyview_unprepare_vblank(struct drm_device *dev,
> > > > unsigned int pipe){
> > > > +
> > > > +   vlv_psr_src_timing_put(dev);
> > > > +}
> > > > +
> > > >  /* Called from drm generic code, passed 'crtc' which
> > > >   * we use as a pipe index
> > > >   */
> > > > @@ -4610,6 +4620,8 @@ void intel_irq_init(struct drm_i915_private
> > > > *dev_priv)
> > > > dev->driver->irq_uninstall =
> > > > cherryview_irq_uninstall;
> > > > dev->driver->enable_vblank =
> > > > valleyview_enable_vblank;
> > > > dev->driver->disable_vblank =
> > > > valleyview_disable_vblank;
> > > > +   dev->driver->prepare_vblank =
> > > > valleyview_prepare_vblank;
> > > > +   dev->driver->unprepare_vblank =
> > > > valleyview_unprepare_vblank;
> > > > dev_priv->display.hpd_irq_setup =
> > > > i915_hpd_irq_setup;
> > > > } else if (IS_VALLEYVIEW(dev_priv)) {
> > > > dev->driver->irq_handler =
> > > > valleyview_irq_handler;
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index 9b5f663..e2078fd

Re: [Intel-gfx] [PATCH 1/2] pciids: Add more Kabylake PCI IDs.

[Pandiyan, Dhinakaran]

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  src/i915_pciids.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/i915_pciids.h b/src/i915_pciids.h
> index 9094599..87dde1c 100644
> --- a/src/i915_pciids.h
> +++ b/src/i915_pciids.h
> @@ -309,6 +309,7 @@
>   INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
>   INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
>   INTEL_VGA_DEVICE(0x5902, info), /* DT  GT1 */ \
> + INTEL_VGA_DEVICE(0x5908, info), /* Halo GT1 */ \
>   INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
>   INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
>  
> @@ -322,7 +323,9 @@
>   INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
>  
>  #define INTEL_KBL_GT3_IDS(info) \
> + INTEL_VGA_DEVICE(0x5923, info), /* ULT GT3 */ \
>   INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
> + INTEL_VGA_DEVICE(0x5927, info), /* ULT GT3 */ \
>   INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
>   INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
>  

I verified the added and removed PCI IDs against the Spec, looks good to
me.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add more Kabylake PCI IDs.

[Pandiyan, Dhinakaran]

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  include/drm/i915_pciids.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 9094599..87dde1c 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -309,6 +309,7 @@
>   INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
>   INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
>   INTEL_VGA_DEVICE(0x5902, info), /* DT  GT1 */ \
> + INTEL_VGA_DEVICE(0x5908, info), /* Halo GT1 */ \
>   INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
>   INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
>  
> @@ -322,7 +323,9 @@
>   INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
>  
>  #define INTEL_KBL_GT3_IDS(info) \
> + INTEL_VGA_DEVICE(0x5923, info), /* ULT GT3 */ \
>   INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
> + INTEL_VGA_DEVICE(0x5927, info), /* ULT GT3 */ \
>   INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
>   INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
>  

I verified the added and removed PCI IDs against Spec, looks good to me.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add more Kabylake PCI IDs.

[Pandiyan, Dhinakaran]

On Fri, 2016-06-24 at 22:06 +, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> > The spec has been updated adding new PCI IDs.
> > 
> > Signed-off-by: Rodrigo Vivi <rodrigo.v...@intel.com>
> > ---
> >  include/drm/i915_pciids.h | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> > index 9094599..87dde1c 100644
> > --- a/include/drm/i915_pciids.h
> > +++ b/include/drm/i915_pciids.h
> > @@ -309,6 +309,7 @@
> > INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
> > INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
> > INTEL_VGA_DEVICE(0x5902, info), /* DT  GT1 */ \
> > +   INTEL_VGA_DEVICE(0x5908, info), /* Halo GT1 */ \
> > INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
> > INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
> >  
> > @@ -322,7 +323,9 @@
> > INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
> >  
> >  #define INTEL_KBL_GT3_IDS(info) \
> > +   INTEL_VGA_DEVICE(0x5923, info), /* ULT GT3 */ \
> > INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
> > +   INTEL_VGA_DEVICE(0x5927, info), /* ULT GT3 */ \
> > INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
> > INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
> >  
> 
> I verified the added and removed PCI IDs against Spec, looks good to me.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Missed the tag.
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] pciids: Add more Kabylake PCI IDs.

[Pandiyan, Dhinakaran]

On Fri, 2016-06-24 at 15:20 -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> > The spec has been updated adding new PCI IDs.
> > 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  src/i915_pciids.h | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/src/i915_pciids.h b/src/i915_pciids.h
> > index 9094599..87dde1c 100644
> > --- a/src/i915_pciids.h
> > +++ b/src/i915_pciids.h
> > @@ -309,6 +309,7 @@
> > INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
> > INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
> > INTEL_VGA_DEVICE(0x5902, info), /* DT  GT1 */ \
> > +   INTEL_VGA_DEVICE(0x5908, info), /* Halo GT1 */ \
> > INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
> > INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
> >  
> > @@ -322,7 +323,9 @@
> > INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
> >  
> >  #define INTEL_KBL_GT3_IDS(info) \
> > +   INTEL_VGA_DEVICE(0x5923, info), /* ULT GT3 */ \
> > INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
> > +   INTEL_VGA_DEVICE(0x5927, info), /* ULT GT3 */ \
> > INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
> > INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
> >  
> 
> I verified the added and removed PCI IDs against the Spec, looks good to
> me.

Missed the tag.
Reviewed-by: Dhinakaran Pandiyan 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] intel: Add more Kabylake PCI IDs.

[Pandiyan, Dhinakaran]

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  intel/intel_chipset.h | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index e2554c3..0c3ca82 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -194,7 +194,9 @@
>  #define PCI_CHIP_KABYLAKE_ULT_GT20x5916
>  #define PCI_CHIP_KABYLAKE_ULT_GT1_5  0x5913
>  #define PCI_CHIP_KABYLAKE_ULT_GT10x5906
> -#define PCI_CHIP_KABYLAKE_ULT_GT30x5926
> +#define PCI_CHIP_KABYLAKE_ULT_GT3_0  0x5923
> +#define PCI_CHIP_KABYLAKE_ULT_GT3_1  0x5926
> +#define PCI_CHIP_KABYLAKE_ULT_GT3_2  0x5927
>  #define PCI_CHIP_KABYLAKE_ULT_GT2F   0x5921
>  #define PCI_CHIP_KABYLAKE_ULX_GT1_5  0x5915
>  #define PCI_CHIP_KABYLAKE_ULX_GT10x590E
> @@ -206,7 +208,8 @@
>  #define PCI_CHIP_KABYLAKE_HALO_GT2   0x591B
>  #define PCI_CHIP_KABYLAKE_HALO_GT4   0x593B
>  #define PCI_CHIP_KABYLAKE_HALO_GT3   0x592B
> -#define PCI_CHIP_KABYLAKE_HALO_GT1   0x590B
> +#define PCI_CHIP_KABYLAKE_H_GT1_00x5908
> +#define PCI_CHIP_KABYLAKE_H_GT1_10x590B

Does H here mean Halo? Some of defines have the whole word "HALO" and
some "H". Shouldn't we keep that uniform? 

>  #define PCI_CHIP_KABYLAKE_SRV_GT20x591A
>  #define PCI_CHIP_KABYLAKE_SRV_GT30x592A
>  #define PCI_CHIP_KABYLAKE_SRV_GT10x590A
> @@ -414,7 +417,8 @@
>(devid) == PCI_CHIP_KABYLAKE_ULT_GT1   || \
>(devid) == PCI_CHIP_KABYLAKE_ULX_GT1   || \
>(devid) == PCI_CHIP_KABYLAKE_DT_GT1|| \
> -  (devid) == PCI_CHIP_KABYLAKE_HALO_GT1  || \
> +  (devid) == PCI_CHIP_KABYLAKE_H_GT1_0   || \
> +  (devid) == PCI_CHIP_KABYLAKE_H_GT1_1   || \
>(devid) == PCI_CHIP_KABYLAKE_SRV_GT1)
>  
>  #define IS_KBL_GT2(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT2   || \
> @@ -425,7 +429,9 @@
>(devid) == PCI_CHIP_KABYLAKE_SRV_GT2   || \
>(devid) == PCI_CHIP_KABYLAKE_WKS_GT2)
>  
> -#define IS_KBL_GT3(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT3   || \
> +#define IS_KBL_GT3(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0 || \
> +  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1 || \
> +  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2 || \
>(devid) == PCI_CHIP_KABYLAKE_HALO_GT3  || \
>(devid) == PCI_CHIP_KABYLAKE_SRV_GT3)
>  

I verified the PCI IDs against the Spec, looks good to me.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Treat cursor plane as another sprite plane for BSW

[Pandiyan, Dhinakaran]

Agreed, it does look messy.

As for the watermarks, we have verified that this patch works on Chrome OS with 
the kernel version 3.18. We have not seen any regressions yet. However, it 
requires the patch "drm/i915: Workaround CHV pipe C cursor fail" to be 
reverted. I will send out another version addressing the comments along with 
the revert.


From: Ville Syrjälä [ville.syrj...@linux.intel.com]
Sent: Wednesday, March 02, 2016 6:03 AM
To: Pandiyan, Dhinakaran
Cc: intel-gfx@lists.freedesktop.org; Kondapally, Kalyan
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Treat cursor plane as another sprite 
plane for BSW

On Tue, Mar 01, 2016 at 03:27:17PM -0800, Dhinakaran Pandiyan wrote:
> From: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
>
> Work around the CHV pipe C FIFO underruns that cause display failure by
> enabling sprite plane for cursor.
>
> This patch for BSW is based on Maarten Lankhorst's work that
> enables universal plane support.
>
> Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>
> Signed-off-by: Kalyan Kondapally <kalyan.kondapa...@intel.com>
> Signed-off-by: Pandiyan Dhinakaran <dhinakaran.pandi...@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 48 +++--
>  drivers/gpu/drm/i915/intel_drv.h | 14 --
>  drivers/gpu/drm/i915/intel_pm.c  | 51 
> +---
>  drivers/gpu/drm/i915/intel_sprite.c  | 25 +-
>  4 files changed, 100 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 44fcff0..4a392d4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11941,9 +11941,14 @@ int intel_plane_atomic_calc_changes(struct 
> drm_crtc_state *crtc_state,
>   bool is_crtc_enabled = crtc_state->active;
>   bool turn_off, turn_on, visible, was_visible;
>   struct drm_framebuffer *fb = plane_state->fb;
> + enum drm_plane_type plane_type = plane->type;
> +
> + if (plane_type == DRM_PLANE_TYPE_CURSOR &&
> + !pipe_has_cursor_plane(to_i915(dev), intel_crtc->pipe))
> + plane_type = DRM_PLANE_TYPE_OVERLAY;

I think spreading this stuff all over is too messy. I would suggest adding some
kind of hw plane type to intel_plane instead.

>
>   if (crtc_state && INTEL_INFO(dev)->gen >= 9 &&
> - plane->type != DRM_PLANE_TYPE_CURSOR) {
> + plane_type != DRM_PLANE_TYPE_CURSOR) {
>   ret = skl_update_scaler_plane(
>   to_intel_crtc_state(crtc_state),
>   to_intel_plane_state(plane_state));
> @@ -14472,7 +14477,7 @@ static void intel_crtc_init(struct drm_device *dev, 
> int pipe)
>   struct intel_crtc_state *crtc_state = NULL;
>   struct drm_plane *primary = NULL;
>   struct drm_plane *cursor = NULL;
> - int i, ret;
> + int i, ret, sprite;
>
>   intel_crtc = kzalloc(sizeof(*intel_crtc), GFP_KERNEL);
>   if (intel_crtc == NULL)
> @@ -14499,9 +14504,32 @@ static void intel_crtc_init(struct drm_device *dev, 
> int pipe)
>   if (!primary)
>   goto fail;
>
> - cursor = intel_cursor_plane_create(dev, pipe);
> - if (!cursor)
> - goto fail;
> + if (pipe_has_cursor_plane(dev_priv, pipe)) {
> + cursor = intel_cursor_plane_create(dev, pipe);
> + if (!cursor)
> + goto fail;
> + }
> +
> + for_each_sprite(dev_priv, pipe, sprite) {
> + enum drm_plane_type plane_type;
> + struct drm_plane *plane;
> +
> + if (sprite + 1 < INTEL_INFO(dev_priv)->num_sprites[pipe] ||
> + pipe_has_cursor_plane(dev_priv, pipe))
> + plane_type = DRM_PLANE_TYPE_OVERLAY;
> + else
> + plane_type = DRM_PLANE_TYPE_CURSOR;

I'm thinking I might put this logic into the sprite init code.

Apart from these the main concern I have with all this is watermarks, cxsr,
vblank waits etc. I can't see anything here to explain how it's going to
actually work so I suspect there will be problems.

> +
> + plane = intel_plane_init(dev, pipe, sprite, plane_type);
> + if (IS_ERR(plane)) {
> + DRM_DEBUG_KMS("pipe %c sprite %c init failed: %ld\n",
> + pipe_name(pipe), sprite_name(pipe, 
> sprite), PTR_ERR(plane));
> + goto fail;
> + }
> +
> + if (plane_type == DRM_PLANE_TYPE_CURSOR)
> + 

Re: [Intel-gfx] [PATCH 2/3] drm/dp/i915: Clean up clock configuration for HDMI audio

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 10:52 +0300, Jani Nikula wrote:
> On Thu, 11 Aug 2016, Dhinakaran Pandiyan  
> wrote:
> > No functional change, just clean up. Debug messages now print out clock
> > units. Additionally, the configuration bits, which are 1:1 mapped to the
> > clock frequency and don't convey much information are not printed out.
> 
> IMO the cleanups here are subjective, i.e. another day someone might
> come in and rewrite it back to having just one code path for return
> instead of many. And someone might prefer early returns for errors.

Fair enough. The change in return style is subjective, I will drop this
patch. Thanks for pointing it out.

> If you really wanted to clean this up, you could abstract the config
> lookup based on clock, and it would be a less subjective improvement.
> 
I guess, this would involve an additional data structure. I will leave
it as it is.

> >
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 20 
> >  1 file changed, 8 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 3efce0e..9465f54 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -104,21 +104,17 @@ static u32 audio_config_hdmi_pixel_clock(const struct 
> > drm_display_mode *adjusted
> > int i;
> >  
> > for (i = 0; i < ARRAY_SIZE(hdmi_audio_clock); i++) {
> > -   if (adjusted_mode->crtc_clock == hdmi_audio_clock[i].clock)
> > -   break;
> > -   }
> > -
> > -   if (i == ARRAY_SIZE(hdmi_audio_clock)) {
> > -   DRM_DEBUG_KMS("HDMI audio pixel clock setting for %d not found, 
> > falling back to defaults\n",
> > - adjusted_mode->crtc_clock);
> > -   i = 1;
> > +   if (adjusted_mode->crtc_clock == hdmi_audio_clock[i].clock) {
> > +   DRM_DEBUG_KMS("Configuring audio for HDMI pixel clk 
> > %dkHz\n",
> > + hdmi_audio_clock[i].clock);
> > +   return hdmi_audio_clock[i].config;
> > +   }
> > }
> >  
> > -   DRM_DEBUG_KMS("Configuring HDMI audio for pixel clock %d (0x%08x)\n",
> > - hdmi_audio_clock[i].clock,
> > - hdmi_audio_clock[i].config);
> > +   DRM_DEBUG_KMS("No config. for HDMI pixel clk %dkHz, using default 
> > %dkHz\n",
> 
> Please at least fix the typos.
> 
Probably the abbreviation was not obvious. I guess, the clock frequency
units are standard in i915 too. Thanks for you time.

> > + adjusted_mode->crtc_clock, hdmi_audio_clock[1].clock);
> >  
> > -   return hdmi_audio_clock[i].config;
> > +   return hdmi_audio_clock[1].config;
> >  }
> >  
> >  static int audio_config_get_n(const struct drm_display_mode *mode, int 
> > rate)
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Eliminate redundant local variable definition

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 08:09 +0100, Chris Wilson wrote:
> On Wed, Aug 10, 2016 at 11:41:13PM -0700, Dhinakaran Pandiyan wrote:
> > No functional change, just clean up.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> Reviewed-by: Chris Wilson 
> 
> A quick conversion to kernel types would also be appreciated.
> -Chris
> 
Thanks for the review.

Just so that I don't misunderstand, do you mean this?
 /s/uint32_t/u32  
 /s/uint8_t/u8 


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: intel_dp_link_is_valid() should only return status of link

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 15:23 -0700, Manasi Navare wrote:
> Intel_dp_link_is_valid() function reads the Link status registers
> and returns a boolean to indicate link is valid or not.
> If the link has lost lock and is not valid any more, link
> training is performed outside the function else previously trained link
> is retained.
> This gives us flexibility of checking whether link is valid and training
> it independently.
> 
> v2:
> * Changed the function name from intel_dp_check_link_status()
> to intel_dp_link_is_valid()  (Lukas Wunner)
> * Checks for CRTC and active CRTC are moved outside the
> intel_dp_link_is_valid() function (Rodrigo Vivi)
> 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 56 
> +++--
>  1 file changed, 37 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 364db90..891147d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3881,36 +3881,33 @@ go_again:
>   return -EINVAL;
>  }
>  
> -static void
> -intel_dp_check_link_status(struct intel_dp *intel_dp)
> +static bool
> +intel_dp_link_is_valid(struct intel_dp *intel_dp)
>  {
> - struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
>   u8 link_status[DP_LINK_STATUS_SIZE];
>  
>   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>  
>   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> - DRM_ERROR("Failed to get link status\n");
> - return;
> + DRM_DEBUG_KMS("Failed to get link status\n");
> + return false;
>   }
>  
> - if (!intel_encoder->base.crtc)
> - return;
> + /* Check if the link is valid by reading the bits of Link status
> +  * registers
> +  */
> + if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
> + DRM_DEBUG_KMS("Channel EQ or CR not ok, need to retrain\n");
drm_dp_channel_eq_ok() does not check for CR. Should we just say
"Channel EQ not ok" to preempt ambiguity while debugging ?

> + return false;
> + }
>  
> - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> - return;
> + DRM_DEBUG_KMS("Link is good, no need to retrain\n");
The caller does not expect us to link train anymore, I don't think we
have to explicitly state "no need to retrain". Also, do we need debug
messages if the link is good?

> + return true;
>  
> - /* if link training is requested we should perform it always */
> - if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
> - (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
> - DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
> -   intel_encoder->base.name);
> - intel_dp_start_link_train(intel_dp);
> - intel_dp_stop_link_train(intel_dp);
> - }
>  }
>  
> +
>  /*
>   * According to DP spec
>   * 5.1.2:
> @@ -3928,6 +3925,8 @@ static bool
>  intel_dp_short_pulse(struct intel_dp *intel_dp)
>  {
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct intel_encoder *intel_encoder = _dig_port->base;
>   u8 sink_irq_vector = 0;
>   u8 old_sink_count = intel_dp->sink_count;
>   bool ret;
> @@ -3968,8 +3967,18 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>   DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
>   }
>  
> + /* Do not train the link if there is no crtc */
> + if (!intel_encoder->base.crtc)
> + return true;
> + if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> + return true;
> +
I might be completely off base here. Shouldn't we keep the link valid
irrespective of whether there is an active crtc? I thought that is what
the refactoring is supposed to enable. Does intel_dp_short_pulse() get
called when there is a link loss during upfront link training? And in
that case, shouldn't we retrain even without a crtc? 

Besides that, how about using just one return?

struct drm_crtc *crtc = intel_encoder->base.crtc;

if (crtc == NULL || !to_intel_crtc(crtc)->active)
return true;


>   drm_modeset_lock(>mode_config.connection_mutex, NULL);
> - intel_dp_check_link_status(intel_dp);
> + if (!intel_dp_link_is_valid(intel_dp) ||
> + intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) {
> + intel_dp_start_link_train(intel_dp);
> + intel_dp_stop_link_train(intel_dp);
> + }
>   drm_modeset_unlock(>mode_config.connection_mutex);
>  
>   return true;
> @@ -4298,8 +4307,17 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>* check links status, there has been known 

Re: [Intel-gfx] [PATCH 1/2] A Helper function that returns available link bandwidth

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 16:41 -0700, Anusha Srivatsa wrote:
> drm/dp/mst
> 
> Signed-off-by: Anusha Srivatsa 
> 
> Add a function that returns the available link bandwidth for
> MST port so that we can accurately determine whether a new
> mode is valid for the link or not.
> 

The Signed-off line should follow the explanation body.

> Cc: dri-de...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 12 
>  include/drm/drm_dp_mst_helper.h   |  1 +
>  2 files changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 04e4571..7a239f6 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -43,6 +43,8 @@ static bool dump_dp_payload_table(struct 
> drm_dp_mst_topology_mgr *mgr,
> char *buf);
>  static int test_calc_pbn_mode(void);
>  
> +int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct 
> drm_dp_mst_port *port);
> +
>  static void drm_dp_put_port(struct drm_dp_mst_port *port);
>  
>  static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
> @@ -2730,6 +2732,16 @@ static int test_calc_pbn_mode(void)
>   return 0;
>  }
>  
> +int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct 
> drm_dp_mst_port *port)
> +{
> +port = drm_dp_get_validated_port_ref(mgr,port);
> +if (port)
> +return port->available_pbn;
> +
> +return -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_dp_mst_get_avail_pbn);
> +
>  /* we want to kick the TX after we've ack the up/down IRQs. */
>  static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr)
>  {
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 0032076..74dc4ab 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -576,6 +576,7 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector 
> *connector, struct drm_dp_
>  
>  int drm_dp_calc_pbn_mode(int clock, int bpp);
>  
> +int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct 
> drm_dp_mst_port *port);
>  
>  bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct 
> drm_dp_mst_port *port, int pbn, int *slots);
>  

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] Validate modes against available link bandwidth

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 16:41 -0700, Anusha Srivatsa wrote:
> drm/dp/mst/i915
> 
> Signed-off-by: Anusha Srivatsa 
> 
> Validate the modes against available link bandwidth rather than
> maximum link bandwidth so that we have a better idea as to whether
> a proposed mode can truly run beside existing stream.

The Signed-off line follows the explanation body.
https://www.kernel.org/doc/Documentation/SubmittingPatches

> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 629337d..e7e87d7 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -352,13 +352,23 @@ static enum drm_mode_status
>  intel_dp_mst_mode_valid(struct drm_connector *connector,
>   struct drm_display_mode *mode)
>  {
> + int req_pbn = 0;
> + int avail_pbn = 0;
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> + struct intel_dp *intel_dp = intel_connector->mst_port;
> + struct drm_dp_mst_topology_mgr *mgr = _dp->mst_mgr;
> + struct drm_dp_mst_port *port = (struct drm_dp_mst_port *) 
> (intel_connector->port);
>   int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
>  
> - /* TODO - validate mode against available PBN for link */
> + avail_pbn = drm_dp_mst_get_avail_pbn(mgr, port);
> + req_pbn = drm_dp_calc_pbn_mode(mode->clock, 24);
> + if (req_pbn > avail_pbn)
> + return MODE_H_ILLEGAL;
> +
>   if (mode->clock < 1)
>   return MODE_CLOCK_LOW;
>  
> - if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> +if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>   return MODE_H_ILLEGAL;
>  
>   if (mode->clock > max_dotclk)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Wed, 2016-08-10 at 17:21 +0300, Ville Syrjälä wrote:
> On Tue, Aug 09, 2016 at 01:58:33PM -0700, Dhinakaran Pandiyan wrote:
> > DP MST provides the capability to send multiple video and audio streams
> > through a single port. This requires the API's between i915 and audio
> > drivers to distinguish between multiple audio capable displays that can be
> > connected to a port. Currently only the port identity is shared in the
> > APIs. This patch adds support for MST with an additional parameter
> > 'int pipe'.  The existing parameter 'port' does not change it's meaning.
> > 
> > pipe =
> > MST : display pipe that the stream originates from
> > Non-MST : -1
> > 
> > Affected APIs:
> > struct i915_audio_component_ops
> > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > +   int (*sync_audio_rate)(struct device *, int port, int pipe,
> > +int rate);
> > 
> > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > -   unsigned char *buf, int max_bytes);
> > +   int (*get_eld)(struct device *, int port, int pipe,
> > +  bool *enabled, unsigned char *buf, int max_bytes);
> > 
> > struct i915_audio_component_audio_ops
> > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > +   void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);
> > 
> > This patch makes dummy changes in the audio drivers (Libin) for build to
> > succeed. The audio side drivers will send the right 'pipe' values in
> > patches that will follow.
> > 
> > v2:
> > Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville)
> > Included Asoc driver API compatibility changes from Jeeja.
> > Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
> > Added comment for av_enc_map[] definition. (Takashi)
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  3 +-
> >  drivers/gpu/drm/i915/intel_audio.c | 92 
> > ++
> >  include/drm/i915_component.h   |  6 +--
> >  include/sound/hda_i915.h   | 11 ++---
> >  sound/hda/hdac_i915.c  |  9 ++--
> >  sound/pci/hda/patch_hdmi.c |  7 +--
> >  sound/soc/codecs/hdac_hdmi.c   |  2 +-
> >  7 files changed, 85 insertions(+), 45 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c36d176..8e4a88f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2036,7 +2036,8 @@ struct drm_i915_private {
> > /* perform PHY state sanity checks? */
> > bool chv_phy_assert[2];
> >  
> > -   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > +   /* Used to save the pipe-to-encoder mapping for audio */
> > +   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> >  
> > /*
> >  * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index ef20875..240dad2 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -500,6 +500,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > enum port port = intel_dig_port->port;
> > +   enum pipe pipe = -1;
> >  
> > connector = drm_select_eld(encoder);
> > if (!connector)
> > @@ -524,12 +525,18 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> >  
> > mutex_lock(_priv->av_mutex);
> > intel_encoder->audio_connector = connector;
> > +
> > /* referred in audio callbacks */
> > -   dev_priv->dig_port_map[port] = intel_encoder;
> > +   dev_priv->av_enc_map[pipe] = intel_encoder;
> 
> [-1] doesn't look right.
> 
Fixed this, thanks for the review.
> > mutex_unlock(_priv->av_mutex);
> >  
> > +
> > +   if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> > +   pipe = crtc->pipe;
> > +
> > if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> > -   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, 
> > (int) port);
> > +   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> > +(int) port, (int) pipe);
> >  }
> >  
> >  /**
> > @@ -542,22 +549,28 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> >  void intel_audio_codec_disable(struct intel_encoder *intel_encoder)
> >  {
> > struct drm_encoder *encoder = _encoder->base;
> > +   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > struct drm_device *dev = encoder->dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > struct 

Re: [Intel-gfx] [PATCH] drm/i915: Fix braces in conditonal branches

[Pandiyan, Dhinakaran]

On Tue, 2016-08-09 at 23:08 +0100, Chris Wilson wrote:
> On Tue, Aug 09, 2016 at 03:06:10PM -0700, Dhinakaran Pandiyan wrote:
> > No functional change, just adding braces to all branches of conditional
> > statement because one of them already had.
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index d32f586..26a795f 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -335,11 +335,11 @@ static void hsw_audio_codec_enable(struct 
> > drm_connector *connector,
> >  
> > tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
> > if (audio_rate_need_prog(intel_crtc, adjusted_mode)) {
> > -   if (!acomp)
> > +   if (!acomp) {
> > rate = 0;
> > -   else if (port >= PORT_A && port <= PORT_E)
> > +   } else if (port >= PORT_A && port <= PORT_E) {
> > rate = acomp->aud_sample_rate[port];
> > -   else {
> > +   } else {
> > DRM_ERROR("invalid port: %d\n", port);
> > rate = 0;
> > }
> 
> Or you could improve scoping of the locals and eliminate a few lines
> whilst adding more information to the debug:
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index d32f586..98d4576 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -282,14 +282,9 @@ static void hsw_audio_codec_enable(struct drm_connector 
> *connector,
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> enum pipe pipe = intel_crtc->pipe;
> -   struct i915_audio_component *acomp = dev_priv->audio_component;
> const uint8_t *eld = connector->eld;
> -   struct intel_digital_port *intel_dig_port =
> -   enc_to_dig_port(>base);
> -   enum port port = intel_dig_port->port;
> uint32_t tmp;
> int len, i;
> -   int n, rate;
>  
> DRM_DEBUG_KMS("Enable audio codec on pipe %c, %u bytes ELD\n",
>   pipe_name(pipe), drm_eld_size(eld));
> @@ -335,19 +330,18 @@ static void hsw_audio_codec_enable(struct drm_connector 
> *connector,
>  
> tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
> if (audio_rate_need_prog(intel_crtc, adjusted_mode)) {
> -   if (!acomp)
> -   rate = 0;
> -   else if (port >= PORT_A && port <= PORT_E)
> +   enum port port = enc_to_dig_port(_base)->port;
> +   struct i915_audio_component *acomp = 
> dev_priv->audio_component;
> +   int rate, n;
> +
> +   rate = 0;
> +   if (acomp && port >= PORT_A && port <= PORT_E)
> rate = acomp->aud_sample_rate[port];
> -   else {
> -   DRM_ERROR("invalid port: %d\n", port);
> -   rate = 0;
> -   }
> +
> n = audio_config_get_n(adjusted_mode, rate);
> -   if (n != 0)
> +   DRM_DEBUG_KMS("port %d audio rate %d => N=%x\n", port, rate, 
> n);
> +   if (n)
> tmp = audio_config_setup_n_reg(n, tmp);
> -   else
> -   DRM_DEBUG_KMS("no suitable N value is found\n");
> }
>  
> I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> 
> 

This looks a lot cleaner. 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Wed, 2016-08-03 at 15:53 +0200, Takashi Iwai wrote:
> On Wed, 03 Aug 2016 04:14:30 +0200,
> Dhinakaran Pandiyan wrote:
> > 
> > DP MST provides the capability to send multiple video and audio streams via
> > one single port. This requires the API's between i915 and audio drivers to
> > distinguish between audio capable displays connected to a port. This patch
> > adds this support via an additional parameter 'int dev_id'. The existing
> > parameter 'port' does not change it's meaning.
> > 
> > dev_id =
> > MST : pipe that the stream originates from
> > Non-MST : -1
> > 
> > Affected APIs:
> > struct i915_audio_component_ops
> > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > +   int (*sync_audio_rate)(struct device *, int port, int dev_id,
> > +int rate);
> > 
> > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > -   unsigned char *buf, int max_bytes);
> > +   int (*get_eld)(struct device *, int port, int dev_id,
> > +  bool *enabled, unsigned char *buf, int max_bytes);
> > 
> > struct i915_audio_component_audio_ops
> > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > +   void (*pin_eld_notify)(void *audio_ptr, int port, int dev_id);
> > 
> > This patch makes dummy changes in the audio drivers for build to succeed.
> 
> OK, so the explicit dev_id will be passed in future change in the
> audio side, right?  It'd be good to write up the grand plan.
> 
Yes, that's right. I will explain that and copy the cover-letter text
here.

> 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  2 +-
> >  drivers/gpu/drm/i915/intel_audio.c | 82 
> > +-
> >  include/drm/i915_component.h   |  6 +--
> >  include/sound/hda_i915.h   | 11 ++---
> >  sound/hda/hdac_i915.c  |  9 +++--
> >  sound/pci/hda/patch_hdmi.c |  7 ++--
> >  6 files changed, 82 insertions(+), 35 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 65ada5d..8e4c8c8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2054,7 +2054,7 @@ struct drm_i915_private {
> > /* perform PHY state sanity checks? */
> > bool chv_phy_assert[2];
> >  
> > -   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > +   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> 
> Better to have a comment for this field.
Will add one.
> 
> 
> > -static int i915_audio_component_sync_audio_rate(struct device *dev,
> > -   int port, int rate)
> > +static struct intel_encoder *get_saved_encoder(struct intel_encoder 
> > *av_enc_map[],
> > +  int port, int dev_id)
> > +{
> > +
> > +   enum pipe pipe;
> > +   struct drm_encoder *encoder;
> > +
> > +   if (dev_id >= 0 && dev_id < I915_MAX_PIPES)
> > +   return av_enc_map[dev_id];
> 
> Actually dev_id >= I915_MAX_PIPES is an invalid call, and worth to
> catch with WARN_ON() and bail out.
Sure, thanks for the review.
> 
> thanks,
> 
> Takashi
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Wed, 2016-08-03 at 22:08 +0300, Ville Syrjälä wrote:
> On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > DP MST provides the capability to send multiple video and audio streams via
> > one single port. This requires the API's between i915 and audio drivers to
> > distinguish between audio capable displays connected to a port. This patch
> > adds this support via an additional parameter 'int dev_id'. The existing
> > parameter 'port' does not change it's meaning.
> > 
> > dev_id =
> > MST : pipe that the stream originates from
> > Non-MST : -1
> > 
> > Affected APIs:
> > struct i915_audio_component_ops
> > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > +   int (*sync_audio_rate)(struct device *, int port, int dev_id,
> 
> Does the term 'dev_id' have some special meaning on the audio side? On
> the i915 side things would be less confusing if we just called it
> 'pipe'.
> 

There was quite a bit of back and forth on this. "pipe" seemed to tie us
to the gfx hardware architecture. In case, there is no 1:1 mapping from
pipes to encoders, this will get confusing as i915 audio registers
(E.g.HSW_AUD_PIN_ELD_CP_VLD) are encoder based. Whereas, dev_id is
generic - HDA spec calls them "devices" or "device entry"


> > +int rate);
> > 
> > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > -   unsigned char *buf, int max_bytes);
> > +   int (*get_eld)(struct device *, int port, int dev_id,
> > +  bool *enabled, unsigned char *buf, int max_bytes);
> > 
> > struct i915_audio_component_audio_ops
> > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > +   void (*pin_eld_notify)(void *audio_ptr, int port, int dev_id);
> > 
> > This patch makes dummy changes in the audio drivers for build to succeed.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  2 +-
> >  drivers/gpu/drm/i915/intel_audio.c | 82 
> > +-
> >  include/drm/i915_component.h   |  6 +--
> >  include/sound/hda_i915.h   | 11 ++---
> >  sound/hda/hdac_i915.c  |  9 +++--
> >  sound/pci/hda/patch_hdmi.c |  7 ++--
> >  6 files changed, 82 insertions(+), 35 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 65ada5d..8e4c8c8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2054,7 +2054,7 @@ struct drm_i915_private {
> > /* perform PHY state sanity checks? */
> > bool chv_phy_assert[2];
> >  
> > -   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > +   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> >  
> > /*
> >  * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 8c493de..cbe44c8 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -500,6 +500,9 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > enum port port = intel_dig_port->port;
> > +   enum pipe pipe = crtc->pipe;
> > +   int dev_id = -1;
> > +
> >  
> > connector = drm_select_eld(encoder);
> > if (!connector)
> > @@ -522,14 +525,19 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> > dev_priv->display.audio_codec_enable(connector, intel_encoder,
> >  adjusted_mode);
> >  
> > +   if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> > +   dev_id = pipe;
> > +
> > mutex_lock(_priv->av_mutex);
> > intel_encoder->audio_connector = connector;
> > +
> > /* referred in audio callbacks */
> > -   dev_priv->dig_port_map[port] = intel_encoder;
> > +   dev_priv->av_enc_map[pipe] = intel_encoder;
> > mutex_unlock(_priv->av_mutex);
> >  
> > if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> > -   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, 
> > (int) port);
> > +   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> > +(int) port, dev_id);
> >  }
> >  
> >  /**
> > @@ -542,22 +550,29 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> >  void intel_audio_codec_disable(struct intel_encoder *intel_encoder)
> >  {
> > struct drm_encoder *encoder = _encoder->base;
> > +   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > struct drm_device *dev = encoder->dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct i915_audio_component *acomp = dev_priv->audio_component;

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Thu, 2016-08-04 at 15:49 +0300, Ville Syrjälä wrote:
> On Wed, Aug 03, 2016 at 09:42:53PM +0000, Pandiyan, Dhinakaran wrote:
> > On Wed, 2016-08-03 at 23:28 +0300, Ville Syrjälä wrote:
> > > On Wed, Aug 03, 2016 at 07:43:06PM +, Pandiyan, Dhinakaran wrote:
> > > > On Wed, 2016-08-03 at 22:08 +0300, Ville Syrjälä wrote:
> > > > > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > DP MST provides the capability to send multiple video and audio 
> > > > > > streams via
> > > > > > one single port. This requires the API's between i915 and audio 
> > > > > > drivers to
> > > > > > distinguish between audio capable displays connected to a port. 
> > > > > > This patch
> > > > > > adds this support via an additional parameter 'int dev_id'. The 
> > > > > > existing
> > > > > > parameter 'port' does not change it's meaning.
> > > > > > 
> > > > > > dev_id =
> > > > > > MST : pipe that the stream originates from
> > > > > > Non-MST : -1
> > > > > > 
> > > > > > Affected APIs:
> > > > > > struct i915_audio_component_ops
> > > > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > > > +   int (*sync_audio_rate)(struct device *, int port, int dev_id,
> > > > > 
> > > > > Does the term 'dev_id' have some special meaning on the audio side? On
> > > > > the i915 side things would be less confusing if we just called it
> > > > > 'pipe'.
> > > > > 
> > > > 
> > > > There was quite a bit of back and forth on this. "pipe" seemed to tie us
> > > > to the gfx hardware architecture. In case, there is no 1:1 mapping from
> > > > pipes to encoders, this will get confusing as i915 audio registers
> > > > (E.g.HSW_AUD_PIN_ELD_CP_VLD) are encoder based.
> > > 
> > > I'm not following. Looking at the current i915 audio code, on HSW+
> > > everything is pipe based.
> > > 
> > Although we pass "pipe" to these macros, the definition here and in the
> > BSpec seem to indicate they are based on the encoder.
> > 
> > Eg: #define HSW_AUD_PIN_ELD_CP_VLD  _MMIO(0x650c0)
> > #define   AUDIO_INACTIVE(trans) ((1 << 3) << ((trans) * 4))
> > #define   AUDIO_OUTPUT_ENABLE(trans)((1 << 2) << ((trans) * 4))
> > #define   AUDIO_CP_READY(trans) ((1 << 1) << ((trans) * 4))
> > #define   AUDIO_ELD_VALID(trans)((1 << 0) << ((trans) * 4))
> 
> That's transcoder, not encoder. transcoder is the tail end of the pipe.
> For all the external ports transcoder==pipe, and for port A there is the
> special edp transcoder which can be fed by any pipe. The edp transcoder
> doesn't support audio though, and I can't see anything in the spec to
> suggest that it would gain audio capabilities, in the near future at
> least. So from that point of view passing around the pipe would seem
> like a safe approach.
> 
> We could of course pass around transcoder instead of pipe. Since we
> don't ever need to enable audio on the edp transcoder, we don't even
> have to worry about what number we assign to it. And hence it is
> actually the same as passing the pipe, except in name.
> 

Thanks for the detailed explanation, makes sense to change it to "pipe".
I will send out a new version. Do you recommend I send this patch with 
"Prep. for DP audio MST support" series
(https://lists.freedesktop.org/archives/intel-gfx/2016-August/102399.html)? 
This patch depends on the some of the patches in that. I had separated this 
patch out because of the audio driver changes in this.
> > 
> > 
> > > > Whereas, dev_id is
> > > > generic - HDA spec calls them "devices" or "device entry"
> > > 
> > > Generic and totally unclear what it means from graphics side.
> > > 
> > > pipe and port are the only things we really have in i915. If those aren't
> > > good enough for the audio side, then I think we should have some decent
> > > code to remap between the pipe+port vs. whatever audio side id is needed.
> > > I don't really care on which side of the border such code would live, as
> > > long as it's clear what it's doing.
> > > 
> > 
> > I agree, dev_id can be misleading within i915.
> > > > 
> > > > >

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Fri, 2016-08-12 at 08:18 +0300, Ville Syrjälä wrote:
> On Fri, Aug 12, 2016 at 04:28:09AM +0000, Pandiyan, Dhinakaran wrote:
> > On Thu, 2016-08-11 at 10:39 +0300, Ville Syrjälä wrote:
> > > On Thu, Aug 11, 2016 at 07:10:39AM +, Pandiyan, Dhinakaran wrote:
> > > > On Thu, 2016-08-11 at 09:26 +0300, Ville Syrjälä wrote:
> > > > > On Wed, Aug 10, 2016 at 12:41:57PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > DP MST provides the capability to send multiple video and audio 
> > > > > > streams
> > > > > > through a single port. This requires the API's between i915 and 
> > > > > > audio
> > > > > > drivers to distinguish between multiple audio capable displays that 
> > > > > > can be
> > > > > > connected to a port. Currently only the port identity is shared in 
> > > > > > the
> > > > > > APIs. This patch adds support for MST with an additional parameter
> > > > > > 'int pipe'.  The existing parameter 'port' does not change it's 
> > > > > > meaning.
> > > > > > 
> > > > > > pipe =
> > > > > > MST : display pipe that the stream originates from
> > > > > > Non-MST : -1
> > > > > > 
> > > > > > Affected APIs:
> > > > > > struct i915_audio_component_ops
> > > > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > > > +   int (*sync_audio_rate)(struct device *, int port, int pipe,
> > > > > > +int rate);
> > > > > > 
> > > > > > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > > > > > -   unsigned char *buf, int max_bytes);
> > > > > > +   int (*get_eld)(struct device *, int port, int pipe,
> > > > > > +  bool *enabled, unsigned char *buf, int 
> > > > > > max_bytes);
> > > > > > 
> > > > > > struct i915_audio_component_audio_ops
> > > > > > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > > > > > +   void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);
> > > > > > 
> > > > > > This patch makes dummy changes in the audio drivers (Libin) for 
> > > > > > build to
> > > > > > succeed. The audio side drivers will send the right 'pipe' values in
> > > > > > patches that will follow.
> > > > > > 
> > > > > > v2:
> > > > > > Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville)
> > > > > > Included Asoc driver API compatibility changes from Jeeja.
> > > > > > Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
> > > > > > Added comment for av_enc_map[] definition. (Takashi)
> > > > > > 
> > > > > > v3:
> > > > > > Fixed logic error introduced while renaming 'dev_id' as 'pipe' 
> > > > > > (Ville)
> > > > > > Renamed get_saved_encoder() to get_saved_enc() to reduce line length
> > > > > > 
> > > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/i915_drv.h|  3 +-
> > > > > >  drivers/gpu/drm/i915/intel_audio.c | 93 
> > > > > > ++
> > > > > >  include/drm/i915_component.h   |  6 +--
> > > > > >  include/sound/hda_i915.h   | 11 +++--
> > > > > >  sound/hda/hdac_i915.c  |  9 ++--
> > > > > >  sound/pci/hda/patch_hdmi.c |  7 +--
> > > > > >  sound/soc/codecs/hdac_hdmi.c   |  2 +-
> > > > > >  7 files changed, 86 insertions(+), 45 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > index c36d176..8e4a88f 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > > @@ -2036,7 +2036,8 @@ struct drm_i915_private {
> > > > > > /* perform PHY state sanity checks? */
> > > > > > bool chv_phy_assert[2]

Re: [Intel-gfx] [PATCH v2] drm/i915: intel_dp_link_is_valid() should only return status of link

[Pandiyan, Dhinakaran]

On Fri, 2016-08-12 at 10:56 -0700, Manasi Navare wrote:
> On Thu, Aug 11, 2016 at 08:18:54PM -0700, Pandiyan, Dhinakaran wrote:
> > On Thu, 2016-08-11 at 15:23 -0700, Manasi Navare wrote:
> > > Intel_dp_link_is_valid() function reads the Link status registers
> > > and returns a boolean to indicate link is valid or not.
> > > If the link has lost lock and is not valid any more, link
> > > training is performed outside the function else previously trained link
> > > is retained.
> > > This gives us flexibility of checking whether link is valid and training
> > > it independently.
> > > 
> > > v2:
> > > * Changed the function name from intel_dp_check_link_status()
> > > to intel_dp_link_is_valid()  (Lukas Wunner)
> > > * Checks for CRTC and active CRTC are moved outside the
> > > intel_dp_link_is_valid() function (Rodrigo Vivi)
> > > 
> > > Signed-off-by: Manasi Navare <manasi.d.nav...@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 56 
> > > +++--
> > >  1 file changed, 37 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 364db90..891147d 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -3881,36 +3881,33 @@ go_again:
> > >   return -EINVAL;
> > >  }
> > >  
> > > -static void
> > > -intel_dp_check_link_status(struct intel_dp *intel_dp)
> > > +static bool
> > > +intel_dp_link_is_valid(struct intel_dp *intel_dp)
> > >  {
> > > - struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
> > >   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > >   u8 link_status[DP_LINK_STATUS_SIZE];
> > >  
> > >   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> > >  
> > >   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > > - DRM_ERROR("Failed to get link status\n");
> > > - return;
> > > + DRM_DEBUG_KMS("Failed to get link status\n");
> > > + return false;
> > >   }
> > >  
> > > - if (!intel_encoder->base.crtc)
> > > - return;
> > > + /* Check if the link is valid by reading the bits of Link status
> > > +  * registers
> > > +  */
> > > + if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
> > > + DRM_DEBUG_KMS("Channel EQ or CR not ok, need to retrain\n");
> > drm_dp_channel_eq_ok() does not check for CR. Should we just say
> > "Channel EQ not ok" to preempt ambiguity while debugging ?
> 
> Actually this macro checks for DP_CHANNEL_EQ_BITS which is defined as:
> #define DP_CHANNEL_EQ_BITS (DP_LANE_CR_DONE |   \
> DP_LANE_CHANNEL_EQ_DONE |   \
> DP_LANE_SYMBOL_LOCKED)
> So it includes checking for Channel EQ and Clock Recovery CR bits
> 
> 

Thank you, I should have looked hard. I will leave this to you. 

> > 
> > > + return false;
> > > + }
> > >  
> > > - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> > > - return;
> > > + DRM_DEBUG_KMS("Link is good, no need to retrain\n");
> > The caller does not expect us to link train anymore, I don't think we
> > have to explicitly state "no need to retrain". Also, do we need debug
> > messages if the link is good?
> 
> I agree , maybe this is not needed. I will remove this
> 
> > 
> > > + return true;
> > >  
> > > - /* if link training is requested we should perform it always */
> > > - if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
> > > - (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
> > > - DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
> > > -   intel_encoder->base.name);
> > > - intel_dp_start_link_train(intel_dp);
> > > - intel_dp_stop_link_train(intel_dp);
> > > - }
> > >  }
> > >  
> > > +
> > >  /*
> > >   * According to DP spec
> > >   * 5.1.2:
> > > @@ -3928,6 +3925,8 @@ static bool
> > >  intel_dp_short_pulse(struct intel_dp *intel_dp)
> > >  {
> > >   struct drm_device *dev = intel_dp_to_dev(intel_dp);
&

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Sat, 2016-08-13 at 00:16 +, Pandiyan, Dhinakaran wrote:
> On Fri, 2016-08-12 at 08:18 +0300, Ville Syrjälä wrote:
> > On Fri, Aug 12, 2016 at 04:28:09AM +, Pandiyan, Dhinakaran wrote:
> > > On Thu, 2016-08-11 at 10:39 +0300, Ville Syrjälä wrote:
> > > > On Thu, Aug 11, 2016 at 07:10:39AM +, Pandiyan, Dhinakaran wrote:
> > > > > On Thu, 2016-08-11 at 09:26 +0300, Ville Syrjälä wrote:
> > > > > > On Wed, Aug 10, 2016 at 12:41:57PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > > DP MST provides the capability to send multiple video and audio 
> > > > > > > streams
> > > > > > > through a single port. This requires the API's between i915 and 
> > > > > > > audio
> > > > > > > drivers to distinguish between multiple audio capable displays 
> > > > > > > that can be
> > > > > > > connected to a port. Currently only the port identity is shared 
> > > > > > > in the
> > > > > > > APIs. This patch adds support for MST with an additional parameter
> > > > > > > 'int pipe'.  The existing parameter 'port' does not change it's 
> > > > > > > meaning.
> > > > > > > 
> > > > > > > pipe =
> > > > > > >   MST : display pipe that the stream originates from
> > > > > > >   Non-MST : -1
> > > > > > > 
> > > > > > > Affected APIs:
> > > > > > > struct i915_audio_component_ops
> > > > > > > -   int (*sync_audio_rate)(struct device *, int port, int 
> > > > > > > rate);
> > > > > > > + int (*sync_audio_rate)(struct device *, int port, int pipe,
> > > > > > > +  int rate);
> > > > > > > 
> > > > > > > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > > > > > > -   unsigned char *buf, int max_bytes);
> > > > > > > +   int (*get_eld)(struct device *, int port, int pipe,
> > > > > > > +bool *enabled, unsigned char *buf, int 
> > > > > > > max_bytes);
> > > > > > > 
> > > > > > > struct i915_audio_component_audio_ops
> > > > > > > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > > > > > > +   void (*pin_eld_notify)(void *audio_ptr, int port, int 
> > > > > > > pipe);
> > > > > > > 
> > > > > > > This patch makes dummy changes in the audio drivers (Libin) for 
> > > > > > > build to
> > > > > > > succeed. The audio side drivers will send the right 'pipe' values 
> > > > > > > in
> > > > > > > patches that will follow.
> > > > > > > 
> > > > > > > v2:
> > > > > > > Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, 
> > > > > > > Ville)
> > > > > > > Included Asoc driver API compatibility changes from Jeeja.
> > > > > > > Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
> > > > > > > Added comment for av_enc_map[] definition. (Takashi)
> > > > > > > 
> > > > > > > v3:
> > > > > > > Fixed logic error introduced while renaming 'dev_id' as 'pipe' 
> > > > > > > (Ville)
> > > > > > > Renamed get_saved_encoder() to get_saved_enc() to reduce line 
> > > > > > > length
> > > > > > > 
> > > > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/i915_drv.h|  3 +-
> > > > > > >  drivers/gpu/drm/i915/intel_audio.c | 93 
> > > > > > > ++
> > > > > > >  include/drm/i915_component.h   |  6 +--
> > > > > > >  include/sound/hda_i915.h   | 11 +++--
> > > > > > >  sound/hda/hdac_i915.c  |  9 ++--
> > > > > > >  sound/pci/hda/patch_hdmi.c |  7 +--
> > > > > > >  sound/soc/codecs/hdac_hdmi.c   |  2 +-
> > > > > > >  7 files changed, 86 insertions(+), 45 deletions(-)
> > > > > &

Re: [Intel-gfx] drm/i915/fbc: disable FBC on FIFO underruns

[Pandiyan, Dhinakaran]

On Fri, 2016-06-10 at 22:18 -0300, Paulo Zanoni wrote:
> Ever since I started working on FBC I was already aware that FBC can
> really amplify the FIFO underrun symptoms. On systems where FIFO
> underruns were harmless error messages, enabling FBC would cause the
> underruns to give black screens.
> 

Do we know why we get black screens in this scenario?

> We recently tried to enable FBC on Haswell and got reports of a system
> that would hang after some hours of uptime, and the first bad commit
> was the one that enabled FBC. We also observed that this system had
> FIFO underrun error messages on its dmesg. Although we don't have any
> evidence that fixing the underruns would solve the bug and make FBC
> work properly on this machine, IMHO it's better if we minimize the
> amount of possible problems by just giving up FBC whenever we detect
> an underrun.
> 
> v2: new version, different implementation and commit message.
> 
> Cc: Stefan Richter 
> Cc: Lyude 
> Cc: Steven Honeyman 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  3 ++
>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_fbc.c   | 53 
> ++
>  drivers/gpu/drm/i915/intel_fifo_underrun.c |  2 ++
>  4 files changed, 59 insertions(+)
> 
> 
> Since my test machines don't produce FIFO underrun errors, I tested this by
> creating a debugfs file that just calls intel_fbc_handle_fifo_underrun(). I'd
> appreciate some Tested-by tags, if possible.
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 20a676d..18b4257 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -908,6 +908,9 @@ struct intel_fbc {
>   bool enabled;
>   bool active;
>  
> + bool underrun_detected;
> + struct work_struct underrun_work;
> +
>   struct intel_fbc_state_cache {
>   struct {
>   unsigned int mode_flags;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index ebe7b34..7bf97b1 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1436,6 +1436,7 @@ void intel_fbc_invalidate(struct drm_i915_private 
> *dev_priv,
>  void intel_fbc_flush(struct drm_i915_private *dev_priv,
>unsigned int frontbuffer_bits, enum fb_op_origin origin);
>  void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
> +void intel_fbc_handle_fifo_underrun(struct drm_i915_private *dev_priv);
>  
>  /* intel_hdmi.c */
>  void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg, enum port 
> port);
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index d268f76..2363bff 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -755,6 +755,13 @@ static bool intel_fbc_can_activate(struct intel_crtc 
> *crtc)
>   struct intel_fbc *fbc = _priv->fbc;
>   struct intel_fbc_state_cache *cache = >state_cache;
>  
> + /* We don't need to use a state cache here since this information is
> +  * global for every CRTC. */
> + if (fbc->underrun_detected) {
> + fbc->no_fbc_reason = "underrun detected";
> + return false;
> + }
> +
>   if (!cache->plane.visible) {
>   fbc->no_fbc_reason = "primary plane not visible";
>   return false;
> @@ -1195,6 +1202,51 @@ void intel_fbc_global_disable(struct drm_i915_private 
> *dev_priv)
>   cancel_work_sync(>work.work);
>  }
>  
> +static void intel_fbc_underrun_work_fn(struct work_struct *work)
> +{
> + struct drm_i915_private *dev_priv =
> + container_of(work, struct drm_i915_private, fbc.underrun_work);
> + struct intel_fbc *fbc = _priv->fbc;
> +
> + mutex_lock(>lock);
> +
> + /* Maybe we were scheduled twice. */
> + if (fbc->underrun_detected)
> + goto out;
> +
> + DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
> + fbc->underrun_detected = true;
> +
> + intel_fbc_deactivate(dev_priv);
> +out:
> + mutex_unlock(>lock);
> +}
> +
> +/**
> + * intel_fbc_handle_fifo_underrun - disable FBC when we get a FIFO underrun
> + * @dev_priv: i915 device instance
> + *
> + * Without FBC, most underruns are harmless and don't really cause too many
> + * problems, except for an annoying message on dmesg. With FBC, underruns can
> + * become black screens or even worse, especially when paired with bad
> + * watermarks. So in order for us to be on the safe side, completely disable 
> FBC
> + * in case we ever detect a FIFO underrun on any pipe. An underrun on any 
> pipe
> + * already suggests that watermarks may be bad, so try to be as safe as
> + * possible.
> + */
> +void intel_fbc_handle_fifo_underrun(struct drm_i915_private *dev_priv)
> +{
> 

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 09:26 +0300, Ville Syrjälä wrote:
> On Wed, Aug 10, 2016 at 12:41:57PM -0700, Dhinakaran Pandiyan wrote:
> > DP MST provides the capability to send multiple video and audio streams
> > through a single port. This requires the API's between i915 and audio
> > drivers to distinguish between multiple audio capable displays that can be
> > connected to a port. Currently only the port identity is shared in the
> > APIs. This patch adds support for MST with an additional parameter
> > 'int pipe'.  The existing parameter 'port' does not change it's meaning.
> > 
> > pipe =
> > MST : display pipe that the stream originates from
> > Non-MST : -1
> > 
> > Affected APIs:
> > struct i915_audio_component_ops
> > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > +   int (*sync_audio_rate)(struct device *, int port, int pipe,
> > +int rate);
> > 
> > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > -   unsigned char *buf, int max_bytes);
> > +   int (*get_eld)(struct device *, int port, int pipe,
> > +  bool *enabled, unsigned char *buf, int max_bytes);
> > 
> > struct i915_audio_component_audio_ops
> > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > +   void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);
> > 
> > This patch makes dummy changes in the audio drivers (Libin) for build to
> > succeed. The audio side drivers will send the right 'pipe' values in
> > patches that will follow.
> > 
> > v2:
> > Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville)
> > Included Asoc driver API compatibility changes from Jeeja.
> > Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
> > Added comment for av_enc_map[] definition. (Takashi)
> > 
> > v3:
> > Fixed logic error introduced while renaming 'dev_id' as 'pipe' (Ville)
> > Renamed get_saved_encoder() to get_saved_enc() to reduce line length
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  3 +-
> >  drivers/gpu/drm/i915/intel_audio.c | 93 
> > ++
> >  include/drm/i915_component.h   |  6 +--
> >  include/sound/hda_i915.h   | 11 +++--
> >  sound/hda/hdac_i915.c  |  9 ++--
> >  sound/pci/hda/patch_hdmi.c |  7 +--
> >  sound/soc/codecs/hdac_hdmi.c   |  2 +-
> >  7 files changed, 86 insertions(+), 45 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c36d176..8e4a88f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2036,7 +2036,8 @@ struct drm_i915_private {
> > /* perform PHY state sanity checks? */
> > bool chv_phy_assert[2];
> >  
> > -   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > +   /* Used to save the pipe-to-encoder mapping for audio */
> > +   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> >  
> > /*
> >  * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index ef20875..a7467ea 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -500,6 +500,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > enum port port = intel_dig_port->port;
> > +   enum pipe pipe = crtc->pipe;
> >  
> > connector = drm_select_eld(encoder);
> > if (!connector)
> > @@ -524,12 +525,18 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> >  
> > mutex_lock(_priv->av_mutex);
> > intel_encoder->audio_connector = connector;
> > +
> > /* referred in audio callbacks */
> > -   dev_priv->dig_port_map[port] = intel_encoder;
> > +   dev_priv->av_enc_map[pipe] = intel_encoder;
> > mutex_unlock(_priv->av_mutex);
> >  
> > +   /* audio drivers expect pipe = -1 to indicate Non-MST cases */
> > +   if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
> > +   pipe = -1;
> > +
> > if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> > -   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, 
> > (int) port);
> > +   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> > +(int) port, (int) pipe);
> >  }
> >  
> >  /**
> > @@ -542,22 +549,29 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> >  void intel_audio_codec_disable(struct intel_encoder *intel_encoder)
> >  {
> > struct drm_encoder *encoder = _encoder->base;
> > +   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > struct drm_device *dev = 

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 10:39 +0300, Ville Syrjälä wrote:
> On Thu, Aug 11, 2016 at 07:10:39AM +0000, Pandiyan, Dhinakaran wrote:
> > On Thu, 2016-08-11 at 09:26 +0300, Ville Syrjälä wrote:
> > > On Wed, Aug 10, 2016 at 12:41:57PM -0700, Dhinakaran Pandiyan wrote:
> > > > DP MST provides the capability to send multiple video and audio streams
> > > > through a single port. This requires the API's between i915 and audio
> > > > drivers to distinguish between multiple audio capable displays that can 
> > > > be
> > > > connected to a port. Currently only the port identity is shared in the
> > > > APIs. This patch adds support for MST with an additional parameter
> > > > 'int pipe'.  The existing parameter 'port' does not change it's meaning.
> > > > 
> > > > pipe =
> > > > MST : display pipe that the stream originates from
> > > > Non-MST : -1
> > > > 
> > > > Affected APIs:
> > > > struct i915_audio_component_ops
> > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > +   int (*sync_audio_rate)(struct device *, int port, int pipe,
> > > > +int rate);
> > > > 
> > > > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > > > -   unsigned char *buf, int max_bytes);
> > > > +   int (*get_eld)(struct device *, int port, int pipe,
> > > > +  bool *enabled, unsigned char *buf, int 
> > > > max_bytes);
> > > > 
> > > > struct i915_audio_component_audio_ops
> > > > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > > > +   void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);
> > > > 
> > > > This patch makes dummy changes in the audio drivers (Libin) for build to
> > > > succeed. The audio side drivers will send the right 'pipe' values in
> > > > patches that will follow.
> > > > 
> > > > v2:
> > > > Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville)
> > > > Included Asoc driver API compatibility changes from Jeeja.
> > > > Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
> > > > Added comment for av_enc_map[] definition. (Takashi)
> > > > 
> > > > v3:
> > > > Fixed logic error introduced while renaming 'dev_id' as 'pipe' (Ville)
> > > > Renamed get_saved_encoder() to get_saved_enc() to reduce line length
> > > > 
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h|  3 +-
> > > >  drivers/gpu/drm/i915/intel_audio.c | 93 
> > > > ++
> > > >  include/drm/i915_component.h   |  6 +--
> > > >  include/sound/hda_i915.h   | 11 +++--
> > > >  sound/hda/hdac_i915.c  |  9 ++--
> > > >  sound/pci/hda/patch_hdmi.c |  7 +--
> > > >  sound/soc/codecs/hdac_hdmi.c   |  2 +-
> > > >  7 files changed, 86 insertions(+), 45 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index c36d176..8e4a88f 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2036,7 +2036,8 @@ struct drm_i915_private {
> > > > /* perform PHY state sanity checks? */
> > > > bool chv_phy_assert[2];
> > > >  
> > > > -   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > > > +   /* Used to save the pipe-to-encoder mapping for audio */
> > > > +   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> > > >  
> > > > /*
> > > >  * NOTE: This is the dri1/ums dungeon, don't add stuff here. 
> > > > Your patch
> > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > index ef20875..a7467ea 100644
> > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > @@ -500,6 +500,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> > > > *intel_encoder)
> > > > struct i915_audio_component *a

Re: [Intel-gfx] [PATCH i-g-t 2/2] lib/intel_chipset: Removing PCI IDs that are no longer listed as Kabylake.

[Pandiyan, Dhinakaran]

On Mon, 2016-06-27 at 17:11 -0700, Rodrigo Vivi wrote:
> This is unusual. Usually IDs listed on early stages of platform
> definition are kept there as reserved for later use.
> 
> However these IDs here are not listed anymore in any of steppings
> and devices IDs tables for Kabylake on configurations overview
> section of BSpec.
> 
> So it is better removing them before they become used in any
> other future platform.
> 
> v2: Rebase.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 
> ---
>  lib/intel_chipset.h | 16 +++-
>  1 file changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
> index 23d0919..e1e552c 100644
> --- a/lib/intel_chipset.h
> +++ b/lib/intel_chipset.h
> @@ -223,18 +223,13 @@ void intel_check_pch(void);
>  #define PCI_CHIP_KABYLAKE_DT_GT2   0x5912
>  #define PCI_CHIP_KABYLAKE_DT_GT1_5 0x5917
>  #define PCI_CHIP_KABYLAKE_DT_GT1   0x5902
> -#define PCI_CHIP_KABYLAKE_DT_GT4   0x5932
>  #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B
> -#define PCI_CHIP_KABYLAKE_HALO_GT3 0x592B
>  #define PCI_CHIP_KABYLAKE_HALO_GT1_0   0x5908
>  #define PCI_CHIP_KABYLAKE_HALO_GT1_1   0x590B
>  #define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B
>  #define PCI_CHIP_KABYLAKE_SRV_GT2  0x591A
> -#define PCI_CHIP_KABYLAKE_SRV_GT3  0x592A
> -#define PCI_CHIP_KABYLAKE_SRV_GT4  0x593A
>  #define PCI_CHIP_KABYLAKE_SRV_GT1  0x590A
>  #define PCI_CHIP_KABYLAKE_WKS_GT2  0x591D
> -#define PCI_CHIP_KABYLAKE_WKS_GT4  0x593D
>  
>  #define PCI_CHIP_BROXTON_0   0x0A84
>  #define PCI_CHIP_BROXTON_1   0x1A84
> @@ -447,14 +442,9 @@ void intel_check_pch(void);
>  
>  #define IS_KBL_GT3(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0|| \
>(devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1|| \
> -  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2|| \
> -  (devid) == PCI_CHIP_KABYLAKE_HALO_GT3|| \
> -  (devid) == PCI_CHIP_KABYLAKE_SRV_GT3)
> -
> -#define IS_KBL_GT4(devid)((devid) == PCI_CHIP_KABYLAKE_DT_GT4|| \
> -  (devid) == PCI_CHIP_KABYLAKE_HALO_GT4|| \
> -  (devid) == PCI_CHIP_KABYLAKE_SRV_GT4|| \
> -  (devid) == PCI_CHIP_KABYLAKE_WKS_GT4)
> +  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2)
> +
> +#define IS_KBL_GT4(devid)((devid) == PCI_CHIP_KABYLAKE_HALO_GT4)
>  
>  #define IS_KABYLAKE(devid)   (IS_KBL_GT1(devid) || \
>IS_KBL_GT2(devid) || \
Reviewed-by: Dhinakaran Pandiyan 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/2] lib/intel_chipset: Add more Kabylake PCI IDs.

[Pandiyan, Dhinakaran]

On Mon, 2016-06-27 at 17:11 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
> 
> v2: Avoid using "H" instead of HALO to keep names uniform - DK.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 
> ---
>  lib/intel_chipset.h | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
> index 2f2e435..23d0919 100644
> --- a/lib/intel_chipset.h
> +++ b/lib/intel_chipset.h
> @@ -213,7 +213,9 @@ void intel_check_pch(void);
>  #define PCI_CHIP_KABYLAKE_ULT_GT2  0x5916
>  #define PCI_CHIP_KABYLAKE_ULT_GT1_50x5913
>  #define PCI_CHIP_KABYLAKE_ULT_GT1  0x5906
> -#define PCI_CHIP_KABYLAKE_ULT_GT3  0x5926
> +#define PCI_CHIP_KABYLAKE_ULT_GT3_00x5923
> +#define PCI_CHIP_KABYLAKE_ULT_GT3_10x5926
> +#define PCI_CHIP_KABYLAKE_ULT_GT3_20x5927
>  #define PCI_CHIP_KABYLAKE_ULT_GT2F 0x5921
>  #define PCI_CHIP_KABYLAKE_ULX_GT1_50x5915
>  #define PCI_CHIP_KABYLAKE_ULX_GT1  0x590E
> @@ -224,7 +226,8 @@ void intel_check_pch(void);
>  #define PCI_CHIP_KABYLAKE_DT_GT4   0x5932
>  #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B
>  #define PCI_CHIP_KABYLAKE_HALO_GT3 0x592B
> -#define PCI_CHIP_KABYLAKE_HALO_GT1 0x590B
> +#define PCI_CHIP_KABYLAKE_HALO_GT1_0   0x5908
> +#define PCI_CHIP_KABYLAKE_HALO_GT1_1   0x590B
>  #define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B
>  #define PCI_CHIP_KABYLAKE_SRV_GT2  0x591A
>  #define PCI_CHIP_KABYLAKE_SRV_GT3  0x592A
> @@ -430,7 +433,8 @@ void intel_check_pch(void);
>(devid) == PCI_CHIP_KABYLAKE_ULT_GT1|| \
>(devid) == PCI_CHIP_KABYLAKE_ULX_GT1|| \
>(devid) == PCI_CHIP_KABYLAKE_DT_GT1||  \
> -  (devid) == PCI_CHIP_KABYLAKE_HALO_GT1|| \
> +  (devid) == PCI_CHIP_KABYLAKE_HALO_GT1_0|| \
> +  (devid) == PCI_CHIP_KABYLAKE_HALO_GT1_1|| \
>(devid) == PCI_CHIP_KABYLAKE_SRV_GT1)
>  
>  #define IS_KBL_GT2(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT2|| \
> @@ -441,7 +445,9 @@ void intel_check_pch(void);
>(devid) == PCI_CHIP_KABYLAKE_SRV_GT2|| \
>(devid) == PCI_CHIP_KABYLAKE_WKS_GT2)
>  
> -#define IS_KBL_GT3(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT3|| \
> +#define IS_KBL_GT3(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0|| \
> +  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1|| \
> +  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2|| \
>(devid) == PCI_CHIP_KABYLAKE_HALO_GT3|| \
>(devid) == PCI_CHIP_KABYLAKE_SRV_GT3)
>  
Looks good.
Reviewed-by: Dhinakaran Pandiyan 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] intel: Removing PCI IDs that are no longer listed as Kabylake.

[Pandiyan, Dhinakaran]

On Mon, 2016-06-27 at 17:10 -0700, Rodrigo Vivi wrote:
> This is unusual. Usually IDs listed on early stages of platform
> definition are kept there as reserved for later use.
> 
> However these IDs here are not listed anymore in any of steppings
> and devices IDs tables for Kabylake on configurations overview
> section of BSpec.
> 
> So it is better removing them before they become used in any
> other future platform.
> 
> v2: Rebase.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 
> ---
>  intel/intel_chipset.h | 16 +++-
>  1 file changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 6b8d4e9..514f659 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -204,18 +204,13 @@
>  #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912
>  #define PCI_CHIP_KABYLAKE_DT_GT1_5   0x5917
>  #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902
> -#define PCI_CHIP_KABYLAKE_DT_GT4 0x5932
>  #define PCI_CHIP_KABYLAKE_HALO_GT2   0x591B
>  #define PCI_CHIP_KABYLAKE_HALO_GT4   0x593B
> -#define PCI_CHIP_KABYLAKE_HALO_GT3   0x592B
>  #define PCI_CHIP_KABYLAKE_HALO_GT1_0 0x5908
>  #define PCI_CHIP_KABYLAKE_HALO_GT1_1 0x590B
>  #define PCI_CHIP_KABYLAKE_SRV_GT20x591A
> -#define PCI_CHIP_KABYLAKE_SRV_GT30x592A
>  #define PCI_CHIP_KABYLAKE_SRV_GT10x590A
> -#define PCI_CHIP_KABYLAKE_SRV_GT40x593A
>  #define PCI_CHIP_KABYLAKE_WKS_GT20x591D
> -#define PCI_CHIP_KABYLAKE_WKS_GT40x593D
>  
>  #define PCI_CHIP_BROXTON_0   0x0A84
>  #define PCI_CHIP_BROXTON_1   0x1A84
> @@ -431,14 +426,9 @@
>  
>  #define IS_KBL_GT3(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0 || \
>(devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1 || \
> -  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2 || \
> -  (devid) == PCI_CHIP_KABYLAKE_HALO_GT3  || \
> -  (devid) == PCI_CHIP_KABYLAKE_SRV_GT3)
> -
> -#define IS_KBL_GT4(devid)((devid) == PCI_CHIP_KABYLAKE_DT_GT4|| \
> -  (devid) == PCI_CHIP_KABYLAKE_HALO_GT4  || \
> -  (devid) == PCI_CHIP_KABYLAKE_SRV_GT4   || \
> -  (devid) == PCI_CHIP_KABYLAKE_WKS_GT4)
> +  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2)
> +
> +#define IS_KBL_GT4(devid)((devid) == PCI_CHIP_KABYLAKE_HALO_GT4)
>  
>  #define IS_KABYLAKE(devid)   (IS_KBL_GT1(devid) || \
>IS_KBL_GT2(devid) || \

Checked against the spec, lgtm.
Reviewed-by: Dhinakaran Pandiyan 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] intel: Add more Kabylake PCI IDs.

[Pandiyan, Dhinakaran]

On Mon, 2016-06-27 at 17:10 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
> 
> v2: Avoid using "H" instead of HALO to keep names uniform - DK.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 
> ---
>  intel/intel_chipset.h | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index e2554c3..6b8d4e9 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -194,7 +194,9 @@
>  #define PCI_CHIP_KABYLAKE_ULT_GT20x5916
>  #define PCI_CHIP_KABYLAKE_ULT_GT1_5  0x5913
>  #define PCI_CHIP_KABYLAKE_ULT_GT10x5906
> -#define PCI_CHIP_KABYLAKE_ULT_GT30x5926
> +#define PCI_CHIP_KABYLAKE_ULT_GT3_0  0x5923
> +#define PCI_CHIP_KABYLAKE_ULT_GT3_1  0x5926
> +#define PCI_CHIP_KABYLAKE_ULT_GT3_2  0x5927
>  #define PCI_CHIP_KABYLAKE_ULT_GT2F   0x5921
>  #define PCI_CHIP_KABYLAKE_ULX_GT1_5  0x5915
>  #define PCI_CHIP_KABYLAKE_ULX_GT10x590E
> @@ -206,7 +208,8 @@
>  #define PCI_CHIP_KABYLAKE_HALO_GT2   0x591B
>  #define PCI_CHIP_KABYLAKE_HALO_GT4   0x593B
>  #define PCI_CHIP_KABYLAKE_HALO_GT3   0x592B
> -#define PCI_CHIP_KABYLAKE_HALO_GT1   0x590B
> +#define PCI_CHIP_KABYLAKE_HALO_GT1_0 0x5908
> +#define PCI_CHIP_KABYLAKE_HALO_GT1_1 0x590B
>  #define PCI_CHIP_KABYLAKE_SRV_GT20x591A
>  #define PCI_CHIP_KABYLAKE_SRV_GT30x592A
>  #define PCI_CHIP_KABYLAKE_SRV_GT10x590A
> @@ -414,7 +417,8 @@
>(devid) == PCI_CHIP_KABYLAKE_ULT_GT1   || \
>(devid) == PCI_CHIP_KABYLAKE_ULX_GT1   || \
>(devid) == PCI_CHIP_KABYLAKE_DT_GT1|| \
> -  (devid) == PCI_CHIP_KABYLAKE_HALO_GT1  || \
> +  (devid) == PCI_CHIP_KABYLAKE_HALO_GT1_0 || \
> +  (devid) == PCI_CHIP_KABYLAKE_HALO_GT1_1 || \
>(devid) == PCI_CHIP_KABYLAKE_SRV_GT1)
>  
>  #define IS_KBL_GT2(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT2   || \
> @@ -425,7 +429,9 @@
>(devid) == PCI_CHIP_KABYLAKE_SRV_GT2   || \
>(devid) == PCI_CHIP_KABYLAKE_WKS_GT2)
>  
> -#define IS_KBL_GT3(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT3   || \
> +#define IS_KBL_GT3(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0 || \
> +  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1 || \
> +  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2 || \
>(devid) == PCI_CHIP_KABYLAKE_HALO_GT3  || \
>(devid) == PCI_CHIP_KABYLAKE_SRV_GT3)
>  
Checked against the spec, lgtm.
Reviewed-by: Dhinakaran Pandiyan 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] lib/intel_chipset: Removing PCI IDs that are no longer listed as Kabylake.

[Pandiyan, Dhinakaran]

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> This is unusual. Usually IDs listed on early stages of platform
> definition are kept there as reserved for later use.
> 
> However these IDs here are not listed anymore in any of steppings
> and devices IDs tables for Kabylake on configurations overview
> section of BSpec.
> 
> So it is better removing them before they become used in any
> other future platform.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  lib/intel_chipset.h | 16 +++-
>  1 file changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
> index 1c894d5..3967468 100644
> --- a/lib/intel_chipset.h
> +++ b/lib/intel_chipset.h
> @@ -223,18 +223,13 @@ void intel_check_pch(void);
>  #define PCI_CHIP_KABYLAKE_DT_GT2   0x5912
>  #define PCI_CHIP_KABYLAKE_DT_GT1_5 0x5917
>  #define PCI_CHIP_KABYLAKE_DT_GT1   0x5902
> -#define PCI_CHIP_KABYLAKE_DT_GT4   0x5932
>  #define PCI_CHIP_KABYLAKE_HALO_GT2 0x591B
> -#define PCI_CHIP_KABYLAKE_HALO_GT3 0x592B
>  #define PCI_CHIP_KABYLAKE_H_GT1_0  0x5908
>  #define PCI_CHIP_KABYLAKE_H_GT1_1  0x590B
>  #define PCI_CHIP_KABYLAKE_HALO_GT4 0x593B
>  #define PCI_CHIP_KABYLAKE_SRV_GT2  0x591A
> -#define PCI_CHIP_KABYLAKE_SRV_GT3  0x592A
> -#define PCI_CHIP_KABYLAKE_SRV_GT4  0x593A
>  #define PCI_CHIP_KABYLAKE_SRV_GT1  0x590A
>  #define PCI_CHIP_KABYLAKE_WKS_GT2  0x591D
> -#define PCI_CHIP_KABYLAKE_WKS_GT4  0x593D
>  
>  #define PCI_CHIP_BROXTON_0   0x0A84
>  #define PCI_CHIP_BROXTON_1   0x1A84
> @@ -447,14 +442,9 @@ void intel_check_pch(void);
>  
>  #define IS_KBL_GT3(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0|| \
>(devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1|| \
> -  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2|| \
> -  (devid) == PCI_CHIP_KABYLAKE_HALO_GT3|| \
> -  (devid) == PCI_CHIP_KABYLAKE_SRV_GT3)
> -
> -#define IS_KBL_GT4(devid)((devid) == PCI_CHIP_KABYLAKE_DT_GT4|| \
> -  (devid) == PCI_CHIP_KABYLAKE_HALO_GT4|| \
> -  (devid) == PCI_CHIP_KABYLAKE_SRV_GT4|| \
> -  (devid) == PCI_CHIP_KABYLAKE_WKS_GT4)
> +  (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_2)
> +
> +#define IS_KBL_GT4(devid)((devid) == PCI_CHIP_KABYLAKE_HALO_GT4)
>  
>  #define IS_KABYLAKE(devid)   (IS_KBL_GT1(devid) || \
>IS_KBL_GT2(devid) || \

I checked the Spec, this looks right.
Reviewed-by: Dhinakaran Pandiyan 


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] pciids: : Removing PCI IDs that are no longer listed as Kabylake.

[Pandiyan, Dhinakaran]

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> This is unusual. Usually IDs listed on early stages of platform
> definition are kept there as reserved for later use.
> 
> However these IDs here are not listed anymore in any of steppings
> and devices IDs tables for Kabylake on configurations overview
> section of BSpec.
> 
> So it is better removing them before they become used in any
> other future platform.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  src/i915_pciids.h | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/src/i915_pciids.h b/src/i915_pciids.h
> index 87dde1c..33466bf 100644
> --- a/src/i915_pciids.h
> +++ b/src/i915_pciids.h
> @@ -325,15 +325,10 @@
>  #define INTEL_KBL_GT3_IDS(info) \
>   INTEL_VGA_DEVICE(0x5923, info), /* ULT GT3 */ \
>   INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
> - INTEL_VGA_DEVICE(0x5927, info), /* ULT GT3 */ \
> - INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
> - INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
> + INTEL_VGA_DEVICE(0x5927, info) /* ULT GT3 */
>  
>  #define INTEL_KBL_GT4_IDS(info) \
> - INTEL_VGA_DEVICE(0x5932, info), /* DT  GT4 */ \
> - INTEL_VGA_DEVICE(0x593B, info), /* Halo GT4 */ \
> - INTEL_VGA_DEVICE(0x593A, info), /* SRV GT4 */ \
> - INTEL_VGA_DEVICE(0x593D, info)  /* WKS GT4 */
> + INTEL_VGA_DEVICE(0x593B, info) /* Halo GT4 */
>  
>  #define INTEL_KBL_IDS(info) \
>   INTEL_KBL_GT1_IDS(info), \
Verified against the spec, lgtm.
Reviewed-by: Dhinakaran Pandiyan 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] i956: Add more Kabylake PCI IDs.

[Pandiyan, Dhinakaran]

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  include/pci_ids/i965_pci_ids.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> index fce00da..7a7897f 100644
> --- a/include/pci_ids/i965_pci_ids.h
> +++ b/include/pci_ids/i965_pci_ids.h
> @@ -137,6 +137,7 @@ CHIPSET(0x193D, skl_gt4, "Intel(R) Iris Pro Graphics P580 
> (Skylake GT4e)")
>  CHIPSET(0x5902, kbl_gt1, "Intel(R) Kabylake GT1")
>  CHIPSET(0x5906, kbl_gt1, "Intel(R) Kabylake GT1")
>  CHIPSET(0x590A, kbl_gt1, "Intel(R) Kabylake GT1")
> +CHIPSET(0x5908, kbl_gt1, "Intel(R) Kabylake GT1")
>  CHIPSET(0x590B, kbl_gt1, "Intel(R) Kabylake GT1")
>  CHIPSET(0x590E, kbl_gt1, "Intel(R) Kabylake GT1")
>  CHIPSET(0x5913, kbl_gt1_5, "Intel(R) Kabylake GT1.5")
> @@ -149,7 +150,9 @@ CHIPSET(0x591B, kbl_gt2, "Intel(R) Kabylake GT2")
>  CHIPSET(0x591D, kbl_gt2, "Intel(R) Kabylake GT2")
>  CHIPSET(0x591E, kbl_gt2, "Intel(R) Kabylake GT2")
>  CHIPSET(0x5921, kbl_gt2, "Intel(R) Kabylake GT2F")
> +CHIPSET(0x5923, kbl_gt3, "Intel(R) Kabylake GT3")
>  CHIPSET(0x5926, kbl_gt3, "Intel(R) Kabylake GT3")
> +CHIPSET(0x5927, kbl_gt3, "Intel(R) Kabylake GT3")
>  CHIPSET(0x592A, kbl_gt3, "Intel(R) Kabylake GT3")
>  CHIPSET(0x592B, kbl_gt3, "Intel(R) Kabylake GT3")
>  CHIPSET(0x5932, kbl_gt4, "Intel(R) Kabylake GT4")

Verified against the spec. lgtm.
Reviewed-by: Dhinakaran Pandiyan 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] i965: Removing PCI IDs that are no longer listed as Kabylake.

[Pandiyan, Dhinakaran]

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> This is unusual. Usually IDs listed on early stages of platform
> definition are kept there as reserved for later use.
> 
> However these IDs here are not listed anymore in any of steppings
> and devices IDs tables for Kabylake on configurations overview
> section of BSpec.
> 
> So it is better removing them before they become used in any
> other future platform.
> 
> Signed-off-by: Rodrigo Vivi 
> ---
>  include/pci_ids/i965_pci_ids.h | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> index 7a7897f..1566afd 100644
> --- a/include/pci_ids/i965_pci_ids.h
> +++ b/include/pci_ids/i965_pci_ids.h
> @@ -153,12 +153,7 @@ CHIPSET(0x5921, kbl_gt2, "Intel(R) Kabylake GT2F")
>  CHIPSET(0x5923, kbl_gt3, "Intel(R) Kabylake GT3")
>  CHIPSET(0x5926, kbl_gt3, "Intel(R) Kabylake GT3")
>  CHIPSET(0x5927, kbl_gt3, "Intel(R) Kabylake GT3")
> -CHIPSET(0x592A, kbl_gt3, "Intel(R) Kabylake GT3")
> -CHIPSET(0x592B, kbl_gt3, "Intel(R) Kabylake GT3")
> -CHIPSET(0x5932, kbl_gt4, "Intel(R) Kabylake GT4")
> -CHIPSET(0x593A, kbl_gt4, "Intel(R) Kabylake GT4")
>  CHIPSET(0x593B, kbl_gt4, "Intel(R) Kabylake GT4")
> -CHIPSET(0x593D, kbl_gt4, "Intel(R) Kabylake GT4")
>  CHIPSET(0x22B0, chv, "Intel(R) HD Graphics (Cherrytrail)")
>  CHIPSET(0x22B1, chv, "Intel(R) HD Graphics XXX (Braswell)") /* 
> Overridden in brw_get_renderer_string */
>  CHIPSET(0x22B2, chv, "Intel(R) HD Graphics (Cherryview)")

Verified against the spec, lgtm.
Reviewed-by: Dhinakaran Pandiyan 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Removing PCI IDs that are no longer listed as Kabylake.

[Pandiyan, Dhinakaran]

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> -   INTEL_VGA_DEVICE(0x5932, info), /* DT  GT4 */ \
> -   INTEL_VGA_DEVICE(0x593B, info), /* Halo GT4 */ \
> -   INTEL_VGA_DEVICE(0x593A, info), /* SRV GT4 */ \
> -   INTEL_VGA_DEVICE(0x593D, info)  /* WKS GT4


Reviewed-by: Dhinakaran Pandiyan 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Fri, 2016-08-05 at 02:31 +, Yang, Libin wrote:
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf 
> > Of
> > Ville Syrjälä
> > Sent: Friday, August 5, 2016 4:48 AM
> > To: Takashi Iwai <ti...@suse.de>
> > Cc: libin.y...@linux.intel.com; intel-gfx@lists.freedesktop.org; alsa-
> > de...@alsa-project.org; Pandiyan, Dhinakaran
> > <dhinakaran.pandi...@intel.com>
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST
> > 
> > On Thu, Aug 04, 2016 at 07:55:09PM +0200, Takashi Iwai wrote:
> > > On Thu, 04 Aug 2016 19:35:16 +0200,
> > > Ville Syrjälä wrote:
> > > >
> > > > On Thu, Aug 04, 2016 at 10:18:52AM -0700, Jim Bride wrote:
> > > > > On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote:
> > > > > > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > > DP MST provides the capability to send multiple video and
> > > > > > > audio streams via one single port. This requires the API's
> > > > > > > between i915 and audio drivers to distinguish between audio
> > > > > > > capable displays connected to a port. This patch adds this
> > > > > > > support via an additional parameter 'int dev_id'. The existing
> > parameter 'port' does not change it's meaning.
> > > > > > >
> > > > > > > dev_id =
> > > > > > >   MST : pipe that the stream originates from
> > > > > > >   Non-MST : -1
> > > > > > >
> > > > > > > Affected APIs:
> > > > > > > struct i915_audio_component_ops
> > > > > > > -   int (*sync_audio_rate)(struct device *, int port, int 
> > > > > > > rate);
> > > > > > > + int (*sync_audio_rate)(struct device *, int port, int
> > > > > > > +dev_id,
> > > > > >
> > > > > > Does the term 'dev_id' have some special meaning on the audio
> > > > > > side? On the i915 side things would be less confusing if we just
> > > > > > called it 'pipe'.
> > > > >
> > > > > Yeah, it does.  All of the documentation on the audio side is
> > > > > written in terms of device ID, so they asked for that nomenclature.
> > > >
> > > > And is the device ID always the same as the pipe? Until now we've
> > > > made due with passing the port instead of the pipe, so either the
> > > > audio side didn't use the device ID, or its meaning changes based on
> > > > how we drive things, or they dug it out from somewhere else based on the
> > port?
> > >
> > > This is my concern, too.  Currently we have a very wild assumption
> > > even for the port mapping.  In the audio side, there is neither port
> > > nor pipe.  There are only the widget node id and the device id.  The
> > > former is supposedly corresponding to the port, and the latter to the
> > > pipe.  But the audio side has absolutely no clue about how these are
> > > connected.
> > 
> > So I tried to study this a bit, and MST and device are mentioned a few
> > times in the description of some audio registers in the GPU docs. Looks 
> > like a
> > bunch of bits overlap somehow with pin vs. device usage. I don't understand
> > how that's supposed to work. Eg:
> 
> For SST & HDMI, port is mapping to pin.
> 
> For MST, in audio, each pin has several device entries. Each device entry
> can transfer audio stream. And we confirmed with silicon team,
> device entry is related to pipe.
> 
> Device entry is always the right concept in audio driver. We are not sure
> the relationship will be always right between pipe and device entry.
> 
> We are worry that the relationship may be changed in the future between
> pipe and device entry. I mean maybe the pipe is not related to device
> entry in the new platforms, but some other conception, such as transcoder.
> If so, if we are using pipe now, maybe we need change the API again.
> For the stability, we are thinking device entry is suitable.
> 
> I think your concern is right. It is not good to use audio conception 
> in gfx driver, which will cause confusion. If we can confirm that
> pipe will always be the fixed mapping to device entry, it will be
> better to use pipe.
> >  AUD_PWRSTAUD_PWRST
> >  1:0 PinB Widget PwrSt Set
> >  PinB Widget power state that wa

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Fri, 2016-08-05 at 06:21 +, Yang, Libin wrote:
> > -Original Message-
> > From: Pandiyan, Dhinakaran
> > Sent: Friday, August 5, 2016 1:57 PM
> > To: Yang, Libin <libin.y...@intel.com>
> > Cc: intel-gfx@lists.freedesktop.org; ti...@suse.de; alsa-devel@alsa-
> > project.org; libin.y...@linux.intel.com
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST
> > 
> > On Fri, 2016-08-05 at 02:35 +, Yang, Libin wrote:
> > > > -Original Message-
> > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > > > Behalf Of Dhinakaran Pandiyan
> > > > Sent: Wednesday, August 3, 2016 10:15 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: alsa-de...@alsa-project.org; ti...@suse.de;
> > > > libin.y...@linux.intel.com; Pandiyan, Dhinakaran
> > > > <dhinakaran.pandi...@intel.com>
> > > > Subject: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for
> > > > MST
> > > >
> > > > DP MST provides the capability to send multiple video and audio
> > > > streams via one single port. This requires the API's between i915
> > > > and audio drivers to distinguish between audio capable displays
> > > > connected to a port. This patch adds this support via an additional
> > > > parameter 'int dev_id'. The existing parameter 'port' does not change 
> > > > it's
> > meaning.
> > > >
> > > > dev_id =
> > > > MST : pipe that the stream originates from
> > > > Non-MST : -1
> > > >
> > > > Affected APIs:
> > > > struct i915_audio_component_ops
> > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > +   int (*sync_audio_rate)(struct device *, int port, int dev_id,
> > > > +int rate);
> > > >
> > > > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > > > -   unsigned char *buf, int max_bytes);
> > > > +   int (*get_eld)(struct device *, int port, int dev_id,
> > > > +  bool *enabled, unsigned char *buf, int 
> > > > max_bytes);
> > > >
> > > > struct i915_audio_component_audio_ops
> > > > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > > > +   void (*pin_eld_notify)(void *audio_ptr, int port, int
> > > > + dev_id);
> > > >
> > > > This patch makes dummy changes in the audio drivers for build to 
> > > > succeed.
> > > >
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h|  2 +-
> > > >  drivers/gpu/drm/i915/intel_audio.c | 82
> > > > +--
> > > > ---
> > > >  include/drm/i915_component.h   |  6 +--
> > > >  include/sound/hda_i915.h   | 11 ++---
> > > >  sound/hda/hdac_i915.c  |  9 +++--
> > > >  sound/pci/hda/patch_hdmi.c |  7 ++--
> > > >  6 files changed, 82 insertions(+), 35 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h index 65ada5d..8e4c8c8 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2054,7 +2054,7 @@ struct drm_i915_private {
> > > > /* perform PHY state sanity checks? */
> > > > bool chv_phy_assert[2];
> > > >
> > > > -   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > > > +   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> > >
> > > We may still need save the port number info.
> > > In non-MST mode, device entry means nothing. This means
> > > av_enc_map[pipe] may not get the right intel_encoder
> > >
> > > Regards,
> > > Libin
> > >
> > We find the encoder using port in get_saved_encoder()
> 
> It seems it still can't get the encoder for SST/HDMI as
> pipe may always be -1 or 0 for SST/HDMI?
> 
> Regards,
> Libin
> 

The audio driver sends dev_id=-1, but the correct "port" for SST. So, we
loop through all the saved encoders and choose the one that is tied to
"port"

for (pipe = PIPE_A; pipe < I915_MAX_PIPES; pipe++) {

if (!

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Fri, 2016-08-05 at 02:35 +, Yang, Libin wrote:
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf 
> > Of
> > Dhinakaran Pandiyan
> > Sent: Wednesday, August 3, 2016 10:15 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: alsa-de...@alsa-project.org; ti...@suse.de; libin.y...@linux.intel.com;
> > Pandiyan, Dhinakaran <dhinakaran.pandi...@intel.com>
> > Subject: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST
> > 
> > DP MST provides the capability to send multiple video and audio streams via
> > one single port. This requires the API's between i915 and audio drivers to
> > distinguish between audio capable displays connected to a port. This patch
> > adds this support via an additional parameter 'int dev_id'. The existing
> > parameter 'port' does not change it's meaning.
> > 
> > dev_id =
> > MST : pipe that the stream originates from
> > Non-MST : -1
> > 
> > Affected APIs:
> > struct i915_audio_component_ops
> > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > +   int (*sync_audio_rate)(struct device *, int port, int dev_id,
> > +int rate);
> > 
> > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > -   unsigned char *buf, int max_bytes);
> > +   int (*get_eld)(struct device *, int port, int dev_id,
> > +  bool *enabled, unsigned char *buf, int max_bytes);
> > 
> > struct i915_audio_component_audio_ops
> > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > +   void (*pin_eld_notify)(void *audio_ptr, int port, int dev_id);
> > 
> > This patch makes dummy changes in the audio drivers for build to succeed.
> > 
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  2 +-
> >  drivers/gpu/drm/i915/intel_audio.c | 82 +--
> > ---
> >  include/drm/i915_component.h   |  6 +--
> >  include/sound/hda_i915.h   | 11 ++---
> >  sound/hda/hdac_i915.c  |  9 +++--
> >  sound/pci/hda/patch_hdmi.c |  7 ++--
> >  6 files changed, 82 insertions(+), 35 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 65ada5d..8e4c8c8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2054,7 +2054,7 @@ struct drm_i915_private {
> > /* perform PHY state sanity checks? */
> > bool chv_phy_assert[2];
> > 
> > -   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > +   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> 
> We may still need save the port number info.
> In non-MST mode, device entry means nothing. This means
> av_enc_map[pipe] may not get the right intel_encoder
> 
> Regards,
> Libin
> 
We find the encoder using port in get_saved_encoder()
> > 
> > /*
> >  * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your
> > patch diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 8c493de..cbe44c8 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -500,6 +500,9 @@ void intel_audio_codec_enable(struct intel_encoder
> > *intel_encoder)
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > enum port port = intel_dig_port->port;
> > +   enum pipe pipe = crtc->pipe;
> > +   int dev_id = -1;
> > +
> > 
> > connector = drm_select_eld(encoder);
> > if (!connector)
> > @@ -522,14 +525,19 @@ void intel_audio_codec_enable(struct intel_encoder
> > *intel_encoder)
> > dev_priv->display.audio_codec_enable(connector,
> > intel_encoder,
> >  adjusted_mode);
> > 
> > +   if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> > +   dev_id = pipe;
> > +
> > mutex_lock(_priv->av_mutex);
> > intel_encoder->audio_connector = connector;
> > +
> > /* referred in audio callbacks */
> > -   dev_priv->dig_port_map[port] = intel_encoder;
> > +   dev_priv->av_enc_map[pipe] = intel_encoder;
> > mutex_unlock(_priv->av_mutex);
> > 
> > if (acomp && acomp->audio_ops && acomp-

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Dump DP link status when link training stages fail

[Pandiyan, Dhinakaran]

On Fri, 2016-08-05 at 10:35 +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 01:48:36PM -0700, Dhinakaran Pandiyan wrote:
> > A full dump of link status can be handy in debugging link training
> > failures. Let's add that to the debug messages when link training fails.
> > 
> > v2: Removing unrelated clean up (Jani)
> > Signed-off-by: Dhinakaran Pandiyan 
> Reviewed-by: Chris Wilson 
> -Chris
> 
Thanks Chris!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: start adding dp mst audio

[Pandiyan, Dhinakaran]

Thanks Lyude. I realized that after sending the patches, will fix that.

On Thu, 2016-08-04 at 19:42 -0400, Lyude wrote:
> This should be added after patch #3, since that's the one that fixes
> enc_to_mst(). Otherwise:
> 
> Reviewed-by: Lyude 
> 
> On Tue, 2016-08-02 at 18:46 -0700, Dhinakaran Pandiyan wrote:
> > From: Libin Yang 
> > 
> > (This patch is developed by Dave Airlie 
> > originally)
> > 
> > This patch adds support for DP MST audio in i915.
> > 
> > Enable audio codec when DP MST is enabled if has_audio flag is set.
> > Disable audio codec when DP MST is disabled if has_audio flag is set.
> > 
> > Another separated patches to support DP MST audio will be implemented
> > in audio driver.
> > 
> > Signed-off-by: Libin Yang 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
> >  drivers/gpu/drm/i915/intel_ddi.c| 20 +++-
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 21 +
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  4 files changed, 56 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 531ca02..56e38b1 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2961,6 +2961,20 @@ static void intel_dp_info(struct seq_file *m,
> > intel_panel_info(m, _connector->panel);
> >  }
> >  
> > +static void intel_dp_mst_info(struct seq_file *m,
> > + struct intel_connector *intel_connector)
> > +{
> > +   struct intel_encoder *intel_encoder = intel_connector-
> > >encoder;
> > +   struct intel_dp_mst_encoder *intel_mst =
> > +   enc_to_mst(_encoder->base);
> > +   struct intel_digital_port *intel_dig_port = intel_mst-
> > >primary;
> > +   struct intel_dp *intel_dp = _dig_port->dp;
> > +   bool has_audio = drm_dp_mst_port_has_audio(_dp-
> > >mst_mgr,
> > +   intel_connector->port);
> > +
> > +   seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
> > +}
> > +
> >  static void intel_hdmi_info(struct seq_file *m,
> > struct intel_connector *intel_connector)
> >  {
> > @@ -3003,7 +3017,10 @@ static void intel_connector_info(struct
> > seq_file *m,
> > switch (connector->connector_type) {
> > case DRM_MODE_CONNECTOR_DisplayPort:
> > case DRM_MODE_CONNECTOR_eDP:
> > -   intel_dp_info(m, intel_connector);
> > +   if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> > +   intel_dp_mst_info(m, intel_connector);
> > +   else
> > +   intel_dp_info(m, intel_connector);
> > break;
> > case DRM_MODE_CONNECTOR_LVDS:
> > if (intel_encoder->type == INTEL_OUTPUT_LVDS)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index dd1d6fe..cbb4e7a 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2154,6 +2154,19 @@ void intel_ddi_fdi_disable(struct drm_crtc
> > *crtc)
> > I915_WRITE(FDI_RX_CTL(PIPE_A), val);
> >  }
> >  
> > +bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
> > +struct intel_crtc *intel_crtc)
> > +{
> > +   u32 temp;
> > +
> > +   if (intel_display_power_is_enabled(dev_priv,
> > POWER_DOMAIN_AUDIO)) {
> > +   temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> > +   if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
> > +   return true;
> > +   }
> > +   return false;
> > +}
> > +
> >  void intel_ddi_get_config(struct intel_encoder *encoder,
> >   struct intel_crtc_state *pipe_config)
> >  {
> > @@ -2219,11 +2232,8 @@ void intel_ddi_get_config(struct intel_encoder
> > *encoder,
> > break;
> > }
> >  
> > -   if (intel_display_power_is_enabled(dev_priv,
> > POWER_DOMAIN_AUDIO)) {
> > -   temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> > -   if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
> > -   pipe_config->has_audio = true;
> > -   }
> > +   pipe_config->has_audio =
> > +   intel_ddi_is_audio_enabled(dev_priv, intel_crtc);
> >  
> > if (encoder->type == INTEL_OUTPUT_EDP && dev_priv-
> > >vbt.edp.bpp &&
> > pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) {
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 68a005d..84dbb50 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -76,6 +76,8 @@ static bool intel_dp_mst_compute_config(struct
> > intel_encoder *encoder,
> > return false;
> > }
> >  
> > +   if (drm_dp_mst_port_has_audio(_dp->mst_mgr, found-
> > >port))
> > +   pipe_config->has_audio = true;
> > mst_pbn = 

Re: [Intel-gfx] [PATCH] drm/i915: Add some curly braces

[Pandiyan, Dhinakaran]

On Fri, 2016-08-05 at 18:49 +0100, Chris Wilson wrote:
> On Fri, Aug 05, 2016 at 08:41:34PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > intel_enable_pipe() looks rather confusing when one side doesn't have
> > the curly braces, and the other one does. And what's even worse,
> > there's another if-else inside the braceless side. Let's put braces
> > around it to make it clear which branch goes where.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Easiest review of the day.
> Reviewed-by: Chris Wilson 
> -Chris
> 
I was just about getting started to do my first review!

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix enc_to_dig_port for MST encoders

[Pandiyan, Dhinakaran]

On Thu, 2016-08-04 at 19:51 -0400, Lyude wrote:
> There was some discussion that happened on the original version of this
> patch:
> 
> https://patchwork.kernel.org/patch/8960831/
> 
> The general consensus was while this fixed the issue, it probably isn't
> the way we want to fix it. It would be a better idea just to have
> enc_to_mst_primary() or something along those lines, or just use
> enc_to_mst()->primary explicitly.
> 

Thanks for the pointer and the review.

It seems like the concerns were about DP MST audio not working anyway. I
wonder with DP MST audio support coming up
(https://patchwork.kernel.org/patch/9260671/) , if the patch is more
acceptable.

> On Tue, 2016-08-02 at 18:46 -0700, Dhinakaran Pandiyan wrote:
> > When a MST encoder is passed to enc_to_dig_port(), the container_of()
> > macro
> > does not return the digital port. Handle this by returning the member
> > "primary" in "struct intel_dp_mst_encoder"
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 45020d2..66af444 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1023,18 +1023,22 @@ intel_attached_encoder(struct drm_connector
> > *connector)
> > return to_intel_connector(connector)->encoder;
> >  }
> >  
> > -static inline struct intel_digital_port *
> > -enc_to_dig_port(struct drm_encoder *encoder)
> > -{
> > -   return container_of(encoder, struct intel_digital_port,
> > base.base);
> > -}
> > -
> >  static inline struct intel_dp_mst_encoder *
> >  enc_to_mst(struct drm_encoder *encoder)
> >  {
> > return container_of(encoder, struct intel_dp_mst_encoder,
> > base.base);
> >  }
> >  
> > +static inline struct intel_digital_port *
> > +enc_to_dig_port(struct drm_encoder *encoder)
> > +{
> > +   if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST)
> > +   return enc_to_mst(encoder)->primary;
> > +   else
> > +   return container_of(encoder, struct
> > intel_digital_port,
> > +   base.base);
> > +}
> > +
> >  static inline struct intel_dp *enc_to_intel_dp(struct drm_encoder
> > *encoder)
> >  {
> > return _to_dig_port(encoder)->dp;

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix the return value of pipe crc read function.

[Pandiyan, Dhinakaran]

On Wed, 2016-08-03 at 14:44 +, Vivi, Rodrigo wrote:
> On Wed, 2016-08-03 at 10:31 +0300, Ville Syrjälä wrote:
> > On Tue, Aug 02, 2016 at 09:42:07PM -0700, Rodrigo Vivi wrote:
> > > 
> > > A read(fd, buf, len) function should return the number
> > > of bytes read. In our case we need to return the
> > > number of bytes we copy to user, instead of returning
> > > the number of bytes we read internally.
> > > 
> > > It was really strange when I saw i-g-t test case using
> > > len '54' but getting '56' as return. First thought was
> > > how do we read more than we asked? But also I checked
> > > and there was really only 54. Until I realized it
> > > was all our fault. EFAULT!
> > > 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 7052c47..b7b8d79 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -3659,7 +3659,7 @@ i915_pipe_crc_read(struct file *filep, char
> > > __user *user_buf, size_t count,
> > >  
> > >   spin_unlock_irq(_crc->lock);
> > >  
> > > - return bytes_read;
> > > + return PIPE_CRC_LINE_LEN;
> > Nope. We can read multiple entries in one go.
> > 
> > bytes_read += snprintf()
> > 
> > so it's mostly good. The only case where it fails if we don't have
> > enough space for the snprintf(), as snprintf() will then return the
> > number of bytes it would have written. That can actually happen on
> > account of the hex vs. decimal mess with the frame counter.
> 
> Oh, I see.
> 
> So what about:
>  if (bytes_read > count)
>   return -E-something?
We could just return from snprintf() when it does not return
PIPE_CRC_LINE_LEN instead of reading all entries.

Anyway, shouldn't we fix hex to decimal conv.? Or is the value incorrect
when entry->frame in decimal exceeds 8 chars?
> > 
> > > 
> > >  }
> > >  
> > >  static const struct file_operations i915_pipe_crc_fops = {
> > > -- 
> > > 2.5.5
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Wed, 2016-08-03 at 23:28 +0300, Ville Syrjälä wrote:
> On Wed, Aug 03, 2016 at 07:43:06PM +0000, Pandiyan, Dhinakaran wrote:
> > On Wed, 2016-08-03 at 22:08 +0300, Ville Syrjälä wrote:
> > > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > > > DP MST provides the capability to send multiple video and audio streams 
> > > > via
> > > > one single port. This requires the API's between i915 and audio drivers 
> > > > to
> > > > distinguish between audio capable displays connected to a port. This 
> > > > patch
> > > > adds this support via an additional parameter 'int dev_id'. The existing
> > > > parameter 'port' does not change it's meaning.
> > > > 
> > > > dev_id =
> > > > MST : pipe that the stream originates from
> > > > Non-MST : -1
> > > > 
> > > > Affected APIs:
> > > > struct i915_audio_component_ops
> > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > +   int (*sync_audio_rate)(struct device *, int port, int dev_id,
> > > 
> > > Does the term 'dev_id' have some special meaning on the audio side? On
> > > the i915 side things would be less confusing if we just called it
> > > 'pipe'.
> > > 
> > 
> > There was quite a bit of back and forth on this. "pipe" seemed to tie us
> > to the gfx hardware architecture. In case, there is no 1:1 mapping from
> > pipes to encoders, this will get confusing as i915 audio registers
> > (E.g.HSW_AUD_PIN_ELD_CP_VLD) are encoder based.
> 
> I'm not following. Looking at the current i915 audio code, on HSW+
> everything is pipe based.
> 
Although we pass "pipe" to these macros, the definition here and in the
BSpec seem to indicate they are based on the encoder.

Eg: #define HSW_AUD_PIN_ELD_CP_VLD  _MMIO(0x650c0)
#define   AUDIO_INACTIVE(trans) ((1 << 3) << ((trans) * 4))
#define   AUDIO_OUTPUT_ENABLE(trans)((1 << 2) << ((trans) * 4))
#define   AUDIO_CP_READY(trans) ((1 << 1) << ((trans) * 4))
#define   AUDIO_ELD_VALID(trans)((1 << 0) << ((trans) * 4))


> > Whereas, dev_id is
> > generic - HDA spec calls them "devices" or "device entry"
> 
> Generic and totally unclear what it means from graphics side.
> 
> pipe and port are the only things we really have in i915. If those aren't
> good enough for the audio side, then I think we should have some decent
> code to remap between the pipe+port vs. whatever audio side id is needed.
> I don't really care on which side of the border such code would live, as
> long as it's clear what it's doing.
> 

I agree, dev_id can be misleading within i915.
> > 
> > > > +int rate);
> > > > 
> > > > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > > > -   unsigned char *buf, int max_bytes);
> > > > +   int (*get_eld)(struct device *, int port, int dev_id,
> > > > +  bool *enabled, unsigned char *buf, int 
> > > > max_bytes);
> > > > 
> > > > struct i915_audio_component_audio_ops
> > > > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > > > +   void (*pin_eld_notify)(void *audio_ptr, int port, int dev_id);
> > > > 
> > > > This patch makes dummy changes in the audio drivers for build to 
> > > > succeed.
> > > > 
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h|  2 +-
> > > >  drivers/gpu/drm/i915/intel_audio.c | 82 
> > > > +-
> > > >  include/drm/i915_component.h   |  6 +--
> > > >  include/sound/hda_i915.h   | 11 ++---
> > > >  sound/hda/hdac_i915.c  |  9 +++--
> > > >  sound/pci/hda/patch_hdmi.c |  7 ++--
> > > >  6 files changed, 82 insertions(+), 35 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 65ada5d..8e4c8c8 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2054,7 +2054,7 @@ struct drm_i915_private {
> > > > /* perform PHY state sanity checks? */
> > > > bool chv

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Switch to using the DRM function for reading DP link status

[Pandiyan, Dhinakaran]

Please ignore this, I am resubmitting this as an independent patch.
-DK

On Thu, 2016-08-11 at 13:49 -0700, Dhinakaran Pandiyan wrote:
> Since a DRM function that reads link DP link status is available, let's
> use that instead of the i915 clone.
> 
> drm_dp_dpcd_read_link_status() returns a negative error code if the number
> of bytes read is not DP_LINK_STATUS_SIZE, drm_dp_dpcd_access() does the
> length check.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> 
> v2: Eliminated redundant DP_LINK_STATUS_SIZE length check.
> ---
>  drivers/gpu/drm/i915/intel_dp.c   | 15 ++-
>  drivers/gpu/drm/i915/intel_dp_link_training.c |  8 ++--
>  drivers/gpu/drm/i915/intel_drv.h  |  2 --
>  3 files changed, 8 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8fe2afa..8eff57e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2863,17 +2863,6 @@ static void chv_dp_post_pll_disable(struct 
> intel_encoder *encoder)
>   chv_phy_post_pll_disable(encoder);
>  }
>  
> -/*
> - * Fetch AUX CH registers 0x202 - 0x207 which contain
> - * link status information
> - */
> -bool
> -intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
> link_status[DP_LINK_STATUS_SIZE])
> -{
> - return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
> - DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> -}
> -
>  /* These are source-specific values. */
>  uint8_t
>  intel_dp_voltage_max(struct intel_dp *intel_dp)
> @@ -3896,8 +3885,8 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>  
>   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>  
> - if (!intel_dp_get_link_status(intel_dp, link_status)) {
> - DRM_ERROR("Failed to get link status\n");
> + if (drm_dp_dpcd_read_link_status(_dp->aux, link_status) <= 0) {
> + DRM_ERROR("failed to get link status\n");
>   return;
>   }
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 60fb39c..8e60e7c 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -150,7 +150,9 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
> *intel_dp)
>   uint8_t link_status[DP_LINK_STATUS_SIZE];
>  
>   drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
> - if (!intel_dp_get_link_status(intel_dp, link_status)) {
> +
> + if (drm_dp_dpcd_read_link_status(_dp->aux, link_status)
> +  <= 0) {
>   DRM_ERROR("failed to get link status\n");
>   break;
>   }
> @@ -258,7 +260,9 @@ intel_dp_link_training_channel_equalization(struct 
> intel_dp *intel_dp)
>   }
>  
>   drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
> - if (!intel_dp_get_link_status(intel_dp, link_status)) {
> +
> + if (drm_dp_dpcd_read_link_status(_dp->aux, link_status)
> +  <= 0) {
>   DRM_ERROR("failed to get link status\n");
>   break;
>   }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index b1fc67e..a3a2cb9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1394,8 +1394,6 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, 
> uint8_t voltage_swing);
>  void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
>  uint8_t *link_bw, uint8_t *rate_select);
>  bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
> -bool
> -intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
> link_status[DP_LINK_STATUS_SIZE]);
>  
>  static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
>  {

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1½ 03/13] drm/i915/dp: rename rate_to_index() to intel_dp_find_rate() and reuse

[Pandiyan, Dhinakaran]

On Thu, 2017-01-26 at 21:44 +0200, Jani Nikula wrote:
> Rename the function, move it at the top, and reuse in
> intel_dp_link_rate_index(). If there was a reason in the past to use
> reverse search order here, there isn't now.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 33 ++---
>  1 file changed, 14 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1d66737a3a0f..f3068ff670a1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -266,6 +266,17 @@ static int intersect_rates(const int *source_rates, int 
> source_len,
>   return k;
>  }
>  
> +static int intel_dp_find_rate(const int *rates, int len, int rate)

I wonder if the function name can be more intuitive. The argument is
rate and the function name indicates it also returns rate. I can't tell
what the function does by it's name. Feel free to ignore this comment as
I might be missing some context.

-DK

> +{
> + int i;
> +
> + for (i = 0; i < len; i++)
> + if (rate == rates[i])
> + return i;
> +
> + return -1;
> +}
> +
>  static int intel_dp_common_rates(struct intel_dp *intel_dp,
>int *common_rates)
>  {
> @@ -284,15 +295,10 @@ static int intel_dp_link_rate_index(struct intel_dp 
> *intel_dp,
>   int *common_rates, int link_rate)
>  {
>   int common_len;
> - int index;
>  
>   common_len = intel_dp_common_rates(intel_dp, common_rates);
> - for (index = 0; index < common_len; index++) {
> - if (link_rate == common_rates[common_len - index - 1])
> - return common_len - index - 1;
> - }
>  
> - return -1;
> + return intel_dp_find_rate(common_rates, common_len, link_rate);
>  }
>  
>  int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> @@ -1542,17 +1548,6 @@ bool intel_dp_read_desc(struct intel_dp *intel_dp)
>   return true;
>  }
>  
> -static int rate_to_index(const int *rates, int len, int rate)
> -{
> - int i;
> -
> - for (i = 0; i < len; i++)
> - if (rate == rates[i])
> - return i;
> -
> - return -1;
> -}
> -
>  int
>  intel_dp_max_link_rate(struct intel_dp *intel_dp)
>  {
> @@ -1568,8 +1563,8 @@ intel_dp_max_link_rate(struct intel_dp *intel_dp)
>  
>  int intel_dp_rate_select(struct intel_dp *intel_dp, int rate)
>  {
> - int i = rate_to_index(intel_dp->sink_rates, intel_dp->num_sink_rates,
> -   rate);
> + int i = intel_dp_find_rate(intel_dp->sink_rates,
> +intel_dp->num_sink_rates, rate);
>  
>   if (WARN_ON(i < 0))
>   i = 0;

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1½ 07/13] drm/i915/dp: cache common rates with sink rates

[Pandiyan, Dhinakaran]

On Thu, 2017-01-26 at 21:44 +0200, Jani Nikula wrote:
> Now that source rates are static and sink rates are updated whenever
> DPCD is updated, we can do and cache the intersection of them whenever
> sink rates are updated. This reduces code complexity, as we don't have
> to keep calling the functions to intersect. We also get rid of several
> common rates arrays on stack.
> 
> Limiting the common rates by a max link rate can be done by picking the
> first N elements of the cached common rates.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 66 
> ++--
>  drivers/gpu/drm/i915/intel_drv.h |  3 ++
>  2 files changed, 40 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f163391e61fa..7d3ff92000c3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -283,17 +283,29 @@ static int intel_dp_find_rate(const int *rates, int 
> len, int rate)
>   return -1;
>  }
>  
> -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> -  int *common_rates)
> +static void intel_dp_set_common_rates(struct intel_dp *intel_dp)
>  {
> - int max_rate = intel_dp->max_sink_link_rate;
> - int i, common_len;
> + WARN_ON(!intel_dp->num_source_rates || !intel_dp->num_sink_rates);
>  
> - common_len = intersect_rates(intel_dp->source_rates,
> -  intel_dp->num_source_rates,
> -  intel_dp->sink_rates,
> -  intel_dp->num_sink_rates,
> -  common_rates);
> + intel_dp->num_common_rates = intersect_rates(intel_dp->source_rates,
> +  intel_dp->num_source_rates,
> +  intel_dp->sink_rates,
> +  intel_dp->num_sink_rates,
> +  intel_dp->common_rates);


Do we need to pass all these args given that all of them are now
available in intel_dp and intersect_rates() is not used anywhere else? 

-DK
> +
> + /* Paranoia, there should always be something in common. */
> + if (WARN_ON(intel_dp->num_common_rates == 0)) {
> + intel_dp->common_rates[0] = default_rates[0];
> + intel_dp->num_common_rates = 1;
> + }
> +}
> +
> +/* get length of common rates potentially limited by max_rate */
> +static int intel_dp_common_len_rate_limit(struct intel_dp *intel_dp,
> +   int max_rate)
> +{
> + const int *common_rates = intel_dp->common_rates;
> + int i, common_len = intel_dp->num_common_rates;
>  
>   /* Limit results by potentially reduced max rate */
>   for (i = 0; i < common_len; i++) {
> @@ -304,25 +316,23 @@ static int intel_dp_common_rates(struct intel_dp 
> *intel_dp,
>   return 0;
>  }
>  
> -static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> - int *common_rates, int link_rate)
> +static int intel_dp_link_rate_index(struct intel_dp *intel_dp, int link_rate)
>  {
>   int common_len;
>  
> - common_len = intel_dp_common_rates(intel_dp, common_rates);
> + common_len = intel_dp_common_len_rate_limit(intel_dp,
> + 
> intel_dp->max_sink_link_rate);
>  
> - return intel_dp_find_rate(common_rates, common_len, link_rate);
> + return intel_dp_find_rate(intel_dp->common_rates, common_len, 
> link_rate);
>  }
>  
>  int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
>   int link_rate, uint8_t lane_count)
>  {
> - int common_rates[DP_MAX_SUPPORTED_RATES];
> + const int *common_rates = intel_dp->common_rates;
>   int link_rate_index;
>  
> - link_rate_index = intel_dp_link_rate_index(intel_dp,
> -common_rates,
> -link_rate);
> + link_rate_index = intel_dp_link_rate_index(intel_dp, link_rate);
>   if (link_rate_index > 0) {
>   intel_dp->max_sink_link_rate = common_rates[link_rate_index - 
> 1];
>   intel_dp->max_sink_lane_count = lane_count;
> @@ -1509,8 +1519,6 @@ static void snprintf_int_array(char *str, size_t len,
>  
>  static void intel_dp_print_rates(struct intel_dp *intel_dp)
>  {
> - int common_len;
> - int common_rates[DP_MAX_SUPPORTED_RATES];
>   char str[128]; /* FIXME: too big for stack? */
>  
>   if ((drm_debug & DRM_UT_KMS) == 0)
> @@ -1524,8 +1532,8 @@ static void intel_dp_print_rates(struct intel_dp 
> *intel_dp)
>  intel_dp->sink_rates, 

Re: [Intel-gfx] [PATCH v1½ 03/13] drm/i915/dp: rename rate_to_index() to intel_dp_find_rate() and reuse

[Pandiyan, Dhinakaran]

On Thu, 2017-02-02 at 10:44 +0200, Jani Nikula wrote:
> On Wed, 01 Feb 2017, "Pandiyan, Dhinakaran" <dhinakaran.pandi...@intel.com> 
> wrote:
> > On Thu, 2017-01-26 at 21:44 +0200, Jani Nikula wrote:
> >> Rename the function, move it at the top, and reuse in
> >> intel_dp_link_rate_index(). If there was a reason in the past to use
> >> reverse search order here, there isn't now.
> >> 
> >> Cc: Manasi Navare <manasi.d.nav...@intel.com>
> >> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> >> Signed-off-by: Jani Nikula <jani.nik...@intel.com>
> >> ---
> >>  drivers/gpu/drm/i915/intel_dp.c | 33 ++---
> >>  1 file changed, 14 insertions(+), 19 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index 1d66737a3a0f..f3068ff670a1 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -266,6 +266,17 @@ static int intersect_rates(const int *source_rates, 
> >> int source_len,
> >>return k;
> >>  }
> >>  
> >> +static int intel_dp_find_rate(const int *rates, int len, int rate)
> >
> > I wonder if the function name can be more intuitive. The argument is
> > rate and the function name indicates it also returns rate. I can't tell
> > what the function does by it's name. Feel free to ignore this comment as
> > I might be missing some context.
> 
> Naming is hard. intel_dp_rate_index?
> 
> BR,
> Jani.
> 
> 

That does sounds good.

Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> >
> > -DK
> >
> >> +{
> >> +  int i;
> >> +
> >> +  for (i = 0; i < len; i++)
> >> +  if (rate == rates[i])
> >> +  return i;
> >> +
> >> +  return -1;
> >> +}
> >> +
> >>  static int intel_dp_common_rates(struct intel_dp *intel_dp,
> >> int *common_rates)
> >>  {
> >> @@ -284,15 +295,10 @@ static int intel_dp_link_rate_index(struct intel_dp 
> >> *intel_dp,
> >>int *common_rates, int link_rate)
> >>  {
> >>int common_len;
> >> -  int index;
> >>  
> >>common_len = intel_dp_common_rates(intel_dp, common_rates);
> >> -  for (index = 0; index < common_len; index++) {
> >> -  if (link_rate == common_rates[common_len - index - 1])
> >> -  return common_len - index - 1;
> >> -  }
> >>  
> >> -  return -1;
> >> +  return intel_dp_find_rate(common_rates, common_len, link_rate);
> >>  }
> >>  
> >>  int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> >> @@ -1542,17 +1548,6 @@ bool intel_dp_read_desc(struct intel_dp *intel_dp)
> >>return true;
> >>  }
> >>  
> >> -static int rate_to_index(const int *rates, int len, int rate)
> >> -{
> >> -  int i;
> >> -
> >> -  for (i = 0; i < len; i++)
> >> -  if (rate == rates[i])
> >> -  return i;
> >> -
> >> -  return -1;
> >> -}
> >> -
> >>  int
> >>  intel_dp_max_link_rate(struct intel_dp *intel_dp)
> >>  {
> >> @@ -1568,8 +1563,8 @@ intel_dp_max_link_rate(struct intel_dp *intel_dp)
> >>  
> >>  int intel_dp_rate_select(struct intel_dp *intel_dp, int rate)
> >>  {
> >> -  int i = rate_to_index(intel_dp->sink_rates, intel_dp->num_sink_rates,
> >> -rate);
> >> +  int i = intel_dp_find_rate(intel_dp->sink_rates,
> >> + intel_dp->num_sink_rates, rate);
> >>  
> >>if (WARN_ON(i < 0))
> >>i = 0;
> >
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1½ 00/13] drm/i915/dp: link rate and lane count refactoring

[Pandiyan, Dhinakaran]

On Thu, 2017-01-26 at 21:44 +0200, Jani Nikula wrote:
> This is kind of version 1½ of [1], basically just rebased on current git

Looks like this version didn't make it into patchwork.

-DK

> (including Manasi's test automation patches) and a couple of more
> cleanups slammed on top.
> 
> BR,
> Jani.
> 
> 
> [1] cover.1485015599.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1485015599.git.jani.nikula@intel.com
> 
> 
> Jani Nikula (13):
>   drm/i915/dp: use known correct array size in rate_to_index
>   drm/i915/dp: return errors from rate_to_index()
>   drm/i915/dp: rename rate_to_index() to intel_dp_find_rate() and reuse
>   drm/i915/dp: cache source rates at init
>   drm/i915/dp: generate and cache sink rate array for all DP, not just
> eDP 1.4
>   drm/i915/dp: use the sink rates array for max sink rates
>   drm/i915/dp: cache common rates with sink rates
>   drm/i915/dp: do not limit rate seek when not needed
>   drm/i915/dp: don't call the link parameters sink parameters
>   drm/i915/dp: add functions for max common link rate and lane count
>   drm/i915/mst: use max link not sink lane count
>   drm/i915/dp: localize link rate index variable more
>   drm/i915/dp: use readb and writeb calls for single byte DPCD access
> 
>  drivers/gpu/drm/i915/intel_dp.c   | 275 
> ++
>  drivers/gpu/drm/i915/intel_dp_link_training.c |   3 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c   |   4 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  19 +-
>  4 files changed, 166 insertions(+), 135 deletions(-)
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm: scrambling support in drm layer

[Pandiyan, Dhinakaran]

On Wed, 2017-02-01 at 18:14 +0530, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340Mhz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
> 
> This patch adds:
> - A function to detect scrambling support parsing HF-VSDB
> - A function to check scrambling status runtime using SCDC read.
> - Two functions to enable/disable scrambling using SCDC read/write.
> - Few new bools to reflect scrambling support and status.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 131 
> +++-
>  include/drm/drm_connector.h |  24 
>  include/drm/drm_edid.h  |   6 +-
>  3 files changed, 159 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 37902e5..f0d940a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define version_greater(edid, maj, min) \
>   (((edid)->version > (maj)) || \
> @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector 
> *connector,
>   }
>  }
>  
> +static void drm_detect_hdmi_scrambling(struct drm_connector *connector,
> +  const u8 *hf_vsdb)
> +{
> + struct drm_display_info *display = >display_info;
> + struct drm_hdmi_info *hdmi = >hdmi_info;
> +
> + /*
> +  * All HDMI 2.0 monitors must support scrambling at rates > 340M.
> +  * And as per the spec, three factors confirm this:
> +  * * Availability of a HF-VSDB block in EDID (check)
> +  * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
> +  * * SCDC support available
> +  * Lets check it out.
> +  */
> +
> + if (hf_vsdb[5]) {
> + display->max_tmds_clock = hf_vsdb[5] * 5000;

Comment explaining or quoting where the 5000 comes from?

> + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> + display->max_tmds_clock);
> +
> + if (hdmi->scdc_supported) {
> + hdmi->scr_info.supported = true;
> +
> + /* Few sinks support scrambling for cloks < 340M */
> + if ((hf_vsdb[6] & 0x8))
> + hdmi->scr_info.low_clocks = true;
> + }
> + }
> +}
> +
> +/**
> + * drm_check_scrambling_status - what is status of scrambling?
> + * @adapter: i2c adapter for SCDC channel
> + *
> + * Read the scrambler status over SCDC channel, and check the
> + * scrambling status.
> + *
> + * Return: True if the scrambling is enabled, false otherwise.
> + */
> +
> +bool drm_check_scrambling_status(struct i2c_adapter *adapter)
> +{
> + u8 status;
> +
> + if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, ) < 0) {
> + DRM_ERROR("Failed to read scrambling status\n");
> + return false;
> + }
> +
> + status &= SCDC_SCRAMBLING_STATUS;
> + return status != 0;
> +}
> +
> +/**
> + * drm_enable_scrambling - enable scrambling
> + * @connector: target drm_connector
> + * @adapter: i2c adapter for SCDC channel
> + * @force: enable scrambling, even if its already enabled
> + *
> + * Write the TMDS config over SCDC channel, and enable scrambling
> + * Return: True if scrambling is successfully enabled, false otherwise.
> + */
> +
> +bool drm_enable_scrambling(struct drm_connector *connector,
> + struct i2c_adapter *adapter, bool force)
> +{
> + u8 config;
> + struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
> +
> + if (hdmi_info->scr_info.status && !force) {
> + DRM_DEBUG_KMS("Scrambling already enabled\n");
> + return true;
> + }
> +
> + if (drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, ) < 0) {
> + DRM_ERROR("Failed to read tmds config\n");
> + return false;
> + }
> +
> + config |= SCDC_SCRAMBLING_ENABLE;
> +
> + if (drm_scdc_writeb(adapter, SCDC_TMDS_CONFIG, config) < 0) {
> + DRM_ERROR("Failed to enable scrambling, write error\n");
> + return false;
> + }
> +
> + hdmi_info->scr_info.status = drm_check_scrambling_status(adapter);
> + return hdmi_info->scr_info.status;
> +}
> +
> +/**
> + * drm_disable_scrambling - disable scrambling
> + * @connector: target drm_connector
> + * @adapter: i2c adapter for SCDC channel
> + * @force: disable scrambling, even if its already disabled
> + *
> + * Write the TMDS config over SCDC channel, and disable scrambling
> + * Return: True if scrambling is successfully disabled, false otherwise.
> + */
> +bool drm_disable_scrambling(struct drm_connector *connector,
> + struct i2c_adapter *adapter, bool force)
> +{
> + u8 config;
> + struct drm_hdmi_info *hdmi_info = >display_info.hdmi_info;
> +
> + if 

Re: [Intel-gfx] [PATCH v2 7/9] drm: Connector helper function to release atomic state

[Pandiyan, Dhinakaran]

On Wed, 2017-01-25 at 07:18 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:35PM -0800, Dhinakaran Pandiyan wrote:
> > Having a ->atomic_release callback is useful to release shared resources
> > that get allocated in compute_config().
> > 
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  include/drm/drm_modeset_helper_vtables.h | 15 +++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/include/drm/drm_modeset_helper_vtables.h 
> > b/include/drm/drm_modeset_helper_vtables.h
> > index 46f5b34..e41b18a 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -831,6 +831,21 @@ struct drm_connector_helper_funcs {
> >  */
> > struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
> > *connector,
> >struct drm_connector_state 
> > *connector_state);
> > +
> > +   /**
> > +* @atomic_release:
> > +*
> > +* This function is used to release shared resources that were
> > +* previously acquired. For example, resources acquired in
> > +* encoder->compute_config() can be released by calling this function
> 
> @compute_config is the right way to do references within the same struct.

compute_config is not in the same structure, which made me realize I
should not be referring to compute_config() at all, as it is a helper
for struct intel_encoder. 


-DK
> 
> > +* from mode_fixup()
> 
> Same here.
> 
> Patch split up is a bit strange, hence why my review of the design is in
> later patches.
> 
> Thanks, Daniel
> 
> > +*
> > +* NOTE:
> > +*
> > +* This function is called in the check phase of an atomic update.
> > +*/
> > +   void (*atomic_release)(struct drm_connector *connector,
> > +  struct drm_connector_state *connector_state);
> >  };
> >  
> >  /**
> > -- 
> > 2.7.4
> > 
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/9] drm: Add driver private objects to atomic state

[Pandiyan, Dhinakaran]

On Wed, 2017-01-25 at 06:59 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:32PM -0800, Dhinakaran Pandiyan wrote:
> > It is necessary to track states for objects other than connector, crtc
> > and plane for atomic modesets. But adding objects like DP MST link
> > bandwidth to drm_atomic_state would mean that a non-core object will be
> > modified by the core helper functions for swapping and clearing
> > it's state. So, lets add void * objects and helper functions that operate
> > on void * types to keep these objects and states private to the core.
> > Drivers can then implement specific functions to swap and clear states.
> > The other advantage having just void * for these objects in
> > drm_atomic_state is that objects of different types can be managed in the
> > same state array.
> > 
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> 
> I think an overview DOC: section to explain how to subclass atomic state
> and how to do private state objects would be great. But I can do that once
> your patch has landed, since it'd be much more about the overall design of
> atomic (and I promised to do that anyway).
> 
> Looks pretty good, a few nits below still. I'll also ask amd folks to
> check this out, and I think Ville could use it for his cdclk stuff.
> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 55 
> > +
> >  drivers/gpu/drm/drm_atomic_helper.c |  6 
> >  include/drm/drm_atomic.h| 30 
> >  3 files changed, 91 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 723392f..f3a71cc 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct 
> > drm_atomic_state *state)
> > kfree(state->connectors);
> > kfree(state->crtcs);
> > kfree(state->planes);
> > +   kfree(state->private_objs);
> >  }
> >  EXPORT_SYMBOL(drm_atomic_state_default_release);
> >  
> > @@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
> > drm_atomic_state *state)
> > state->planes[i].ptr = NULL;
> > state->planes[i].state = NULL;
> > }
> > +
> > +   for (i = 0; i < state->num_private_objs; i++) {
> > +   void *priv_obj = state->private_objs[i].obj;
> > +   void *obj_state = state->private_objs[i].obj_state;
> > +
> > +   if (!priv_obj)
> > +   continue;
> > +
> > +   state->private_objs[i].funcs->destroy_state(obj_state);
> > +   state->private_objs[i].obj = NULL;
> > +   state->private_objs[i].obj_state = NULL;
> > +   state->private_objs[i].funcs = NULL;
> > +   }
> > +
> >  }
> >  EXPORT_SYMBOL(drm_atomic_state_default_clear);
> >  
> > @@ -976,6 +991,46 @@ static void drm_atomic_plane_print_state(struct 
> > drm_printer *p,
> > plane->funcs->atomic_print_state(p, state);
> >  }
> >  
> > +
> 
> Needs kerneldoc here.
> 
> > +void *
> > +drm_atomic_get_priv_obj_state(struct drm_atomic_state *state, void *obj,
> 
> ocd bikeshed: priv_obj vs private_obj inconsistency here, please stick to
> one (I don't care which one).
> 
> > + const struct drm_private_state_funcs *funcs)
> > +{
> > +   int index, num_objs, i;
> > +   size_t size;
> > +   struct __drm_private_objs_state *arr;
> > +
> > +   for (i = 0; i < state->num_private_objs; i++)
> > +   if (obj == state->private_objs[i].obj &&
> > +   state->private_objs[i].obj_state)
> > +   return state->private_objs[i].obj_state;
> > +
> > +   num_objs = state->num_private_objs + 1;
> > +   size = sizeof(*state->private_objs) * num_objs;
> > +   arr = krealloc(state->private_objs, size, GFP_KERNEL);
> > +   if (!arr)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   state->private_objs = arr;
> > +   index = state->num_private_objs;
> > +   memset(>private_objs[index], 0, sizeof(*state->private_objs));
> > +
> > +   state->private_objs[index].obj_state = funcs->duplicate_state(state, 
> > obj);
> > +   if (!state->private_objs[index].obj_state)
> > +   return ERR_PTR(-ENOMEM);
> 
> I wondered whether we need to allow other error codes than ENOMEM, e.g.
> if duplicate_state needs to acquire a ww_mutex. But we can always acquire
> the necessary locks outside of drm_atomic_get_priv_obj_state in some
> helper/driver wrapper. So no big deal, but worth explaining that
> drm_atomic_get_priv_obj_state won't acquire necessarily locsk (since it
> doesn't know about them) in the kernel-doc.
> 

Got it, will include that.

> > +
> > +   state->private_objs[index].obj = obj;
> > +   state->private_objs[index].funcs = funcs;
> > +   state->num_private_objs = num_objs;
> > +
> > +   DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n",
> > +

Re: [Intel-gfx] [PATCH v2 8/9] drm/dp: Release DP MST shared link bandwidth

[Pandiyan, Dhinakaran]

On Wed, 2017-01-25 at 07:16 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:36PM -0800, Dhinakaran Pandiyan wrote:
> > Implement the ->atomic_release() callback to release the shared link
> > bandwidth that was originally acquired during compute_config()
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 28 
> >  1 file changed, 28 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index f51574f..2f57a56 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -78,6 +78,33 @@ static bool intel_dp_mst_compute_config(struct 
> > intel_encoder *encoder,
> >  
> >  }
> >  
> > +static void intel_dp_mst_atomic_release(struct drm_connector *connector,
> > +   struct drm_connector_state *conn_state)
> > +{
> > +   struct intel_dp_mst_encoder *intel_mst;
> > +   struct drm_dp_mst_topology_mgr *mgr;
> > +   struct drm_dp_mst_topology_state *topology_state;
> > +   struct drm_encoder *encoder;
> > +   struct intel_connector *intel_connector = to_intel_connector(connector);
> > +
> > +   encoder = connector->state->best_encoder;
> > +   if (!encoder || to_intel_encoder(encoder)->type != INTEL_OUTPUT_DP_MST)
> > +   return;
> 
> NULL encoder should imo be caught in core. Type != DP_MST is impossible,
> if you're unsure make it into a BUG_ON for testing.


I don't get why (type != INTEL_OUTPUT_DP_MST) is impossible. Is that
because we have the implementation for atomic_release() only for MST
connectors? But, that is only for now.

-DK
> > +
> > +   intel_mst = enc_to_mst(encoder);
> > +   mgr = _mst->primary->dp.mst_mgr;
> > +
> > +   topology_state = drm_atomic_get_mst_topology_state(conn_state->state,
> > +  mgr);
> > +   if (IS_ERR(topology_state)) {
> > +   DRM_DEBUG_KMS("failed to create MST topology state %ld\n",
> > +   PTR_ERR(topology_state));
> > +   return;
> > +   }
> > +
> > +   drm_dp_atomic_release_vcpi_slots(topology_state, intel_connector->port);
> 
> I think it'd be great to merge this together into 1 helper that both gets
> the state and releases the vcpi, for less code in drivers.

Agreed.

> > +}
> > +
> >  static void intel_mst_disable_dp(struct intel_encoder *encoder,
> >  struct intel_crtc_state *old_crtc_state,
> >  struct drm_connector_state *old_conn_state)
> > @@ -401,6 +428,7 @@ static const struct drm_connector_helper_funcs 
> > intel_dp_mst_connector_helper_fun
> > .mode_valid = intel_dp_mst_mode_valid,
> > .atomic_best_encoder = intel_mst_atomic_best_encoder,
> > .best_encoder = intel_mst_best_encoder,
> > +   .atomic_release = intel_dp_mst_atomic_release,
> >  };
> >  
> >  static void intel_dp_mst_encoder_destroy(struct drm_encoder *encoder)
> > -- 
> > 2.7.4
> > 
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 9/9] drm/dp: Track MST link bandwidth

[Pandiyan, Dhinakaran]

On Wed, 2017-01-25 at 07:15 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:37PM -0800, Dhinakaran Pandiyan wrote:
> > Use the added helpers to track MST link bandwidth for atomic modesets.
> > Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> > enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots().
> > Similarly, link bw is released during ->atomic_check() with the connector
> > helper callback ->atomic_release() when CRTCs are disabled.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c |  9 -
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 13 -
> >  2 files changed, 20 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index dd34d21..0d42173 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -385,8 +385,15 @@ mode_fixup(struct drm_atomic_state *state)
> >  
> > WARN_ON(!!conn_state->best_encoder != !!conn_state->crtc);
> >  
> > -   if (!conn_state->crtc || !conn_state->best_encoder)
> > +   if (!conn_state->crtc || !conn_state->best_encoder) {
> > +   const struct drm_connector_helper_funcs *conn_funcs;
> > +
> > +   conn_funcs = connector->helper_private;
> > +   if (conn_funcs->atomic_release)
> > +   conn_funcs->atomic_release(connector,
> > +  conn_state);
> 
> I wonder whether this won't surprise drivers: The way you coded this
> release only gets called when the connector is fully disabled. But it does
> not get called when you atomically switch it from one crtc to the other
> (in which case you also might want to release resources, before allocating
> new ones). I think that case of directly switching stuff is even a bug in
> your current atomic tracking code ...
> 
> We also need to extract the release calls into a separate loop which runs
> _before_ we allocate any resources. Otherwise if you do an atomic commit
> where you disable connector2 and enable connector1 and they can't run both
> at the same time it'll fail, because we'll release the vcpi for connector2
> only after we've tried to get it for connnector1.
> 


Yeah, you are right. I thought of this problem and then forgot about it.
Is there any igt test to test the switching?


-DK
> > continue;
> > +   }
> >  
> > crtc_state = drm_atomic_get_existing_crtc_state(state,
> > 
> > conn_state->crtc);
> 
> Misplaced hunk, this needs to be in the patch that adds the
> ->atomic_release callback.
> 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 2f57a56..ee5fedb 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -44,6 +44,7 @@ static bool intel_dp_mst_compute_config(struct 
> > intel_encoder *encoder,
> > int lane_count, slots;
> > const struct drm_display_mode *adjusted_mode = 
> > _config->base.adjusted_mode;
> > int mst_pbn;
> > +   struct drm_dp_mst_topology_state *topology_state;
> >  
> > pipe_config->has_pch_encoder = false;
> > bpp = 24;
> > @@ -65,7 +66,17 @@ static bool intel_dp_mst_compute_config(struct 
> > intel_encoder *encoder,
> > mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
> >  
> > pipe_config->pbn = mst_pbn;
> > -   slots = drm_dp_find_vcpi_slots(_dp->mst_mgr, mst_pbn);
> > +   topology_state = drm_atomic_get_mst_topology_state(state,
> > +  _dp->mst_mgr);
> > +   if (topology_state == NULL)
> > +   return false;
> > +
> > +   slots = drm_dp_atomic_find_vcpi_slots(topology_state, connector->port,
> > + mst_pbn);
> 
> Can we merge the get_mst_topology_state and find_vcpi_slots functions
> together? Would be less code in drivers ...
> 
> > +   if (slots < 0) {
> > +   DRM_DEBUG_KMS("not enough link bw for this mode\n");
> > +   return false;
> > +   }
> 
> And then also stuff the error checking in there, and just have a return
> -EINVAL when there's not enough bw.
> 
> I think this should be together with the previous patch, to wire up the
> entire mst state tracking for i915 at the same time. Atm the previous
> patch just wires up dead code, which is a bit backwards.
> -Daniel
> 
> >  
> > intel_link_compute_m_n(bpp, lane_count,
> >adjusted_mode->crtc_clock,
> > -- 
> > 2.7.4
> > 
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 7/9] drm: Connector helper function to release atomic state

[Pandiyan, Dhinakaran]

On Wed, 2017-01-25 at 07:18 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:35PM -0800, Dhinakaran Pandiyan wrote:
> > Having a ->atomic_release callback is useful to release shared resources
> > that get allocated in compute_config().
> > 
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  include/drm/drm_modeset_helper_vtables.h | 15 +++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/include/drm/drm_modeset_helper_vtables.h 
> > b/include/drm/drm_modeset_helper_vtables.h
> > index 46f5b34..e41b18a 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -831,6 +831,21 @@ struct drm_connector_helper_funcs {
> >  */
> > struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
> > *connector,
> >struct drm_connector_state 
> > *connector_state);
> > +
> > +   /**
> > +* @atomic_release:
> > +*
> > +* This function is used to release shared resources that were
> > +* previously acquired. For example, resources acquired in
> > +* encoder->compute_config() can be released by calling this function
> 
> @compute_config is the right way to do references within the same struct.
> 
> > +* from mode_fixup()
> 
> Same here.
> 
> Patch split up is a bit strange, hence why my review of the design is in
> later patches.
> 
> Thanks, Daniel
> 


I'll squash them appropriately, thanks for the review.

-DK
> > +*
> > +* NOTE:
> > +*
> > +* This function is called in the check phase of an atomic update.
> > +*/
> > +   void (*atomic_release)(struct drm_connector *connector,
> > +  struct drm_connector_state *connector_state);
> >  };
> >  
> >  /**
> > -- 
> > 2.7.4
> > 
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/9] drm/dp: Split drm_dp_mst_allocate_vcpi

[Pandiyan, Dhinakaran]

On Wed, 2017-01-25 at 10:31 +1000, Dave Airlie wrote:
> On 25 January 2017 at 09:49, Dhinakaran Pandiyan
>  wrote:
> > drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure,
> > also finds if there are enough slots available. This check is a duplicate
> > of that implemented in drm_dp_mst_find_vcpi_slots(). Let's move this check
> > out and reuse the existing drm_dp_mst_find_vcpi_slots() function to check
> > if there are enough vcpi slots before allocating them.
> >
> > This brings the check to one place. Additionally drivers that will use MST
> > state tracking for atomic modesets can use the atomic version of
> > find_vcpi_slots() and reuse drm_dp_mst_allocate_vcpi()
> >
> 
> Also seem sane, at least for the core bits,
> 
> Reviewed-by: Dave Airlie 
> 

Thanks for the review.

-DK


> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c  | 20 +---
> >  drivers/gpu/drm/i915/intel_dp_mst.c|  4 ++--
> >  drivers/gpu/drm/nouveau/nv50_display.c |  3 ++-
> >  drivers/gpu/drm/radeon/radeon_dp_mst.c |  4 +++-
> >  include/drm/drm_dp_mst_helper.h|  2 +-
> >  5 files changed, 17 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index d9edd84..b871d4e 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2479,20 +2479,17 @@ int drm_dp_find_vcpi_slots(struct 
> > drm_dp_mst_topology_mgr *mgr,
> >  EXPORT_SYMBOL(drm_dp_find_vcpi_slots);
> >
> >  static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr,
> > -   struct drm_dp_vcpi *vcpi, int pbn)
> > +   struct drm_dp_vcpi *vcpi, int pbn, int slots)
> >  {
> > -   int num_slots;
> > int ret;
> >
> > -   num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
> > -
> > /* max. time slots - one slot for MTP header */
> > -   if (num_slots > 63)
> > +   if (slots > 63)
> > return -ENOSPC;
> >
> > vcpi->pbn = pbn;
> > -   vcpi->aligned_pbn = num_slots * mgr->pbn_div;
> > -   vcpi->num_slots = num_slots;
> > +   vcpi->aligned_pbn = slots * mgr->pbn_div;
> > +   vcpi->num_slots = slots;
> >
> > ret = drm_dp_mst_assign_payload_id(mgr, vcpi);
> > if (ret < 0)
> > @@ -2507,7 +2504,7 @@ static int drm_dp_init_vcpi(struct 
> > drm_dp_mst_topology_mgr *mgr,
> >   * @pbn: payload bandwidth number to request
> >   * @slots: returned number of slots for this PBN.
> >   */
> > -bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct 
> > drm_dp_mst_port *port, int pbn, int *slots)
> > +bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct 
> > drm_dp_mst_port *port, int pbn, int slots)
> >  {
> > int ret;
> >
> > @@ -2515,16 +2512,18 @@ bool drm_dp_mst_allocate_vcpi(struct 
> > drm_dp_mst_topology_mgr *mgr, struct drm_dp
> > if (!port)
> > return false;
> >
> > +   if (slots < 0)
> > +   return false;
> > +
> > if (port->vcpi.vcpi > 0) {
> > DRM_DEBUG_KMS("payload: vcpi %d already allocated for pbn 
> > %d - requested pbn %d\n", port->vcpi.vcpi, port->vcpi.pbn, pbn);
> > if (pbn == port->vcpi.pbn) {
> > -   *slots = port->vcpi.num_slots;
> > drm_dp_put_port(port);
> > return true;
> > }
> > }
> >
> > -   ret = drm_dp_init_vcpi(mgr, >vcpi, pbn);
> > +   ret = drm_dp_init_vcpi(mgr, >vcpi, pbn, slots);
> > if (ret) {
> > DRM_DEBUG_KMS("failed to init vcpi slots=%d max=63 
> > ret=%d\n",
> > DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
> > @@ -2532,7 +2531,6 @@ bool drm_dp_mst_allocate_vcpi(struct 
> > drm_dp_mst_topology_mgr *mgr, struct drm_dp
> > }
> > DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
> > pbn, port->vcpi.num_slots);
> > -   *slots = port->vcpi.num_slots;
> >
> > drm_dp_put_port(port);
> > return true;
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 38e3ca2..f51574f 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -147,7 +147,6 @@ static void intel_mst_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > to_intel_connector(conn_state->connector);
> > int ret;
> > uint32_t temp;
> > -   int slots;
> >
> > /* MST encoders are bound to a crtc, not to a connector,
> >  * force the mapping here for get_hw_state.
> > @@ -177,7 +176,8 @@ static void intel_mst_pre_enable_dp(struct 
> > intel_encoder *encoder,
> >
> > ret = 

Re: [Intel-gfx] [PATCH v2 2/9] drm/dp: Kill unused MST vcpi slot availability tracking

[Pandiyan, Dhinakaran]

On Wed, 2017-01-25 at 06:43 +0100, Daniel Vetter wrote:
> On Tue, Jan 24, 2017 at 03:49:30PM -0800, Dhinakaran Pandiyan wrote:
> > The avail_slots member in the MST topology manager is never updated to
> > reflect the available vcpi slots. The check is effectively against
> > total_slots. So, let's make that check obvious. Secondly, since the total
> > vcpi time slots is always 63 and does not depend on the link BW, remove
> > total_slots from MST topology manager struct. The third change is to
> > remove total_pbn which is hardcoded to 2560. The total PBN that the
> > topology manager allocates from depends on the link rate and is not a
> > constant. So, fix this by removing the total_pbn member itself. Finally,
> > make debug messages more descriptive.
> 
> Ok, these are 3 different changes, and they need to be split up. Well, at
> least in 2 patches, to get the functional change out of there:
> - First hardcode avail_slots to 63, with the commit message explaining in
>   detail why that's the right thing. You can already remove total_pbn and
>   total_slots in that patch, since they will be unused. The commit message
>   should have a reference to the DP spec to support that "it's always 63"
>   claim.
> - Then garbage-collect ->avail_slots in a 2nd patch.
> 
> If you smash these together it's a lot less obvious that this is not just
> a pure refactoring.
> 
> Thanks, Daniel
> 

Makes sense, will do this in the next revision.

-DK
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 16 
> >  include/drm/drm_dp_mst_helper.h   | 12 
> >  2 files changed, 8 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 122a1b0..d9edd84 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2042,10 +2042,6 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
> > drm_dp_mst_topology_mgr *mgr, bool ms
> > goto out_unlock;
> > }
> >  
> > -   mgr->total_pbn = 2560;
> > -   mgr->total_slots = DIV_ROUND_UP(mgr->total_pbn, mgr->pbn_div);
> > -   mgr->avail_slots = mgr->total_slots;
> > -
> > /* add initial branch device at LCT 1 */
> > mstb = drm_dp_add_mst_branch_device(1, NULL);
> > if (mstb == NULL) {
> > @@ -2475,7 +2471,8 @@ int drm_dp_find_vcpi_slots(struct 
> > drm_dp_mst_topology_mgr *mgr,
> >  
> > num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
> >  
> > -   if (num_slots > mgr->avail_slots)
> > +   /* max. time slots - one slot for MTP header */
> > +   if (num_slots > 63)
> > return -ENOSPC;
> > return num_slots;
> >  }
> > @@ -2489,7 +2486,8 @@ static int drm_dp_init_vcpi(struct 
> > drm_dp_mst_topology_mgr *mgr,
> >  
> > num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
> >  
> > -   if (num_slots > mgr->avail_slots)
> > +   /* max. time slots - one slot for MTP header */
> > +   if (num_slots > 63)
> > return -ENOSPC;
> >  
> > vcpi->pbn = pbn;
> > @@ -2528,10 +2526,12 @@ bool drm_dp_mst_allocate_vcpi(struct 
> > drm_dp_mst_topology_mgr *mgr, struct drm_dp
> >  
> > ret = drm_dp_init_vcpi(mgr, >vcpi, pbn);
> > if (ret) {
> > -   DRM_DEBUG_KMS("failed to init vcpi %d %d %d\n", 
> > DIV_ROUND_UP(pbn, mgr->pbn_div), mgr->avail_slots, ret);
> > +   DRM_DEBUG_KMS("failed to init vcpi slots=%d max=63 ret=%d\n",
> > +   DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
> > goto out;
> > }
> > -   DRM_DEBUG_KMS("initing vcpi for %d %d\n", pbn, port->vcpi.num_slots);
> > +   DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
> > +   pbn, port->vcpi.num_slots);
> > *slots = port->vcpi.num_slots;
> >  
> > drm_dp_put_port(port);
> > diff --git a/include/drm/drm_dp_mst_helper.h 
> > b/include/drm/drm_dp_mst_helper.h
> > index 27f3e99..b0f4a09 100644
> > --- a/include/drm/drm_dp_mst_helper.h
> > +++ b/include/drm/drm_dp_mst_helper.h
> > @@ -479,18 +479,6 @@ struct drm_dp_mst_topology_mgr {
> >  * @pbn_div: PBN to slots divisor.
> >  */
> > int pbn_div;
> > -   /**
> > -* @total_slots: Total slots that can be allocated.
> > -*/
> > -   int total_slots;
> > -   /**
> > -* @avail_slots: Still available slots that can be allocated.
> > -*/
> > -   int avail_slots;
> > -   /**
> > -* @total_pbn: Total PBN count.
> > -*/
> > -   int total_pbn;
> >  
> > /**
> >  * @qlock: protects @tx_msg_downq, the tx_slots in struct
> > -- 
> > 2.7.4
> > 
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> 
> On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> > On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
> >> Hi,
> >>
> >> On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
> >>> It is necessary to track states for objects other than connector, crtc
> >>> and plane for atomic modesets. But adding objects like DP MST link
> >>> bandwidth to drm_atomic_state would mean that a non-core object will be
> >>> modified by the core helper functions for swapping and clearing
> >>> it's state. So, lets add void * objects and helper functions that operate
> >>> on void * types to keep these objects and states private to the core.
> >>> Drivers can then implement specific functions to swap and clear states.
> >>> The other advantage having just void * for these objects in
> >>> drm_atomic_state is that objects of different types can be managed in the
> >>> same state array.
> >>>
> >>> v2: Added docs and new iterator to filter private objects (Daniel)
> >>>
> >>> Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> >>> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> >>> ---
> >>>  drivers/gpu/drm/drm_atomic.c| 68 +++
> >>>  drivers/gpu/drm/drm_atomic_helper.c |  5 ++
> >>>  include/drm/drm_atomic.h| 91 
> >>> +
> >>>  3 files changed, 164 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >>> index a567310..1a9ffe8 100644
> >>> --- a/drivers/gpu/drm/drm_atomic.c
> >>> +++ b/drivers/gpu/drm/drm_atomic.c
> >>> @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct 
> >>> drm_atomic_state *state)
> >>>   kfree(state->connectors);
> >>>   kfree(state->crtcs);
> >>>   kfree(state->planes);
> >>> + kfree(state->private_objs);
> >>>  }
> >>>  EXPORT_SYMBOL(drm_atomic_state_default_release);
> >>>
> >>> @@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
> >>> drm_atomic_state *state)
> >>>   state->planes[i].ptr = NULL;
> >>>   state->planes[i].state = NULL;
> >>>   }
> >>> +
> >>> + for (i = 0; i < state->num_private_objs; i++) {
> >>> + void *private_obj = state->private_objs[i].obj;
> >>> + void *obj_state = state->private_objs[i].obj_state;
> >>> +
> >>> + if (!private_obj)
> >>> + continue;
> >>> +
> >>> + state->private_objs[i].funcs->destroy_state(obj_state);
> >>> + state->private_objs[i].obj = NULL;
> >>> + state->private_objs[i].obj_state = NULL;
> >>> + state->private_objs[i].funcs = NULL;
> >>> + }
> >>> +
> >>>  }
> >>>  EXPORT_SYMBOL(drm_atomic_state_default_clear);
> >>>
> >>> @@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
> >>> drm_printer *p,
> >>>  }
> >>>
> >>>  /**
> >>> + * drm_atomic_get_private_obj_state - get private object state
> >>> + * @state: global atomic state
> >>> + * @obj: private object to get the state for
> >>> + * @funcs: pointer to the struct of function pointers that identify the 
> >>> object
> >>> + * type
> >>> + *
> >>> + * This function returns the private object state for the given private 
> >>> object,
> >>> + * allocating the state if needed. It does not grab any locks as the 
> >>> caller is
> >>> + * expected to care of any required locking.
> >>> + *
> >>> + * RETURNS:
> >>> + *
> >>> + * Either the allocated state or the error code encoded into a pointer.
> >>> + */
> >>> +void *
> >>> +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void 
> >>> *obj,
> >>> +   const struct drm_private_state_funcs *funcs)
> >>> +{
> >>> + int index, num_objs, i;
> >>> + size_t size;
> >>> + struct __drm_private_objs_state *arr;
> >>> +
> >>> + for (i = 

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Wed, 2017-02-22 at 09:59 +0530, Archit Taneja wrote:
> 
> On 02/22/2017 05:31 AM, Pandiyan, Dhinakaran wrote:
> > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> >>
> >> On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> >>> On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
> >>>> Hi,
> >>>>
> >>>> On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
> >>>>> It is necessary to track states for objects other than connector, crtc
> >>>>> and plane for atomic modesets. But adding objects like DP MST link
> >>>>> bandwidth to drm_atomic_state would mean that a non-core object will be
> >>>>> modified by the core helper functions for swapping and clearing
> >>>>> it's state. So, lets add void * objects and helper functions that 
> >>>>> operate
> >>>>> on void * types to keep these objects and states private to the core.
> >>>>> Drivers can then implement specific functions to swap and clear states.
> >>>>> The other advantage having just void * for these objects in
> >>>>> drm_atomic_state is that objects of different types can be managed in 
> >>>>> the
> >>>>> same state array.
> >>>>>
> >>>>> v2: Added docs and new iterator to filter private objects (Daniel)
> >>>>>
> >>>>> Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> >>>>> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> >>>>> ---
> >>>>>  drivers/gpu/drm/drm_atomic.c| 68 +++
> >>>>>  drivers/gpu/drm/drm_atomic_helper.c |  5 ++
> >>>>>  include/drm/drm_atomic.h| 91 
> >>>>> +
> >>>>>  3 files changed, 164 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >>>>> index a567310..1a9ffe8 100644
> >>>>> --- a/drivers/gpu/drm/drm_atomic.c
> >>>>> +++ b/drivers/gpu/drm/drm_atomic.c
> >>>>> @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct 
> >>>>> drm_atomic_state *state)
> >>>>> kfree(state->connectors);
> >>>>> kfree(state->crtcs);
> >>>>> kfree(state->planes);
> >>>>> +   kfree(state->private_objs);
> >>>>>  }
> >>>>>  EXPORT_SYMBOL(drm_atomic_state_default_release);
> >>>>>
> >>>>> @@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
> >>>>> drm_atomic_state *state)
> >>>>> state->planes[i].ptr = NULL;
> >>>>> state->planes[i].state = NULL;
> >>>>> }
> >>>>> +
> >>>>> +   for (i = 0; i < state->num_private_objs; i++) {
> >>>>> +   void *private_obj = state->private_objs[i].obj;
> >>>>> +   void *obj_state = state->private_objs[i].obj_state;
> >>>>> +
> >>>>> +   if (!private_obj)
> >>>>> +   continue;
> >>>>> +
> >>>>> +   state->private_objs[i].funcs->destroy_state(obj_state);
> >>>>> +   state->private_objs[i].obj = NULL;
> >>>>> +   state->private_objs[i].obj_state = NULL;
> >>>>> +   state->private_objs[i].funcs = NULL;
> >>>>> +   }
> >>>>> +
> >>>>>  }
> >>>>>  EXPORT_SYMBOL(drm_atomic_state_default_clear);
> >>>>>
> >>>>> @@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
> >>>>> drm_printer *p,
> >>>>>  }
> >>>>>
> >>>>>  /**
> >>>>> + * drm_atomic_get_private_obj_state - get private object state
> >>>>> + * @state: global atomic state
> >>>>> + * @obj: private object to get the state for
> >>>>> + * @funcs: pointer to the struct of function pointers that identify 
> >>>>> the object
> >>>>> + * type
> >>>>> + *
> >>>>> + * This functi

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Pandiyan, Dhinakaran]

On Thu, 2017-02-16 at 09:09 +, Lankhorst, Maarten wrote:
> Daniel Vetter schreef op di 14-02-2017 om 20:51 [+0100]:
> > On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran
> > <dhinakaran.pandi...@intel.com> wrote:
> > > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> > > > Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> > > > > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> > > > > > 
> > > > > > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-
> > > > > > 0800]:
> > > > > > > 
> > > > > > > Having a ->atomic_release callback is useful to release
> > > > > > > shared
> > > > > > > resources
> > > > > > > that get allocated in compute_config(). This function is
> > > > > > > expected
> > > > > > > to
> > > > > > > be
> > > > > > > called in the atomic_check() phase before new resources are
> > > > > > > acquired.
> > > > > > > 
> > > > > > > v2: Moved the caller hunk to this patch (Daniel)
> > > > > > > 
> > > > > > > Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> > > > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@int
> > > > > > > el.com
> > > > > > > > 
> > > > > > > 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/drm_atomic_helper.c  | 19
> > > > > > > +++
> > > > > > >  include/drm/drm_modeset_helper_vtables.h | 13
> > > > > > > +
> > > > > > >  2 files changed, 32 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > index 8795088..92bd741 100644
> > > > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> > > > > > > drm_device *dev,
> > > > > > > }
> > > > > > > }
> > > > > > > 
> > > > > > > +   for_each_connector_in_state(state, connector,
> > > > > > > connector_state, i) {
> > > > > > > +   const struct drm_connector_helper_funcs
> > > > > > > *conn_funcs;
> > > > > > > +   struct drm_crtc_state *crtc_state;
> > > > > > > +
> > > > > > > +   conn_funcs = connector->helper_private;
> > > > > > > +   if (!conn_funcs->atomic_release)
> > > > > > > +   continue;
> > > > > > > +
> > > > > > > +   if (!connector->state->crtc)
> > > > > > > +   continue;
> > > > > > > +
> > > > > > > +   crtc_state =
> > > > > > > drm_atomic_get_existing_crtc_state(state, connector->state-
> > > > > > > > crtc);
> > > > > > > 
> > > > > > > +
> > > > > > > +   if (crtc_state->connectors_changed ||
> > > > > > > +   crtc_state->mode_changed ||
> > > > > > > +   (crtc_state->active_changed &&
> > > > > > > !crtc_state-
> > > > > > > > 
> > > > > > > > active))
> > > > > > > 
> > > > > > > +   conn_funcs-
> > > > > > > >atomic_release(connector,
> > > > > > > connector_state);
> > > > > > > +   }
> > > > > > 
> > > > > > Could we deal with the VCPI state separately in
> > > > > > intel_modeset_checks,
> > > > > > like we do with dpll?
> > > > > 
> > > > > We'd want to release the VCPI slots before they are acquired in
> > > > > ->compute_config(). intel_modeset_check

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Pandiyan, Dhinakaran]

On Mon, 2017-02-13 at 21:26 +, Pandiyan, Dhinakaran wrote:
> On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> > Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> > > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> > > > 
> > > > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> > > > > 
> > > > > Having a ->atomic_release callback is useful to release shared
> > > > > resources
> > > > > that get allocated in compute_config(). This function is expected
> > > > > to
> > > > > be
> > > > > called in the atomic_check() phase before new resources are
> > > > > acquired.
> > > > > 
> > > > > v2: Moved the caller hunk to this patch (Daniel)
> > > > > 
> > > > > Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com
> > > > > >
> > > > > ---
> > > > >  drivers/gpu/drm/drm_atomic_helper.c  | 19
> > > > > +++
> > > > >  include/drm/drm_modeset_helper_vtables.h | 13 +
> > > > >  2 files changed, 32 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > index 8795088..92bd741 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> > > > > drm_device *dev,
> > > > >   }
> > > > >   }
> > > > >  
> > > > > + for_each_connector_in_state(state, connector,
> > > > > connector_state, i) {
> > > > > + const struct drm_connector_helper_funcs
> > > > > *conn_funcs;
> > > > > + struct drm_crtc_state *crtc_state;
> > > > > +
> > > > > + conn_funcs = connector->helper_private;
> > > > > + if (!conn_funcs->atomic_release)
> > > > > + continue;
> > > > > +
> > > > > + if (!connector->state->crtc)
> > > > > + continue;
> > > > > +
> > > > > + crtc_state =
> > > > > drm_atomic_get_existing_crtc_state(state, connector->state-
> > > > > >crtc);
> > > > > +
> > > > > + if (crtc_state->connectors_changed ||
> > > > > + crtc_state->mode_changed ||
> > > > > + (crtc_state->active_changed && !crtc_state-
> > > > > > 
> > > > > > active))
> > > > > + conn_funcs->atomic_release(connector,
> > > > > connector_state);
> > > > > + }
> > > > 
> > > > Could we deal with the VCPI state separately in
> > > > intel_modeset_checks,
> > > > like we do with dpll?
> > > 
> > > We'd want to release the VCPI slots before they are acquired in
> > > ->compute_config(). intel_modeset_checks() will be too late to
> > > release
> > > them. Are you suggesting both acquiring and releasing slots should be
> > > done in intel_modeset_checks()?
> > 
> > That makes things a bit more nasty. Maybe add a
> > conn_funcs->atomic_check that always gets called, something like I did
> > below?
> > 
> > I'd love to use it for some atomic connector properties too.
> 
> 
> Adding and unconditionally calling conn_funcs->atomic_check() should be
> doable. It also follows the pattern we have for encoders and CRTCs. But
> I'll have to move the connector->state->crtc state checks inside the
> function.
> 
> -DK


This is what I mean -https://pastebin.ubuntu.com/23991405/
But, I do have one concern with calling this conn_func->atomic_check().
We are not validating the new connector_state like atomic_check() seems
to do generally but only cleaning up vcpi resources for compute_config()
to later acquire. Let me know if I am wrong in my understanding what
atomic_check() is expected to do.


-DK
> > > > 
> > > > 
> > > > Maybe implementing the relevant VCPI state could be done as an
> > > > atomic
> > > > helper function too, so other atomic drivers can just plug it in.
> > > > 
> > > The idea was to reduce boilerplate in the drivers and use the
> > > private_obj state for different object types.
> > > 
> > > 
> > > > 
> > > > Not sure how doable this is, but if it's not too hard, then it's
> > > > probably cleaner :)
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Pandiyan, Dhinakaran]

On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> > > 
> > > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> > > > 
> > > > Having a ->atomic_release callback is useful to release shared
> > > > resources
> > > > that get allocated in compute_config(). This function is expected
> > > > to
> > > > be
> > > > called in the atomic_check() phase before new resources are
> > > > acquired.
> > > > 
> > > > v2: Moved the caller hunk to this patch (Daniel)
> > > > 
> > > > Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com
> > > > >
> > > > ---
> > > >  drivers/gpu/drm/drm_atomic_helper.c  | 19
> > > > +++
> > > >  include/drm/drm_modeset_helper_vtables.h | 13 +
> > > >  2 files changed, 32 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 8795088..92bd741 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> > > > drm_device *dev,
> > > > }
> > > > }
> > > >  
> > > > +   for_each_connector_in_state(state, connector,
> > > > connector_state, i) {
> > > > +   const struct drm_connector_helper_funcs
> > > > *conn_funcs;
> > > > +   struct drm_crtc_state *crtc_state;
> > > > +
> > > > +   conn_funcs = connector->helper_private;
> > > > +   if (!conn_funcs->atomic_release)
> > > > +   continue;
> > > > +
> > > > +   if (!connector->state->crtc)
> > > > +   continue;
> > > > +
> > > > +   crtc_state =
> > > > drm_atomic_get_existing_crtc_state(state, connector->state-
> > > > >crtc);
> > > > +
> > > > +   if (crtc_state->connectors_changed ||
> > > > +   crtc_state->mode_changed ||
> > > > +   (crtc_state->active_changed && !crtc_state-
> > > > > 
> > > > > active))
> > > > +   conn_funcs->atomic_release(connector,
> > > > connector_state);
> > > > +   }
> > > 
> > > Could we deal with the VCPI state separately in
> > > intel_modeset_checks,
> > > like we do with dpll?
> > 
> > We'd want to release the VCPI slots before they are acquired in
> > ->compute_config(). intel_modeset_checks() will be too late to
> > release
> > them. Are you suggesting both acquiring and releasing slots should be
> > done in intel_modeset_checks()?
> 
> That makes things a bit more nasty. Maybe add a
> conn_funcs->atomic_check that always gets called, something like I did
> below?
> 
> I'd love to use it for some atomic connector properties too.


Adding and unconditionally calling conn_funcs->atomic_check() should be
doable. It also follows the pattern we have for encoders and CRTCs. But
I'll have to move the connector->state->crtc state checks inside the
function.

-DK
> > > 
> > > 
> > > Maybe implementing the relevant VCPI state could be done as an
> > > atomic
> > > helper function too, so other atomic drivers can just plug it in.
> > > 
> > The idea was to reduce boilerplate in the drivers and use the
> > private_obj state for different object types.
> > 
> > 
> > > 
> > > Not sure how doable this is, but if it's not too hard, then it's
> > > probably cleaner :)
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/dp/mst: fix kernel oops when turning off secondary monitor

[Pandiyan, Dhinakaran]

Looks like the right fix to me.

Reviewed-by: Dhinakaran Pandiyan 

On Wed, 2017-01-25 at 16:25 -0800, Nathan Ciobanu wrote:
> I tested this patch in dinq on a KBL system and it fixed the bug. The 
> system doesn't crash on disconnecting or powering off the second monitor 
> in the DP-MST chain. I also replied to the Bugzilla issue.
> 
> Tested-by: Nathan D Ciobanu 
> 
> On 12/05/2016 01:49 PM, Pierre-Louis Bossart wrote:
> > 100% reproducible issue found on SKL SkullCanyon NUC with two external
> > DP daisy-chained monitors in DP/MST mode. When turning off or changing
> > the input of the second monitor the machine stops with a kernel
> > oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly.
> >
> > This issue is traced to an inconsistent control flow in
> > drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at
> > the same time as 'req_payload.num_slots' is set to zero, but the pointer
> > is dereferenced even when req_payload.num_slot is zero.
> >
> > The problematic dereference was introduced in commit dfda0df34
> > ("drm/mst: rework payload table allocation to conform better")
> > and may impact all versions since v3.18
> >
> > The fix suggested by Chris Wilson removes the kernel oops and was found to
> > work well after 10mn of monkey-testing with the second monitor power and
> > input buttons
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990
> > Cc: Dave Airlie 
> > Signed-off-by: Pierre-Louis Bossart 
> > ---
> >   drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index aa64448..f59771d 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1817,7 +1817,7 @@ int drm_dp_update_payload_part1(struct 
> > drm_dp_mst_topology_mgr *mgr)
> > mgr->payloads[i].vcpi = req_payload.vcpi;
> > } else if (mgr->payloads[i].num_slots) {
> > mgr->payloads[i].num_slots = 0;
> > -   drm_dp_destroy_payload_step1(mgr, port, 
> > port->vcpi.vcpi, >payloads[i]);
> > +   drm_dp_destroy_payload_step1(mgr, port, 
> > mgr->payloads[i].vcpi, >payloads[i]);
> > req_payload.payload_state = 
> > mgr->payloads[i].payload_state;
> > mgr->payloads[i].start_slot = 0;
> > }
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Pandiyan, Dhinakaran]

On Tue, 2017-02-14 at 20:51 +0100, Daniel Vetter wrote:
> On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran
> <dhinakaran.pandi...@intel.com> wrote:
> > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> >> Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> >> > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> >> > >
> >> > > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> >> > > >
> >> > > > Having a ->atomic_release callback is useful to release shared
> >> > > > resources
> >> > > > that get allocated in compute_config(). This function is expected
> >> > > > to
> >> > > > be
> >> > > > called in the atomic_check() phase before new resources are
> >> > > > acquired.
> >> > > >
> >> > > > v2: Moved the caller hunk to this patch (Daniel)
> >> > > >
> >> > > > Suggested-by: Daniel Vetter <daniel.vet...@ffwll.ch>
> >> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com
> >> > > > >
> >> > > > ---
> >> > > >  drivers/gpu/drm/drm_atomic_helper.c  | 19
> >> > > > +++
> >> > > >  include/drm/drm_modeset_helper_vtables.h | 13 +
> >> > > >  2 files changed, 32 insertions(+)
> >> > > >
> >> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> >> > > > index 8795088..92bd741 100644
> >> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> > > > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> >> > > > drm_device *dev,
> >> > > > }
> >> > > > }
> >> > > >
> >> > > > +   for_each_connector_in_state(state, connector,
> >> > > > connector_state, i) {
> >> > > > +   const struct drm_connector_helper_funcs
> >> > > > *conn_funcs;
> >> > > > +   struct drm_crtc_state *crtc_state;
> >> > > > +
> >> > > > +   conn_funcs = connector->helper_private;
> >> > > > +   if (!conn_funcs->atomic_release)
> >> > > > +   continue;
> >> > > > +
> >> > > > +   if (!connector->state->crtc)
> >> > > > +   continue;
> >> > > > +
> >> > > > +   crtc_state =
> >> > > > drm_atomic_get_existing_crtc_state(state, connector->state-
> >> > > > >crtc);
> >> > > > +
> >> > > > +   if (crtc_state->connectors_changed ||
> >> > > > +   crtc_state->mode_changed ||
> >> > > > +   (crtc_state->active_changed && !crtc_state-
> >> > > > >
> >> > > > > active))
> >> > > > +   conn_funcs->atomic_release(connector,
> >> > > > connector_state);
> >> > > > +   }
> >> > >
> >> > > Could we deal with the VCPI state separately in
> >> > > intel_modeset_checks,
> >> > > like we do with dpll?
> >> >
> >> > We'd want to release the VCPI slots before they are acquired in
> >> > ->compute_config(). intel_modeset_checks() will be too late to
> >> > release
> >> > them. Are you suggesting both acquiring and releasing slots should be
> >> > done in intel_modeset_checks()?
> >>
> >> That makes things a bit more nasty. Maybe add a
> >> conn_funcs->atomic_check that always gets called, something like I did
> >> below?
> >>
> >> I'd love to use it for some atomic connector properties too.
> >
> >
> > Adding and unconditionally calling conn_funcs->atomic_check() should be
> > doable. It also follows the pattern we have for encoders and CRTCs. But
> > I'll have to move the connector->state->crtc state checks inside the
> > function.
> 
> Adding ->atomic_check that's unconditionally called sounds 

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
> Hi,
> 
> On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
> > It is necessary to track states for objects other than connector, crtc
> > and plane for atomic modesets. But adding objects like DP MST link
> > bandwidth to drm_atomic_state would mean that a non-core object will be
> > modified by the core helper functions for swapping and clearing
> > it's state. So, lets add void * objects and helper functions that operate
> > on void * types to keep these objects and states private to the core.
> > Drivers can then implement specific functions to swap and clear states.
> > The other advantage having just void * for these objects in
> > drm_atomic_state is that objects of different types can be managed in the
> > same state array.
> >
> > v2: Added docs and new iterator to filter private objects (Daniel)
> >
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 68 +++
> >  drivers/gpu/drm/drm_atomic_helper.c |  5 ++
> >  include/drm/drm_atomic.h| 91 
> > +
> >  3 files changed, 164 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index a567310..1a9ffe8 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct 
> > drm_atomic_state *state)
> > kfree(state->connectors);
> > kfree(state->crtcs);
> > kfree(state->planes);
> > +   kfree(state->private_objs);
> >  }
> >  EXPORT_SYMBOL(drm_atomic_state_default_release);
> >
> > @@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
> > drm_atomic_state *state)
> > state->planes[i].ptr = NULL;
> > state->planes[i].state = NULL;
> > }
> > +
> > +   for (i = 0; i < state->num_private_objs; i++) {
> > +   void *private_obj = state->private_objs[i].obj;
> > +   void *obj_state = state->private_objs[i].obj_state;
> > +
> > +   if (!private_obj)
> > +   continue;
> > +
> > +   state->private_objs[i].funcs->destroy_state(obj_state);
> > +   state->private_objs[i].obj = NULL;
> > +   state->private_objs[i].obj_state = NULL;
> > +   state->private_objs[i].funcs = NULL;
> > +   }
> > +
> >  }
> >  EXPORT_SYMBOL(drm_atomic_state_default_clear);
> >
> > @@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
> > drm_printer *p,
> >  }
> >
> >  /**
> > + * drm_atomic_get_private_obj_state - get private object state
> > + * @state: global atomic state
> > + * @obj: private object to get the state for
> > + * @funcs: pointer to the struct of function pointers that identify the 
> > object
> > + * type
> > + *
> > + * This function returns the private object state for the given private 
> > object,
> > + * allocating the state if needed. It does not grab any locks as the 
> > caller is
> > + * expected to care of any required locking.
> > + *
> > + * RETURNS:
> > + *
> > + * Either the allocated state or the error code encoded into a pointer.
> > + */
> > +void *
> > +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
> > + const struct drm_private_state_funcs *funcs)
> > +{
> > +   int index, num_objs, i;
> > +   size_t size;
> > +   struct __drm_private_objs_state *arr;
> > +
> > +   for (i = 0; i < state->num_private_objs; i++)
> > +   if (obj == state->private_objs[i].obj &&
> > +   state->private_objs[i].obj_state)
> > +   return state->private_objs[i].obj_state;
> 
> Comparing this func to drm_atomic_get_plane_state/drm_atomic_get_crtc_state, 
> it
> doesn't seem to call drm_modeset_lock if the obj_state doesn't already exist. 
> I
> don't understand the locking stuff toowell, I just noticed this difference 
> when
> comparing this approach with what is done in the msm kms driver (where we
> have subclassed drm_atomic_state to msm_kms_state).
> 
> Thanks,
> Archit
> 


The caller is expected to take care of any required locking. The
driver-private objects are opaque from core's pov, so the core is not
aware of necessary locks for that object type.

-DK 

> > +
> > +   num_objs = state->num_private_objs + 1;
> > +   size = sizeof(*state->private_objs) * num_objs;
> > +   arr = krealloc(state->private_objs, size, GFP_KERNEL);
> > +   if (!arr)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   state->private_objs = arr;
> > +   index = state->num_private_objs;
> > +   memset(>private_objs[index], 0, sizeof(*state->private_objs));
> > +
> > +   state->private_objs[index].obj_state = funcs->duplicate_state(state, 
> > obj);
> > +   if (!state->private_objs[index].obj_state)
> > +   return ERR_PTR(-ENOMEM);
> > +
> > +   state->private_objs[index].obj = 

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Pandiyan, Dhinakaran]

On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> > Having a ->atomic_release callback is useful to release shared
> > resources
> > that get allocated in compute_config(). This function is expected to
> > be
> > called in the atomic_check() phase before new resources are acquired.
> > 
> > v2: Moved the caller hunk to this patch (Daniel)
> > 
> > Suggested-by: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c  | 19 +++
> >  include/drm/drm_modeset_helper_vtables.h | 13 +
> >  2 files changed, 32 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 8795088..92bd741 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> > drm_device *dev,
> > }
> > }
> >  
> > +   for_each_connector_in_state(state, connector,
> > connector_state, i) {
> > +   const struct drm_connector_helper_funcs *conn_funcs;
> > +   struct drm_crtc_state *crtc_state;
> > +
> > +   conn_funcs = connector->helper_private;
> > +   if (!conn_funcs->atomic_release)
> > +   continue;
> > +
> > +   if (!connector->state->crtc)
> > +   continue;
> > +
> > +   crtc_state =
> > drm_atomic_get_existing_crtc_state(state, connector->state->crtc);
> > +
> > +   if (crtc_state->connectors_changed ||
> > +   crtc_state->mode_changed ||
> > +   (crtc_state->active_changed && !crtc_state-
> > >active))
> > +   conn_funcs->atomic_release(connector,
> > connector_state);
> > +   }
> 
> Could we deal with the VCPI state separately in intel_modeset_checks,
> like we do with dpll?

We'd want to release the VCPI slots before they are acquired in
->compute_config(). intel_modeset_checks() will be too late to release
them. Are you suggesting both acquiring and releasing slots should be
done in intel_modeset_checks()?


> 
> Maybe implementing the relevant VCPI state could be done as an atomic
> helper function too, so other atomic drivers can just plug it in.
> 
The idea was to reduce boilerplate in the drivers and use the
private_obj state for different object types.


> Not sure how doable this is, but if it's not too hard, then it's
> probably cleaner :)
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Thu, 2017-02-09 at 08:08 +, Chris Wilson wrote:
> On Wed, Feb 08, 2017 at 10:38:07PM -0800, Dhinakaran Pandiyan wrote:
> > +#define for_each_private_obj(__state, obj_funcs, obj, obj_state, __i, 
> > __funcs) \
> > +   for ((__i) = 0; \
> > +(__i) < (__state)->num_private_objs && \
> > +((obj) = (__state)->private_objs[__i].obj, \
> > +(__funcs) = (__state)->private_objs[__i].funcs,\
> > +(obj_state) = (__state)->private_objs[__i].obj_state, 1);  \
> 
> Align to ( and put the trailing 1 on its own line so it stands out.

Sure, will do that. Looks like I have to change other macros in that
file too.

-DK
> 
>(__i) < (__state)->num_private_objs && \
>((obj) = (__state)->private_objs[__i].obj, \
> (__funcs) = (__state)->private_objs[__i].funcs,   \
> (obj_state) = (__state)->private_objs[__i].obj_state, \
> 1);   \
>(__i)++)   \
> > +   for_each_if (__funcs == obj_funcs)
> > +
> > +/**
> >   * drm_atomic_crtc_needs_modeset - compute combined modeset need
> >   * @state: _crtc_state for the CRTC
> >   *
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Add function to return port from an encoder

[Pandiyan, Dhinakaran]

On Thu, 2016-08-18 at 21:39 -0700, Rodrigo Vivi wrote:
> On Mon, Aug 15, 2016 at 05:00:53PM -0700, Dhinakaran Pandiyan wrote:
> > There are places in the driver where we just need the 'port' associated
> > with an encoder and not 'struct intel_digital_port' that contains it.
> > This basically is a generic implementation of intel_ddi_get_encoder_port()
> > handling both DDI and Non-DDI encoders. The handling of the analog encoder
> > is delegated to the DDI specific function.
> > 
> > The idea to have a generic implementation that returned the 'enum port'
> > from 'struct intel_encoder' came from Ville.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  | 42 
> > ++-
> >  drivers/gpu/drm/i915/intel_display.c  | 18 +++
> >  drivers/gpu/drm/i915/intel_drv.h  |  8 ++-
> >  drivers/gpu/drm/i915/intel_opregion.c |  2 +-
> >  4 files changed, 38 insertions(+), 32 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index c2df4e4..13ceef4 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -301,24 +301,6 @@ static const struct bxt_ddi_buf_trans 
> > bxt_ddi_translations_hdmi[] = {
> > { 154, 0x9A, 1, 128, true },/* 9:   12000   */
> >  };
> >  
> > -enum port intel_ddi_get_encoder_port(struct intel_encoder *encoder)
> > -{
> > -   switch (encoder->type) {
> > -   case INTEL_OUTPUT_DP_MST:
> > -   return enc_to_mst(>base)->primary->port;
> > -   case INTEL_OUTPUT_DP:
> > -   case INTEL_OUTPUT_EDP:
> > -   case INTEL_OUTPUT_HDMI:
> > -   case INTEL_OUTPUT_UNKNOWN:
> > -   return enc_to_dig_port(>base)->port;
> > -   case INTEL_OUTPUT_ANALOG:
> > -   return PORT_E;
> > -   default:
> > -   MISSING_CASE(encoder->type);
> > -   return PORT_A;
> > -   }
> > -}
> > -
> >  static const struct ddi_buf_trans *
> >  bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
> >  {
> > @@ -421,7 +403,7 @@ void intel_prepare_dp_ddi_buffers(struct intel_encoder 
> > *encoder)
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > u32 iboost_bit = 0;
> > int i, n_dp_entries, n_edp_entries, size;
> > -   enum port port = intel_ddi_get_encoder_port(encoder);
> > +   enum port port = intel_get_encoder_port(encoder);
> > const struct ddi_buf_trans *ddi_translations_fdi;
> > const struct ddi_buf_trans *ddi_translations_dp;
> > const struct ddi_buf_trans *ddi_translations_edp;
> > @@ -499,7 +481,7 @@ static void intel_prepare_hdmi_ddi_buffers(struct 
> > intel_encoder *encoder)
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > u32 iboost_bit = 0;
> > int n_hdmi_entries, hdmi_level;
> > -   enum port port = intel_ddi_get_encoder_port(encoder);
> > +   enum port port = intel_get_encoder_port(encoder);
> > const struct ddi_buf_trans *ddi_translations_hdmi;
> >  
> > if (IS_BROXTON(dev_priv))
> > @@ -987,7 +969,7 @@ static void bxt_ddi_clock_get(struct intel_encoder 
> > *encoder,
> > struct intel_crtc_state *pipe_config)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > -   enum port port = intel_ddi_get_encoder_port(encoder);
> > +   enum port port = intel_get_encoder_port(encoder);
> > uint32_t dpll = port;
> >  
> > pipe_config->port_clock = bxt_calc_pll_link(dev_priv, dpll);
> > @@ -1130,7 +1112,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
> > *crtc)
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > enum pipe pipe = intel_crtc->pipe;
> > enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
> > -   enum port port = intel_ddi_get_encoder_port(intel_encoder);
> > +   enum port port = intel_get_encoder_port(intel_encoder);
> > int type = intel_encoder->type;
> > uint32_t temp;
> >  
> > @@ -1226,7 +1208,7 @@ bool intel_ddi_connector_get_hw_state(struct 
> > intel_connector *intel_connector)
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct intel_encoder *intel_encoder = intel_connector->encoder;
> > int type = intel_connector->base.connector_type;
> > -   enum port port = intel_ddi_get_encoder_port(intel_encoder);
> > +   enum port port = intel_get_encoder_port(intel_encoder);
> > enum pipe pipe = 0;
> > enum transcoder cpu_transcoder;
> > enum intel_display_power_domain power_domain;
> > @@ -1286,7 +1268,7 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
> > *encoder,
> >  {
> > struct drm_device *dev = encoder->base.dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > -   enum port port = intel_ddi_get_encoder_port(encoder);
> > +   enum port port = intel_get_encoder_port(encoder);
> > enum intel_display_power_domain power_domain;
> > u32 tmp;
> > int 

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Add function to return port from an encoder

[Pandiyan, Dhinakaran]

On Fri, 2016-08-19 at 10:02 +0200, Daniel Vetter wrote:
> On Mon, Aug 15, 2016 at 05:00:53PM -0700, Dhinakaran Pandiyan wrote:
> > There are places in the driver where we just need the 'port' associated
> > with an encoder and not 'struct intel_digital_port' that contains it.
> > This basically is a generic implementation of intel_ddi_get_encoder_port()
> > handling both DDI and Non-DDI encoders. The handling of the analog encoder
> > is delegated to the DDI specific function.
> > 
> > The idea to have a generic implementation that returned the 'enum port'
> > from 'struct intel_encoder' came from Ville.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  | 42 
> > ++-
> >  drivers/gpu/drm/i915/intel_display.c  | 18 +++
> >  drivers/gpu/drm/i915/intel_drv.h  |  8 ++-
> >  drivers/gpu/drm/i915/intel_opregion.c |  2 +-
> >  4 files changed, 38 insertions(+), 32 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index c2df4e4..13ceef4 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -301,24 +301,6 @@ static const struct bxt_ddi_buf_trans 
> > bxt_ddi_translations_hdmi[] = {
> > { 154, 0x9A, 1, 128, true },/* 9:   12000   */
> >  };
> >  
> > -enum port intel_ddi_get_encoder_port(struct intel_encoder *encoder)
> > -{
> > -   switch (encoder->type) {
> > -   case INTEL_OUTPUT_DP_MST:
> > -   return enc_to_mst(>base)->primary->port;
> > -   case INTEL_OUTPUT_DP:
> > -   case INTEL_OUTPUT_EDP:
> > -   case INTEL_OUTPUT_HDMI:
> > -   case INTEL_OUTPUT_UNKNOWN:
> > -   return enc_to_dig_port(>base)->port;
> > -   case INTEL_OUTPUT_ANALOG:
> > -   return PORT_E;
> > -   default:
> > -   MISSING_CASE(encoder->type);
> > -   return PORT_A;
> > -   }
> > -}
> 
> tbh if we really need this in general, I'd just store the port enum in
> intel_encoder and that's it. Maybe add a PORT_NONE = -1 for all the cases
> where it's not a port. A bit more churn to roll it tou, but this maze of
> indirections and casting here is really not pretty.
> 
A cursory check shows around 12 places (combined) in intel_ddi.c,
intel_audio.c and intel_hdmi.c where this can be useful.


Out of curiosity, what are the cases where we don't have a port? Before
hdmi/dp initialization? Or wireless display? 

> The give-away is that we have this massive type switch block, for
> something which is designed after OO priniciples: The correct way to fix
> that is by moving stuff up in the inheritence hirarchy.
> -Daniel
> 
I get your point. Something like this?

struct intel_encoder{
...
enum port attached_port;

}



> > -
> >  static const struct ddi_buf_trans *
> >  bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
> >  {
> > @@ -421,7 +403,7 @@ void intel_prepare_dp_ddi_buffers(struct intel_encoder 
> > *encoder)
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > u32 iboost_bit = 0;
> > int i, n_dp_entries, n_edp_entries, size;
> > -   enum port port = intel_ddi_get_encoder_port(encoder);
> > +   enum port port = intel_get_encoder_port(encoder);
> > const struct ddi_buf_trans *ddi_translations_fdi;
> > const struct ddi_buf_trans *ddi_translations_dp;
> > const struct ddi_buf_trans *ddi_translations_edp;
> > @@ -499,7 +481,7 @@ static void intel_prepare_hdmi_ddi_buffers(struct 
> > intel_encoder *encoder)
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > u32 iboost_bit = 0;
> > int n_hdmi_entries, hdmi_level;
> > -   enum port port = intel_ddi_get_encoder_port(encoder);
> > +   enum port port = intel_get_encoder_port(encoder);
> > const struct ddi_buf_trans *ddi_translations_hdmi;
> >  
> > if (IS_BROXTON(dev_priv))
> > @@ -987,7 +969,7 @@ static void bxt_ddi_clock_get(struct intel_encoder 
> > *encoder,
> > struct intel_crtc_state *pipe_config)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > -   enum port port = intel_ddi_get_encoder_port(encoder);
> > +   enum port port = intel_get_encoder_port(encoder);
> > uint32_t dpll = port;
> >  
> > pipe_config->port_clock = bxt_calc_pll_link(dev_priv, dpll);
> > @@ -1130,7 +1112,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
> > *crtc)
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > enum pipe pipe = intel_crtc->pipe;
> > enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
> > -   enum port port = intel_ddi_get_encoder_port(intel_encoder);
> > +   enum port port = intel_get_encoder_port(intel_encoder);
> > int type = intel_encoder->type;
> > uint32_t temp;
> >  
> > @@ -1226,7 +1208,7 @@ bool intel_ddi_connector_get_hw_state(struct 
> > intel_connector 

Re: [Intel-gfx] [PATCH 4/4] drm/i915/dp: Dump DP link status when link training stages fails

[Pandiyan, Dhinakaran]

On Thu, 2016-08-04 at 10:46 +0300, Jani Nikula wrote:
> On Thu, 04 Aug 2016, Dhinakaran Pandiyan  
> wrote:
> > A full dump of link status can be handy in debugging link training
> > failures. Let's add that to the debug messages when link training fails.
> >
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 11 +++
> >  drivers/gpu/drm/i915/intel_drv.h  |  6 --
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index c0a858d..ab7d1a6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -24,6 +24,15 @@
> >  #include "intel_drv.h"
> >  
> >  static void
> > +intel_dp_dump_link_status(const uint8_t link_status[DP_LINK_STATUS_SIZE])
> > +{
> > +
> > +   DRM_DEBUG_KMS("ln0_1:0x%x ln2_3:0x%x align:0x%x sink:0x%x 
> > adj_req0_1:0x%x adj_req2_3:0x%x",
> > + link_status[0], link_status[1], link_status[2],
> > + link_status[3], link_status[4], link_status[5]);
> > +}
> > +
> > +static void
> >  intel_get_adjust_train(struct intel_dp *intel_dp,
> >const uint8_t link_status[DP_LINK_STATUS_SIZE])
> >  {
> > @@ -170,6 +179,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
> > *intel_dp)
> > ++loop_tries;
> > if (loop_tries == 5) {
> > DRM_ERROR("too many full retries, give up\n");
> > +   intel_dp_dump_link_status(link_status);
> > break;
> > }
> > intel_dp_reset_link_train(intel_dp,
> > @@ -257,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct 
> > intel_dp *intel_dp)
> >  
> > if (cr_tries > 5) {
> > DRM_ERROR("failed to train DP, aborting\n");
> > +   intel_dp_dump_link_status(link_status);
> > break;
> > }
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 87069ba..549a8fd 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1356,8 +1356,6 @@ bool intel_dp_init_connector(struct 
> > intel_digital_port *intel_dig_port,
> >  struct intel_connector *intel_connector);
> >  void intel_dp_set_link_params(struct intel_dp *intel_dp,
> >   const struct intel_crtc_state *pipe_config);
> > -void intel_dp_start_link_train(struct intel_dp *intel_dp);
> > -void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> >  void intel_dp_encoder_reset(struct drm_encoder *encoder);
> >  void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
> > @@ -1409,6 +1407,10 @@ static inline unsigned int 
> > intel_dp_unused_lane_mask(int lane_count)
> > return ~((1 << lane_count) - 1) & 0xf;
> >  }
> >  
> > +/* intel_dp_link_training.c */
> > +void intel_dp_start_link_train(struct intel_dp *intel_dp);
> > +void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> 
> Unrelated cleanup change. Should be a (standalone) separate patch, and
> if it were, it could have been merged already.
> 
> Pro-tip: In general, you'll want to organize your series in a way that
> allows the early patches to be merged even when the review rounds are
> still in progress on the later patches. Crucial fixes first (so they can
> be backported without conflicts), trivial and non-controversial things
> next, and so on. You'll have a feeling of making progress, you'll have
> fewer rebases and conflicts later on, and it'll be easier for the
> reviewers too as the number of patches in later versions shrinks.
> 
> BR,
> Jani.
> 

Thanks for the tip Jani, will keep that in mind. I will split this patch
when I send the next version of the series.
> > +
> >  /* intel_dp_aux_backlight.c */
> >  int intel_dp_aux_init_backlight_funcs(struct intel_connector 
> > *intel_connector);
> 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/dp: Clarify clock recovery and channel equalization failures

[Pandiyan, Dhinakaran]

On Thu, 2016-08-04 at 04:12 +0100, Chris Wilson wrote:
> On Wed, Aug 03, 2016 at 08:07:40PM -0700, Dhinakaran Pandiyan wrote:
> > The causes of clock recovery and channel equalization failures are not
> > explicitly printed in debug messages. Help debugging link training
> > failures by printing why it failed.
> > 
> > Doing this in the driver would mean re-implementing some of the drm static
> > functions that decode link status. Let's avoid that with these debug
> > messages in drm.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 091053e..d763b57 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -64,12 +64,16 @@ bool drm_dp_channel_eq_ok(const u8 
> > link_status[DP_LINK_STATUS_SIZE],
> >  
> > lane_align = dp_link_status(link_status,
> > DP_LANE_ALIGN_STATUS_UPDATED);
> > -   if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0)
> > +   if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0) {
> > +   DRM_DEBUG_KMS("Inter-lane alignment not done\n");
> > return false;
> > +   }
> > for (lane = 0; lane < lane_count; lane++) {
> > lane_status = dp_get_lane_status(link_status, lane);
> > -   if ((lane_status & DP_CHANNEL_EQ_BITS) != DP_CHANNEL_EQ_BITS)
> > +   if ((lane_status & DP_CHANNEL_EQ_BITS) != DP_CHANNEL_EQ_BITS) {
> > +   DRM_DEBUG_KMS("Channel equalization not done for lane 
> > %d\n", lane);
> > return false;
> > +   }
> > }
> > return true;
> >  }
> > @@ -83,8 +87,10 @@ bool drm_dp_clock_recovery_ok(const u8 
> > link_status[DP_LINK_STATUS_SIZE],
> >  
> > for (lane = 0; lane < lane_count; lane++) {
> > lane_status = dp_get_lane_status(link_status, lane);
> > -   if ((lane_status & DP_LANE_CR_DONE) == 0)
> > +   if ((lane_status & DP_LANE_CR_DONE) == 0) {
> > +   DRM_DEBUG_KMS("Clock recovery not done for lane %d\n", 
> > lane);
> 
> Please petition, with patch, for DRM_DEBUG_DP.
> -Chris
> 
Is that because DRM_DEBUG_KMS in not appropriate or that we have plenty
of DP related debug messages that it warrants it's own debug macro?

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dp: Add debug messages to print DP link training pattern

[Pandiyan, Dhinakaran]

On Thu, 2016-08-04 at 04:07 +0100, Chris Wilson wrote:
> On Wed, Aug 03, 2016 at 08:07:38PM -0700, Dhinakaran Pandiyan wrote:
> > @@ -2588,7 +2592,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
> > *DP |= DP_LINK_TRAIN_PAT_2_CPT;
> > break;
> > case DP_TRAINING_PATTERN_3:
> > -   DRM_ERROR("DP training pattern 3 not supported\n");
> > +   DRM_ERROR("TPS3 not supported, using TPS2 instead\n");
> > *DP |= DP_LINK_TRAIN_PAT_2_CPT;
> > break;
> > }
> > @@ -2613,7 +2617,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
> > if (IS_CHERRYVIEW(dev)) {
> > *DP |= DP_LINK_TRAIN_PAT_3_CHV;
> > } else {
> > -   DRM_ERROR("DP training pattern 3 not 
> > supported\n");
> > +   DRM_ERROR("TPS3 not supported, using TPS2 
> > instead\n");
> > *DP |= DP_LINK_TRAIN_PAT_2;
> 
> Given that you have a fallback plan and if the fallback plan fails you
> alert the user with an error already, these aren't errors but debug.
> -Chris
> 
I will make that change. Thanks for the review.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Sun, 2017-02-26 at 20:57 +0100, Daniel Vetter wrote:
> On Wed, Feb 22, 2017 at 12:01:12AM +0000, Pandiyan, Dhinakaran wrote:
> > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> > > 
> > > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> > > > On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
> > > >> Comparing this func to 
> > > >> drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
> > > >> doesn't seem to call drm_modeset_lock if the obj_state doesn't already 
> > > >> exist. I
> > > >> don't understand the locking stuff toowell, I just noticed this 
> > > >> difference when
> > > >> comparing this approach with what is done in the msm kms driver (where 
> > > >> we
> > > >> have subclassed drm_atomic_state to msm_kms_state).
> > > >>
> > > >> Thanks,
> > > >> Archit
> > > >>
> > > >
> > > >
> > > > The caller is expected to take care of any required locking. The
> > > > driver-private objects are opaque from core's pov, so the core is not
> > > > aware of necessary locks for that object type.
> > > 
> > > I had a look at the rest of the series, and I couldn't easily understand
> > > whether the caller code protects the MST related driver private state. Is
> > > it expected to be protect via the drm_mode_config.connection_mutex lock?
> > > 
> > > Thanks,
> > > Archit
> > > 
> > 
> > That's right, the connection_mutex takes care of the locking for the MST
> > private state. I can add that as a comment to the caller's (MST helper)
> > kernel doc with a
> > 
> > WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex)); 
> 
> Please don't add this as a comment, but as real code so it is checked at
> runtime :-) Personally I wouldn't mention locking rules in kernel-doc,
> that part tends to get outdated fast. Better to enforce with
> runtime-checks.
> -Daniel

That's what I meant but evidently didn't type it that way:) I was going
to add that the connection_mutex does the locking for MST state as a
comment and put the WARN_ON() in code.

-DK

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/14] drm/dp/i915: Make clock recovery in the link training compliant with DP Spec 1.2

[Pandiyan, Dhinakaran]

On Fri, 2016-09-02 at 12:16 +0300, Mika Kahola wrote:
> On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote:
> > From: Dhinakaran Pandiyan 
> > 
> > This function cleans up clock recovery loop in link training
> > compliant
> > tp Dp Spec 1.2. It tries the clock recovery 5 times for the same
> > voltage
> > or until max voltage swing is reached and removes the additional non
> > compliant retries. This function now returns a boolean values based
> > on
> > if clock recovery passed or failed.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 59 -
> > --
> >  1 file changed, 26 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 9145e5a..13a0341 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -117,19 +117,19 @@ static bool
> > intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp)
> > int lane;
> >  
> > for (lane = 0; lane < intel_dp->lane_count; lane++)
> > -   if (intel_dp->train_set[lane] &
> > DP_TRAIN_MAX_SWING_REACHED == 0)
> > +   if ((intel_dp->train_set[lane] &
> > +DP_TRAIN_MAX_SWING_REACHED) == 0)
> > return false;
> >  
> This function was defined in the previous patch. Do we need to split
> this if(...) line into separate lines in this patch? 
> 

Ah! That was not intended, I will re-submit. 

> > return true;
> >  }
> >  
> >  /* Enable corresponding port and start training pattern 1 */
> > -static void
> > +static bool
> >  intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >  {
> > -   int i;
> > uint8_t voltage;
> > -   int voltage_tries, loop_tries;
> > +   int voltage_tries, max_vswing_tries;
> > uint8_t link_config[2];
> > uint8_t link_bw, rate_select;
> >  
> > @@ -145,6 +145,7 @@ intel_dp_link_training_clock_recovery(struct
> > intel_dp *intel_dp)
> > if (drm_dp_enhanced_frame_cap(intel_dp->dpcd))
> > link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> > drm_dp_dpcd_write(_dp->aux, DP_LINK_BW_SET,
> > link_config, 2);
> > +
> > if (intel_dp->num_sink_rates)
> > drm_dp_dpcd_write(_dp->aux, DP_LINK_RATE_SET,
> >   _select, 1);
> > @@ -160,58 +161,50 @@ intel_dp_link_training_clock_recovery(struct
> > intel_dp *intel_dp)
> >DP_TRAINING_PATTERN_1 |
> >DP_LINK_SCRAMBLING_DISABLE))
> > {
> > DRM_ERROR("failed to enable link training\n");
> > -   return;
> > +   return false;
> > }
> >  
> > -   voltage = 0xff;
> > -   voltage_tries = 0;
> > -   loop_tries = 0;
> > +   voltage_tries = 1;
> > +   max_vswing_tries = 0;
> > for (;;) {
> > uint8_t link_status[DP_LINK_STATUS_SIZE];
> >  
> > drm_dp_link_train_clock_recovery_delay(intel_dp-
> > >dpcd);
> > +
> > if (!intel_dp_get_link_status(intel_dp,
> > link_status)) {
> > DRM_ERROR("failed to get link status\n");
> > -   break;
> > +   return false;
> > }
> >  
> > if (drm_dp_clock_recovery_ok(link_status, intel_dp-
> > >lane_count)) {
> > DRM_DEBUG_KMS("clock recovery OK\n");
> > -   break;
> > +   return true;
> > }
> >  
> > -   /* Check to see if we've tried the max voltage */
> > -   if (intel_dp_link_max_vswing_reached(intel_dp)) {
> > -   ++loop_tries;
> > -   if (loop_tries == 5) {
> > -   DRM_ERROR("too many full retries,
> > give up\n");
> > -   intel_dp_dump_link_status(link_statu
> > s);
> > -   break;
> > -   }
> > -   intel_dp_reset_link_train(intel_dp,
> > - DP_TRAINING_PATTER
> > N_1 |
> > - DP_LINK_SCRAMBLING
> > _DISABLE);
> > -   voltage_tries = 0;
> > -   continue;
> > +   if (voltage_tries == 5 || max_vswing_tries == 1) {
> > +   DRM_DEBUG_KMS("Max. vswing reached or same
> > voltage "
> > + "tried 5 times\n");
> > +   return false;
> > }
> I think it would be beneficial to know which one we hit if the clock
> recovery fails. Therefore, I would split these debug messages so that
> there would be separate debug messages when reaching max vswing or
> trying out the same voltage for five times.

Agreed.

Also, I don't think we need the 'max_vswing_tries' local at all. We
could just call 

Re: [Intel-gfx] [PATCH 10/14] drm/i915: Make DP link training channel equalization DP 1.2 Spec compliant

[Pandiyan, Dhinakaran]

On Fri, 2016-09-02 at 14:20 +0300, Mika Kahola wrote:
> On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote:
> > Fix the number of tries in channel euqalization link training
> > sequence
> > according to DP 1.2 Spec. It returns a boolean depending on channel
> > equalization pass or failure.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 57 ++---
> > --
> >  drivers/gpu/drm/i915/intel_drv.h  |  1 +
> >  2 files changed, 22 insertions(+), 36 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 13a0341..07f0159 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -240,12 +240,12 @@ static u32 intel_dp_training_pattern(struct
> > intel_dp *intel_dp)
> > return training_pattern;
> >  }
> >  
> > -static void
> > +static bool
> >  intel_dp_link_training_channel_equalization(struct intel_dp
> > *intel_dp)
> >  {
> > -   bool channel_eq = false;
> > -   int tries, cr_tries;
> > +   int tries;
> > u32 training_pattern;
> > +   uint8_t link_status[DP_LINK_STATUS_SIZE];
> >  
> > training_pattern = intel_dp_training_pattern(intel_dp);
> >  
> > @@ -254,20 +254,11 @@
> > intel_dp_link_training_channel_equalization(struct intel_dp
> > *intel_dp)
> >  training_pattern |
> >  DP_LINK_SCRAMBLING_DISABLE)) {
> > DRM_ERROR("failed to start channel equalization\n");
> > -   return;
> > +   return false;
> > }
> >  
> > -   tries = 0;
> > -   cr_tries = 0;
> > -   channel_eq = false;
> > -   for (;;) {
> > -   uint8_t link_status[DP_LINK_STATUS_SIZE];
> > -
> > -   if (cr_tries > 5) {
> > -   DRM_ERROR("failed to train DP, aborting\n");
> > -   intel_dp_dump_link_status(link_status);
> > -   break;
> > -   }
> > +   intel_dp->channel_eq_status = false;
> > +   for (tries = 0; tries < 5; tries++) {
> >  
> > drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
> > if (!intel_dp_get_link_status(intel_dp,
> > link_status)) {
> > @@ -278,44 +269,38 @@
> > intel_dp_link_training_channel_equalization(struct intel_dp
> > *intel_dp)
> > /* Make sure clock is still ok */
> > if (!drm_dp_clock_recovery_ok(link_status,
> >   intel_dp->lane_count)) 
> > {
> > -   intel_dp_link_training_clock_recovery(intel_
> > dp);
> > -   intel_dp_set_link_train(intel_dp,
> > -   training_pattern |
> > -   DP_LINK_SCRAMBLING_D
> > ISABLE);
> > -   cr_tries++;
> > -   continue;
> > +   intel_dp_dump_link_status(link_status);
> > +   DRM_DEBUG_KMS("Clock recovery check failed,
> > cannot "
> > + "continue channel
> > equalization\n");
> > +   break;
> > }
> This clock recovery check got me thinking. Do we really need to check
> if clock recovery is still ok within a loop? Could we move this outside
> the loop and return early if we have failed in clock recovery? One idea
> that I have in mind is that we wouldn't need to enter in channel
> equalization if we have failed with clock recovery earlier.
> 

Looks like we do. This check helps us to break out of the loop for link
rate reduction after adjusting drive setting. 


> >  
> > if (drm_dp_channel_eq_ok(link_status,
> >  intel_dp->lane_count)) {
> > -   channel_eq = true;
> > +   intel_dp->channel_eq_status = true;
> > +   DRM_DEBUG_KMS("Channel EQ done. DP Training
> > "
> > + "successful\n");
> > break;
> > }
> >  
> > -   /* Try 5 times, then try clock recovery if that
> > fails */
> > -   if (tries > 5) {
> > -   intel_dp_link_training_clock_recovery(intel_
> > dp);
> > -   intel_dp_set_link_train(intel_dp,
> > -   training_pattern |
> > -   DP_LINK_SCRAMBLING_D
> > ISABLE);
> > -   tries = 0;
> > -   cr_tries++;
> > -   continue;
> > -   }
> > -
> > /* Update training set as requested by target */
> > intel_get_adjust_train(intel_dp, link_status);
> > if (!intel_dp_update_link_train(intel_dp)) {
> > DRM_ERROR("failed to update link
> > training\n");
> >

Re: [Intel-gfx] [PATCH v3 07/14] drm/i915/dp: Add a standalone function to obtain shared dpll for HSW/BDW/SKL/BXT

[Pandiyan, Dhinakaran]

On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote:
> From: Jim Bride 
> 
> Add the PLL selection code for HSW/BDW/BXT/SKL into a stand-alone function
> in order to allow for the implementation of a platform neutral upfront
> link training function.
> 
> v3:
> * Add Hooks for all DDI platforms into this standalone function
> 
> v2:
> * Change the macro to use dev_priv instead of dev (David Weinehall)
> 
> Reviewed-by: Durgadoss R 
> Signed-off-by: Manasi Navare 
> Signed-off-by: Jim Bride 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 38 
> +++
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 38 
> +++
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h  |  3 ++-
>  4 files changed, 80 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index e4b875e..67a6a0b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2393,6 +2393,44 @@ intel_ddi_init_hdmi_connector(struct 
> intel_digital_port *intel_dig_port)
>   return connector;
>  }
>  
> +struct intel_shared_dpll *
> +intel_ddi_get_link_dpll(struct intel_dp *intel_dp, int clock)
> +{
> + struct intel_connector *connector = intel_dp->attached_connector;
> + struct intel_encoder *encoder = connector->encoder;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct intel_shared_dpll *pll = NULL;
> + struct intel_shared_dpll_config tmp_pll_config;
> + enum intel_dpll_id dpll_id;
> +
> + if (IS_BROXTON(dev_priv)) {
> + dpll_id =  (enum intel_dpll_id)dig_port->port;
> + /*
> +  * Select the required PLL. This works for platforms where
> +  * there is no shared DPLL.
> +  */
> + pll = _priv->shared_dplls[dpll_id];
> + if (WARN_ON(pll->active_mask)) {
> +
> + DRM_ERROR("Shared DPLL in use. active_mask:%x\n",
> +   pll->active_mask);
> + pll = NULL;
> + }
> + tmp_pll_config = pll->config;

NULL dereference when pll is in use? 

> + if (!bxt_ddi_dp_set_dpll_hw_state(clock,
> +   >config.hw_state)) {
> + DRM_ERROR("Could not setup DPLL\n");
> + pll->config = tmp_pll_config;
> + }
> + } else if (IS_SKYLAKE(dev_priv)) {
> + pll = skl_find_link_pll(dev_priv, clock);
> + } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> + pll = hsw_ddi_dp_get_dpll(encoder, clock);
> + }
> + return pll;
> +}
> +
>  void intel_ddi_init(struct drm_device *dev, enum port port)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 9a1da98..4b067ac 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -24,6 +24,44 @@
>  #include "intel_drv.h"
>  
>  struct intel_shared_dpll *
> +skl_find_link_pll(struct drm_i915_private *dev_priv, int clock)
> +{
> + struct intel_shared_dpll *pll = NULL;
> + struct intel_dpll_hw_state dpll_hw_state;
> + enum intel_dpll_id i;
> + bool found = false;
> +
> + if (!skl_ddi_dp_set_dpll_hw_state(clock, _hw_state))
> + return pll;
> +
> + for (i = DPLL_ID_SKL_DPLL1; i <= DPLL_ID_SKL_DPLL3; i++) {
> + pll = _priv->shared_dplls[i];
> +
> + /* Only want to check enabled timings first */
> + if (pll->config.crtc_mask == 0)
> + continue;
> +
> + if (memcmp(_hw_state, >config.hw_state,
> +sizeof(pll->config.hw_state)) == 0) {
> + found = true;
> + break;
> + }
> + }
> +
> + /* Ok no matching timings, maybe there's a free one? */
> + for (i = DPLL_ID_SKL_DPLL1;
> +  ((found == false) && (i <= DPLL_ID_SKL_DPLL3)); i++) {
> + pll = _priv->shared_dplls[i];
> + if (pll->config.crtc_mask == 0) {
> + pll->config.hw_state = dpll_hw_state;
> + break;
> + }
> + }
> +
> + return pll;
> +}
> +
> +struct intel_shared_dpll *
>  intel_get_shared_dpll_by_id(struct drm_i915_private *dev_priv,
>   enum intel_dpll_id id)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> index aed7408..f438535 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h
> @@ -168,6 +168,8 @@ 

Re: [Intel-gfx] [PATCH 12/14] drm/i915: Reverse the loop in intel_dp_compute_config

[Pandiyan, Dhinakaran]

On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote:
> While configuring the pipe during modeset, it should loop
> starting from max clock and max lane count reducing the
> lane count and clock in each iteration until the requested mode
> rate is less than or equal to available link BW.
> 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dfdbe65..e094b25 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1552,11 +1552,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   for (; bpp >= 6*3; bpp -= 2*3) {
>   mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
>  bpp);
> -
> - for (clock = min_clock; clock <= max_clock; clock++) {
> - for (lane_count = min_lane_count;
> - lane_count <= max_lane_count;
> - lane_count <<= 1) {
> + for (clock = max_clock; clock >= max_clock; clock--) {
> + for (lane_count = max_lane_count;
> +  lane_count >= min_lane_count;
> +  lane_count >>= 1) {
>  
>   link_clock = common_rates[clock];
>   link_avail = intel_dp_max_data_rate(link_clock,


I don't understand why the loop is still here? We are starting with the
max.link rate and max.lane count. If that is not good enough for the
mode rate, then lowering link bandwidth won't help.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/14] drm/i915: Fallback to lower link rate and lane count during link training

[Pandiyan, Dhinakaran]

On Thu, 2016-09-01 at 15:08 -0700, Manasi Navare wrote:
> According to the DisplayPort Spec, in case of Clock Recovery failure
> the link training sequence should fall back to the lower link rate
> followed by lower lane count until CR succeeds.
> On CR success, the sequence proceeds with Channel EQ.
> In case of Channel EQ failures, it should fallback to
> lower link rate and lane count and start the CR phase again.
> 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 109 
> +++---
>  drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
>  drivers/gpu/drm/i915/intel_drv.h  |   4 +-
>  3 files changed, 110 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 67a6a0b..78d6687 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1634,29 +1634,50 @@ void intel_ddi_clk_select(struct intel_encoder 
> *encoder,
>   }
>  }
>  
> -static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> +static void intel_ddi_pre_enable_edp(struct intel_encoder *encoder,
>   int link_rate, uint32_t lane_count,
> - struct intel_shared_dpll *pll,
> - bool link_mst)
> + struct intel_shared_dpll *pll)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = intel_ddi_get_encoder_port(encoder);
>  
>   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> -  link_mst);
> - if (encoder->type == INTEL_OUTPUT_EDP)
> - intel_edp_panel_on(intel_dp);
> +  false);
> +
> + intel_edp_panel_on(intel_dp);
>  
>   intel_ddi_clk_select(encoder, pll);
>   intel_prepare_dp_ddi_buffers(encoder);
>   intel_ddi_init_dp_buf_reg(encoder);
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>   intel_dp_start_link_train(intel_dp);
> - if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> + if (port != PORT_A || INTEL_INFO(dev_priv)->gen >= 9)
>   intel_dp_stop_link_train(intel_dp);
>  }
>  
> +static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> + int link_rate, uint32_t lane_count,
> + struct intel_shared_dpll *pll,
> + bool link_mst)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_shared_dpll_config tmp_pll_config;
> +
> + /* Disable the PLL and obtain the PLL for Link Training
> +  * that starts with highest link rate and lane count.
> +  */
> + tmp_pll_config = pll->config;
> + pll->funcs.disable(dev_priv, pll);
> + pll->config.crtc_mask = 0;
> +
> + /* If Link Training fails, send a uevent to generate a hotplug */
> + if (!(intel_ddi_link_train(intel_dp, link_rate, lane_count, link_mst)))
> + drm_kms_helper_hotplug_event(encoder->base.dev);
> + pll->config = tmp_pll_config;
> +}
> +
>  static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> bool has_hdmi_sink,
> struct drm_display_mode *adjusted_mode,
> @@ -1690,20 +1711,26 @@ static void intel_ddi_pre_enable(struct intel_encoder 
> *intel_encoder,
>   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
>   int type = intel_encoder->type;
>  
> - if (type == INTEL_OUTPUT_DP || type == INTEL_OUTPUT_EDP) {
> + if (type == INTEL_OUTPUT_EDP)
> + intel_ddi_pre_enable_edp(intel_encoder,
> + crtc->config->port_clock,
> + crtc->config->lane_count,
> + crtc->config->shared_dpll);
> +
> + if (type == INTEL_OUTPUT_DP)
>   intel_ddi_pre_enable_dp(intel_encoder,
>   crtc->config->port_clock,
>   crtc->config->lane_count,
>   crtc->config->shared_dpll,
>   intel_crtc_has_type(crtc->config,
>   
> INTEL_OUTPUT_DP_MST));
> - }
> - if (type == INTEL_OUTPUT_HDMI) {
> +
> + if (type == INTEL_OUTPUT_HDMI)
>   intel_ddi_pre_enable_hdmi(intel_encoder,
> crtc->config->has_hdmi_sink,
> >config->base.adjusted_mode,
> crtc->config->shared_dpll);
> - }
> +
>  }
>  
>  static void 

Re: [Intel-gfx] [PATCH v4] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

The changes in this version are primarily in i915. I have carried over
Takashi's R-B from the previous version and removed Ville's.


From: Pandiyan, Dhinakaran
Sent: Thursday, September 01, 2016 12:50 AM
To: intel-gfx@lists.freedesktop.org
Cc: libin.y...@linux.intel.com; jim.br...@linux.intel.com; 
ville.syrj...@linux.intel.com; ti...@suse.de; alsa-de...@alsa-project.org; Kp, 
Jeeja; Pandiyan, Dhinakaran
Subject: [PATCH v4] drm/i915/dp: DP audio API changes for MST

DP MST provides the capability to send multiple video and audio streams
through a single port. This requires the API's between i915 and audio
drivers to distinguish between multiple audio capable displays that can be
connected to a port. Currently only the port identity is shared in the
APIs. This patch adds support for MST with an additional parameter
'int pipe'. The existing parameter 'port' does not change it's meaning.

pipe =
MST : display pipe that the stream originates from
Non-MST : -1

Affected APIs:
struct i915_audio_component_ops
-   int (*sync_audio_rate)(struct device *, int port, int rate);
+   int (*sync_audio_rate)(struct device *, int port, int pipe,
+int rate);

-   int (*get_eld)(struct device *, int port, bool *enabled,
-   unsigned char *buf, int max_bytes);
+   int (*get_eld)(struct device *, int port, int pipe,
+  bool *enabled, unsigned char *buf, int max_bytes);

struct i915_audio_component_audio_ops
-   void (*pin_eld_notify)(void *audio_ptr, int port);
+   void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);

This patch makes dummy changes in the audio drivers (thanks Libin) for
build to succeed. The audio side drivers will send the right 'pipe' values
for MST in patches that will follow.

v2:
Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville)
Included Asoc driver API compatibility changes from Jeeja.
Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
Added comment for av_enc_map[] definition. (Takashi)

v3:
Fixed logic error introduced while renaming 'dev_id' as 'pipe' (Ville)
Renamed get_saved_encoder() to get_saved_enc() to reduce line length

v4:
Rebased.
Parameter check for pipe < -1 values in get_saved_enc() (Ville)
Switched to for_each_pipe() in get_saved_enc() (Ville)
Renamed 'pipe' to 'dev_id' in audio side code (Takashi)

Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
Reviewed-by: Takashi Iwai <ti...@suse.de>

---
 drivers/gpu/drm/i915/i915_drv.h|  3 +-
 drivers/gpu/drm/i915/intel_audio.c | 94 ++
 include/drm/i915_component.h   |  6 +--
 include/sound/hda_i915.h   | 11 +++--
 sound/hda/hdac_i915.c  | 16 ---
 sound/pci/hda/patch_hdmi.c |  7 +--
 sound/soc/codecs/hdac_hdmi.c   |  2 +-
 7 files changed, 92 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index aaa9c60..dac81c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2056,7 +2056,8 @@ struct drm_i915_private {
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];

-   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
+   /* Used to save the pipe-to-encoder mapping for audio */
+   struct intel_encoder *av_enc_map[I915_MAX_PIPES];

/*
 * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 40fbdd8..9583f43 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -491,6 +491,7 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder)
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
enum port port = intel_encoder->port;
+   enum pipe pipe = crtc->pipe;

connector = drm_select_eld(encoder);
if (!connector)
@@ -515,12 +516,18 @@ void intel_audio_codec_enable(struct intel_encoder 
*intel_encoder)

mutex_lock(_priv->av_mutex);
intel_encoder->audio_connector = connector;
+
/* referred in audio callbacks */
-   dev_priv->dig_port_map[port] = intel_encoder;
+   dev_priv->av_enc_map[pipe] = intel_encoder;
mutex_unlock(_priv->av_mutex);

+   /* audio drivers expect pipe = -1 to indicate Non-MST cases */
+   if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
+   pipe = -1;
+
if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
-   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, 
(int) port);
+   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
+  

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

[Pandiyan, Dhinakaran]

On Mon, 2016-08-15 at 19:36 -0300, Paulo Zanoni wrote:
> Ever since I started working on FBC I was already aware that FBC can
> really amplify the FIFO underrun symptoms. On systems where FIFO
> underruns were harmless error messages, enabling FBC would cause the
> underruns to give black screens.
> 
> We recently tried to enable FBC on Haswell and got reports of a system
> that would hang after some hours of uptime, and the first bad commit
> was the one that enabled FBC. We also observed that this system had
> FIFO underrun error messages on its dmesg. Although we don't have any
> evidence that fixing the underruns would solve the bug and make FBC
> work properly on this machine, IMHO it's better if we minimize the
> amount of possible problems by just giving up FBC whenever we detect
> an underrun.
> 
> v2: New version, different implementation and commit message.
> v3: Clarify the fact that we run from an IRQ handler (Chris).
> 
> Cc: Stefan Richter 
> Cc: Lyude 
> Cc: stevenhoney...@gmail.com 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  3 ++
>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_fbc.c   | 61 
> ++
>  drivers/gpu/drm/i915/intel_fifo_underrun.c |  2 +
>  4 files changed, 67 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 35caa9b..baa9c66 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -941,6 +941,9 @@ struct intel_fbc {
>   bool enabled;
>   bool active;
>  
> + bool underrun_detected;
> + struct work_struct underrun_work;
> +
>   struct intel_fbc_state_cache {
>   struct {
>   unsigned int mode_flags;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1c700b0..50c1eb0 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1494,6 +1494,7 @@ void intel_fbc_invalidate(struct drm_i915_private 
> *dev_priv,
>  void intel_fbc_flush(struct drm_i915_private *dev_priv,
>unsigned int frontbuffer_bits, enum fb_op_origin origin);
>  void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
> +void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv);
>  
>  /* intel_hdmi.c */
>  void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg, enum port 
> port);
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index e122052..950aed5 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -750,6 +750,13 @@ static bool intel_fbc_can_activate(struct intel_crtc 
> *crtc)
>   struct intel_fbc *fbc = _priv->fbc;
>   struct intel_fbc_state_cache *cache = >state_cache;
>  
> + /* We don't need to use a state cache here since this information is
> +  * global for every CRTC. */
> + if (fbc->underrun_detected) {
> + fbc->no_fbc_reason = "underrun detected";
> + return false;
> + }
> +
>   if (!cache->plane.visible) {
>   fbc->no_fbc_reason = "primary plane not visible";
>   return false;
> @@ -1193,6 +1200,59 @@ void intel_fbc_global_disable(struct drm_i915_private 
> *dev_priv)
>   cancel_work_sync(>work.work);
>  }
>  
> +static void intel_fbc_underrun_work_fn(struct work_struct *work)
> +{
> + struct drm_i915_private *dev_priv =
> + container_of(work, struct drm_i915_private, fbc.underrun_work);
> + struct intel_fbc *fbc = _priv->fbc;
> +
> + mutex_lock(>lock);
> +
> + /* Maybe we were scheduled twice. */
> + if (fbc->underrun_detected)
> + goto out;

If the underrun happens very early after boot (likely during modeset),
the user might end up seeing just FBC enable and disable messages in
dmesg without knowing it (or why it) was deactivated.

For e.g.,

[ 1855.552489] [drm:intel_fbc_enable] Enabling FBC on pipe A
[ 1856.854239] [drm:__intel_fbc_disable] Disabling FBC on pipe A
[ 1857.753383] [drm:intel_fbc_alloc_cfb] Reducing the compressed
framebuffer size. This may lead to less power savings than a
non-reduced-size. Try to increase stolen memory size if available in
BIOS.
[ 1857.753384] [drm:intel_fbc_alloc_cfb] reserved 10368000 bytes of
contiguous stolen space for FBC, threshold: 4
[ 1857.753384] [drm:intel_fbc_enable] Enabling FBC on pipe A

I find this noise misleading because FBC is not going to be activated at
all.


> +
> + DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");

Print out the pipe here? Both the enabling and disabling debug messages
clarify the pipe. It may be useful to provide this information here too.

> + fbc->underrun_detected = true;
> +
> + intel_fbc_deactivate(dev_priv);
> +out:
> + 

Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Switch to using port stored in intel_encoder

[Pandiyan, Dhinakaran]

Just realized this patch needs s/attached_port/port, will send out
another version.


On Mon, 2016-08-29 at 17:23 -0400, Lyude Paul wrote:
> Looks like a much better solution then the previous one.
> 
> Reviewed-by: Lyude 
> 
> On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> > Now that we have the port enum stored in intel_encoder, use that instead of
> > dereferencing intel_dig_port. Saves us a few locals.
> > 
> > struct intel_encoder variables have been renamed to be consistent and
> > convey type information.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 39 +++
> > ---
> >  1 file changed, 15 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index d32f586..5a41439 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -276,17 +276,15 @@ static void hsw_audio_codec_disable(struct 
> > intel_encoder
> > *encoder)
> >  }
> >  
> >  static void hsw_audio_codec_enable(struct drm_connector *connector,
> > -  struct intel_encoder *encoder,
> > +  struct intel_encoder *intel_encoder,
> >const struct drm_display_mode
> > *adjusted_mode)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > -   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > +   struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder-
> > >base.crtc);
> > enum pipe pipe = intel_crtc->pipe;
> > +   enum port port = intel_encoder->attached_port;
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > const uint8_t *eld = connector->eld;
> > -   struct intel_digital_port *intel_dig_port =
> > -   enc_to_dig_port(>base);
> > -   enum port port = intel_dig_port->port;
> > uint32_t tmp;
> > int len, i;
> > int n, rate;
> > @@ -355,14 +353,12 @@ static void hsw_audio_codec_enable(struct 
> > drm_connector
> > *connector,
> > mutex_unlock(_priv->av_mutex);
> >  }
> >  
> > -static void ilk_audio_codec_disable(struct intel_encoder *encoder)
> > +static void ilk_audio_codec_disable(struct intel_encoder *intel_encoder)
> >  {
> > -   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > -   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > -   struct intel_digital_port *intel_dig_port =
> > -   enc_to_dig_port(>base);
> > -   enum port port = intel_dig_port->port;
> > +   struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev);
> > +   struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder-
> > >base.crtc);
> > enum pipe pipe = intel_crtc->pipe;
> > +   enum port port = intel_encoder->attached_port;
> > uint32_t tmp, eldv;
> > i915_reg_t aud_config, aud_cntrl_st2;
> >  
> > @@ -402,18 +398,15 @@ static void ilk_audio_codec_disable(struct 
> > intel_encoder
> > *encoder)
> >  }
> >  
> >  static void ilk_audio_codec_enable(struct drm_connector *connector,
> > -  struct intel_encoder *encoder,
> > +  struct intel_encoder *intel_encoder,
> >const struct drm_display_mode
> > *adjusted_mode)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > -   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > -   struct intel_digital_port *intel_dig_port =
> > -   enc_to_dig_port(>base);
> > -   enum port port = intel_dig_port->port;
> > +   struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder-
> > >base.crtc);
> > enum pipe pipe = intel_crtc->pipe;
> > +   enum port port = intel_encoder->attached_port;
> > uint8_t *eld = connector->eld;
> > -   uint32_t eldv;
> > -   uint32_t tmp;
> > +   uint32_t tmp, eldv;
> > int len, i;
> > i915_reg_t hdmiw_hdmiedid, aud_config, aud_cntl_st, aud_cntrl_st2;
> >  
> > @@ -495,11 +488,10 @@ void intel_audio_codec_enable(struct intel_encoder
> > *intel_encoder)
> > struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > const struct drm_display_mode *adjusted_mode = >config-
> > >base.adjusted_mode;
> > struct drm_connector *connector;
> > -   struct drm_device *dev = encoder->dev;
> > -   struct drm_i915_private *dev_priv = to_i915(dev);
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > -   enum port port = intel_dig_port->port;
> > +   enum port port = intel_encoder->attached_port;
> >  
> > connector = drm_select_eld(encoder);
> > if (!connector)
> > @@ -542,11 +534,10 @@ void intel_audio_codec_enable(struct intel_encoder
> > *intel_encoder)
> >  

Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Move audio_connector to intel_encoder

[Pandiyan, Dhinakaran]

Confirmed on IRC, Lyude is fine with carrying over R-B from previous
version.


On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> With DP MST, a digital_port can carry more than one audio stream. Hence,
> more than one audio_connector needs to be attached to intel_digital_port in
> such cases. However, each stream is associated with an unique encoder. So,
> instead of creating an array of audio_connectors per port, move
> audio_connector from struct intel_digital_port to struct intel_encoder.
> This also simplifies access to the right audio_connector from codec
> functions in intel_audio.c that receive intel_encoder.
> 
> v2: Removed locals that are not needed anymore.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 12 
>  drivers/gpu/drm/i915/intel_drv.h   |  4 ++--
>  2 files changed, 6 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 5a41439..b86bfad 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -490,7 +490,6 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>   struct drm_connector *connector;
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct i915_audio_component *acomp = dev_priv->audio_component;
> - struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>   enum port port = intel_encoder->attached_port;
>  
>   connector = drm_select_eld(encoder);
> @@ -515,7 +514,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>adjusted_mode);
>  
>   mutex_lock(_priv->av_mutex);
> - intel_dig_port->audio_connector = connector;
> + intel_encoder->audio_connector = connector;
>   /* referred in audio callbacks */
>   dev_priv->dig_port_map[port] = intel_encoder;
>   mutex_unlock(_priv->av_mutex);
> @@ -536,14 +535,13 @@ void intel_audio_codec_disable(struct intel_encoder 
> *intel_encoder)
>   struct drm_encoder *encoder = _encoder->base;
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct i915_audio_component *acomp = dev_priv->audio_component;
> - struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>   enum port port = intel_encoder->attached_port;
>  
>   if (dev_priv->display.audio_codec_disable)
>   dev_priv->display.audio_codec_disable(intel_encoder);
>  
>   mutex_lock(_priv->av_mutex);
> - intel_dig_port->audio_connector = NULL;
> + intel_encoder->audio_connector = NULL;
>   dev_priv->dig_port_map[port] = NULL;
>   mutex_unlock(_priv->av_mutex);
>  
> @@ -704,7 +702,6 @@ static int i915_audio_component_get_eld(struct device 
> *dev, int port,
>  {
>   struct drm_i915_private *dev_priv = dev_to_i915(dev);
>   struct intel_encoder *intel_encoder;
> - struct intel_digital_port *intel_dig_port;
>   const u8 *eld;
>   int ret = -EINVAL;
>  
> @@ -713,10 +710,9 @@ static int i915_audio_component_get_eld(struct device 
> *dev, int port,
>   /* intel_encoder might be NULL for DP MST */
>   if (intel_encoder) {
>   ret = 0;
> - intel_dig_port = enc_to_dig_port(_encoder->base);
> - *enabled = intel_dig_port->audio_connector != NULL;
> + *enabled = intel_encoder->audio_connector != NULL;
>   if (*enabled) {
> - eld = intel_dig_port->audio_connector->eld;
> + eld = intel_encoder->audio_connector->eld;
>   ret = drm_eld_size(eld);
>   memcpy(buf, eld, min(max_bytes, ret));
>   }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 68bf134..30186bf 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -232,6 +232,8 @@ struct intel_encoder {
>   void (*suspend)(struct intel_encoder *);
>   int crtc_mask;
>   enum hpd_pin hpd_pin;
> + /* for communication with audio component; protected by av_mutex */
> + const struct drm_connector *audio_connector;
>  };
>  
>  struct intel_panel {
> @@ -948,8 +950,6 @@ struct intel_digital_port {
>   enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
>   bool release_cl2_override;
>   uint8_t max_lanes;
> - /* for communication with audio component; protected by av_mutex */
> - const struct drm_connector *audio_connector;
>  };
>  
>  struct intel_dp_mst_encoder {

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

[Pandiyan, Dhinakaran]

Looks good to me.
Reviewed-by: Dhinakaran Pandiyan 

On Tue, 2016-09-13 at 10:38 -0300, Paulo Zanoni wrote:
> Ever since I started working on FBC I was already aware that FBC can
> really amplify the FIFO underrun symptoms. On systems where FIFO
> underruns were harmless error messages, enabling FBC would cause the
> underruns to give black screens.
> 
> We recently tried to enable FBC on Haswell and got reports of a system
> that would hang after some hours of uptime, and the first bad commit
> was the one that enabled FBC. We also observed that this system had
> FIFO underrun error messages on its dmesg. Although we don't have any
> evidence that fixing the underruns would solve the bug and make FBC
> work properly on this machine, IMHO it's better if we minimize the
> amount of possible problems by just giving up FBC whenever we detect
> an underrun.
> 
> v2: New version, different implementation and commit message.
> v3: Clarify the fact that we run from an IRQ handler (Chris).
> v4: Also add the underrun_detected check at can_choose() to avoid
> misleading dmesg messages (DK).
> v5: Fix Engrish, use READ_ONCE on the unlocked read (Chris).
> 
> Cc: Stefan Richter 
> Cc: Lyude 
> Cc: stevenhoney...@gmail.com 
> Cc: Dhinakaran Pandiyan 
> Cc: Chris Wilson 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  3 ++
>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_fbc.c   | 67 
> ++
>  drivers/gpu/drm/i915/intel_fifo_underrun.c |  2 +
>  4 files changed, 73 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 20b7743..5b1c241 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -971,6 +971,9 @@ struct intel_fbc {
>   bool enabled;
>   bool active;
>  
> + bool underrun_detected;
> + struct work_struct underrun_work;
> +
>   struct intel_fbc_state_cache {
>   struct {
>   unsigned int mode_flags;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index abe7a4d..0d05712 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1508,6 +1508,7 @@ void intel_fbc_invalidate(struct drm_i915_private 
> *dev_priv,
>  void intel_fbc_flush(struct drm_i915_private *dev_priv,
>unsigned int frontbuffer_bits, enum fb_op_origin origin);
>  void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
> +void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv);
>  
>  /* intel_hdmi.c */
>  void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg, enum port 
> port);
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 5dcb81a..10ca8cd 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -774,6 +774,14 @@ static bool intel_fbc_can_activate(struct intel_crtc 
> *crtc)
>   struct intel_fbc *fbc = _priv->fbc;
>   struct intel_fbc_state_cache *cache = >state_cache;
>  
> + /* We don't need to use a state cache here since this information is
> +  * global for all CRTC.
> +  */
> + if (fbc->underrun_detected) {
> + fbc->no_fbc_reason = "underrun detected";
> + return false;
> + }
> +
>   if (!cache->plane.visible) {
>   fbc->no_fbc_reason = "primary plane not visible";
>   return false;
> @@ -859,6 +867,11 @@ static bool intel_fbc_can_choose(struct intel_crtc *crtc)
>   return false;
>   }
>  
> + if (fbc->underrun_detected) {
> + fbc->no_fbc_reason = "underrun detected";
> + return false;
> + }
> +
>   if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A) {
>   fbc->no_fbc_reason = "no enabled pipes can have FBC";
>   return false;
> @@ -1221,6 +1234,59 @@ void intel_fbc_global_disable(struct drm_i915_private 
> *dev_priv)
>   cancel_work_sync(>work.work);
>  }
>  
> +static void intel_fbc_underrun_work_fn(struct work_struct *work)
> +{
> + struct drm_i915_private *dev_priv =
> + container_of(work, struct drm_i915_private, fbc.underrun_work);
> + struct intel_fbc *fbc = _priv->fbc;
> +
> + mutex_lock(>lock);
> +
> + /* Maybe we were scheduled twice. */
> + if (fbc->underrun_detected)
> + goto out;
> +
> + DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
> + fbc->underrun_detected = true;
> +
> + intel_fbc_deactivate(dev_priv);
> +out:
> + mutex_unlock(>lock);
> +}
> +
> +/**
> + * intel_fbc_handle_fifo_underrun_irq - disable FBC when we get a FIFO 
> underrun
> + * @dev_priv: 

Re: [Intel-gfx] [PATCH v6 1/4] drm/i915: Store port enum in intel_encoder

[Pandiyan, Dhinakaran]

On Mon, 2016-09-12 at 18:00 -0700, Dhinakaran Pandiyan wrote:
> Storing the port enum in intel_encoder makes it convenient to know the
> port attached to an encoder. Moving the port information up from
> intel_digital_port to intel_encoder avoids unecessary intel_digital_port
> access and handles MST encoders cleanly without requiring conditional
> checks for them (thanks danvet).
> 
> v2:
> Renamed the port enum member from 'attached_port' to 'port' (danvet)
> Fixed missing initialization of port in intel_sdvo.c (danvet)
> 
> v3:
> Fixed missing initialization of port in intel_crt.c (Ville)
> 
> Signed-off-by: Dhinakaran Pandiyan 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Acked-by: Daniel Vetter 
> Reviewed-by: Lyude 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 1 +
>  drivers/gpu/drm/i915/intel_crt.c| 1 +
>  drivers/gpu/drm/i915/intel_ddi.c| 1 +
>  drivers/gpu/drm/i915/intel_dp.c | 1 +
>  drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
>  drivers/gpu/drm/i915/intel_drv.h| 1 +
>  drivers/gpu/drm/i915/intel_dsi.c| 1 +
>  drivers/gpu/drm/i915/intel_dvo.c| 2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c   | 1 +
>  drivers/gpu/drm/i915/intel_lvds.c   | 3 ++-
>  drivers/gpu/drm/i915/intel_sdvo.c   | 1 +
>  drivers/gpu/drm/i915/intel_tv.c | 2 ++
>  12 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1e2dda8..3a2c9e7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -185,6 +185,7 @@ enum plane {
>  #define sprite_name(p, s) ((p) * INTEL_INFO(dev)->num_sprites[(p)] + (s) + 
> 'A')
>  
>  enum port {
> + PORT_NONE = -1,
>   PORT_A = 0,
>   PORT_B,
>   PORT_C,
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index dfbcf16..76ff1ff 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -892,6 +892,7 @@ void intel_crt_init(struct drm_device *dev)
>   intel_connector_attach_encoder(intel_connector, >base);
>  
>   crt->base.type = INTEL_OUTPUT_ANALOG;
> + crt->base.port = PORT_NONE;

Or is this actually PORT_E for any analog encoder ? 

>   crt->base.cloneable = (1 << INTEL_OUTPUT_DVO) | (1 << 
> INTEL_OUTPUT_HDMI);
>   if (IS_I830(dev))
>   crt->base.crtc_mask = (1 << 0);
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 8280548..672f71c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2523,6 +2523,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
> port)
>   intel_dig_port->max_lanes = max_lanes;
>  
>   intel_encoder->type = INTEL_OUTPUT_UNKNOWN;
> + intel_encoder->port = port;
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
>   intel_encoder->cloneable = 0;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 75ac62f..e0dda78 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5752,6 +5752,7 @@ bool intel_dp_init(struct drm_device *dev,
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
>   }
>   intel_encoder->cloneable = 0;
> + intel_encoder->port = port;
>  
>   intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
>   dev_priv->hotplug.irq_port[port] = intel_dig_port;
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 54a9d76..3ffbd69 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -523,6 +523,7 @@ intel_dp_create_fake_mst_encoder(struct 
> intel_digital_port *intel_dig_port, enum
>DRM_MODE_ENCODER_DPMST, "DP-MST %c", pipe_name(pipe));
>  
>   intel_encoder->type = INTEL_OUTPUT_DP_MST;
> + intel_encoder->port = intel_dig_port->port;
>   intel_encoder->crtc_mask = 0x7;
>   intel_encoder->cloneable = 0;
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index abe7a4d..a26f08b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -202,6 +202,7 @@ struct intel_encoder {
>   struct drm_encoder base;
>  
>   enum intel_output_type type;
> + enum port port;
>   unsigned int cloneable;
>   void (*hot_plug)(struct intel_encoder *);
>   bool (*compute_config)(struct intel_encoder *,
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index b2e3d3a..727adaa 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1488,6 +1488,7 @@ void intel_dsi_init(struct drm_device *dev)
>  
>   intel_connector->get_hw_state = intel_connector_get_hw_state;
>  
> + 

Re: [Intel-gfx] [PATCH v2] drm/i915: Standardize port type for DVO encoders

[Pandiyan, Dhinakaran]

This version of the patch has been included in the series "Prep. for DP
audio MST support" since the helper is used by the patch that stores
port in struct intel_encoder.

On Wed, 2016-09-14 at 14:03 -0700, Dhinakaran Pandiyan wrote:
> Changing the return type from 'char' to 'enum port' in
> intel_dvo_port_name() makes it easier to later move the port information to
> intel_encoder. In addition, the port type conforms to what we have
> elsewhere.
> 
> Removing the last conditional that handles invalid port because dvo_reg is
> intialized to valid values for all DVO devices at definition.
> 
> v2: Changed return type, for real (Jani)
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_dvo.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> b/drivers/gpu/drm/i915/intel_dvo.c
> index 2e452c5..6489755 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -412,16 +412,14 @@ intel_dvo_get_current_mode(struct drm_connector 
> *connector)
>   return mode;
>  }
>  
> -static char intel_dvo_port_name(i915_reg_t dvo_reg)
> +static enum port intel_dvo_port(i915_reg_t dvo_reg)
>  {
>   if (i915_mmio_reg_equal(dvo_reg, DVOA))
> - return 'A';
> + return PORT_A;
>   else if (i915_mmio_reg_equal(dvo_reg, DVOB))
> - return 'B';
> - else if (i915_mmio_reg_equal(dvo_reg, DVOC))
> - return 'C';
> + return PORT_B;
>   else
> - return '?';
> + return PORT_C;
>  }
>  
>  void intel_dvo_init(struct drm_device *dev)
> @@ -464,6 +462,7 @@ void intel_dvo_init(struct drm_device *dev)
>   bool dvoinit;
>   enum pipe pipe;
>   uint32_t dpll[I915_MAX_PIPES];
> + enum port port;
>  
>   /* Allow the I2C driver info to specify the GPIO to be used in
>* special cases, but otherwise default to what's defined
> @@ -511,9 +510,10 @@ void intel_dvo_init(struct drm_device *dev)
>   if (!dvoinit)
>   continue;
>  
> + port = intel_dvo_port(dvo->dvo_reg);
>   drm_encoder_init(dev, _encoder->base,
>_dvo_enc_funcs, encoder_type,
> -  "DVO %c", intel_dvo_port_name(dvo->dvo_reg));
> +  "DVO %c", port_name(port));
>  
>   intel_encoder->type = INTEL_OUTPUT_DVO;
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1);

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/4] drm/i915: Store port enum in intel_encoder

[Pandiyan, Dhinakaran]

On Tue, 2016-09-06 at 15:07 +0300, Ville Syrjälä wrote:
> On Wed, Aug 24, 2016 at 12:22:57AM -0700, Dhinakaran Pandiyan wrote:
> > Storing the port enum in intel_encoder makes it convenient to know the
> > port attached to an encoder. Moving the port information up from
> > intel_digital_port to intel_encoder avoids unecessary intel_digital_port
> > access and handles MST encoders cleanly without requiring conditional
> > checks for them (thanks danvet).
> > 
> > v2:
> > Renamed the port enum member from 'attached_port' to 'port' (danvet)
> > Fixed missing initialization of port in intel_sdvo.c (danvet)
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h | 1 +
> >  drivers/gpu/drm/i915/intel_ddi.c| 1 +
> >  drivers/gpu/drm/i915/intel_dp.c | 1 +
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
> >  drivers/gpu/drm/i915/intel_drv.h| 1 +
> >  drivers/gpu/drm/i915/intel_dsi.c| 1 +
> >  drivers/gpu/drm/i915/intel_dvo.c| 2 ++
> >  drivers/gpu/drm/i915/intel_hdmi.c   | 1 +
> >  drivers/gpu/drm/i915/intel_lvds.c   | 3 ++-
> >  drivers/gpu/drm/i915/intel_sdvo.c   | 1 +
> >  drivers/gpu/drm/i915/intel_tv.c | 2 ++
> 
> Missing intel_crt.c at least.
> 
My grep search string was inadequate, will fix this.
Thanks for the review. Can you also look at the the API change patch that you 
had R-B'd
earlier? I removed your R-B as the patch changed.

> Also we're going to want a patch to kill off the, now duplicated,
> information from intel_dig_port.
> 

Makes sense, I will work on it. 

> >  11 files changed, 14 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 9cd102c..60e282d5 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -185,6 +185,7 @@ enum plane {
> >  #define sprite_name(p, s) ((p) * INTEL_INFO(dev)->num_sprites[(p)] + (s) + 
> > 'A')
> >  
> >  enum port {
> > +   PORT_NONE = -1,
> > PORT_A = 0,
> > PORT_B,
> > PORT_C,
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index c2df4e4..402755d 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2426,6 +2426,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
> > port)
> > intel_dig_port->max_lanes = max_lanes;
> >  
> > intel_encoder->type = INTEL_OUTPUT_UNKNOWN;
> > +   intel_encoder->port = port;
> > intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
> > intel_encoder->cloneable = 0;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 364db90..cfe2f4a 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5726,6 +5726,7 @@ bool intel_dp_init(struct drm_device *dev,
> > intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
> > }
> > intel_encoder->cloneable = 0;
> > +   intel_encoder->port = port;
> >  
> > intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> > dev_priv->hotplug.irq_port[port] = intel_dig_port;
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 629337d..d1d7e91 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -540,6 +540,7 @@ intel_dp_create_fake_mst_encoder(struct 
> > intel_digital_port *intel_dig_port, enum
> >  DRM_MODE_ENCODER_DPMST, "DP-MST %c", pipe_name(pipe));
> >  
> > intel_encoder->type = INTEL_OUTPUT_DP_MST;
> > +   intel_encoder->port = intel_dig_port->port;
> > intel_encoder->crtc_mask = 0x7;
> > intel_encoder->cloneable = 0;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 1c700b0..68bf134 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -202,6 +202,7 @@ struct intel_encoder {
> > struct drm_encoder base;
> >  
> > enum intel_output_type type;
> > +   enum port port;
> > unsigned int cloneable;
> > void (*hot_plug)(struct intel_encoder *);
> > bool (*compute_config)(struct intel_encoder *,
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index de8e9fb..eb5cc0b 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -1478,6 +1478,7 @@ void intel_dsi_init(struct drm_device *dev)
> >  
> > intel_connector->get_hw_state = intel_connector_get_hw_state;
> >  
> > +   intel_encoder->port = port;
> > /*
> >  * On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI
> >  * port C. BXT isn't limited like this.
> > diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> > 

Re: [Intel-gfx] [PATCH v2 12/14] drm/i915: Remove the link rate and lane count loop in compute config

[Pandiyan, Dhinakaran]

On Thu, 2016-09-08 at 13:02 -0700, Manasi Navare wrote:
> While configuring the pipe during modeset, it should use
> max clock and max lane count and reduce the bpp until
> the requested mode rate is less than or equal to
> available link BW.
> This is required to pass DP Compliance.
> 
> v2:
> * Removed the loop since we use max values of clock
> and lane count (Dhinakaran Pandiyan)
> 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 22 --
>  1 file changed, 8 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1378116..60c8857 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1567,20 +1567,14 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   for (; bpp >= 6*3; bpp -= 2*3) {
>   mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
>  bpp);
> -
> - for (clock = min_clock; clock <= max_clock; clock++) {
> - for (lane_count = min_lane_count;
> - lane_count <= max_lane_count;
> - lane_count <<= 1) {
> -
> - link_clock = common_rates[clock];
> - link_avail = intel_dp_max_data_rate(link_clock,
> - lane_count);
> -
> - if (mode_rate <= link_avail) {
> - goto found;
> - }
> - }
> + clock = max_clock;
> + lane_count = max_lane_count;

Do we still need lane_count? We can eliminate it if it's always going to
be max_lane_count. 


> + link_clock = common_rates[clock];

Same here for link_clock.

> + link_avail = intel_dp_max_data_rate(link_clock,
> + lane_count);
> +
> + if (mode_rate <= link_avail) {
> + goto found;

Print KMS debug if we cannot satisfy the mode_rate at the max DP link
rate?

>   }
>   }
>  

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: use NULL for NULL pointers

[Pandiyan, Dhinakaran]

Reviewed-by: Dhinakaran Pandiyan 

On Thu, 2016-09-15 at 16:28 +0300, Jani Nikula wrote:
> Fix sparse warning:
> 
> drivers/gpu/drm/i915/i915_cmd_parser.c:987:72: warning: Using plain
> integer as NULL pointer
> 
> Fixes: 52a42cec4b70 ("drm/i915/cmdparser: Accelerate copies from WC memory")
> Cc: Chris Wilson 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 3c72b3b103e7..70980f82a15b 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -984,7 +984,7 @@ static u32 *copy_batch(struct drm_i915_gem_object 
> *dst_obj,
>  
>   src = ERR_PTR(-ENODEV);
>   if (src_needs_clflush &&
> - i915_memcpy_from_wc((void *)(uintptr_t)batch_start_offset, 0, 0)) {
> + i915_memcpy_from_wc((void *)(uintptr_t)batch_start_offset, NULL, 
> 0)) {
>   src = i915_gem_object_pin_map(src_obj, I915_MAP_WC);
>   if (!IS_ERR(src)) {
>   i915_memcpy_from_wc(dst,

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: do not use 'false' as a NULL pointer

[Pandiyan, Dhinakaran]

Reviewed-by: Dhinakaran Pandiyan 

On Thu, 2016-09-15 at 16:28 +0300, Jani Nikula wrote:
> Fixes sparse warning:
> 
> drivers/gpu/drm/i915/intel_dpll_mgr.c:1712:24: warning: Using plain
> integer as NULL pointer
> 
> Fixes: a277ca7dc01d ("drm/i915: Split bxt_ddi_pll_select()")
> Cc: Manasi Navare 
> Cc: Ander Conselvan de Oliveira 
> Cc: Durgadoss R 
> Cc: Rodrigo Vivi 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 4b067accd5cd..c26d18a574b6 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -1709,12 +1709,12 @@ bxt_get_dpll(struct intel_crtc *crtc,
>   if (encoder->type == INTEL_OUTPUT_HDMI
>   && !bxt_ddi_hdmi_pll_dividers(crtc, crtc_state,
> clock, _div))
> - return false;
> + return NULL;
>  
>   if ((encoder->type == INTEL_OUTPUT_DP ||
>encoder->type == INTEL_OUTPUT_EDP) &&
>   !bxt_ddi_dp_set_dpll_hw_state(clock, _hw_state))
> - return false;
> + return NULL;
>  
>   memset(_state->dpll_hw_state, 0,
>  sizeof(crtc_state->dpll_hw_state));

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/dp/mst: Add support for upfront link training for DP MST

[Pandiyan, Dhinakaran]

On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> From: Jim Bride 
> 
> Add upfront link training to intel_dp_mst_mode_valid() so that we know
> topology constraints before we validate the legality of modes to be
> checked.
> 

The patch seems to do a lot more things than just what is described
here. I guess, it would be better to split this into multiple patches or
at least provide adequate description here.

> v3:
> * Reset the upfront values but dont unset the EDID for MST. (Manasi)
> v2:
> * Rebased on new revision of link training patch. (Manasi)
> 
> Signed-off-by: Manasi Navare 
> Signed-off-by: Jim Bride 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 15 
>  drivers/gpu/drm/i915/intel_dp_mst.c | 74 
> +++--
>  drivers/gpu/drm/i915/intel_drv.h|  3 ++
>  3 files changed, 64 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9042d28..635830e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -131,7 +131,7 @@ static void vlv_steal_power_sequencer(struct drm_device 
> *dev,
> enum pipe pipe);
>  static void intel_dp_unset_edid(struct intel_dp *intel_dp);
>  
> -static int
> +int
>  intel_dp_max_link_bw(struct intel_dp  *intel_dp)
>  {
>   int max_link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
> @@ -150,7 +150,7 @@ intel_dp_max_link_bw(struct intel_dp  *intel_dp)
>   return max_link_bw;
>  }
>  
> -static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
> +u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   u8 temp, source_max, sink_max;
> @@ -296,8 +296,7 @@ static int intersect_rates(const int *source_rates, int 
> source_len,
>   return k;
>  }
>  
> -static int intel_dp_common_rates(struct intel_dp *intel_dp,
> -  int *common_rates)
> +int intel_dp_common_rates(struct intel_dp *intel_dp, int *common_rates)
>  {
>   const int *source_rates, *sink_rates;
>   int source_len, sink_len;
> @@ -321,7 +320,7 @@ static int intel_dp_common_rates(struct intel_dp 
> *intel_dp,
>  common_rates);
>  }
>  
> -static bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
> +bool intel_dp_upfront_link_train(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct intel_encoder *intel_encoder = _dig_port->base;
> @@ -4545,12 +4544,12 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>   }
>  
>  out:
> - if ((status != connector_status_connected) &&
> - (intel_dp->is_mst == false)) {
> - intel_dp_unset_edid(intel_dp);
> + if (status != connector_status_connected) {
>   intel_dp->upfront_done = false;
>   intel_dp->max_lanes_upfront = 0;
>   intel_dp->max_link_rate_upfront = 0;
> + if (intel_dp->is_mst == false)
> + intel_dp_unset_edid(intel_dp);
>   }
>  
>   intel_display_power_put(to_i915(dev), power_domain);
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 54a9d76..98d45a4 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -41,21 +41,30 @@ static bool intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>   int bpp;
>   int lane_count, slots;
>   const struct drm_display_mode *adjusted_mode = 
> _config->base.adjusted_mode;
> - int mst_pbn;
> + int mst_pbn, common_len;
> + int common_rates[DP_MAX_SUPPORTED_RATES] = {};
>  
>   pipe_config->dp_encoder_is_mst = true;
>   pipe_config->has_pch_encoder = false;
> - bpp = 24;
> +
>   /*
> -  * for MST we always configure max link bw - the spec doesn't
> -  * seem to suggest we should do otherwise.
> +  * For MST we always configure for the maximum trainable link bw -
> +  * the spec doesn't seem to suggest we should do otherwise.  The
> +  * calls to intel_dp_max_lane_count() and intel_dp_common_rates()
> +  * both take successful upfront link training into account, and
> +  * return the DisplayPort max supported values in the event that
> +  * upfront link training was not done.
>*/
> - lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> + lane_count = intel_dp_max_lane_count(intel_dp);
>  
>   pipe_config->lane_count = lane_count;
>  
> - pipe_config->pipe_bpp = 24;
> - pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
> + pipe_config->pipe_bpp = bpp = 24;
> + common_len = intel_dp_common_rates(intel_dp, common_rates);
> + pipe_config->port_clock = common_rates[common_len - 1];
> +
> + 

Re: [Intel-gfx] [PATCH v3 4/9] drm/i915: Decode system memory bandwidth

[Pandiyan, Dhinakaran]

On Fri, 2016-09-09 at 13:31 +0530, Kumar, Mahesh wrote:
> From: Mahesh Kumar 
> 
> This patch adds support to decode system memory bandwidth
> which will be used for arbitrated display memory percentage
> calculation in GEN9 based system.
> 
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 96 
> +
>  drivers/gpu/drm/i915/i915_drv.h | 18 
>  drivers/gpu/drm/i915/i915_reg.h | 25 +++
>  3 files changed, 139 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 02c34d6..0a4f18d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -973,6 +973,96 @@ static void intel_sanitize_options(struct 
> drm_i915_private *dev_priv)
>   DRM_DEBUG_DRIVER("use GPU sempahores? %s\n", yesno(i915.semaphores));
>  }
>  
> +static void
> +intel_get_memdev_info(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + uint32_t val = 0;
> + uint32_t mem_speed = 0;
> + uint8_t dram_type;
> + uint32_t dram_channel;
> + uint8_t num_channel;
> + bool rank_valid = false;
> +
> + if (!IS_GEN9(dev_priv))
> + goto exit;
> +
> + val = I915_READ(P_CR_MC_BIOS_REQ_0_0_0);
> + mem_speed = div_u64((uint64_t) (val & REQ_DATA_MASK) *
> + MEMORY_FREQ_MULTIPLIER, 1000);
> +
> + if (mem_speed == 0)
> + goto exit;
> +
> + dev_priv->memdev_info.valid = true;
> + dev_priv->memdev_info.mem_speed = mem_speed;
> + dram_type = (val >> DRAM_TYPE_SHIFT) & DRAM_TYPE_MASK;
> + dram_channel = (val >> DRAM_CHANNEL_SHIFT) & DRAM_CHANNEL_MASK;
> + num_channel = hweight32(dram_channel);
> +
> + /*
> +  * The lpddr3 and lpddr4 technologies can have 1-4 channels and the
> +  * channels are 32bits wide; while ddr3l technologies can have 1-2
> +  * channels and the channels are 64 bits wide. But SV team found that in
> +  * case of single 64 bit wide DDR3L dimms two bits were set and system
> +  * with two DDR3L 64bit dimm all four bits were set.

What bits are set? It would be good to clarify the register.

> +  */
> +
> + switch (dram_type) {
> + case DRAM_TYPE_LPDDR3:
> + case DRAM_TYPE_LPDDR4:
> + dev_priv->memdev_info.data_width = 4;
> + dev_priv->memdev_info.num_channel = num_channel;
> + break;
> + case DRAM_TYPE_DDR3L:
> + dev_priv->memdev_info.data_width = 8;
> + dev_priv->memdev_info.num_channel = num_channel / 2;

Why is this /2 done here?

> + break;
> + default:
> + dev_priv->memdev_info.data_width = 4;
> + dev_priv->memdev_info.num_channel = num_channel;
> + }
> +
> + /*
> +  * Now read each DUNIT8/9/10/11 to check the rank of each dimms.
> +  * all the dimms should have same rank as in first valid Dimm
> +  */
> +#define D_CR_DRP0_DUNIT_INVALID  0x
> +
> + dev_priv->memdev_info.rank_valid = true;
> + if (I915_READ(D_CR_DRP0_DUNIT8) != D_CR_DRP0_DUNIT_INVALID) {
> + val = I915_READ(D_CR_DRP0_DUNIT8);
> + rank_valid = true;
> + } else if (I915_READ(D_CR_DRP0_DUNIT9) != D_CR_DRP0_DUNIT_INVALID) {
> + val = I915_READ(D_CR_DRP0_DUNIT9);
> + rank_valid = true;
> + } else if (I915_READ(D_CR_DRP0_DUNIT10) != D_CR_DRP0_DUNIT_INVALID) {
> + val = I915_READ(D_CR_DRP0_DUNIT10);
> + rank_valid = true;
> + } else if (I915_READ(D_CR_DRP0_DUNIT11) != D_CR_DRP0_DUNIT_INVALID) {
> + val = I915_READ(D_CR_DRP0_DUNIT11);
> + rank_valid = true;
> + }
> +#undef D_CR_DRP0_DUNIT_INVALID
> +
> + if (rank_valid) {
> + dev_priv->memdev_info.rank_valid = true;
> + dev_priv->memdev_info.rank = (val & DRAM_RANK_MASK);
> + }
> +
> + DRM_DEBUG_DRIVER("valid:%s speed-%d width-%d num_channel-%d\n",
> + dev_priv->memdev_info.valid ? "true" : "false",
> + dev_priv->memdev_info.mem_speed,
> + dev_priv->memdev_info.data_width,
> + dev_priv->memdev_info.num_channel);
> + DRM_DEBUG_DRIVER("rank_valid:%s rank-%d\n",
> + dev_priv->memdev_info.rank_valid ? "true" : "false",
> + dev_priv->memdev_info.rank);
> + return;
> +exit:
> + dev_priv->memdev_info.valid = false;
> +}
> +
>  /**
>   * i915_driver_init_hw - setup state requiring device access
>   * @dev_priv: device private
> @@ -1076,6 +1166,12 @@ static int i915_driver_init_hw(struct drm_i915_private 
> *dev_priv)
>   DRM_DEBUG_DRIVER("can't enable MSI");
>   }
>  
> + /*
> +  * Fill the memdev structure to get the system raw bandwidth
> +  * This will be used by WM algorithm, to implement GEN9 based WA
> +  */
> + 

Re: [Intel-gfx] [PATCH] Revert "drm/i915: start adding dp mst audio"

[Pandiyan, Dhinakaran]

On Thu, 2016-09-29 at 11:39 +0300, Jani Nikula wrote:
> On Thu, 29 Sep 2016, Jani Nikula <jani.nik...@intel.com> wrote:
> > On Thu, 29 Sep 2016, Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com> 
> > wrote:
> >> This reverts 'commit 3708d5e082c3 ("drm/i915: start adding dp mst audio")'
> >> because it breaks MST multi-monitor setups on some platforms.
> >>
> >> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97907
> >>
> >> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> >> Reported-by: Kim Lidström <k...@dxtr.im>
> >> Cc: Libin Yang <libin.y...@linux.intel.com>
> >> Cc: Lyude <cp...@redhat.com>
> >> Cc: Jani Nikula <jani.nik...@intel.com>
> >
> > Pushed to drm-intel-next-queued, thanks for the patch.
> 
> Oh, I hope
> 
> commit f931894194b9395313d1c34f95ceb8d91f49790d
> Author: Pandiyan, Dhinakaran <dhinakaran.pandi...@intel.com>
> Date:   Wed Sep 21 13:02:48 2016 -0700
> 
> drm/i915/dp: DP audio API changes for MST
> 
> doesn't have a (functional) dependency on the reverted commit?
> 
> BR,
> Jani.
> 
> 
> 


No, it doesn't. The API patch adds an extra parameter to the functions
already exposed to the audio drivers and should not depend on the
reverted MST audio enabling patch.

-DK

> >
> > BR,
> > Jani.
> >
> >
> >> ---
> >>  drivers/gpu/drm/i915/i915_debugfs.c | 19 +--
> >>  drivers/gpu/drm/i915/intel_ddi.c| 20 +---
> >>  drivers/gpu/drm/i915/intel_dp_mst.c | 18 --
> >>  drivers/gpu/drm/i915/intel_drv.h|  2 --
> >>  4 files changed, 6 insertions(+), 53 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> >> b/drivers/gpu/drm/i915/i915_debugfs.c
> >> index 1ba6795..4fb9d82 100644
> >> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >> @@ -2879,20 +2879,6 @@ static void intel_dp_info(struct seq_file *m,
> >>_dp->aux);
> >>  }
> >>  
> >> -static void intel_dp_mst_info(struct seq_file *m,
> >> -struct intel_connector *intel_connector)
> >> -{
> >> -  struct intel_encoder *intel_encoder = intel_connector->encoder;
> >> -  struct intel_dp_mst_encoder *intel_mst =
> >> -  enc_to_mst(_encoder->base);
> >> -  struct intel_digital_port *intel_dig_port = intel_mst->primary;
> >> -  struct intel_dp *intel_dp = _dig_port->dp;
> >> -  bool has_audio = drm_dp_mst_port_has_audio(_dp->mst_mgr,
> >> -  intel_connector->port);
> >> -
> >> -  seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
> >> -}
> >> -
> >>  static void intel_hdmi_info(struct seq_file *m,
> >>struct intel_connector *intel_connector)
> >>  {
> >> @@ -2935,10 +2921,7 @@ static void intel_connector_info(struct seq_file *m,
> >>switch (connector->connector_type) {
> >>case DRM_MODE_CONNECTOR_DisplayPort:
> >>case DRM_MODE_CONNECTOR_eDP:
> >> -  if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> >> -  intel_dp_mst_info(m, intel_connector);
> >> -  else
> >> -  intel_dp_info(m, intel_connector);
> >> +  intel_dp_info(m, intel_connector);
> >>break;
> >>case DRM_MODE_CONNECTOR_LVDS:
> >>if (intel_encoder->type == INTEL_OUTPUT_LVDS)
> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> >> b/drivers/gpu/drm/i915/intel_ddi.c
> >> index 07cba6c..35f0b7c 100644
> >> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> @@ -2227,19 +2227,6 @@ void intel_ddi_prepare_link_retrain(struct intel_dp 
> >> *intel_dp)
> >>udelay(600);
> >>  }
> >>  
> >> -bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
> >> -   struct intel_crtc *intel_crtc)
> >> -{
> >> -  u32 temp;
> >> -
> >> -  if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
> >> -  temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> >> -  if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
> >> -  return true;
> >> -  }
> >> -  return false;
> >

Re: [Intel-gfx] [2/9] drm/doc: Polish kerneldoc for encoders

[Pandiyan, Dhinakaran]

I guess it's too late for review now. But, I want to send this anyway.

On Mon, 2016-08-29 at 10:27 +0200, Daniel Vetter wrote:
> - Move missing bits into struct drm_encoder docs.
> - Explain that encoders are 95% internal and only 5% uapi, and that in
>   general the uapi part is broken.
> - Remove verbose comments for functions not exposed to drivers.
> 
> v2: Review from Archit:
> - Appease checkpatch in the moved code.
> - Make it clearer that bridges are not exposed to userspace.
> 
> Reviewed-by: Archit Taneja 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms.rst | 46 
>  drivers/gpu/drm/drm_encoder.c | 48 ++---
>  include/drm/drm_encoder.h | 70 
> +++
>  3 files changed, 101 insertions(+), 63 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 7f788caebea3..47c2835b7c2d 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -128,6 +128,12 @@ Connector Functions Reference
>  Encoder Abstraction
>  ===
>  
> +.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
> +   :doc: overview
> +
> +Encoder Functions Reference
> +---
> +
>  .. kernel-doc:: include/drm/drm_encoder.h
> :internal:
>  
> @@ -207,46 +213,6 @@ future); drivers that do not wish to provide special 
> handling for
>  primary planes may make use of the helper functions described in ? to
>  create and register a primary plane with standard capabilities.
>  
> -Encoders (:c:type:`struct drm_encoder `)
> --
> -
> -An encoder takes pixel data from a CRTC and converts it to a format
> -suitable for any attached connectors. On some devices, it may be
> -possible to have a CRTC send data to more than one encoder. In that
> -case, both encoders would receive data from the same scanout buffer,
> -resulting in a "cloned" display configuration across the connectors
> -attached to each encoder.
> -
> -Encoder Initialization
> -~~
> -
> -As for CRTCs, a KMS driver must create, initialize and register at least
> -one :c:type:`struct drm_encoder ` instance. The
> -instance is allocated and zeroed by the driver, possibly as part of a
> -larger structure.
> -
> -Drivers must initialize the :c:type:`struct drm_encoder
> -` possible_crtcs and possible_clones fields before
> -registering the encoder. Both fields are bitmasks of respectively the
> -CRTCs that the encoder can be connected to, and sibling encoders
> -candidate for cloning.
> -
> -After being initialized, the encoder must be registered with a call to
> -:c:func:`drm_encoder_init()`. The function takes a pointer to the
> -encoder functions and an encoder type. Supported types are
> -
> --  DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A
> --  DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort
> --  DRM_MODE_ENCODER_LVDS for display panels
> --  DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video,
> -   Component, SCART)
> --  DRM_MODE_ENCODER_VIRTUAL for virtual machine displays
> -
> -Encoders must be attached to a CRTC to be used. DRM drivers leave
> -encoders unattached at initialization time. Applications (or the fbdev
> -compatibility layer when implemented) are responsible for attaching the
> -encoders they want to use to a CRTC.
> -
>  Cleanup
>  ---
>  
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index bce781b7bb5f..998a6743a586 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -26,6 +26,30 @@
>  
>  #include "drm_crtc_internal.h"
>  
> +/**
> + * DOC: overview
> + *
> + * Encoders represent the connecting element between the CRTC (as the overall
> + * pixel pipeline, represented by struct _crtc) and the connectors (as 
> the
> + * generic sink entity, represented by struct _connector). Encoders are

Doesn't really say what encoders actually do apart being in between crtc
and connector. This line could have been useful here - "An encoder takes
pixel data from a CRTC and converts it to a format suitable for any
attached connectors." 

> + * objects exposed to userspace, originally to allow userspace to infer 
> cloning
> + * and connector/CRTC restrictions. Unfortunately almost all drivers get this
> + * wrong, making the uabi pretty much useless. On top of that the exposed
> + * restrictions are too simple for todays hardware, and the recommend way to
> + * infer restrictions is by using the DRM_MODE_ATOMIC_TEST_ONLY flag for the
> + * atomic IOCTL.
> + *
> + * Otherwise encoders aren't used in the uapi at all (any modeset request 
> from
> + * userspace directly connects a connector with a CRTC), drivers are 
> therefore
> + * free to use them however they wish. Modeset helper libraries make strong 
> use
> + * of encoders to facilitate 

Re: [Intel-gfx] [PATCH v5] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

Ville who had R-B'd the previous version of the patch, confirmed this
version "looks all right" via IRC. 


On Fri, 2016-09-02 at 10:53 -0700, Dhinakaran Pandiyan wrote:
> DP MST provides the capability to send multiple video and audio streams
> through a single port. This requires the API's between i915 and audio
> drivers to distinguish between multiple audio capable displays that can be
> connected to a port. Currently only the port identity is shared in the
> APIs. This patch adds support for MST with an additional parameter
> 'int pipe'. The existing parameter 'port' does not change it's meaning.
> 
> pipe =
>   MST : display pipe that the stream originates from
>   Non-MST : -1
> 
> Affected APIs:
> struct i915_audio_component_ops
> -   int (*sync_audio_rate)(struct device *, int port, int rate);
> + int (*sync_audio_rate)(struct device *, int port, int pipe,
> +  int rate);
> 
> -   int (*get_eld)(struct device *, int port, bool *enabled,
> -   unsigned char *buf, int max_bytes);
> +   int (*get_eld)(struct device *, int port, int pipe,
> +bool *enabled, unsigned char *buf, int max_bytes);
> 
> struct i915_audio_component_audio_ops
> -   void (*pin_eld_notify)(void *audio_ptr, int port);
> +   void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);
> 
> This patch makes dummy changes in the audio drivers (thanks Libin) for
> build to succeed. The audio side drivers will send the right 'pipe' values
> for MST in patches that will follow.
> 
> v2:
> Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville)
> Included Asoc driver API compatibility changes from Jeeja.
> Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
> Added comment for av_enc_map[] definition. (Takashi)
> 
> v3:
> Fixed logic error introduced while renaming 'dev_id' as 'pipe' (Ville)
> Renamed get_saved_encoder() to get_saved_enc() to reduce line length
> 
> v4:
> Rebased.
> Parameter check for pipe < -1 values in get_saved_enc() (Ville)
> Switched to for_each_pipe() in get_saved_enc() (Ville)
> Renamed 'pipe' to 'dev_id' in audio side code (Takashi)
> 
> v5:
> Included a comment for the dev_id arg. (Libin)
> 
> Signed-off-by: Dhinakaran Pandiyan 
> Reviewed-by: Takashi Iwai 
> 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  3 +-
>  drivers/gpu/drm/i915/intel_audio.c | 94 
> ++
>  include/drm/i915_component.h   |  6 +--
>  include/sound/hda_i915.h   | 11 +++--
>  sound/hda/hdac_i915.c  | 18 +---
>  sound/pci/hda/patch_hdmi.c |  7 +--
>  sound/soc/codecs/hdac_hdmi.c   |  2 +-
>  7 files changed, 94 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index aaa9c60..dac81c7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2056,7 +2056,8 @@ struct drm_i915_private {
>   /* perform PHY state sanity checks? */
>   bool chv_phy_assert[2];
>  
> - struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> + /* Used to save the pipe-to-encoder mapping for audio */
> + struct intel_encoder *av_enc_map[I915_MAX_PIPES];
>  
>   /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 40fbdd8..9583f43 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -491,6 +491,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   struct i915_audio_component *acomp = dev_priv->audio_component;
>   enum port port = intel_encoder->port;
> + enum pipe pipe = crtc->pipe;
>  
>   connector = drm_select_eld(encoder);
>   if (!connector)
> @@ -515,12 +516,18 @@ void intel_audio_codec_enable(struct intel_encoder 
> *intel_encoder)
>  
>   mutex_lock(_priv->av_mutex);
>   intel_encoder->audio_connector = connector;
> +
>   /* referred in audio callbacks */
> - dev_priv->dig_port_map[port] = intel_encoder;
> + dev_priv->av_enc_map[pipe] = intel_encoder;
>   mutex_unlock(_priv->av_mutex);
>  
> + /* audio drivers expect pipe = -1 to indicate Non-MST cases */
> + if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
> + pipe = -1;
> +
>   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> - acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, 
> (int) port);
> + acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> +  (int) port, (int) pipe);
>  }
>  
>  /**
> @@ -536,17 +543,24 @@ void intel_audio_codec_disable(struct intel_encoder 
> *intel_encoder)
>   struct drm_i915_private 

Re: [Intel-gfx] [PATCH v4 1/4] drm/i915: Store port enum in intel_encoder

[Pandiyan, Dhinakaran]

IRC acked-by: Daniel Vetter 

On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote:
> Storing the port enum in intel_encoder makes it convenient to know the
> port attached to an encoder. Moving the port information up from
> intel_digital_port to intel_encoder avoids unecessary intel_digital_port
> access and handles MST encoders cleanly without requiring conditional
> checks for them (thanks danvet).
> 
> v2:
> Renamed the port enum member from 'attached_port' to 'port' (danvet)
> Fixed missing initialization of port in intel_sdvo.c (danvet)
> 
> Signed-off-by: Dhinakaran Pandiyan 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 1 +
>  drivers/gpu/drm/i915/intel_ddi.c| 1 +
>  drivers/gpu/drm/i915/intel_dp.c | 1 +
>  drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
>  drivers/gpu/drm/i915/intel_drv.h| 1 +
>  drivers/gpu/drm/i915/intel_dsi.c| 1 +
>  drivers/gpu/drm/i915/intel_dvo.c| 2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c   | 1 +
>  drivers/gpu/drm/i915/intel_lvds.c   | 3 ++-
>  drivers/gpu/drm/i915/intel_sdvo.c   | 1 +
>  drivers/gpu/drm/i915/intel_tv.c | 2 ++
>  11 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9cd102c..60e282d5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -185,6 +185,7 @@ enum plane {
>  #define sprite_name(p, s) ((p) * INTEL_INFO(dev)->num_sprites[(p)] + (s) + 
> 'A')
>  
>  enum port {
> + PORT_NONE = -1,
>   PORT_A = 0,
>   PORT_B,
>   PORT_C,
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index c2df4e4..402755d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2426,6 +2426,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
> port)
>   intel_dig_port->max_lanes = max_lanes;
>  
>   intel_encoder->type = INTEL_OUTPUT_UNKNOWN;
> + intel_encoder->port = port;
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
>   intel_encoder->cloneable = 0;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 364db90..cfe2f4a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5726,6 +5726,7 @@ bool intel_dp_init(struct drm_device *dev,
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
>   }
>   intel_encoder->cloneable = 0;
> + intel_encoder->port = port;
>  
>   intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
>   dev_priv->hotplug.irq_port[port] = intel_dig_port;
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 629337d..d1d7e91 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -540,6 +540,7 @@ intel_dp_create_fake_mst_encoder(struct 
> intel_digital_port *intel_dig_port, enum
>DRM_MODE_ENCODER_DPMST, "DP-MST %c", pipe_name(pipe));
>  
>   intel_encoder->type = INTEL_OUTPUT_DP_MST;
> + intel_encoder->port = intel_dig_port->port;
>   intel_encoder->crtc_mask = 0x7;
>   intel_encoder->cloneable = 0;
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1c700b0..68bf134 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -202,6 +202,7 @@ struct intel_encoder {
>   struct drm_encoder base;
>  
>   enum intel_output_type type;
> + enum port port;
>   unsigned int cloneable;
>   void (*hot_plug)(struct intel_encoder *);
>   bool (*compute_config)(struct intel_encoder *,
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index de8e9fb..eb5cc0b 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1478,6 +1478,7 @@ void intel_dsi_init(struct drm_device *dev)
>  
>   intel_connector->get_hw_state = intel_connector_get_hw_state;
>  
> + intel_encoder->port = port;
>   /*
>* On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI
>* port C. BXT isn't limited like this.
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> b/drivers/gpu/drm/i915/intel_dvo.c
> index 47bdf9d..6dc2791 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -511,7 +511,9 @@ void intel_dvo_init(struct drm_device *dev)
>"DVO %c", intel_dvo_port_name(dvo->dvo_reg));
>  
>   intel_encoder->type = INTEL_OUTPUT_DVO;
> + intel_encoder->port = PORT_NONE;
>   intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
> +
>   switch (dvo->type) {
>   case INTEL_DVO_CHIP_TMDS:
>   

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915: Store port enum in intel_encoder

[Pandiyan, Dhinakaran]

On Wed, 2016-08-24 at 08:08 +0200, Daniel Vetter wrote:
> On Tue, Aug 23, 2016 at 01:49:17PM -0700, Dhinakaran Pandiyan wrote:
> > Storing the port enum in intel_encoder makes it convenient to know the
> > port attached to an encoder. Moving the port information up from
> > intel_digital_port to intel_encoder avoids unecessary intel_digital_port
> > access and handles MST encoders cleanly without requiring conditional
> > checks for them (thanks danvet).
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h | 1 +
> >  drivers/gpu/drm/i915/intel_ddi.c| 1 +
> >  drivers/gpu/drm/i915/intel_dp.c | 1 +
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
> >  drivers/gpu/drm/i915/intel_drv.h| 1 +
> >  drivers/gpu/drm/i915/intel_dsi.c| 1 +
> >  drivers/gpu/drm/i915/intel_dvo.c| 2 ++
> >  drivers/gpu/drm/i915/intel_hdmi.c   | 1 +
> >  drivers/gpu/drm/i915/intel_lvds.c   | 3 ++-
> >  drivers/gpu/drm/i915/intel_tv.c | 2 ++
> >  10 files changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 9cd102c..60e282d5 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -185,6 +185,7 @@ enum plane {
> >  #define sprite_name(p, s) ((p) * INTEL_INFO(dev)->num_sprites[(p)] + (s) + 
> > 'A')
> >  
> >  enum port {
> > +   PORT_NONE = -1,
> > PORT_A = 0,
> > PORT_B,
> > PORT_C,
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index c2df4e4..086de39 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2426,6 +2426,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
> > port)
> > intel_dig_port->max_lanes = max_lanes;
> >  
> > intel_encoder->type = INTEL_OUTPUT_UNKNOWN;
> > +   intel_encoder->attached_port = port;
> > intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
> > intel_encoder->cloneable = 0;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 364db90..4771428 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5726,6 +5726,7 @@ bool intel_dp_init(struct drm_device *dev,
> > intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
> > }
> > intel_encoder->cloneable = 0;
> > +   intel_encoder->attached_port = port;
> >  
> > intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> > dev_priv->hotplug.irq_port[port] = intel_dig_port;
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 629337d..a51f6f7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -540,6 +540,7 @@ intel_dp_create_fake_mst_encoder(struct 
> > intel_digital_port *intel_dig_port, enum
> >  DRM_MODE_ENCODER_DPMST, "DP-MST %c", pipe_name(pipe));
> >  
> > intel_encoder->type = INTEL_OUTPUT_DP_MST;
> > +   intel_encoder->attached_port = intel_dig_port->port;
> > intel_encoder->crtc_mask = 0x7;
> > intel_encoder->cloneable = 0;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 1c700b0..101d671 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -202,6 +202,7 @@ struct intel_encoder {
> > struct drm_encoder base;
> >  
> > enum intel_output_type type;
> > +   enum port attached_port;
> 
> Why the attached_ prefix? The intel_encoder _is_ the port (more or less at
> least). Also intel_sdvo.c is missing. Otherwise I think it makes sense.
> -Daniel
> 
> 

I didn't realize that, will change. 

> > unsigned int cloneable;
> > void (*hot_plug)(struct intel_encoder *);
> > bool (*compute_config)(struct intel_encoder *,
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index de8e9fb..293e530 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -1478,6 +1478,7 @@ void intel_dsi_init(struct drm_device *dev)
> >  
> > intel_connector->get_hw_state = intel_connector_get_hw_state;
> >  
> > +   intel_encoder->attached_port = port;
> > /*
> >  * On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI
> >  * port C. BXT isn't limited like this.
> > diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> > b/drivers/gpu/drm/i915/intel_dvo.c
> > index 47bdf9d..86a888f 100644
> > --- a/drivers/gpu/drm/i915/intel_dvo.c
> > +++ b/drivers/gpu/drm/i915/intel_dvo.c
> > @@ -511,7 +511,9 @@ void intel_dvo_init(struct drm_device *dev)
> >  "DVO %c", intel_dvo_port_name(dvo->dvo_reg));
> >  
> > 

Re: [Intel-gfx] [PATCH 4/5] drm/i915; Add a function to return index of link rate

[Pandiyan, Dhinakaran]

On Fri, 2016-10-21 at 16:45 -0700, Manasi Navare wrote:
> This is required to return the index of link rate into
> common_rates array. This gets used to retry the link
> training at lower link rate.
> 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c499ec1..c192e18 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -288,6 +288,21 @@ static int intel_dp_common_rates(struct intel_dp 
> *intel_dp,
>  common_rates);
>  }
>  
> +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> + int *common_rates, int link_rate)
> +{
> + int common_len;
> + int index;
> +
> + common_len = intel_dp_common_rates(intel_dp, common_rates);
> + for (index = 0; index < common_len; index++) {


Running the loop in the opposite direction will eliminate the
unnecessary array index computations.


> + if (link_rate == common_rates[common_len - index - 1])
> + return common_len - index - 1;
> + }
> +
> + return -1;
> +}
> +
>  static enum drm_mode_status
>  intel_dp_mode_valid(struct drm_connector *connector,
>   struct drm_display_mode *mode)

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Pandiyan, Dhinakaran]

On Wed, 2016-10-26 at 12:11 +0300, Ville Syrjälä wrote:
> On Tue, Oct 25, 2016 at 07:37:36PM -0700, Dhinakaran Pandiyan wrote:
> > Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
> > let's set this bit right before enabling the audio codec. Playing audio
> > without setting this bit results in pipe FIFO underruns.
> > 
> > This workaround is applicable only for audio sample rates up to 96kHz. For
> > frequencies above 96kHz, this is insufficient and cdclk should be increased
> > to at least 432 MHz, just like BDW. Since, the audio driver does not
> > support sample rates > 48 kHz, we are safe with this fix for now.
> > 
> > v2: Inlined the code change within hsw_audio_codec_enable() (Jani)
> > Fixed the port clock typo
> > Added TODO comment
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h|  5 +
> >  drivers/gpu/drm/i915/intel_audio.c | 30 +-
> >  2 files changed, 34 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 00efaa1..76dac48 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6236,6 +6236,11 @@ enum {
> >  #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
> >  #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
> >  
> > +#define _CHICKEN_TRANS_A   0x420C0
> > +#define _CHICKEN_TRANS_B   0x420C4
> > +#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
> > _CHICKEN_TRANS_B)
> > +#define SPARE_13   (1<<13)
> > +
> >  /* WaCatErrorRejectionIssue */
> >  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
> >  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 7093cfb..894f11e 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -283,6 +283,8 @@ static void hsw_audio_codec_disable(struct 
> > intel_encoder *encoder)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > +   struct intel_crtc_state *crtc_config =  intel_crtc->config;
> > +   enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
> > enum pipe pipe = intel_crtc->pipe;
> > uint32_t tmp;
> >  
> > @@ -290,13 +292,21 @@ static void hsw_audio_codec_disable(struct 
> > intel_encoder *encoder)
> >  
> > mutex_lock(_priv->av_mutex);
> >  
> > +   /*Disable DP audio stall fix for HBR2*/
> > +   if (IS_GEN9(dev_priv) && intel_crtc_has_dp_encoder(crtc_config) &&
> > +   crtc_config->port_clock >= 54) {
> > +   tmp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +   tmp &= ~SPARE_13;
> > +   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), tmp);
> > +   }
> > +
> > /* Disable timestamps */
> > tmp = I915_READ(HSW_AUD_CFG(pipe));
> > tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> > tmp |= AUD_CONFIG_N_PROG_ENABLE;
> > tmp &= ~AUD_CONFIG_UPPER_N_MASK;
> > tmp &= ~AUD_CONFIG_LOWER_N_MASK;
> > -   if (intel_crtc_has_dp_encoder(intel_crtc->config))
> > +   if (intel_crtc_has_dp_encoder(crtc_config))
> > tmp |= AUD_CONFIG_N_VALUE_INDEX;
> > I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> >  
> > @@ -315,6 +325,8 @@ static void hsw_audio_codec_enable(struct drm_connector 
> > *connector,
> >  {
> > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
> > +   struct intel_crtc_state *crtc_config =  intel_crtc->config;
> > +   enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
> > enum pipe pipe = intel_crtc->pipe;
> > enum port port = intel_encoder->port;
> > const uint8_t *eld = connector->eld;
> > @@ -326,6 +338,22 @@ static void hsw_audio_codec_enable(struct 
> > drm_connector *connector,
> >  
> > mutex_lock(_priv->av_mutex);
> >  
> > +   /* Enable DP audio stall fix for HBR2
> > +*
> > +* TODO: This workaround is applicable only for audio sample rates up
> > +* to 96kHz. For frequencies above 96kHz, this is insufficient and
> > +* cdclk should be increased to at least 432 MHz, just like BDW. Since,
> > +* the audio driver does not support sample rates > 48 kHz, we are safe
> > +* with this fix for now.
> 
> Where in the sound driver is this supposed 96kHz limit? I see a lot of
> stuff for >96kHz in the code at least.
> 

Libin/Jeeja can you help me here?


> > +*/
> > +
> > +   if (IS_GEN9(dev_priv) && intel_crtc_has_dp_encoder(crtc_config) &&
> > +   crtc_config->port_clock >= 54) {
> > +   tmp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +   tmp |= SPARE_13;
> > +   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), tmp);
> > +   }
> > +
> > /* Enable audio 

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Debug log MST active links explicitly

[Pandiyan, Dhinakaran]

Jim,
Please let me know if the R-B is still good.

-DK

On Tue, 2016-10-25 at 21:37 -0700, Dhinakaran Pandiyan wrote:
> From: "Pandiyan, Dhinakaran" <dhinakaran.pandi...@intel.com>
> 
> No functional change. Just printing the number of active links without
> stating what the number means is not very useful. So, add relevant text.
> 
> v2: Included connector info (Chris)
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandi...@intel.com>
> Reviewed-by: Jim Bride <jim.br...@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 3ffbd69..8f2016b 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -86,8 +86,6 @@ static void intel_mst_disable_dp(struct intel_encoder 
> *encoder,
>   to_intel_connector(old_conn_state->connector);
>   int ret;
>  
> - DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> -
>   drm_dp_mst_reset_vcpi_slots(_dp->mst_mgr, connector->port);
>  
>   ret = drm_dp_update_payload_part1(_dp->mst_mgr);
> @@ -106,8 +104,6 @@ static void intel_mst_post_disable_dp(struct 
> intel_encoder *encoder,
>   struct intel_connector *connector =
>   to_intel_connector(old_conn_state->connector);
>  
> - DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> -
>   /* this can fail */
>   drm_dp_check_act_status(_dp->mst_mgr);
>   /* and this can also fail */
> @@ -124,6 +120,11 @@ static void intel_mst_post_disable_dp(struct 
> intel_encoder *encoder,
>  
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>   }
> +
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] MST link deactivated, total active 
> links: %d\n",
> +   old_conn_state->connector->base.id,
> +   old_conn_state->connector->name,
> +   intel_dp->active_mst_links);
>  }
>  
>  static void intel_mst_pre_enable_dp(struct intel_encoder *encoder,
> @@ -147,8 +148,6 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder,
>   connector->encoder = encoder;
>   intel_mst->connector = connector;
>  
> - DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> -
>   if (intel_dp->active_mst_links == 0) {
>   intel_ddi_clk_select(_dig_port->base,
>pipe_config->shared_dpll);
> @@ -175,7 +174,6 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder,
>   return;
>   }
>  
> -
>   intel_dp->active_mst_links++;
>   temp = I915_READ(DP_TP_STATUS(port));
>   I915_WRITE(DP_TP_STATUS(port), temp);
> @@ -194,8 +192,6 @@ static void intel_mst_enable_dp(struct intel_encoder 
> *encoder,
>   enum port port = intel_dig_port->port;
>   int ret;
>  
> - DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> -
>   if (intel_wait_for_register(dev_priv,
>   DP_TP_STATUS(port),
>   DP_TP_STATUS_ACT_SENT,
> @@ -206,6 +202,11 @@ static void intel_mst_enable_dp(struct intel_encoder 
> *encoder,
>   ret = drm_dp_check_act_status(_dp->mst_mgr);
>  
>   ret = drm_dp_update_payload_part2(_dp->mst_mgr);
> +
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] MST link activated, total active 
> links: %d\n",
> +   conn_state->connector->base.id,
> +   conn_state->connector->name,
> +   intel_dp->active_mst_links);
>  }
>  
>  static bool intel_dp_mst_enc_get_hw_state(struct intel_encoder *encoder,

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Pandiyan, Dhinakaran]

On Wed, 2016-10-26 at 11:57 +0300, Jani Nikula wrote:
> On Wed, 26 Oct 2016, Dhinakaran Pandiyan  
> wrote:
> > Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
> > let's set this bit right before enabling the audio codec. Playing audio
> > without setting this bit results in pipe FIFO underruns.
> >
> > This workaround is applicable only for audio sample rates up to 96kHz. For
> > frequencies above 96kHz, this is insufficient and cdclk should be increased
> > to at least 432 MHz, just like BDW. Since, the audio driver does not
> > support sample rates > 48 kHz, we are safe with this fix for now.
> >
> > v2: Inlined the code change within hsw_audio_codec_enable() (Jani)
> > Fixed the port clock typo
> > Added TODO comment
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h|  5 +
> >  drivers/gpu/drm/i915/intel_audio.c | 30 +-
> >  2 files changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 00efaa1..76dac48 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6236,6 +6236,11 @@ enum {
> >  #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
> >  #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
> >  
> > +#define _CHICKEN_TRANS_A   0x420C0
> > +#define _CHICKEN_TRANS_B   0x420C4
> > +#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
> > _CHICKEN_TRANS_B)
> > +#define SPARE_13   (1<<13)
> > +
> >  /* WaCatErrorRejectionIssue */
> >  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
> >  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 7093cfb..894f11e 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -283,6 +283,8 @@ static void hsw_audio_codec_disable(struct 
> > intel_encoder *encoder)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > +   struct intel_crtc_state *crtc_config =  intel_crtc->config;
> > +   enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
> > enum pipe pipe = intel_crtc->pipe;
> > uint32_t tmp;
> >  
> > @@ -290,13 +292,21 @@ static void hsw_audio_codec_disable(struct 
> > intel_encoder *encoder)
> >  
> > mutex_lock(_priv->av_mutex);
> >  
> > +   /*Disable DP audio stall fix for HBR2*/
> 
> Nitpick, spaces after /* and before */.
> 
> > +   if (IS_GEN9(dev_priv) && intel_crtc_has_dp_encoder(crtc_config) &&
> > +   crtc_config->port_clock >= 54) {
> > +   tmp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +   tmp &= ~SPARE_13;
> > +   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), tmp);
> > +   }
> 
> Hmm. Why don't we just do this unconditionally?
> 

That bit is disabled by default, so avoiding  two MMIO ops. that are not
required.

> > +
> > /* Disable timestamps */
> > tmp = I915_READ(HSW_AUD_CFG(pipe));
> > tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> > tmp |= AUD_CONFIG_N_PROG_ENABLE;
> > tmp &= ~AUD_CONFIG_UPPER_N_MASK;
> > tmp &= ~AUD_CONFIG_LOWER_N_MASK;
> > -   if (intel_crtc_has_dp_encoder(intel_crtc->config))
> > +   if (intel_crtc_has_dp_encoder(crtc_config))
> > tmp |= AUD_CONFIG_N_VALUE_INDEX;
> > I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> >  
> > @@ -315,6 +325,8 @@ static void hsw_audio_codec_enable(struct drm_connector 
> > *connector,
> >  {
> > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
> > +   struct intel_crtc_state *crtc_config =  intel_crtc->config;
> > +   enum transcoder cpu_transcoder = crtc_config->cpu_transcoder;
> > enum pipe pipe = intel_crtc->pipe;
> > enum port port = intel_encoder->port;
> > const uint8_t *eld = connector->eld;
> > @@ -326,6 +338,22 @@ static void hsw_audio_codec_enable(struct 
> > drm_connector *connector,
> >  
> > mutex_lock(_priv->av_mutex);
> >  
> > +   /* Enable DP audio stall fix for HBR2
> > +*
> > +* TODO: This workaround is applicable only for audio sample rates up
> > +* to 96kHz. For frequencies above 96kHz, this is insufficient and
> > +* cdclk should be increased to at least 432 MHz, just like BDW. Since,
> > +* the audio driver does not support sample rates > 48 kHz, we are safe
> > +* with this fix for now.
> > +*/
> 
> Is this TODO required if you already have that check in patch 2/2?
> 

In fact, this patch itself is not required if we are increasing the
cdclk to 432 MHz for gen9 platforms (like patch 2/2). Having this
workaround gives us the option running the pipeline at a lower cdclk
frequency 

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Pandiyan, Dhinakaran]

On Wed, 2016-10-26 at 08:37 +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 09:18:36PM -0700, Dhinakaran Pandiyan wrote:
> > Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
> > let's set this bit right before enabling the audio codec. Playing audio
> > without setting this bit results in pipe FIFO underruns.
> 
> Please insert a full Bspec citation here so that we can find where this is
> documented in the future. Both where in Bspec it is, and then just quote
> the full text with the explanation and put that into the commit message.
> 
> Otherwise there's no way we'll ever find this again in the future.
> -Daniel
> 
This particular update has not landed in BSpec yet. I will update the
commit message and re-send the patches after they are reviewed.

> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  5 +
> >  drivers/gpu/drm/i915/intel_ddi.c | 38 
> > ++
> >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >  3 files changed, 45 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 00efaa1..76dac48 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6236,6 +6236,11 @@ enum {
> >  #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
> >  #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
> >  
> > +#define _CHICKEN_TRANS_A   0x420C0
> > +#define _CHICKEN_TRANS_B   0x420C4
> > +#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
> > _CHICKEN_TRANS_B)
> > +#define SPARE_13   (1<<13)
> > +
> >  /* WaCatErrorRejectionIssue */
> >  #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
> >  #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index fb18d69..84c91c1 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1858,6 +1858,38 @@ void intel_ddi_fdi_post_disable(struct intel_encoder 
> > *intel_encoder,
> > I915_WRITE(FDI_RX_CTL(PIPE_A), val);
> >  }
> >  
> > +void gen9_enable_dp_audio_stall_fix(struct intel_crtc_state *pipe_config)
> > +{
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(pipe_config->base.crtc->dev);
> > +   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> > +   uint32_t temp;
> > +
> > +   if (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->port_clock >= 54000) {
> > +
> > +   temp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +   temp |= SPARE_13;
> > +   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), temp);
> > +   }
> > +}
> > +
> > +void gen9_disable_dp_audio_stall_fix(struct intel_crtc_state *pipe_config)
> > +{
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(pipe_config->base.crtc->dev);
> > +   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> > +   uint32_t temp;
> > +
> > +   if (intel_crtc_has_dp_encoder(pipe_config) &&
> > +   pipe_config->port_clock >= 54000) {
> > +
> > +   temp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
> > +   temp &= ~SPARE_13;
> > +   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), temp);
> > +   }
> > +}
> > +
> >  static void intel_enable_ddi(struct intel_encoder *intel_encoder,
> >  struct intel_crtc_state *pipe_config,
> >  struct drm_connector_state *conn_state)
> > @@ -1893,6 +1925,9 @@ static void intel_enable_ddi(struct intel_encoder 
> > *intel_encoder,
> > }
> >  
> > if (intel_crtc->config->has_audio) {
> > +   if (IS_GEN9(dev_priv))
> > +   gen9_enable_dp_audio_stall_fix(pipe_config);
> > +
> > intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
> > intel_audio_codec_enable(intel_encoder);
> > }
> > @@ -1912,6 +1947,9 @@ static void intel_disable_ddi(struct intel_encoder 
> > *intel_encoder,
> > if (intel_crtc->config->has_audio) {
> > intel_audio_codec_disable(intel_encoder);
> > intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
> > +
> > +   if (IS_GEN9(dev_priv))
> > +   gen9_disable_dp_audio_stall_fix(old_crtc_state);
> > }
> >  
> > if (type == INTEL_OUTPUT_EDP) {
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 4e90b07..ef02c62 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1189,6 +1189,8 @@ unsigned int intel_fb_align_height(struct drm_device 
> > *dev,
> >uint64_t fb_format_modifier);
> >  u32 intel_fb_stride_alignment(const struct drm_i915_private *dev_priv,
> >   uint64_t fb_modifier, uint32_t pixel_format);
> > +void