Re: [Intel-gfx] [PATCH v6 1/4] drm/i915: Add audio sync_audio_rate callback

[Jani Nikula]

On Wed, 02 Sep 2015, libin.y...@intel.com wrote:
> From: Libin Yang 
>
> Add the sync_audio_rate callback.
>
> With the callback, audio driver can trigger
> i915 driver to set the proper N/CTS or N/M
> based on different sample rates.
>
> Signed-off-by: Libin Yang 

Reviewed-by: Jani Nikula 

> ---
>  include/drm/i915_component.h | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index c9a8b64..8ad6f1b 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -33,6 +33,13 @@ struct i915_audio_component {
>   void (*put_power)(struct device *);
>   void (*codec_wake_override)(struct device *, bool enable);
>   int (*get_cdclk_freq)(struct device *);
> + /**
> +  * @sync_audio_rate: set n/cts based on the sample rate
> +  *
> +  * Called from audio driver. After audio driver sets the
> +  * sample rate, it will call this function to set n/cts
> +  */
> + int (*sync_audio_rate)(struct device *, int port, int rate);
>   } *ops;
>  };
>  
> -- 
> 1.9.1
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 2/4] drm/i915: implement sync_audio_rate callback

[Jani Nikula]

On Wed, 02 Sep 2015, libin.y...@intel.com wrote:
> From: Libin Yang 
>
> HDMI audio may not work at some frequencies
> with the HW provided N/CTS.
>
> This patch sets the proper N value for the
> given audio sample rate at the impacted frequencies.
> At other frequencies, it will use the N/CTS value
> which HW provides.
>
> Signed-off-by: Libin Yang 

Okay, so there are a number of questions and comments this patch still
raises. Please find them inline.

*However*, we should really get this finally moving forward, and I don't
think the issues are or need to be blockers, so this is

Reviewed-by: Jani Nikula 

I think we (as in i915 folks) can clean the rest of the bikeshedding up,
and I don't think we should be NAKing this ad infinitum to teach you to
become an i915 developer... unless you want to be one. ;)

> ---
>  drivers/gpu/drm/i915/i915_dma.c|   1 +
>  drivers/gpu/drm/i915/i915_drv.h|   5 ++
>  drivers/gpu/drm/i915/intel_audio.c | 138 
> +
>  3 files changed, 144 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 097d4ba..8ffb5dc 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -858,6 +858,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   mutex_init(&dev_priv->sb_lock);
>   mutex_init(&dev_priv->modeset_restore_lock);
>   mutex_init(&dev_priv->csr_lock);
> + mutex_init(&dev_priv->av_mutex);
>  
>   intel_pm_setup(dev);
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 05ffd5a..2c6b76f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1882,6 +1882,11 @@ struct drm_i915_private {
>  
>   /* hda/i915 audio component */
>   bool audio_component_registered;
> + /**
> +  * av_mutex - mutex for audio/video sync
> +  *
> +  */
> + struct mutex av_mutex;
>  
>   uint32_t hw_context_size;
>   struct list_head context_list;
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index dc32cf4..a021720 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -68,6 +68,31 @@ static const struct {
>   { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
>  };
>  
> +/* HDMI N/CTS table */
> +#define TMDS_297M 297000
> +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
> +static const struct {
> + int sample_rate;
> + int clock;
> + int n;
> + int cts;
> +} aud_ncts[] = {
> + { 44100, TMDS_296M, 4459, 234375 },
> + { 44100, TMDS_297M, 4704, 247500 },
> + { 48000, TMDS_296M, 5824, 281250 },
> + { 48000, TMDS_297M, 5120, 247500 },
> + { 32000, TMDS_296M, 5824, 421875 },
> + { 32000, TMDS_297M, 3072, 222750 },
> + { 88200, TMDS_296M, 8918, 234375 },
> + { 88200, TMDS_297M, 9408, 247500 },
> + { 96000, TMDS_296M, 11648, 281250 },
> + { 96000, TMDS_297M, 10240, 247500 },
> + { 176400, TMDS_296M, 17836, 234375 },
> + { 176400, TMDS_297M, 18816, 247500 },
> + { 192000, TMDS_296M, 23296, 281250 },
> + { 192000, TMDS_297M, 20480, 247500 },
> +};

Okay, I admit, I did not look these up in the spec. *blush*. I'm sure
Ville has/will. ;)

> +
>  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
>  static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
>  {
> @@ -90,6 +115,31 @@ static u32 audio_config_hdmi_pixel_clock(struct 
> drm_display_mode *mode)
>   return hdmi_audio_clock[i].config;
>  }
>  
> +static int audio_config_get_n(const struct drm_display_mode *mode, int rate)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
> + if ((rate == aud_ncts[i].sample_rate) &&
> + (mode->clock == aud_ncts[i].clock)) {
> + return aud_ncts[i].n;
> + }
> + }
> + return 0;
> +}
> +
> +/* check whether N/CTS/M need be set manually */
> +static bool audio_rate_need_prog(struct intel_crtc *crtc,
> + struct drm_display_mode *mode)
> +{
> + if (((mode->clock == TMDS_297M) ||
> +  (mode->clock == TMDS_296M)) &&
> + intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))
> + return true;
> + else
> + return false;
> +}
> +
>  static bool intel_eld_uptodate(struct drm_connector *connector,
>  int reg_eldv, uint32_t bits_eldv,
>  int reg_elda, uint32_t bits_elda,
> @@ -184,6 +234,8 @@ static void hsw_audio_codec_disable(struct intel_encoder 
> *encoder)
>  
>   DRM_DEBUG_KMS("Disable audio codec on pipe %c\n", pipe_name(pipe));
>  
> + mutex_lock(&dev_priv->av_mutex);
> +

Bikeshed. We should think about moving the locking to
intel_audio_codec_enable and intel_audio_codec_disable for
consistency. We'll be adding new platform hook

Re: [Intel-gfx] [PATCH 02/16] drm/i915: fix the FBC work allocation failure path

[Daniel Vetter]

On Tue, Sep 01, 2015 at 02:03:34PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 01, 2015 at 12:07:01PM +0200, Daniel Vetter wrote:
> > On Fri, Aug 28, 2015 at 11:50:08AM -0300, Paulo Zanoni wrote:
> > > 2015-08-28 11:20 GMT-03:00 Ville Syrjälä :
> > > > On Fri, Aug 14, 2015 at 06:34:07PM -0300, Paulo Zanoni wrote:
> > > >> Always update the currrent crtc, fb and vertical offset after calling
> > > >> enable_fbc. We were forgetting to do so along the failure paths when
> > > >> enabling fbc synchronously. Fix this with a new helper to enable_fbc()
> > > >> and update the state simultaneously.
> > > >>
> > > >> v2: Improve commit message (Chris).
> > > >>
> > > >> Signed-off-by: Paulo Zanoni 
> > > >> ---
> > > >>  drivers/gpu/drm/i915/intel_fbc.c | 27 +--
> > > >>  1 file changed, 17 insertions(+), 10 deletions(-)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > > >> b/drivers/gpu/drm/i915/intel_fbc.c
> > > >> index c97aba2..fa9b004 100644
> > > >> --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > >> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > >> @@ -308,6 +308,18 @@ bool intel_fbc_enabled(struct drm_i915_private 
> > > >> *dev_priv)
> > > >>   return dev_priv->fbc.enabled;
> > > >>  }
> > > >>
> > > >> +static void intel_fbc_enable(struct intel_crtc *crtc,
> > > >> +  struct drm_framebuffer *fb)
> > > >
> > > > fb could be const
> > > 
> > > I guess a lot of things could be constified, if we decide to do this.
> > 
> > Personally I like const on .data (especially vfunc tables since those are
> > nice to create exploits if they're writable and you can get at them). And
> > for core functions/vfuncs where the const has a semantic meaning.
> > Otherwise I personally don't see to much value in sprinkling const all
> > over.
> 
> I especially like making display mode, state, etc. structs const to make
> it clear which functions can change them and which can't. IMO
> drm_framebuffer could use the same treatment.

Yeah I guess making a few things in the drm core static could be useful
indeed, for example plane_state->fb reall should be static, or
crtc_state->mode_blob (or any other fb or blob pointer in state
structures). Same for all the {plane, connector, crtc}->state pointers
(although that would need some casts in swap_states()). I'm not too sure
how much benefit there is if we do this just in i915, since if the
top-level entry points called from drm core aren't enforcing constness
trying to do it in i915 only will probably be an endless effort of fixing
things up all the time.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix module initialisation, v2.

[Daniel Vetter]

On Tue, Sep 01, 2015 at 01:51:38PM +0200, Maarten Lankhorst wrote:
> Op 01-09-15 om 12:12 schreef Daniel Vetter:
> > On Mon, Aug 31, 2015 at 03:13:41PM -0700, Matt Roper wrote:
> >> On Thu, Aug 27, 2015 at 03:15:15PM +0200, Maarten Lankhorst wrote:
> >>> Set DRIVER_MODESET and DRIVER_ATOMIC by default. The driver is fully 
> >>> atomic.
> >>> Remove the legacy suspend/resume, to fix a warning introduced by:
> >>>
> >>> "drm: WARN_ON if a modeset driver uses legacy suspend/resume helpers"
> >>>
> >>> and removing the .get_vblank_timestamp reset to NULL. It's a noop without 
> >>> UMS.
> >>>
> >>> Signed-off-by: Maarten Lankhorst 
> >> Reviewed-by: Matt Roper 
> > Review should include the commit message and this commit message doesn't
> > match v2 at all ... Please rectify (or at least tell me what I should put
> > there).
> >
> Oops..
> 
> The driver doesn't support UMS any more, so set DRIVER_MODESET by default,
> remove the legacy s/r callbacks, and rename the s/r functions to make it more 
> clear
> they're only in use by switcheroo now.
> 
> Also remove an obsolete comment about atomic. Normal updates are supported 
> only
> async updates aren't yet.

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Support GuC version 4.3

[Daniel Vetter]

On Thu, Aug 27, 2015 at 05:32:10PM +0100, Dave Gordon wrote:
> On 18/08/15 22:32, yu@intel.com wrote:
> >From: Alex Dai 
> >
> >The firmware layout changes that now it only has css header +
> >uCode + RSA signature. Plus, other trivial changes to support
> >GuC V4.3.
> >
> >Signed-off-by: Alex Dai 
> 
> Reviewed-by: Dave Gordon 

Queued for -next, thanks for the patch.
-Daniel

> 
> This works with the version 4.3 binary currently available for download from
> 01.org :)
> 
> >---
> >  drivers/gpu/drm/i915/intel_guc_fwif.h   | 11 ---
> >  drivers/gpu/drm/i915/intel_guc_loader.c | 17 ++---
> >  2 files changed, 14 insertions(+), 14 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
> >b/drivers/gpu/drm/i915/intel_guc_fwif.h
> >index 950c7e7..e1f47ba 100644
> >--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> >+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> >@@ -41,7 +41,7 @@
> >  #define GUC_CTX_PRIORITY_NORMAL3
> >
> >  #define GUC_MAX_GPU_CONTEXTS   1024
> >-#define GUC_INVALID_CTX_ID  (GUC_MAX_GPU_CONTEXTS + 1)
> >+#define GUC_INVALID_CTX_ID  GUC_MAX_GPU_CONTEXTS
> >
> >  /* Work queue item header definitions */
> >  #define WQ_STATUS_ACTIVE   1
> >@@ -75,6 +75,7 @@
> >  #define GUC_CTX_DESC_ATTR_RESET(1 << 4)
> >  #define GUC_CTX_DESC_ATTR_WQLOCKED (1 << 5)
> >  #define GUC_CTX_DESC_ATTR_PCH  (1 << 6)
> >+#define GUC_CTX_DESC_ATTR_TERMINATED(1 << 7)
> >
> >  /* The guc control data is 10 DWORDs */
> >  #define GUC_CTL_CTXINFO0
> >@@ -107,6 +108,7 @@
> >  #define   GUC_CTL_DISABLE_SCHEDULER(1 << 4)
> >  #define   GUC_CTL_PREEMPTION_LOG   (1 << 5)
> >  #define   GUC_CTL_ENABLE_SLPC  (1 << 7)
> >+#define   GUC_CTL_RESET_ON_PREMPT_FAILURE   (1 << 8)
> >  #define GUC_CTL_DEBUG  8
> >  #define   GUC_LOG_VERBOSITY_SHIFT  0
> >  #define   GUC_LOG_VERBOSITY_LOW(0 << GUC_LOG_VERBOSITY_SHIFT)
> >@@ -116,8 +118,9 @@
> >  /* Verbosity range-check limits, without the shift */
> >  #define  GUC_LOG_VERBOSITY_MIN 0
> >  #define  GUC_LOG_VERBOSITY_MAX 3
> >+#define GUC_CTL_RSRVD   9
> >
> >-#define GUC_CTL_MAX_DWORDS  (GUC_CTL_DEBUG + 1)
> >+#define GUC_CTL_MAX_DWORDS  (GUC_CTL_RSRVD + 1)
> >
> >  struct guc_doorbell_info {
> > u32 db_status;
> >@@ -207,7 +210,9 @@ struct guc_context_desc {
> >
> > u32 engine_presence;
> >
> >-u32 reserved0[1];
> >+u8 engine_suspended;
> >+
> >+u8 reserved0[3];
> > u64 reserved1[1];
> >
> > u64 desc_private;
> >diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> >b/drivers/gpu/drm/i915/intel_guc_loader.c
> >index d46195c..7521eac 100644
> >--- a/drivers/gpu/drm/i915/intel_guc_loader.c
> >+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> >@@ -59,7 +59,7 @@
> >   *
> >   */
> >
> >-#define I915_SKL_GUC_UCODE "i915/skl_guc_ver3.bin"
> >+#define I915_SKL_GUC_UCODE "i915/skl_guc_ver4.bin"
> >  MODULE_FIRMWARE(I915_SKL_GUC_UCODE);
> >
> >  /* User-friendly representation of an enum */
> >@@ -226,10 +226,6 @@ static inline bool guc_ucode_response(struct 
> >drm_i915_private *dev_priv,
> >   * +---+  
> >   * | RSA signature |  256B
> >   * +---+  
> >- * | RSA public Key|  256B
> >- * +---+  
> >- * |   Public key modulus  |4B
> >- * +---+  
> >   *
> >   * Architecturally, the DMA engine is bidirectional, and can potentially 
> > even
> >   * transfer between GTT locations. This functionality is left out of the 
> > API
> >@@ -244,7 +240,6 @@ static inline bool guc_ucode_response(struct 
> >drm_i915_private *dev_priv,
> >  #define UOS_VER_MAJOR_OFFSET   0x46
> >  #define UOS_CSS_HEADER_SIZE0x80
> >  #define UOS_RSA_SIG_SIZE   0x100
> >-#define UOS_CSS_SIGNING_SIZE0x204
> >
> >  static int guc_ucode_xfer_dma(struct drm_i915_private *dev_priv)
> >  {
> >@@ -256,7 +251,7 @@ static int guc_ucode_xfer_dma(struct drm_i915_private 
> >*dev_priv)
> > int i, ret = 0;
> >
> > /* uCode size, also is where RSA signature starts */
> >-offset = ucode_size = guc_fw->guc_fw_size - UOS_CSS_SIGNING_SIZE;
> >+offset = ucode_size = guc_fw->guc_fw_size - UOS_RSA_SIG_SIZE;
> > I915_WRITE(DMA_COPY_SIZE, ucode_size);
> >
> > /* Copy RSA signature from the fw image to HW for verification */
> >@@ -471,8 +466,8 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
> >intel_guc_fw *guc_fw)
> > struct drm_i915_gem_object *obj;
> > const struct firmware *fw;
> > const u8 *css_header;
> >-const size_t minsize = UOS_CSS_HEADER_SIZE + UOS_CSS_SIGNING_SIZE;
> >-const size_t maxsize = GUC_WOPCM_SIZE_VALUE + UOS_CSS_SIGNING_SIZE
> >+const size_t minsize = UOS_CSS_

Re: [Intel-gfx] [PATCH] drm/i915: Notify GuC rc6 state

[Daniel Vetter]

On Thu, Aug 27, 2015 at 12:47:30PM -0700, O'Rourke, Tom wrote:
> On Tue, Aug 18, 2015 at 02:34:47PM -0700, yu@intel.com wrote:
> > From: Alex Dai 
> > 
> > If rc6 is enabled, notify GuC so it can do proper forcewake before
> > command submission.
> > 
> > Signed-off-by: Alex Dai 
> 
> Reviewed-by: Tom O'Rourke 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Daniel Vetter]

On Fri, Aug 28, 2015 at 04:10:36PM +0300, Jani Nikula wrote:
> On Thu, 20 Aug 2015, Takashi Iwai  wrote:
> > On Thu, 20 Aug 2015 11:41:42 +0200,
> > David Henningsson wrote:
> >> 
> >> 
> >> 
> >> On 2015-08-20 11:28, Takashi Iwai wrote:
> >> > On Wed, 19 Aug 2015 10:48:58 +0200,
> >> > David Henningsson wrote:
> >> >>
> >> >> Whenever there is an event from the i915 driver, wake the codec
> >> >> and recheck plug/unplug + ELD status.
> >> >>
> >> >> This fixes the issue with lost unsol events in power save mode,
> >> >> the codec and controller can now sleep in D3 and still know when
> >> >> the HDMI monitor has been connected.
> >> >>
> >> >> Signed-off-by: David Henningsson 
> >> >
> >> > This addition looks fine, but then we'll get double notification for
> >> > the normal hotplug/unplug, one via component ops and another via unsol
> >> > event?
> >> 
> >> Right, in case the unsol event actually works...
> >> 
> >> I would argue that the normal case would be that the controller and 
> >> codec is in D3 which means that the unsol event never gets through - due 
> >> to hw limitations - which is what triggered this patch set in the first 
> >> place.
> >> 
> >> But yes, in some case we might get double notification, but this should 
> >> not cause any trouble in practice. The unsol event could be turned off, 
> >> but would it be okay to save that for a later patch set (so I don't miss 
> >> the upcoming merge window)?
> >
> > In that case, it should be mentioned in the changelog at least.
> >
> > This series came a bit too late for the merge window, so I'm not sure
> > whether this can get in.  I personally find it OK, so take my ack for
> > ALSA parts (patch 3/4), but the rest need review and ack from i915
> > guys.  And we don't know who to merge this, if any.  The changes are
> > almost even to i915 and hda.  I don't mind either way, via drm or
> > sound tree.
> 
> Personally I'm fine with this still going for v4.3 since to me it looks
> like any regressions this might cause will be on your side. *grin*.

The only bit I want is some decent kerneldoc for the ad-hoc growing
i915/hda-intel interfaces. But that can be done in follow-up patches and
needs to be coordinated with the audio rate handling series anyway. So ack
from my side for all getting merged through alsa trees too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 14/15] drm/i915: skl nv12 workarounds

[Daniel Vetter]

On Thu, Aug 27, 2015 at 01:44:06AM +, Konduru, Chandra wrote:
> > > -static char intel_get_stepping(struct drm_device *dev)
> > > +char intel_get_stepping(struct drm_device *dev)
> > 
> > I guess we should have a new home for this now that it's used outside of
> > intel_csr.c Plus kerneldoc, as usual.
> 
> Will add kerneldoc header and respun, but where do you want to move to?

If you want my dice-roll, I'd shovel it into intel_uncore.c for lack of
better home.
-Daniel

> 
> > 
> > >  {
> > >   if (IS_SKYLAKE(dev) && (dev->pdev->revision <
> > >   ARRAY_SIZE(skl_stepping_info)))
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > > index 419660d..2158b8f 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -3196,6 +3196,16 @@ static void skylake_update_primary_plane(struct
> > drm_crtc *crtc,
> > >   I915_WRITE(PLANE_AUX_DIST(pipe, 0), aux_dist | aux_stride);
> > >   I915_WRITE(PLANE_AUX_OFFSET(pipe, 0), aux_y_offset << 16 |
> > aux_x_offset);
> > >
> > > + DRM_DEBUG_KMS("KCM: is_skl = %d is_bxt = %d\n",
> > > + IS_SKYLAKE(dev), IS_BROXTON(dev));
> > > +
> > 
> > Wa comments are missing here. Also generally we do 1 wa per commit.
> > -Daniel
> 
> Sure, will split and respun.
> 

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

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Wed, 02 Sep 2015 10:00:44 +0200,
Daniel Vetter wrote:
> 
> On Fri, Aug 28, 2015 at 04:10:36PM +0300, Jani Nikula wrote:
> > On Thu, 20 Aug 2015, Takashi Iwai  wrote:
> > > On Thu, 20 Aug 2015 11:41:42 +0200,
> > > David Henningsson wrote:
> > >> 
> > >> 
> > >> 
> > >> On 2015-08-20 11:28, Takashi Iwai wrote:
> > >> > On Wed, 19 Aug 2015 10:48:58 +0200,
> > >> > David Henningsson wrote:
> > >> >>
> > >> >> Whenever there is an event from the i915 driver, wake the codec
> > >> >> and recheck plug/unplug + ELD status.
> > >> >>
> > >> >> This fixes the issue with lost unsol events in power save mode,
> > >> >> the codec and controller can now sleep in D3 and still know when
> > >> >> the HDMI monitor has been connected.
> > >> >>
> > >> >> Signed-off-by: David Henningsson 
> > >> >
> > >> > This addition looks fine, but then we'll get double notification for
> > >> > the normal hotplug/unplug, one via component ops and another via unsol
> > >> > event?
> > >> 
> > >> Right, in case the unsol event actually works...
> > >> 
> > >> I would argue that the normal case would be that the controller and 
> > >> codec is in D3 which means that the unsol event never gets through - due 
> > >> to hw limitations - which is what triggered this patch set in the first 
> > >> place.
> > >> 
> > >> But yes, in some case we might get double notification, but this should 
> > >> not cause any trouble in practice. The unsol event could be turned off, 
> > >> but would it be okay to save that for a later patch set (so I don't miss 
> > >> the upcoming merge window)?
> > >
> > > In that case, it should be mentioned in the changelog at least.
> > >
> > > This series came a bit too late for the merge window, so I'm not sure
> > > whether this can get in.  I personally find it OK, so take my ack for
> > > ALSA parts (patch 3/4), but the rest need review and ack from i915
> > > guys.  And we don't know who to merge this, if any.  The changes are
> > > almost even to i915 and hda.  I don't mind either way, via drm or
> > > sound tree.
> > 
> > Personally I'm fine with this still going for v4.3 since to me it looks
> > like any regressions this might cause will be on your side. *grin*.
> 
> The only bit I want is some decent kerneldoc for the ad-hoc growing
> i915/hda-intel interfaces. But that can be done in follow-up patches and
> needs to be coordinated with the audio rate handling series anyway. So ack
> from my side for all getting merged through alsa trees too.

Are you going to merge Libin's patchset?  If yes, it's better to align
both patchsets through a single tree.  It'll make merges easier, as
both touch the similar place.


thanks,

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

Re: [Intel-gfx] [PATCH i-g-t 2/2] Adding kms_nv12 to test display NV12 feature

[Daniel Vetter]

On Thu, Aug 27, 2015 at 01:51:52AM +, Konduru, Chandra wrote:
> > > +static void test_nv12_invalid_fb_params(data_t *d)
> > > +{
> > > + igt_display_t *display = &d->display;
> > > + igt_output_t *output;
> > > + enum pipe pipe;
> > > + int valid_tests = 0;
> > > +
> > > + igt_require(d->display.has_universal_planes);
> > > + igt_require(d->num_scalers);
> > > +
> > > + for_each_connected_output(display, output) {
> > > + struct local_drm_mode_fb_cmd2 f;
> > > + int fd = d->drm_fd;
> > > + drmModeModeInfo *mode;
> > > +
> > > + mode = igt_output_get_mode(output);
> > > + pipe = output->config.pipe;
> > > +
> > > + igt_output_set_pipe(output, pipe);
> > > +
> > > + /* Set up display with plane 1 */
> > > + d->plane1 = igt_output_get_plane(output,
> > IGT_PLANE_PRIMARY);
> > > + igt_plane_set_rotation(d->plane1, IGT_ROTATION_0);
> > > + prepare_crtc(d, output, pipe, d->plane1, mode,
> > COMMIT_LEGACY);
> > > +
> > > + /* use igt helper to create bo and addfb tile-Yf, this should 
> > > pass
> > */
> > > + d->fb_id1_nv12 = igt_create_fb(d->drm_fd,
> > > + 1920, 1080,
> > > + DRM_FORMAT_NV12,
> > > + LOCAL_I915_FORMAT_MOD_Yf_TILED,
> > > + &d->fb1_nv12);
> > > + igt_assert(d->fb_id1_nv12);
> > > +
> > > + /* now remove fb but keep bo to redo addfb */
> > > + drmModeRmFB(d->drm_fd, d->fb_id1_nv12);
> > > +
> > > + /* redo AddFB */
> > > + memset(&f, 0, sizeof(f));
> > > +
> > > + f.width = d->fb1_nv12.width;
> > > + f.height = d->fb1_nv12.height;
> > > + f.pixel_format = d->fb1_nv12.drm_format;
> > > + f.flags = LOCAL_DRM_MODE_FB_MODIFIERS;
> > > + f.handles[0] = d->fb1_nv12.gem_handle;
> > > + f.pitches[0] = d->fb1_nv12.stride;
> > > + f.modifier[0] = LOCAL_I915_FORMAT_MOD_Yf_TILED;
> > > + f.modifier[1] = LOCAL_I915_FORMAT_MOD_Yf_TILED;
> > > +
> > > + /* test invalid uv start */
> > > + f.handles[1] = d->fb1_nv12.gem_handle;
> > > + f.pitches[1] = d->fb1_nv12.stride;
> > > + f.offsets[1] = 0;  /* invalid uv start */
> > > + igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2,
> > &f) != 0);
> > 
> > For such simple invalid input paramaters tests the usual approach is to
> > split them out. Also you don't have to do a modeset for addfb (which will
> > speed things up). Essentially each block with an igt_assert should be its
> > own subtest.
> > -Daniel
> > 
> 
> If each block is split into it's own subtest, if one runs just a subtest 
> and without a modeset, I don't know in which state the system is to start
> the test and doing a modeset will start with a known state.

ADDFB ioctl doesn't need any known modeset state at all, and that seems to
be the only ioctl you do. Which means you really don't need to do a
modeset (it's just overhead). See e.g. the other addfb testcases we have
in kms_addfb_basic.c.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Enable full ppgtt for vgpu

[Daniel Vetter]

On Thu, Aug 27, 2015 at 10:28:49AM +0800, Zhiyuan Lv wrote:
> Hi Danie,
> 
> On Wed, Aug 26, 2015 at 10:47:37AM +0200, Daniel Vetter wrote:
> > On Thu, Aug 20, 2015 at 01:57:13PM +0300, Joonas Lahtinen wrote:
> > > On to, 2015-08-20 at 15:45 +0800, Zhiyuan Lv wrote:
> > > > The full ppgtt is supported in Intel GVT-g device model. So the
> > > > restriction can be removed.
> > > > 
> > > > Signed-off-by: Zhiyuan Lv 
> > > > Signed-off-by: Zhi Wang 
> > > 
> > > Reviewed-by: Joonas Lahtinen 
> > > 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ---
> > > >  1 file changed, 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > > > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > > index ed10e77..823005c 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > > @@ -108,9 +108,6 @@ static int sanitize_enable_ppgtt(struct 
> > > > drm_device *dev, int enable_ppgtt)
> > > > has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
> > > > has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
> > > >  
> > > > -   if (intel_vgpu_active(dev))
> > > > -   has_full_ppgtt = false; /* emulation is too hard */
> > 
> > Don't we need a feature check for the virtual gpu here? Or at least a
> > platform check? Seems like the backwards/forwards compat story isn't too
> > thought out yet here. Note that the kernel of the host and the guest might
> > not be the same at all, much less the kvm part.
> 
> Yeah, backwards/forwards compatibility is not considered, since we are
> just to start the upstream of iGVT-g host changes. Right now if people
> uses new enough iGVT-g code (off-tree now), both HSW and BDW should
> work with PPGTT.
> 
> So new host with both old guest or new guest are working. The only
> thing impacted is old host with new guest kernel. In order to keep it
> work, I can change the code like:
> 
> + if (intel_vgpu_active(dev))
> + has_full_ppgtt = !IS_HASWELL(dev);
> 
> Any comments? Thanks for the review!

In the end that's your call (well until we have users screaming that a
kernel upgrade breaks their xengt setup, then you have to keep backwards
compat). But since it's a requirement from Linus Torvalds for upstream I
highly suggest you start thinking/testing for backwards compat (both on
host and guest side when the other part is older) right away. Otherwise
trying to shoehorn a good backwards compat scheme later on could be really
painful.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Always enable execlists on BDW for vgpu

[Daniel Vetter]

On Thu, Aug 27, 2015 at 10:49:28AM +0800, Zhiyuan Lv wrote:
> Hi Daniel,
> 
> On Wed, Aug 26, 2015 at 10:50:23AM +0200, Daniel Vetter wrote:
> > > > @@ -332,6 +332,12 @@ int i915_gem_context_init(struct drm_device 
> > > > *dev)
> > > > if (WARN_ON(dev_priv->ring[RCS].default_context))
> > > > return 0;
> > > >  
> > > > +   if (intel_vgpu_active(dev)) {
> > > > +   if (WARN_ON(HAS_LOGICAL_RING_CONTEXTS(dev) &&
> > > > +   !i915.enable_execlist))
> > > > +   return 0;
> > > > +   }
> > > > +
> > > 
> > > This looks fine to me. Maybe comment might be in place stating that
> > > support is not yet implemented, but could be.
> > 
> > You should fail this instead so that i915.ko knows that the render side of
> > the gpu doesn't work. And maybe just DRM_INFO with a useful informational
> > notice?
> 
> Thanks for the comments! Will change.
> 
> > 
> > Also same comment here: Don't we need to coordinate this a bit better with
> > the host?
> 
> In host side, if driver is running in ring buffer mode, we will let GVT-g
> initialization fail, so that guest cannot set vgpu active. Would that be good
> enough? Thanks!

Yeah that seems sensible.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset

[Jani Nikula]

On Wed, 02 Sep 2015, libin.y...@intel.com wrote:
> From: Libin Yang 
>
> When modeset occurs and the TMDS frequency is set to some
> speical values, the N/CTS need to be set manually if audio
> is playing.

Do we still need this patch after David Henningsson's series [1]? IIUC
you will now always get the callback on modesets, so you should be able
to, uh, callback on the callback to set audio rate. Granted, with this I
suppose you reduce the time there might be wrong N/CTS after enable.

Some other comments inline.

[1] 
http://mid.gmane.org/1440781350-12053-1-git-send-email-david.hennings...@canonical.com

>
> Signed-off-by: Libin Yang 
> ---
>  drivers/gpu/drm/i915/i915_reg.h|  8 
>  drivers/gpu/drm/i915/intel_audio.c | 40 
> +-
>  2 files changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ae7fa3e..5bdee36 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7058,6 +7058,8 @@ enum skl_disp_power_wells {
>   _HSW_AUD_MISC_CTRL_A, \
>   _HSW_AUD_MISC_CTRL_B)
>  
> +#define HSW_AUD_PIPE_CONN_SEL_CTRL  0x650ac

Nitpick. The bit fields are not defined.

> +
>  #define _HSW_AUD_DIP_ELD_CTRL_ST_A   0x650b4
>  #define _HSW_AUD_DIP_ELD_CTRL_ST_B   0x651b4
>  #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
> @@ -7072,6 +7074,12 @@ enum skl_disp_power_wells {
>   _HSW_AUD_DIG_CNVT_2)
>  #define DIP_PORT_SEL_MASK0x3
>  
> +#define _HSW_AUD_STR_DESC_1  0x65084
> +#define _HSW_AUD_STR_DESC_2  0x65184
> +#define AUD_STR_DESC(pipe)   _PIPE(pipe, \
> +  _HSW_AUD_STR_DESC_1,   \
> +  _HSW_AUD_STR_DESC_2)

Nitpick. The bit fields are not defined. I think it's fine to use _PIPE
macro, but you should probably use "converter" or "cvt" or something for
the parameter name to not mislead people into thinking this is pipe
based.

> +
>  #define _HSW_AUD_EDID_DATA_A 0x65050
>  #define _HSW_AUD_EDID_DATA_B 0x65150
>  #define HSW_AUD_EDID_DATA(pipe) _PIPE(pipe, \
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index a021720..acdb68c 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -140,6 +140,27 @@ static bool audio_rate_need_prog(struct intel_crtc *crtc,
>   return false;
>  }
>  
> +static int audio_config_get_rate(struct drm_i915_private *dev_priv,
> + enum pipe pipe)
> +{
> + uint32_t tmp;
> + int cvt_idx;
> + int base_rate, mul, div, rate;
> +
> + tmp = I915_READ(HSW_AUD_PIPE_CONN_SEL_CTRL);
> + cvt_idx = (tmp >> (pipe * 8)) & 0xff;

This one needs to be addressed. Are you sure it's indexed by pipe? The
spec is vague.

Bits 7:0 are "control B", 15:8 are "control C", and so on, while your
(tmp >> (pipe * 8)) maps pipe A to control B, pipe B to control C,
etc. This would speak for port, not pipe, as pipe A should be valid
while port A not.

> + tmp = I915_READ(AUD_STR_DESC(cvt_idx));
> + base_rate = tmp & (1 << 14);

Nitpick. We prefer (tmp & MASK) >> SHIFT.

> + if (base_rate == 0)
> + rate = 48000;
> + else
> + rate = 44100;
> + mul = (tmp & (0x7 << 11)) + 1;
> + div = (tmp & (0x7 << 8)) + 1;

This one needs to be addressed. This is bogus. The +1 would work if you
actually did (tmp & MASK) >> SHIFT, but now you add it to the shifted
value. Your multipliers and divisors are *way* off.

NAK on this patch.

> + rate = rate * mul / div;
> + return rate;
> +}
> +
>  static bool intel_eld_uptodate(struct drm_connector *connector,
>  int reg_eldv, uint32_t bits_eldv,
>  int reg_elda, uint32_t bits_elda,
> @@ -265,6 +286,8 @@ static void hsw_audio_codec_enable(struct drm_connector 
> *connector,
>   const uint8_t *eld = connector->eld;
>   uint32_t tmp;
>   int len, i;
> + int n_low, n_up, n;
> + int rate;
>  
>   DRM_DEBUG_KMS("Enable audio codec on pipe %c, %u bytes ELD\n",
> pipe_name(pipe), drm_eld_size(eld));
> @@ -302,12 +325,27 @@ static void hsw_audio_codec_enable(struct drm_connector 
> *connector,
>   /* Enable timestamps */
>   tmp = I915_READ(HSW_AUD_CFG(pipe));
>   tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> - tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
>   tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
>   if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
>   tmp |= AUD_CONFIG_N_VALUE_INDEX;
>   else
>   tmp |= audio_config_hdmi_pixel_clock(mode);
> +
> + tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
> + if (audio_rate_need_prog(intel_crtc, mode)) {
> + rate = audio_c

Re: [Intel-gfx] About the iGVT-g's requirement to pin guest contexts in VM

[Daniel Vetter]

On Thu, Aug 27, 2015 at 09:50:03AM +0800, Zhiyuan Lv wrote:
> Hi Daniel,
> 
> On Wed, Aug 26, 2015 at 10:56:00AM +0200, Daniel Vetter wrote:
> > On Tue, Aug 25, 2015 at 08:17:05AM +0800, Zhiyuan Lv wrote:
> > > Hi Chris,
> > > 
> > > On Mon, Aug 24, 2015 at 11:23:13AM +0100, Chris Wilson wrote:
> > > > On Mon, Aug 24, 2015 at 06:04:28PM +0800, Zhiyuan Lv wrote:
> > > > > Hi Chris,
> > > > > 
> > > > > On Thu, Aug 20, 2015 at 09:36:00AM +0100, Chris Wilson wrote:
> > > > > > On Thu, Aug 20, 2015 at 03:45:21PM +0800, Zhiyuan Lv wrote:
> > > > > > > Intel GVT-g will perform EXECLIST context shadowing and ring 
> > > > > > > buffer
> > > > > > > shadowing. The shadow copy is created when guest creates a 
> > > > > > > context.
> > > > > > > If a context changes its LRCA address, the hypervisor is hard to 
> > > > > > > know
> > > > > > > whether it is a new context or not. We always pin context objects 
> > > > > > > to
> > > > > > > global GTT to make life easier.
> > > > > > 
> > > > > > Nak. Please explain why we need to workaround a bug in the host. We
> > > > > > cannot pin the context as that breaks userspace (e.g. synmark) who 
> > > > > > can
> > > > > > and will try to use more contexts than we have room.
> > > > > 
> > > > > Could you have a look at below reasons and kindly give us your inputs?
> > > > > 
> > > > > 1, Due to the GGTT partitioning, the global graphics memory available
> > > > > inside virtual machines is much smaller than native case. We cannot
> > > > > support some graphics memory intensive workloads anyway. So it looks
> > > > > affordable to just pin contexts which do not take much GGTT.
> > > > 
> > > > Wrong. It exposes the guest to a trivial denial-of-service attack. A
> > > 
> > > Inside a VM, indeed.
> > > 
> > > > smaller GGTT does not actually limit clients (there is greater aperture
> > > > pressure and some paths are less likely but an individual client will
> > > > function just fine).
> > > >  
> > > > > 2, Our hypervisor needs to change i915 guest context in the shadow
> > > > > context implementation. That part will be tricky if the context is not
> > > > > always pinned. One scenario is that when a context finishes running,
> > > > > we need to copy shadow context, which has been updated by hardware, to
> > > > > guest context. The hypervisor knows context finishing by context
> > > > > interrupt, but that time shrinker may have unpin the context and its
> > > > > backing storage may have been swap-out. Such copy may fail. 
> > > > 
> > > > That is just a bug in your code. Firstly allowing swapout on an object
> > > > you still are using, secondly not being able to swapin.
> > > 
> > > As Zhi replied in another email, we do not have the knowledge of guest
> > > driver's swap operations. If we cannot pin context, we may have to ask
> > > guest driver not to swap out context pages. Do you think that would be
> > > the right way to go? Thanks!
> > 
> > It doesn't matter at all - if the guest unpins the ctx and puts something
> > else in there before the host tells it that the ctx is completed, that's a
> > bug in the guest. Same with real hw, we guarantee that the context stays
> > around for long enough.
> 
> You are right. Previously I did not realize that shrinker will check
> not only the seqno, but also "ACTIVE_TO_IDLE" context interrupt for
> unpinning a context, then had above concern. Thanks for the
> explanation!
> 
> > 
> > Also you obviously have to complete the copying from shadow->guest ctx
> > before you send the irq to the guest to signal ctx completion. Which means
> > there's really no overall problem here from a design pov, the only thing
> 
> Right. We cannot control when guest driver sees seqno change, but we
> can control when guest sees context interrupts. The guest CSB update
> and interrupt injection will be after we finish writing guest
> contexts.
> 
> So right now we have two options of context shadowing: one is to track
> the whole life-cycle of guest context, and another is to do the shadow
> work in context schedule-in/schedule-out time. Zhi draws a nice
> picture of them.
> 
> Currently we do not have concrete performance comparison of the two
> approaches. We will have a try and see. And about this patchset, I
> will remove the "context notification" part and send out an updated
> version. Thanks!
> 
> > you have to do is fix up bugs in the host code (probably you should just
> > write through the ggtt).
> 
> Sorry could you elaborate a little more about this? Guest context may
> not always be in aperture right?

Yeah the high-level problem is that global gtt is contended (we already
have trouble with that on xengt and there's the ongoing but unfished
partial mmap support for that). And permanently pinning execlist contexts
will cause lots of troubles.

Windows can do this because it segments the global gtt into different
parts (at least last time I looked at their memory manager), which means
execlist will never sit in the middle of the 

Re: [Intel-gfx] [PATCH v6 2/4] drm/i915: implement sync_audio_rate callback

[Yang, Libin]

Hi Jani,

> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Wednesday, September 02, 2015 3:52 PM
> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> ville.syrj...@linux.intel.com
> Cc: Yang, Libin
> Subject: Re: [PATCH v6 2/4] drm/i915: implement sync_audio_rate
> callback
> 
> On Wed, 02 Sep 2015, libin.y...@intel.com wrote:
> > From: Libin Yang 
> >
> > HDMI audio may not work at some frequencies
> > with the HW provided N/CTS.
> >
> > This patch sets the proper N value for the
> > given audio sample rate at the impacted frequencies.
> > At other frequencies, it will use the N/CTS value
> > which HW provides.
> >
> > Signed-off-by: Libin Yang 
> 
> Okay, so there are a number of questions and comments this patch still
> raises. Please find them inline.
> 
> *However*, we should really get this finally moving forward, and I
> don't
> think the issues are or need to be blockers, so this is
> 
> Reviewed-by: Jani Nikula 
> 
> I think we (as in i915 folks) can clean the rest of the bikeshedding up,
> and I don't think we should be NAKing this ad infinitum to teach you to
> become an i915 developer... unless you want to be one. ;)
> 
> > ---
> >  drivers/gpu/drm/i915/i915_dma.c|   1 +
> >  drivers/gpu/drm/i915/i915_drv.h|   5 ++
> >  drivers/gpu/drm/i915/intel_audio.c | 138
> +
> >  3 files changed, 144 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> b/drivers/gpu/drm/i915/i915_dma.c
> > index 097d4ba..8ffb5dc 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -858,6 +858,7 @@ int i915_driver_load(struct drm_device *dev,
> unsigned long flags)
> > mutex_init(&dev_priv->sb_lock);
> > mutex_init(&dev_priv->modeset_restore_lock);
> > mutex_init(&dev_priv->csr_lock);
> > +   mutex_init(&dev_priv->av_mutex);
> >
> > intel_pm_setup(dev);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> > index 05ffd5a..2c6b76f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1882,6 +1882,11 @@ struct drm_i915_private {
> >
> > /* hda/i915 audio component */
> > bool audio_component_registered;
> > +   /**
> > +* av_mutex - mutex for audio/video sync
> > +*
> > +*/
> > +   struct mutex av_mutex;
> >
> > uint32_t hw_context_size;
> > struct list_head context_list;
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> > index dc32cf4..a021720 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -68,6 +68,31 @@ static const struct {
> > { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> >  };
> >
> > +/* HDMI N/CTS table */
> > +#define TMDS_297M 297000
> > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
> > +static const struct {
> > +   int sample_rate;
> > +   int clock;
> > +   int n;
> > +   int cts;
> > +} aud_ncts[] = {
> > +   { 44100, TMDS_296M, 4459, 234375 },
> > +   { 44100, TMDS_297M, 4704, 247500 },
> > +   { 48000, TMDS_296M, 5824, 281250 },
> > +   { 48000, TMDS_297M, 5120, 247500 },
> > +   { 32000, TMDS_296M, 5824, 421875 },
> > +   { 32000, TMDS_297M, 3072, 222750 },
> > +   { 88200, TMDS_296M, 8918, 234375 },
> > +   { 88200, TMDS_297M, 9408, 247500 },
> > +   { 96000, TMDS_296M, 11648, 281250 },
> > +   { 96000, TMDS_297M, 10240, 247500 },
> > +   { 176400, TMDS_296M, 17836, 234375 },
> > +   { 176400, TMDS_297M, 18816, 247500 },
> > +   { 192000, TMDS_296M, 23296, 281250 },
> > +   { 192000, TMDS_297M, 20480, 247500 },
> > +};
> 
> Okay, I admit, I did not look these up in the spec. *blush*. I'm sure
> Ville has/will. ;)
> 
> > +
> >  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> >  static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode
> *mode)
> >  {
> > @@ -90,6 +115,31 @@ static u32
> audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
> > return hdmi_audio_clock[i].config;
> >  }
> >
> > +static int audio_config_get_n(const struct drm_display_mode
> *mode, int rate)
> > +{
> > +   int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
> > +   if ((rate == aud_ncts[i].sample_rate) &&
> > +   (mode->clock == aud_ncts[i].clock)) {
> > +   return aud_ncts[i].n;
> > +   }
> > +   }
> > +   return 0;
> > +}
> > +
> > +/* check whether N/CTS/M need be set manually */
> > +static bool audio_rate_need_prog(struct intel_crtc *crtc,
> > +   struct drm_display_mode
> *mode)
> > +{
> > +   if (((mode->clock == TMDS_297M) ||
> > +(mode->clock == TMDS_296M)) &&
> > +   intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))
> > +   return true;
> > +   else
> > +   return false;
> > +}
> > +
> >  static bool intel_eld_u

Re: [Intel-gfx] [PATCH] drm/i915: Enabling RC6 immediately during init/resume

[Daniel Vetter]

On Mon, Aug 31, 2015 at 05:08:36PM +0530, Salonie, Namrta wrote:
> Hi Chris, Daniel.
> 
> Thanks for your inputs.
> I agree that we need to amend the patch. Will do following changes.
> 1.RPM ref count is not needed with immediate enabling of RC6, I will 
> remove
> that.
> 2.I will extend this to other GEN as well.
> 
> This was one of the set of optimization we implemented for BYT Android. All
> of these
> gave improvement of ~5mW for 30minutes for Active Idle WLAN KPI. And about
> ~5mW for other airplane, wifi, radio suspend scenarios.
> 
> The other optimizations included :-
> 1.Reduction of autosuspend delay to 500ms from 10ms (On BYT, display D3

I guess you meant 10 s runtime pm autosuspend default?

> should happen in suspend as Punit initiates S0iX flow only considering
> Display D3). Because of this reduction Display D3 will happen immediately:
> This can be controlled by user mode in android. However shall we bring this
> value for Linux as well?

I have a patch for that (including enabling runtime pm by default), but
it's blocked because atm runtime pm is broken in upstream.

> 2.Deferring RC6 disabling from early_resume callback to resume callback to
> reduce the delay for which the wells had to stay ON – We verified the HDMI
> case and it worked without issues.

I think the big trouble there is that right now we don't handle power well
references correctly in the suspend/resume code at all - we just
force-enable them all. Definitely something we want to fix, but will be a
lot of work to make sure it works everywhere. I'd like to see an overall
approach to this though since I fear if we just move around individual
rpm references (like rc6 or specific power wells) the end-result will be a
really complicated and fragile design. Suspend/resume is already one of
the most fragile parts of the driver as-is.

> 3.During resume, perform modeset based on the DPMS state, so that Display
> remains Off for the intermediate wake ups where no DPMS ON/OFF happens.

That /should/ be how it's supposed to work. I.e. for dpms off, we should
not try to enable things again. Might have been broken, but with latest
atomic it really should work correctly.

> Also, can we port the optimizations 2 & 3 to the upstream kernel?

Sure, sounds like some good. Usual caveat applies though since upstream
needs to work everywhere, so probably some more work is needed to make
sure the patches don't break anything.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Daniel Vetter]

On Wed, Sep 02, 2015 at 10:03:55AM +0200, Takashi Iwai wrote:
> On Wed, 02 Sep 2015 10:00:44 +0200,
> Daniel Vetter wrote:
> > 
> > On Fri, Aug 28, 2015 at 04:10:36PM +0300, Jani Nikula wrote:
> > > On Thu, 20 Aug 2015, Takashi Iwai  wrote:
> > > > On Thu, 20 Aug 2015 11:41:42 +0200,
> > > > David Henningsson wrote:
> > > >> 
> > > >> 
> > > >> 
> > > >> On 2015-08-20 11:28, Takashi Iwai wrote:
> > > >> > On Wed, 19 Aug 2015 10:48:58 +0200,
> > > >> > David Henningsson wrote:
> > > >> >>
> > > >> >> Whenever there is an event from the i915 driver, wake the codec
> > > >> >> and recheck plug/unplug + ELD status.
> > > >> >>
> > > >> >> This fixes the issue with lost unsol events in power save mode,
> > > >> >> the codec and controller can now sleep in D3 and still know when
> > > >> >> the HDMI monitor has been connected.
> > > >> >>
> > > >> >> Signed-off-by: David Henningsson 
> > > >> >
> > > >> > This addition looks fine, but then we'll get double notification for
> > > >> > the normal hotplug/unplug, one via component ops and another via 
> > > >> > unsol
> > > >> > event?
> > > >> 
> > > >> Right, in case the unsol event actually works...
> > > >> 
> > > >> I would argue that the normal case would be that the controller and 
> > > >> codec is in D3 which means that the unsol event never gets through - 
> > > >> due 
> > > >> to hw limitations - which is what triggered this patch set in the 
> > > >> first 
> > > >> place.
> > > >> 
> > > >> But yes, in some case we might get double notification, but this 
> > > >> should 
> > > >> not cause any trouble in practice. The unsol event could be turned 
> > > >> off, 
> > > >> but would it be okay to save that for a later patch set (so I don't 
> > > >> miss 
> > > >> the upcoming merge window)?
> > > >
> > > > In that case, it should be mentioned in the changelog at least.
> > > >
> > > > This series came a bit too late for the merge window, so I'm not sure
> > > > whether this can get in.  I personally find it OK, so take my ack for
> > > > ALSA parts (patch 3/4), but the rest need review and ack from i915
> > > > guys.  And we don't know who to merge this, if any.  The changes are
> > > > almost even to i915 and hda.  I don't mind either way, via drm or
> > > > sound tree.
> > > 
> > > Personally I'm fine with this still going for v4.3 since to me it looks
> > > like any regressions this might cause will be on your side. *grin*.
> > 
> > The only bit I want is some decent kerneldoc for the ad-hoc growing
> > i915/hda-intel interfaces. But that can be done in follow-up patches and
> > needs to be coordinated with the audio rate handling series anyway. So ack
> > from my side for all getting merged through alsa trees too.
> 
> Are you going to merge Libin's patchset?  If yes, it's better to align
> both patchsets through a single tree.  It'll make merges easier, as
> both touch the similar place.

Oh that was an ack for merging it all through your tree. If you punt it to
4.4 I might ask you for a stable tree to pull in in case I get conflicts.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 2/4] drm/i915: implement sync_audio_rate callback

[Jani Nikula]

On Wed, 02 Sep 2015, "Yang, Libin"  wrote:
> Hi Jani,
>
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Wednesday, September 02, 2015 3:52 PM
>> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
>> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
>> ville.syrj...@linux.intel.com
>> Cc: Yang, Libin
>> Subject: Re: [PATCH v6 2/4] drm/i915: implement sync_audio_rate
>> callback
>> 
>> On Wed, 02 Sep 2015, libin.y...@intel.com wrote:
>> > From: Libin Yang 
>> >
>> > HDMI audio may not work at some frequencies
>> > with the HW provided N/CTS.
>> >
>> > This patch sets the proper N value for the
>> > given audio sample rate at the impacted frequencies.
>> > At other frequencies, it will use the N/CTS value
>> > which HW provides.
>> >
>> > Signed-off-by: Libin Yang 
>> 
>> Okay, so there are a number of questions and comments this patch still
>> raises. Please find them inline.
>> 
>> *However*, we should really get this finally moving forward, and I
>> don't
>> think the issues are or need to be blockers, so this is
>> 
>> Reviewed-by: Jani Nikula 
>> 
>> I think we (as in i915 folks) can clean the rest of the bikeshedding up,
>> and I don't think we should be NAKing this ad infinitum to teach you to
>> become an i915 developer... unless you want to be one. ;)

Libin, I suggest taking that R-b now instead of writing a new version of
this patch if you want to get things upstreamed!

Please focus on patch 4.

BR,
Jani.


>> 
>> > ---
>> >  drivers/gpu/drm/i915/i915_dma.c|   1 +
>> >  drivers/gpu/drm/i915/i915_drv.h|   5 ++
>> >  drivers/gpu/drm/i915/intel_audio.c | 138
>> +
>> >  3 files changed, 144 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> > index 097d4ba..8ffb5dc 100644
>> > --- a/drivers/gpu/drm/i915/i915_dma.c
>> > +++ b/drivers/gpu/drm/i915/i915_dma.c
>> > @@ -858,6 +858,7 @@ int i915_driver_load(struct drm_device *dev,
>> unsigned long flags)
>> >mutex_init(&dev_priv->sb_lock);
>> >mutex_init(&dev_priv->modeset_restore_lock);
>> >mutex_init(&dev_priv->csr_lock);
>> > +  mutex_init(&dev_priv->av_mutex);
>> >
>> >intel_pm_setup(dev);
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> > index 05ffd5a..2c6b76f 100644
>> > --- a/drivers/gpu/drm/i915/i915_drv.h
>> > +++ b/drivers/gpu/drm/i915/i915_drv.h
>> > @@ -1882,6 +1882,11 @@ struct drm_i915_private {
>> >
>> >/* hda/i915 audio component */
>> >bool audio_component_registered;
>> > +  /**
>> > +   * av_mutex - mutex for audio/video sync
>> > +   *
>> > +   */
>> > +  struct mutex av_mutex;
>> >
>> >uint32_t hw_context_size;
>> >struct list_head context_list;
>> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> b/drivers/gpu/drm/i915/intel_audio.c
>> > index dc32cf4..a021720 100644
>> > --- a/drivers/gpu/drm/i915/intel_audio.c
>> > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> > @@ -68,6 +68,31 @@ static const struct {
>> >{ 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
>> >  };
>> >
>> > +/* HDMI N/CTS table */
>> > +#define TMDS_297M 297000
>> > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
>> > +static const struct {
>> > +  int sample_rate;
>> > +  int clock;
>> > +  int n;
>> > +  int cts;
>> > +} aud_ncts[] = {
>> > +  { 44100, TMDS_296M, 4459, 234375 },
>> > +  { 44100, TMDS_297M, 4704, 247500 },
>> > +  { 48000, TMDS_296M, 5824, 281250 },
>> > +  { 48000, TMDS_297M, 5120, 247500 },
>> > +  { 32000, TMDS_296M, 5824, 421875 },
>> > +  { 32000, TMDS_297M, 3072, 222750 },
>> > +  { 88200, TMDS_296M, 8918, 234375 },
>> > +  { 88200, TMDS_297M, 9408, 247500 },
>> > +  { 96000, TMDS_296M, 11648, 281250 },
>> > +  { 96000, TMDS_297M, 10240, 247500 },
>> > +  { 176400, TMDS_296M, 17836, 234375 },
>> > +  { 176400, TMDS_297M, 18816, 247500 },
>> > +  { 192000, TMDS_296M, 23296, 281250 },
>> > +  { 192000, TMDS_297M, 20480, 247500 },
>> > +};
>> 
>> Okay, I admit, I did not look these up in the spec. *blush*. I'm sure
>> Ville has/will. ;)
>> 
>> > +
>> >  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
>> >  static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode
>> *mode)
>> >  {
>> > @@ -90,6 +115,31 @@ static u32
>> audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
>> >return hdmi_audio_clock[i].config;
>> >  }
>> >
>> > +static int audio_config_get_n(const struct drm_display_mode
>> *mode, int rate)
>> > +{
>> > +  int i;
>> > +
>> > +  for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
>> > +  if ((rate == aud_ncts[i].sample_rate) &&
>> > +  (mode->clock == aud_ncts[i].clock)) {
>> > +  return aud_ncts[i].n;
>> > +  }
>> > +  }
>> > +  return 0;
>> > +}
>> > +
>> > +/* check whether N/CTS/M need be set manually */
>> > +static bool audio_rate_need_prog(struct intel_crtc *crtc,
>> > +  str

[Intel-gfx] [PATCH 2/2] drm/i915: Make plane fb tracking work correctly.

[Maarten Lankhorst]

atomic->disabled_planes is a hack that had to exist because
prepare_fb was only called when a new fb was set. This messed
up fb tracking in some circumstances like aborts from
interruptible waits. As a result interruptible waiting in
prepare_plane_fb was forbidden, but other errors could still
cause frontbuffer tracking to be messed up.

Now that prepare_fb is always called, this hack is no longer
required and prepare_fb may fail without consequences.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 47 ++--
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 2 files changed, 18 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index edcf8746440e..6ebc7661ec8c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4718,17 +4718,6 @@ static void intel_pre_plane_update(struct intel_crtc 
*crtc)
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
-   struct drm_plane *p;
-
-   /* Track fb's for any planes being disabled */
-   drm_for_each_plane_mask(p, dev, atomic->disabled_planes) {
-   struct intel_plane *plane = to_intel_plane(p);
-
-   mutex_lock(&dev->struct_mutex);
-   i915_gem_track_fb(intel_fb_obj(plane->base.fb), NULL,
- plane->frontbuffer_bit);
-   mutex_unlock(&dev->struct_mutex);
-   }
 
if (atomic->wait_for_flips)
intel_crtc_wait_for_pending_flips(&crtc->base);
@@ -11511,14 +11500,6 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
return ret;
}
 
-   /*
-* Disabling a plane is always okay; we just need to update
-* fb tracking in a special way since cleanup_fb() won't
-* get called by the plane helpers.
-*/
-   if (old_plane_state->base.fb && !fb)
-   intel_crtc->atomic.disabled_planes |= 1 << i;
-
was_visible = old_plane_state->visible;
visible = to_intel_plane_state(plane_state)->visible;
 
@@ -13272,15 +13253,17 @@ intel_prepare_plane_fb(struct drm_plane *plane,
struct drm_framebuffer *fb = new_state->fb;
struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
-   struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
+   struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
int ret = 0;
 
-   if (!obj)
+   if (!obj && !old_obj)
return 0;
 
mutex_lock(&dev->struct_mutex);
 
-   if (plane->type == DRM_PLANE_TYPE_CURSOR &&
+   if (!obj) {
+   ret = 0;
+   } else if (plane->type == DRM_PLANE_TYPE_CURSOR &&
INTEL_INFO(dev)->cursor_needs_physical) {
int align = IS_I830(dev) ? 16 * 1024 : 256;
ret = i915_gem_object_attach_phys(obj, align);
@@ -13310,17 +13293,23 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
   const struct drm_plane_state *old_state)
 {
struct drm_device *dev = plane->dev;
-   struct drm_i915_gem_object *obj = intel_fb_obj(old_state->fb);
+   struct intel_plane *intel_plane = to_intel_plane(plane);
+   struct drm_i915_gem_object *old_obj = intel_fb_obj(old_state->fb);
+   struct drm_i915_gem_object *obj = intel_fb_obj(plane->fb);
 
-   if (!obj)
+   if (!obj && !old_obj)
return;
 
-   if (plane->type != DRM_PLANE_TYPE_CURSOR ||
-   !INTEL_INFO(dev)->cursor_needs_physical) {
-   mutex_lock(&dev->struct_mutex);
+   mutex_lock(&dev->struct_mutex);
+   if (old_obj && (plane->type != DRM_PLANE_TYPE_CURSOR ||
+   !INTEL_INFO(dev)->cursor_needs_physical))
intel_unpin_fb_obj(old_state->fb, old_state);
-   mutex_unlock(&dev->struct_mutex);
-   }
+
+   /* prepare_fb aborted? */
+   if ((old_obj && (old_obj->frontbuffer_bits & 
intel_plane->frontbuffer_bit)) ||
+   (obj && !(obj->frontbuffer_bits & intel_plane->frontbuffer_bit)))
+   i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
+   mutex_unlock(&dev->struct_mutex);
 }
 
 int
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 104a7f8b650d..176f0a15e41b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -505,7 +505,6 @@ struct intel_crtc_atomic_commit {
bool disable_cxsr;
bool pre_disable_primary;
bool update_wm_pre, update_wm_post;
-   unsigned disabled_planes;
 
/* Sleepable operations to perform after commit */
unsigned fb_bits;
-- 
2.1.0

___
Intel-g

[Intel-gfx] [PATCH 1/2] drm/atomic: Make prepare_fb/cleanup_fb only take state, v3.

[Maarten Lankhorst]

This removes the need to separately track fb changes i915.
That will be done as a separate commit, however.

Changes since v1:
- Add dri-devel to cc.
- Fix a check in intel's prepare and cleanup fb to take rotation
  into account.
Changes since v2:
- Split out i915 changes to a separate commit.

Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 +++-
 drivers/gpu/drm/drm_atomic_helper.c | 21 ++---
 drivers/gpu/drm/drm_plane_helper.c  |  6 +++---
 drivers/gpu/drm/i915/intel_display.c|  9 -
 drivers/gpu/drm/i915/intel_drv.h|  2 --
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   | 10 --
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  9 -
 drivers/gpu/drm/omapdrm/omap_plane.c| 10 ++
 drivers/gpu/drm/tegra/dc.c  |  2 --
 include/drm/drm_plane_helper.h  |  2 --
 10 files changed, 38 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index be9fa8220499..36fda86b3518 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -712,11 +712,13 @@ static int atmel_hlcdc_plane_atomic_check(struct 
drm_plane *p,
 }
 
 static int atmel_hlcdc_plane_prepare_fb(struct drm_plane *p,
-   struct drm_framebuffer *fb,
const struct drm_plane_state *new_state)
 {
struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
 
+   if (!new_state->fb)
+   return 0;
+
return atmel_hlcdc_layer_update_start(&plane->layer);
 }
 
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index a2629ee133ba..9b0c47690ae8 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -,17 +,14 @@ int drm_atomic_helper_prepare_planes(struct drm_device 
*dev,
const struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
struct drm_plane_state *plane_state = state->plane_states[i];
-   struct drm_framebuffer *fb;
 
if (!plane)
continue;
 
funcs = plane->helper_private;
 
-   fb = plane_state->fb;
-
-   if (fb && funcs->prepare_fb) {
-   ret = funcs->prepare_fb(plane, fb, plane_state);
+   if (funcs->prepare_fb) {
+   ret = funcs->prepare_fb(plane, plane_state);
if (ret)
goto fail;
}
@@ -1134,17 +1131,14 @@ fail:
const struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
struct drm_plane_state *plane_state = state->plane_states[i];
-   struct drm_framebuffer *fb;
 
if (!plane)
continue;
 
funcs = plane->helper_private;
 
-   fb = state->plane_states[i]->fb;
-
-   if (fb && funcs->cleanup_fb)
-   funcs->cleanup_fb(plane, fb, plane_state);
+   if (funcs->cleanup_fb)
+   funcs->cleanup_fb(plane, plane_state);
 
}
 
@@ -1300,14 +1294,11 @@ void drm_atomic_helper_cleanup_planes(struct drm_device 
*dev,
 
for_each_plane_in_state(old_state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
-   struct drm_framebuffer *old_fb;
 
funcs = plane->helper_private;
 
-   old_fb = plane_state->fb;
-
-   if (old_fb && funcs->cleanup_fb)
-   funcs->cleanup_fb(plane, old_fb, plane_state);
+   if (funcs->cleanup_fb)
+   funcs->cleanup_fb(plane, plane_state);
}
 }
 EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 5e5a07af02c8..d384ebcf0aaf 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -426,7 +426,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
 
if (plane_funcs->prepare_fb && plane_state->fb &&
plane_state->fb != old_fb) {
-   ret = plane_funcs->prepare_fb(plane, plane_state->fb,
+   ret = plane_funcs->prepare_fb(plane,
  plane_state);
if (ret)
goto out;
@@ -479,8 +479,8 @@ int drm_plane_helper_commit(struct drm_plane *plane,
ret = 0;
}
 
-   if (plane_funcs->cleanup_fb && old_fb)
-   plane_funcs->cleanup_fb(plane, old_fb, plane_state);
+ 

Re: [Intel-gfx] [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset

[Yang, Libin]

Hi Jani,

> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Wednesday, September 02, 2015 4:20 PM
> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> ville.syrj...@linux.intel.com
> Cc: Yang, Libin
> Subject: Re: [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset
> 
> On Wed, 02 Sep 2015, libin.y...@intel.com wrote:
> > From: Libin Yang 
> >
> > When modeset occurs and the TMDS frequency is set to some
> > speical values, the N/CTS need to be set manually if audio
> > is playing.
> 
> Do we still need this patch after David Henningsson's series [1]? IIUC
> you will now always get the callback on modesets, so you should be
> able
> to, uh, callback on the callback to set audio rate. Granted, with this I
> suppose you reduce the time there might be wrong N/CTS after enable.

Yes, we need. David's patch will not trigger the sync_audio_rate
callback.

> 
> Some other comments inline.
> 
> [1] http://mid.gmane.org/1440781350-12053-1-git-send-email-
> david.hennings...@canonical.com
> 
> >
> > Signed-off-by: Libin Yang 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h|  8 
> >  drivers/gpu/drm/i915/intel_audio.c | 40
> +-
> >  2 files changed, 47 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> > index ae7fa3e..5bdee36 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7058,6 +7058,8 @@ enum skl_disp_power_wells {
> > _HSW_AUD_MISC_CTRL_A, \
> > _HSW_AUD_MISC_CTRL_B)
> >
> > +#define HSW_AUD_PIPE_CONN_SEL_CTRL  0x650ac
> 
> Nitpick. The bit fields are not defined.

OK, I will add the bit definition. 

> 
> > +
> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
> >  #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
> > @@ -7072,6 +7074,12 @@ enum skl_disp_power_wells {
> > _HSW_AUD_DIG_CNVT_2)
> >  #define DIP_PORT_SEL_MASK  0x3
> >
> > +#define _HSW_AUD_STR_DESC_10x65084
> > +#define _HSW_AUD_STR_DESC_20x65184
> > +#define AUD_STR_DESC(pipe) _PIPE(pipe, \
> > +_HSW_AUD_STR_DESC_1,
>   \
> > +_HSW_AUD_STR_DESC_2)
> 
> Nitpick. The bit fields are not defined. I think it's fine to use _PIPE
> macro, but you should probably use "converter" or "cvt" or something
> for
> the parameter name to not mislead people into thinking this is pipe
> based.

Do you mean it should be like:
_PIPE(cvt, _HSW_AUD_STR_DESC_1, ...) ?

> 
> > +
> >  #define _HSW_AUD_EDID_DATA_A   0x65050
> >  #define _HSW_AUD_EDID_DATA_B   0x65150
> >  #define HSW_AUD_EDID_DATA(pipe) _PIPE(pipe, \
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> > index a021720..acdb68c 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -140,6 +140,27 @@ static bool audio_rate_need_prog(struct
> intel_crtc *crtc,
> > return false;
> >  }
> >
> > +static int audio_config_get_rate(struct drm_i915_private *dev_priv,
> > +   enum pipe pipe)
> > +{
> > +   uint32_t tmp;
> > +   int cvt_idx;
> > +   int base_rate, mul, div, rate;
> > +
> > +   tmp = I915_READ(HSW_AUD_PIPE_CONN_SEL_CTRL);
> > +   cvt_idx = (tmp >> (pipe * 8)) & 0xff;
> 
> This one needs to be addressed. Are you sure it's indexed by pipe? The
> spec is vague.

Yes, I did lot of test to confirm it.

> 
> Bits 7:0 are "control B", 15:8 are "control C", and so on, while your
> (tmp >> (pipe * 8)) maps pipe A to control B, pipe B to control C,
> etc. This would speak for port, not pipe, as pipe A should be valid
> while port A not.

We found there is something wrong/or vague in the spec.

> 
> > +   tmp = I915_READ(AUD_STR_DESC(cvt_idx));
> > +   base_rate = tmp & (1 << 14);
> 
> Nitpick. We prefer (tmp & MASK) >> SHIFT.

OK, I will change it.

> 
> > +   if (base_rate == 0)
> > +   rate = 48000;
> > +   else
> > +   rate = 44100;
> > +   mul = (tmp & (0x7 << 11)) + 1;
> > +   div = (tmp & (0x7 << 8)) + 1;
> 
> This one needs to be addressed. This is bogus. The +1 would work if
> you
> actually did (tmp & MASK) >> SHIFT, but now you add it to the shifted
> value. Your multipliers and divisors are *way* off.

OK, I will check it and change the patch.
> 
> NAK on this patch.
> 
> > +   rate = rate * mul / div;
> > +   return rate;
> > +}
> > +
> >  static bool intel_eld_uptodate(struct drm_connector *connector,
> >int reg_eldv, uint32_t bits_eldv,
> >int reg_elda, uint32_t bits_elda,
> > @@ -265,6 +286,8 @@ static void hsw_audio_codec_e

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Retry for live status

[Daniel Vetter]

On Thu, Aug 27, 2015 at 02:46:26PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
> 
> On 8/26/2015 8:47 PM, Daniel Vetter wrote:
> >On Wed, Aug 26, 2015 at 10:05:00AM +, Jindal, Sonika wrote:
> >>HPD bits control the interrupt but the live status (with some monitors) 
> >>takes time to get set.
> >>We had experienced this with VLV and CHV with few monitors.
> >>So Android code always has this retry for live status.
> >>
> >>Yes, this was not added in the previous series because we planned to add 
> >>the next set of optimization a little while later.
> >>But this seems to be an important one.
> >>
> >>It will be great if you can try it with your ivb. But for that you would 
> >>need to first change the gen check and add a call to check live status for 
> >>ivb.
> >
> >Done (well I just quickly hacked up the same idea on top of your old
> >patches). Lessons to be learned from this:
> >- Make sure that you really include _all_ the bugfixes. This pach here
> >   isn't just tuning, it's crucial to make it work. And this isn't the
> >   first time vpg teams upstream something and later on we notice that
> >   important bugfixes have been forgotten.
> >
> >   Because this wasn't done both you & me wasted a lot of time arguing
> >   about these patches and trying to test them.
> >
> Agree. We thought once the basic optimization goes in, we will add this as
> fine tuning patch. We were afraid of you guys doubting this approach at
> first itself. It looks like a little hack, but the HW itself is screwed up
> like this, to deal with.

Reality always wins, even if it looks really broken at first. The
important bit in those cases is to justify the change with a really good
commit message to make it clear what exactly is going on and why this
change is the correct fix/work-around.

> >- Please squash this patch in with patch 3 since otherwise we have a
> >   regression. Also please try to dig out why exactly this works like this
> >   since the hpd irq happening _before_ hpd status settles sounds to me
> >   like we have a little time machine in our silicon which can predict the
> >   future ...
> >
> Actually this depends on the monitor also. Few monitors are slow to assert
> the HPD line, or sometimes they don't provide the right voltage on that,
> causing live status to fluctuate for a while. While VLV/CHV beta testing we
> have done this experiment with a big range of monitors, and concluded that
> 30ms(retry of 10ms * 3) is the optimized time where most of the monitors
> respond well.
> 
> We saw that we cant delay further, because HDCP compliance expects us to
> respond to HPD (out) with in 100ms. So after careful testing with many
> monitors, we have concluded this range.

So what's happening on the wire is
   
  /
^  /\/
   / \/\  /  \/\/  <- hpd threshold
--/\--/ \/

^ first early hpd causing irq
   ^ hpd status stable

If that's what's going on then yeah your patch makes a lot of sense, since
it perfectly explains why we've seen this on all platforms. Have you
confirmed this with oscilloscopes and all that? Please add all that
information (including pretty ascii graphs pls) to the commit message to
make sure we really have this documented correctly.
  
> >- Please respin the patch series with the IS_VLV || gen >= 8 checks drop,
> >   I'm fairly confident that this bugfix here is the bit we've been looking
> >   for since years. At least it would be good to retest on all platforms
> >   for maximal test coverage.
> >
> Sure. Will do that.

Awesome, really looking forward to finally settling this after years!

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

Re: [Intel-gfx] [PATCH v6 2/4] drm/i915: implement sync_audio_rate callback

[Yang, Libin]

Hi Jani,



> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Wednesday, September 02, 2015 4:42 PM
> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> ville.syrj...@linux.intel.com
> Subject: RE: [PATCH v6 2/4] drm/i915: implement sync_audio_rate
> callback
> 
> On Wed, 02 Sep 2015, "Yang, Libin"  wrote:
> > Hi Jani,
> >
> >> -Original Message-
> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> >> Sent: Wednesday, September 02, 2015 3:52 PM
> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
> >> ville.syrj...@linux.intel.com
> >> Cc: Yang, Libin
> >> Subject: Re: [PATCH v6 2/4] drm/i915: implement sync_audio_rate
> >> callback
> >>
> >> On Wed, 02 Sep 2015, libin.y...@intel.com wrote:
> >> > From: Libin Yang 
> >> >
> >> > HDMI audio may not work at some frequencies
> >> > with the HW provided N/CTS.
> >> >
> >> > This patch sets the proper N value for the
> >> > given audio sample rate at the impacted frequencies.
> >> > At other frequencies, it will use the N/CTS value
> >> > which HW provides.
> >> >
> >> > Signed-off-by: Libin Yang 
> >>
> >> Okay, so there are a number of questions and comments this patch
> still
> >> raises. Please find them inline.
> >>
> >> *However*, we should really get this finally moving forward, and I
> >> don't
> >> think the issues are or need to be blockers, so this is
> >>
> >> Reviewed-by: Jani Nikula 
> >>
> >> I think we (as in i915 folks) can clean the rest of the bikeshedding up,
> >> and I don't think we should be NAKing this ad infinitum to teach you
> to
> >> become an i915 developer... unless you want to be one. ;)
> 
> Libin, I suggest taking that R-b now instead of writing a new version of
> this patch if you want to get things upstreamed!
> 
> Please focus on patch 4.

Oh, I didn't realize you mean this. Thanks. :) 

Regards,
Libin
> 
> BR,
> Jani.
> 
> 
> >>
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_dma.c|   1 +
> >> >  drivers/gpu/drm/i915/i915_drv.h|   5 ++
> >> >  drivers/gpu/drm/i915/intel_audio.c | 138
> >> +
> >> >  3 files changed, 144 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> >> b/drivers/gpu/drm/i915/i915_dma.c
> >> > index 097d4ba..8ffb5dc 100644
> >> > --- a/drivers/gpu/drm/i915/i915_dma.c
> >> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> >> > @@ -858,6 +858,7 @@ int i915_driver_load(struct drm_device
> *dev,
> >> unsigned long flags)
> >> >  mutex_init(&dev_priv->sb_lock);
> >> >  mutex_init(&dev_priv->modeset_restore_lock);
> >> >  mutex_init(&dev_priv->csr_lock);
> >> > +mutex_init(&dev_priv->av_mutex);
> >> >
> >> >  intel_pm_setup(dev);
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> > index 05ffd5a..2c6b76f 100644
> >> > --- a/drivers/gpu/drm/i915/i915_drv.h
> >> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> > @@ -1882,6 +1882,11 @@ struct drm_i915_private {
> >> >
> >> >  /* hda/i915 audio component */
> >> >  bool audio_component_registered;
> >> > +/**
> >> > + * av_mutex - mutex for audio/video sync
> >> > + *
> >> > + */
> >> > +struct mutex av_mutex;
> >> >
> >> >  uint32_t hw_context_size;
> >> >  struct list_head context_list;
> >> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> >> b/drivers/gpu/drm/i915/intel_audio.c
> >> > index dc32cf4..a021720 100644
> >> > --- a/drivers/gpu/drm/i915/intel_audio.c
> >> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> >> > @@ -68,6 +68,31 @@ static const struct {
> >> >  { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> >> >  };
> >> >
> >> > +/* HDMI N/CTS table */
> >> > +#define TMDS_297M 297000
> >> > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
> >> > +static const struct {
> >> > +int sample_rate;
> >> > +int clock;
> >> > +int n;
> >> > +int cts;
> >> > +} aud_ncts[] = {
> >> > +{ 44100, TMDS_296M, 4459, 234375 },
> >> > +{ 44100, TMDS_297M, 4704, 247500 },
> >> > +{ 48000, TMDS_296M, 5824, 281250 },
> >> > +{ 48000, TMDS_297M, 5120, 247500 },
> >> > +{ 32000, TMDS_296M, 5824, 421875 },
> >> > +{ 32000, TMDS_297M, 3072, 222750 },
> >> > +{ 88200, TMDS_296M, 8918, 234375 },
> >> > +{ 88200, TMDS_297M, 9408, 247500 },
> >> > +{ 96000, TMDS_296M, 11648, 281250 },
> >> > +{ 96000, TMDS_297M, 10240, 247500 },
> >> > +{ 176400, TMDS_296M, 17836, 234375 },
> >> > +{ 176400, TMDS_297M, 18816, 247500 },
> >> > +{ 192000, TMDS_296M, 23296, 281250 },
> >> > +{ 192000, TMDS_297M, 20480, 247500 },
> >> > +};
> >>
> >> Okay, I admit, I did not look these up in the spec. *blush*. I'm sure
> >> Ville

Re: [Intel-gfx] [DMC_BUGFIX_SKL_V2 1/5] drm/i915/skl: Added a check for the hardware status of csr fw before loading.

[Daniel Vetter]

On Wed, Aug 26, 2015 at 07:40:54PM +0530, Animesh Manna wrote:
> 
> 
> On 8/26/2015 6:40 PM, Daniel Vetter wrote:
> >On Wed, Aug 26, 2015 at 01:36:05AM +0530, Animesh Manna wrote:
> >>Dmc will restore the csr program except DC9, cold boot,
> >>warm reset, PCI function level reset, and hibernate/suspend.
> >>
> >>intel_csr_load_program() function is used to load the firmware
> >>data from kernel memory to csr address space.
> >>
> >>All values of csr address space will be zero if it got reset and
> >>the first byte of csr program is always a non-zero if firmware
> >>is loaded successfuly. Based on hardware status will load the
> >>firmware.
> >>
> >>Without this condition check if we overwrite the firmware data the
> >>counters exposed for dc5/dc6 (help for debugging) will be nullified.
> 
> Bacause of the above reason mentioned just above we need to block firmware 
> loading again.
> So only WARN_ON will not help.
> 
> 
> >>
> >>v1: Initial version.
> >>
> >>v2: Based on review comments from Daniel,
> >>- Added a check to know hardware status and load the firmware if not loaded.
> >>
> >>Cc: Daniel Vetter 
> >>Cc: Damien Lespiau 
> >>Cc: Imre Deak 
> >>Cc: Sunil Kamath 
> >>Signed-off-by: Animesh Manna 
> >>Signed-off-by: Vathsala Nagaraju 
> >>---
> >>  drivers/gpu/drm/i915/intel_csr.c | 9 +
> >>  1 file changed, 9 insertions(+)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> >>b/drivers/gpu/drm/i915/intel_csr.c
> >>index ba1ae03..682cc26 100644
> >>--- a/drivers/gpu/drm/i915/intel_csr.c
> >>+++ b/drivers/gpu/drm/i915/intel_csr.c
> >>@@ -252,6 +252,15 @@ void intel_csr_load_program(struct drm_device *dev)
> >>return;
> >>}
> >>+   /*
> >>+* Dmc will restore the csr the program except DC9, cold boot,
> >>+* warm reset, PCI function level reset, and hibernate/suspend.
> >>+* This condition will help to check if csr address space is reset/
> >>+* not loaded.
> >>+*/
> >Atm we call this from driver load and resume, which doesn seem to cover
> >all the cases you mention in the comment. Should this be a WARN_ON
> >instead? Or do we have troubles in our init sequence where we load too
> >many times?
> 
> Yes, the above statement taken from bspec to describe about the special cases 
> dmc will not restore the firmware.
> Agree, In our cases cold boot and hibernate/suspend mainly we need to load 
> the firmware again, so in my
> second sentence I wanted to comment mainly regarding this condition check 
> added for suspend-hibernate(reset)
> and cold boot(not loaded).
> 
> Anyways the same api later can be used to load the firmware from anywhere, so 
> my intention to check firmware loaded or not.
> If already loaded then not to overwrite the csr address space to maintain the 
> dc5/dc6 counter value.
> 
> Can the below comment more clear to you.
> 
>   /*
>* Dmc will restore the csr the program except DC9, cold boot,
>* warm reset, PCI function level reset, and hibernate/suspend.
>* If firmware is restored by dmc then no need to load again which
>* will keep the dc5/dc6 counter exposed by firmware.
>*/
> 
> No issue in init sequence.

That seems to still cover all the callers of the function afaics - we do
pci resets over suspend resume unconditionally. So I still don't
understand where exactly we try to load the dmc firmware in i915.ko when
it's already loaded.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [DMC_BUGFIX_SKL_V2 4/5] drm/i915/skl: Do not disable cdclk PLL if csr firmware is present

[Daniel Vetter]

On Mon, Aug 31, 2015 at 01:03:03AM +, Hindman, Gavin wrote:
> Unless I'm misreading that would imply that we are moving away from our
> previous position that DMC FW is optional, correct?Would this not
> render power-sequencing broken if a distro chose not to include DMC FW?

For upstream we never had the stance (and I wouldn't accept the patches
really without a really good reason) that we'll support runtime pm without
DMC firmware.

We already have a really bad time just trying to keep things working in 1
configuration (there's a patch from me to enable runtime pm by default
blocked on unfixed regressions which are open since months and no one's
working on them), we absolutely don't have the resources to support any
crazy configurations that's theoretically possible. If a distro won't
include DMC then they won't get proper runtime pm and that's it.

Yes the original DMC patches (and the code still in tree) had code to
handle that case, but follow-up patches rip that complexity out.

If we are in position where we can actually ship all the power features we
develop then we could consider supporting more combinations of features,
but right now I think that's in the very distant future.

Thanks, Daniel

> 
> Gavin Hindman
> Senior Program Manager
> SSG/OTC – Open Source Technology Center
> 
> 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
> Daniel Vetter
> Sent: Wednesday, August 26, 2015 6:12 AM
> To: Manna, Animesh
> Cc: Bhardwaj, Rajneesh; intel-gfx@lists.freedesktop.org; Vetter, Daniel
> Subject: Re: [Intel-gfx] [DMC_BUGFIX_SKL_V2 4/5] drm/i915/skl: Do not disable 
> cdclk PLL if csr firmware is present
> 
> On Wed, Aug 26, 2015 at 01:36:08AM +0530, Animesh Manna wrote:
> > While display engine entering into low power state no need to disable 
> > cdclk pll as CSR firmware of dmc will take care. If pll is already 
> > enabled firmware execution sequence will be blocked. This is one of 
> > the criteria for dmc to work properly.
> > 
> > v1: Initial version.
> > 
> > v2: Based on review comment from Daniel added code commnent.
> > 
> > Cc: Daniel Vetter 
> > Cc: Damien Lespiau 
> > Cc: Imre Deak 
> > Cc: Sunil Kamath 
> > Signed-off-by: Animesh Manna 
> > Signed-off-bt: Vathsala Nagaraju 
> > Signed-off-by: Rajneesh Bhardwaj 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 14 ++
> >  1 file changed, 10 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index f604ce1..b6bef20 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5687,10 +5687,16 @@ void skl_uninit_cdclk(struct drm_i915_private 
> > *dev_priv)
> > if (I915_READ(DBUF_CTL) & DBUF_POWER_STATE)
> > DRM_ERROR("DBuf power disable timeout\n");
> >  
> > -   /* disable DPLL0 */
> > -   I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) & ~LCPLL_PLL_ENABLE);
> > -   if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
> > -   DRM_ERROR("Couldn't disable DPLL0\n");
> > +   /*
> > +* DMC assumes ownership of LCPLL and will get confused if we touch it.
> 
> This should get a FIXME - once we have dmc loading fixed up we require the 
> firmware and there's no point in this check any more. Flexibilty just because 
> is something we simply don't have the developer and validation resources for.
> -Daniel
> 
> > +*/
> > +   if (dev_priv->csr.dmc_payload) {
> > +   /* disable DPLL0 */
> > +   I915_WRITE(LCPLL1_CTL, I915_READ(LCPLL1_CTL) &
> > +   ~LCPLL_PLL_ENABLE);
> > +   if (wait_for(!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_LOCK), 1))
> > +   DRM_ERROR("Couldn't disable DPLL0\n");
> > +   }
> >  
> > intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);  }
> > --
> > 2.0.2
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset

[Jani Nikula]

On Wed, 02 Sep 2015, "Yang, Libin"  wrote:
> Hi Jani,
>
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Wednesday, September 02, 2015 4:20 PM
>> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
>> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch;
>> ville.syrj...@linux.intel.com
>> Cc: Yang, Libin
>> Subject: Re: [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset
>> 
>> On Wed, 02 Sep 2015, libin.y...@intel.com wrote:
>> > From: Libin Yang 
>> >
>> > When modeset occurs and the TMDS frequency is set to some
>> > speical values, the N/CTS need to be set manually if audio
>> > is playing.
>> 
>> Do we still need this patch after David Henningsson's series [1]? IIUC
>> you will now always get the callback on modesets, so you should be
>> able
>> to, uh, callback on the callback to set audio rate. Granted, with this I
>> suppose you reduce the time there might be wrong N/CTS after enable.
>
> Yes, we need. David's patch will not trigger the sync_audio_rate
> callback.

Okay.

>
>> 
>> Some other comments inline.
>> 
>> [1] http://mid.gmane.org/1440781350-12053-1-git-send-email-
>> david.hennings...@canonical.com
>> 
>> >
>> > Signed-off-by: Libin Yang 
>> > ---
>> >  drivers/gpu/drm/i915/i915_reg.h|  8 
>> >  drivers/gpu/drm/i915/intel_audio.c | 40
>> +-
>> >  2 files changed, 47 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> > index ae7fa3e..5bdee36 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -7058,6 +7058,8 @@ enum skl_disp_power_wells {
>> >_HSW_AUD_MISC_CTRL_A, \
>> >_HSW_AUD_MISC_CTRL_B)
>> >
>> > +#define HSW_AUD_PIPE_CONN_SEL_CTRL  0x650ac
>> 
>> Nitpick. The bit fields are not defined.
>
> OK, I will add the bit definition. 
>
>> 
>> > +
>> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_A0x650b4
>> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_B0x651b4
>> >  #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
>> > @@ -7072,6 +7074,12 @@ enum skl_disp_power_wells {
>> >_HSW_AUD_DIG_CNVT_2)
>> >  #define DIP_PORT_SEL_MASK 0x3
>> >
>> > +#define _HSW_AUD_STR_DESC_1   0x65084
>> > +#define _HSW_AUD_STR_DESC_2   0x65184
>> > +#define AUD_STR_DESC(pipe)_PIPE(pipe, \
>> > +   _HSW_AUD_STR_DESC_1,
>>  \
>> > +   _HSW_AUD_STR_DESC_2)
>> 
>> Nitpick. The bit fields are not defined. I think it's fine to use _PIPE
>> macro, but you should probably use "converter" or "cvt" or something
>> for
>> the parameter name to not mislead people into thinking this is pipe
>> based.
>
> Do you mean it should be like:
> _PIPE(cvt, _HSW_AUD_STR_DESC_1, ...) ?

Yes.

>
>> 
>> > +
>> >  #define _HSW_AUD_EDID_DATA_A  0x65050
>> >  #define _HSW_AUD_EDID_DATA_B  0x65150
>> >  #define HSW_AUD_EDID_DATA(pipe) _PIPE(pipe, \
>> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> b/drivers/gpu/drm/i915/intel_audio.c
>> > index a021720..acdb68c 100644
>> > --- a/drivers/gpu/drm/i915/intel_audio.c
>> > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> > @@ -140,6 +140,27 @@ static bool audio_rate_need_prog(struct
>> intel_crtc *crtc,
>> >return false;
>> >  }
>> >
>> > +static int audio_config_get_rate(struct drm_i915_private *dev_priv,
>> > +  enum pipe pipe)
>> > +{
>> > +  uint32_t tmp;
>> > +  int cvt_idx;
>> > +  int base_rate, mul, div, rate;
>> > +
>> > +  tmp = I915_READ(HSW_AUD_PIPE_CONN_SEL_CTRL);
>> > +  cvt_idx = (tmp >> (pipe * 8)) & 0xff;
>> 
>> This one needs to be addressed. Are you sure it's indexed by pipe? The
>> spec is vague.
>
> Yes, I did lot of test to confirm it.
>
>> 
>> Bits 7:0 are "control B", 15:8 are "control C", and so on, while your
>> (tmp >> (pipe * 8)) maps pipe A to control B, pipe B to control C,
>> etc. This would speak for port, not pipe, as pipe A should be valid
>> while port A not.
>
> We found there is something wrong/or vague in the spec.

Indeed.

>
>> 
>> > +  tmp = I915_READ(AUD_STR_DESC(cvt_idx));
>> > +  base_rate = tmp & (1 << 14);
>> 
>> Nitpick. We prefer (tmp & MASK) >> SHIFT.
>
> OK, I will change it.
>
>> 
>> > +  if (base_rate == 0)
>> > +  rate = 48000;
>> > +  else
>> > +  rate = 44100;
>> > +  mul = (tmp & (0x7 << 11)) + 1;
>> > +  div = (tmp & (0x7 << 8)) + 1;
>> 
>> This one needs to be addressed. This is bogus. The +1 would work if
>> you
>> actually did (tmp & MASK) >> SHIFT, but now you add it to the shifted
>> value. Your multipliers and divisors are *way* off.
>
> OK, I will check it and change the patch.
>> 
>> NAK on this patch.
>> 
>> > +  rate = rate * mul / div;
>> > +  return rate;
>> > +}
>> > +
>> >  static bool intel_eld_uptod

Re: [Intel-gfx] [PATCH 1/2] drm/i915: move intel_hrawclk() to intel_display.c

[Daniel Vetter]

On Wed, Aug 26, 2015 at 02:22:13PM -0700, Clint Taylor wrote:
> On 08/26/2015 12:58 AM, Jani Nikula wrote:
> >Make it available outside of intel_dp.c.
> >
> >Signed-off-by: Jani Nikula 
> >---
> >  drivers/gpu/drm/i915/intel_display.c | 33 +
> >  drivers/gpu/drm/i915/intel_dp.c  | 34 
> > --
> >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> >  3 files changed, 34 insertions(+), 34 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >b/drivers/gpu/drm/i915/intel_display.c
> >index cba6299b3450..f25a847bcbc5 100644
> >--- a/drivers/gpu/drm/i915/intel_display.c
> >+++ b/drivers/gpu/drm/i915/intel_display.c
> >@@ -135,6 +135,39 @@ intel_pch_rawclk(struct drm_device *dev)
> > return I915_READ(PCH_RAWCLK_FREQ) & RAWCLK_FREQ_MASK;
> >  }
> >
> >+/* hrawclock is 1/4 the FSB frequency */
> >+int intel_hrawclk(struct drm_device *dev)
> >+{
> >+struct drm_i915_private *dev_priv = dev->dev_private;
> >+uint32_t clkcfg;
> >+
> >+/* There is no CLKCFG reg in Valleyview. VLV hrawclk is 200 MHz */
> >+if (IS_VALLEYVIEW(dev))
> >+return 200;
> >+
> >+clkcfg = I915_READ(CLKCFG);
> >+switch (clkcfg & CLKCFG_FSB_MASK) {
> >+case CLKCFG_FSB_400:
> >+return 100;
> >+case CLKCFG_FSB_533:
> >+return 133;
> >+case CLKCFG_FSB_667:
> >+return 166;
> >+case CLKCFG_FSB_800:
> >+return 200;
> >+case CLKCFG_FSB_1067:
> >+return 266;
> >+case CLKCFG_FSB_1333:
> >+return 333;
> >+/* these two are just a guess; one of them might be right */
> >+case CLKCFG_FSB_1600:
> >+case CLKCFG_FSB_1600_ALT:
> >+return 400;
> >+default:
> >+return 133;
> >+}
> >+}
> >+
> >  static inline u32 /* units of 100MHz */
> >  intel_fdi_link_freq(struct drm_device *dev)
> >  {
> >diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >b/drivers/gpu/drm/i915/intel_dp.c
> >index 67f0e291232f..0800d87e876c 100644
> >--- a/drivers/gpu/drm/i915/intel_dp.c
> >+++ b/drivers/gpu/drm/i915/intel_dp.c
> >@@ -253,40 +253,6 @@ static void intel_dp_unpack_aux(uint32_t src, uint8_t 
> >*dst, int dst_bytes)
> > dst[i] = src >> ((3-i) * 8);
> >  }
> >
> >-/* hrawclock is 1/4 the FSB frequency */
> >-static int
> >-intel_hrawclk(struct drm_device *dev)
> >-{
> >-struct drm_i915_private *dev_priv = dev->dev_private;
> >-uint32_t clkcfg;
> >-
> >-/* There is no CLKCFG reg in Valleyview. VLV hrawclk is 200 MHz */
> >-if (IS_VALLEYVIEW(dev))
> >-return 200;
> >-
> >-clkcfg = I915_READ(CLKCFG);
> >-switch (clkcfg & CLKCFG_FSB_MASK) {
> >-case CLKCFG_FSB_400:
> >-return 100;
> >-case CLKCFG_FSB_533:
> >-return 133;
> >-case CLKCFG_FSB_667:
> >-return 166;
> >-case CLKCFG_FSB_800:
> >-return 200;
> >-case CLKCFG_FSB_1067:
> >-return 266;
> >-case CLKCFG_FSB_1333:
> >-return 333;
> >-/* these two are just a guess; one of them might be right */
> >-case CLKCFG_FSB_1600:
> >-case CLKCFG_FSB_1600_ALT:
> >-return 400;
> >-default:
> >-return 133;
> >-}
> >-}
> >-
> >  static void
> >  intel_dp_init_panel_power_sequencer(struct drm_device *dev,
> > struct intel_dp *intel_dp);
> >diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> >b/drivers/gpu/drm/i915/intel_drv.h
> >index 81b7d77a3c8b..ca475f2a5f7c 100644
> >--- a/drivers/gpu/drm/i915/intel_drv.h
> >+++ b/drivers/gpu/drm/i915/intel_drv.h
> >@@ -993,6 +993,7 @@ void i915_audio_component_cleanup(struct 
> >drm_i915_private *dev_priv);
> >  extern const struct drm_plane_funcs intel_plane_funcs;
> >  bool intel_has_pending_fb_unpin(struct drm_device *dev);
> >  int intel_pch_rawclk(struct drm_device *dev);
> >+int intel_hrawclk(struct drm_device *dev);
> >  void intel_mark_busy(struct drm_device *dev);
> >  void intel_mark_idle(struct drm_device *dev);
> >  void intel_crtc_restore_mode(struct drm_crtc *crtc);
> >
> 
> Simple move of the function with no change in functionality.
> 
> Reviewed-by: Clint Taylor 
> Tested-by: Clint Taylor 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: read dpcd 0 - 12 & link_status always

[Daniel Vetter]

On Tue, Sep 01, 2015 at 01:16:49PM +0300, Jani Nikula wrote:
> On Thu, 27 Aug 2015, Sivakumar Thulasimani  
> wrote:
> > From: "Thulasimani,Sivakumar" 
> >
> > Compliance requires the driver to read dpcd register 0 to 12 and
> > registers 0x200 to 0x205 to be read always.
> > Current code performs dpcd read for short pulse interrupts only
> > if the sink is enabled. This patch forces read for link status
> > and registers 0 to 12.
> 
> While this seems a bit silly from the driver perspective, I don't see it
> doing much harm either.

I don't think this is silly, but fixing it like this might be - currently
we don't do _any_ detection of sink ports, so if you have a hub with two
outputs and then plug in another one and plug out the first userspace
won't reprobe. So probably what we should be doing is not just read the
dpcd, but actually look at it, figure out whether something has changed
and make sure we send out the uevent even if the hpd line stays unchanged
on short pulses to make userspace aware of the changes.

Punting on this for now since I suspect there's a bigger story to be had
here ...
-Daniel

> 
> Note that We do read dpcd 0 to 14 no matter what the spec says.
> 
> Reviewed-by: Jani Nikula 
> 
> >
> > Signed-off-by: Sivakumar Thulasimani 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c |   12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 8a66a44..76561e0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4374,12 +4374,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> >  
> > WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
> >  
> > -   if (!intel_encoder->base.crtc)
> > -   return;
> > -
> > -   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> > -   return;
> > -
> > /* Try to read receiver status if the link appears to be up */
> > if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > return;
> > @@ -4390,6 +4384,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> > return;
> > }
> >  
> > +   if (!intel_encoder->base.crtc)
> > +   return;
> > +
> > +   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> > +   return;
> > +
> > /* Try to read the source of the interrupt */
> > if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> > intel_dp_get_sink_irq(intel_dp, &sink_irq_vector)) {
> > -- 
> > 1.7.9.5
> >
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: force full detect on sink count change

[Daniel Vetter]

On Thu, Aug 27, 2015 at 02:18:32PM +0530, Sivakumar Thulasimani wrote:
> From: "Thulasimani,Sivakumar" 
> 
> This patch checks for changes in sink count between short pulse
> hpds and forces full detect when there is a change.
> 
> This will allow both detection of hotplug and unplug of panels
> through dongles that give only short pulse for such events.
> 
> v2: changed variable type from u8 to bool (Jani)
> return immediately if perform_full_detect is set(Siva)
> 
> Signed-off-by: Sivakumar Thulasimani 

That's still incomplete since in the hotplug work function we check
whether ->detect status has changed. If that doesn't happen (e.g. sink
count changes from 1->2 or whatever) then we'll fail to generate the
required uevent.

I suspect the only clean way to fix this is to merge all the dp hpd
handling together into one place and stop using ->detect for some parts of
it. Then we would have one place only that decides whether anything
changed, and whether we need to send anything to userspace or not.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_dp.c |   27 ++-
>  1 file changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 834f513..279e52c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4370,26 +4370,39 @@ go_again:
>   *  4. Check link status on receipt of hot-plug interrupt
>   */
>  static void
> -intel_dp_check_link_status(struct intel_dp *intel_dp)
> +intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
> *perform_full_detect)
>  {
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
>   struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
>   struct intel_crtc *crtc =
>   to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
>   u8 sink_irq_vector;
> + u8 old_sink_count = intel_dp->sink_count;
> + bool ret;
>   u8 link_status[DP_LINK_STATUS_SIZE];
>  
>   WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
>  
> + *perform_full_detect = false;
> +
>   /* Try to read receiver status if the link appears to be up */
>   if (!intel_dp_get_link_status(intel_dp, link_status)) {
>   return;
>   }
>  
> - /* Now read the DPCD to see if it's actually running */
> - if (!intel_dp_get_dpcd(intel_dp)) {
> + /* Now read the DPCD to see if it's actually running
> +  * Don't return immediately if dpcd read failed,
> +  * if sink count was 1 and dpcd read failed we need
> +  * to do full detection
> +  */
> + ret = intel_dp_get_dpcd(intel_dp);
> +
> + if (old_sink_count != intel_dp->sink_count)
> + *perform_full_detect = true;
> +
> + /* No need to proceed if we are going to do full detect */
> + if (!ret || *perform_full_detect)
>   return;
> - }
>  
>   if (!intel_encoder->base.crtc)
>   return;
> @@ -5031,13 +5044,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> *intel_dig_port, bool long_hpd)
>   }
>  
>   if (!intel_dp->is_mst) {
> + bool full_detect;
>   /*
>* we'll check the link status via the normal hot plug 
> path later -
>* but for short hpds we should check it now
>*/
>   drm_modeset_lock(&dev->mode_config.connection_mutex, 
> NULL);
> - intel_dp_check_link_status(intel_dp);
> + intel_dp_check_link_status(intel_dp, &full_detect);
>   drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> + if (full_detect)
> + goto put_power;
>   }
>   }
>  
> -- 
> 1.7.9.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [RFC PATCH] drm/i915: Use universal planes for cursor on skylake.

[Daniel Vetter]

On Thu, Aug 27, 2015 at 12:08:30PM +0200, Maarten Lankhorst wrote:
> This appears to make all the cursor tests really slow because of the many 
> calls to skl_update_wm
> when the cursor plane visibility is changed. It performs does 3 vblanks each 
> time it's called, and
> it's probably called more than once on each update.

On all other platforms wm updates (right now at least) don't do any vblank
waits, which means changing cursors actually _does_ cause tons of
underruns. Can we perhaps add a hack in skl to do the same (maybe just for
cursors) so that we can get this in? There's lots other work that really
wants proper universal planes ...
-Daniel

> 
> Smarter watermark updates will hopefully fix this..
> 
> This patch is tested with Xorg and kms_cursor_crc, and is just a RFC. :)
> 
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 05523491ad6f..bf5f814f72ae 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -263,11 +263,11 @@ struct i915_hotplug {
>   for ((__p) = 0; (__p) < INTEL_INFO(__dev_priv)->num_pipes; (__p)++)
>  #define for_each_plane(__dev_priv, __pipe, __p)  
> \
>   for ((__p) = 0; \
> -  (__p) < INTEL_INFO(__dev_priv)->num_sprites[(__pipe)] + 1; \
> +  (__p) < INTEL_INFO(__dev_priv)->num_sprites[(__pipe)] + 1 + 
> IS_GEN9(__dev_priv);   \
>(__p)++)
>  #define for_each_sprite(__dev_priv, __p, __s)
> \
>   for ((__s) = 0; \
> -  (__s) < INTEL_INFO(__dev_priv)->num_sprites[(__p)];\
> +  (__s) < INTEL_INFO(__dev_priv)->num_sprites[(__p)] + 
> IS_GEN9(__dev_priv);  \
>(__s)++)
>  
>  #define for_each_crtc(dev, crtc) \
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 92e3f074ae30..307d1374daa5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1402,7 +1402,7 @@ static void assert_sprites_disabled(struct 
> drm_i915_private *dev_priv,
>  
>   if (INTEL_INFO(dev)->gen >= 9) {
>   for_each_sprite(dev_priv, pipe, sprite) {
> - val = I915_READ(PLANE_CTL(pipe, sprite));
> + val = I915_READ(PLANE_CTL(pipe, sprite + 1));
>   I915_STATE_WARN(val & PLANE_CTL_ENABLE,
>"plane %d assertion failure, should be off on pipe 
> %c but is still active\n",
>sprite, pipe_name(pipe));
> @@ -11563,12 +11563,15 @@ int intel_plane_atomic_calc_changes(struct 
> drm_crtc_state *crtc_state,
>   bool mode_changed = needs_modeset(crtc_state);
>   bool was_crtc_enabled = crtc->state->active;
>   bool is_crtc_enabled = crtc_state->active;
> -
> + enum drm_plane_type plane_type = plane->type;
>   bool turn_off, turn_on, visible, was_visible;
>   struct drm_framebuffer *fb = plane_state->fb;
>  
> + if (IS_GEN9(dev) && plane->type == DRM_PLANE_TYPE_CURSOR)
> + plane_type = DRM_PLANE_TYPE_OVERLAY;
> +
>   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));
> @@ -11601,7 +11604,7 @@ int intel_plane_atomic_calc_changes(struct 
> drm_crtc_state *crtc_state,
>   if (turn_on) {
>   intel_crtc->atomic.update_wm_pre = true;
>   /* must disable cxsr around plane enable/disable */
> - if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> + if (plane_type != DRM_PLANE_TYPE_CURSOR) {
>   intel_crtc->atomic.disable_cxsr = true;
>   /* to potentially re-enable cxsr */
>   intel_crtc->atomic.wait_vblank = true;
> @@ -11610,7 +11613,7 @@ int intel_plane_atomic_calc_changes(struct 
> drm_crtc_state *crtc_state,
>   } else if (turn_off) {
>   intel_crtc->atomic.update_wm_post = true;
>   /* must disable cxsr around plane enable/disable */
> - if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> + if (plane_type != DRM_PLANE_TYPE_CURSOR) {
>   if (is_crtc_enabled)
>   intel_crtc->atomic.wait_vblank = true;
>   intel_crtc->atomic.disable_cxsr = true;
> @@ -11623,7 +11626,7 @@ int intel_plane_atomic_calc_changes(struct 
> drm_crtc_state *crtc_state,
>   intel_crtc->atomic.fb_bits |=
>   to_intel_plane(plane)->frontbuffer_bit;
>  
> - switch (plane->type) {
> + switch (plane_type) {
>   case DRM_PLANE_TYPE_PRIMARY

Re: [Intel-gfx] [PATCH 2/3] drm/i915: add yesno utility function

[Daniel Vetter]

On Mon, Aug 31, 2015 at 03:33:13PM +0100, Chris Wilson wrote:
> On Mon, Aug 31, 2015 at 05:23:27PM +0300, Jani Nikula wrote:
> > On Thu, 27 Aug 2015, Jani Nikula  wrote:
> > > On Thu, 27 Aug 2015, Chris Wilson  wrote:
> > >> On Thu, Aug 27, 2015 at 04:23:30PM +0300, Jani Nikula wrote:
> > >>> Add a common function to return "yes" or "no" string based on the
> > >>> argument, and drop the local versions of it.
> > >>
> > >> Purely out of curiosity, gcc is able to amalgamate the constant strings
> > >> (I remember reading that it is intelligent enough to do so), right? i.e.
> > >> size i915.ko doesn't change (at least .data, we may see .text
> > >> differences for gcc having different ideas about inlines)?
> > >
> > > I admit to giving GCC the benefit of the doubt. I may be naïve that way,
> > > trusting the tools to do what seems like the obviously right thing to
> > > do.
> > >
> > > If GCC lets us down, we could try something like the yesno version in
> > > drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c. GCC not doing the
> > > right thing with that would be violating the standard.
> > 
> > AFAICT GCC does the right thing with the patch.
> 
> Fwiw, I didn't see any harm in the series, so
> Reviewed-by: Chris Wilson 

Merged just this patch (due to conflict fun for now) to dinq, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Make sure lock is held in trylock contexts.

[Daniel Vetter]

On Thu, Aug 27, 2015 at 01:58:09PM +0200, Maarten Lankhorst wrote:
> This will make sure we get a lockdep spat in all cases
> even if the context is a complete garbage pointer.
> 
> Signed-off-by: Maarten Lankhorst 

Applied to drm-misc, thanks.
-Daniel

> ---
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 9abee87c1501..7c9ca2381d78 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -305,6 +305,8 @@ static inline int modeset_lock(struct drm_modeset_lock 
> *lock,
>   WARN_ON(ctx->contended);
>  
>   if (ctx->trylock_only) {
> + lockdep_assert_held(&ctx->ww_ctx);
> +
>   if (!ww_mutex_trylock(&lock->mutex))
>   return -EBUSY;
>   else
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 4/5] Documentation: drm: Convert KMS Properties HTML table to CALS

[Graham Whaley]

On Tue, 2015-09-01 at 14:56 -0300, Danilo Cesar Lemes de Paula wrote:
> On 08/25/2015 01:10 PM, Graham Whaley wrote:
> > On Tue, 2015-08-25 at 16:29 +0200, Daniel Vetter wrote:
> > > On Tue, Aug 25, 2015 at 10:26:44AM +0100, Graham Whaley wrote:
> > > > The KMS Properties table is in HTML format, which is not
> > > > supported
> > > > for building pdfdocs, resulting in the following types of
> > > > errors:
> > > > 
> > > >  jade:/Documentation/DocBook/drm.xml:34413:15:E: there is no
> > > > attribute
> > > >  "border"
> > > >  jade:/Documentation/DocBook/drm.xml:34413:31:E: there is no
> > > > attribute
> > > >  "cellpadding"
> > > >  jade:/Documentation/DocBook/drm.xml:34413:47:E: there is no
> > > > attribute
> > > >  "cellspacing"
> > > >  jade:/Documentation/DocBook/drm.xml:34414:7:E: document type
> > > > does
> > > > not
> > > >  allow element "tbody" here
> > > > 
> > > > Convert the table over to a CALS format table
> > > 
> > > Hm, long-term plan was to move this table into DOC: comments in
> > > the
> > > source-code using markdown, which we now have (at least in
> > > drm-intel-nightly and also planned to be merged into 4.4). Since
> > > this
> > > is
> > > both a lot of churn I'd like to get there in just 1 step ...
> > > -Daniel
> > First - I've just noted an erroneous debug comment (or two) left in
> > this patch as well, so looks like I will have to re-issue the
> > series
> > anyway.
> > 
> > OK. I guess this comes down to a matter of timing...
> > From Danilos patch of: f6d6913 (drm/doc: Convert to markdown)
> > we can see markdown does not natively support tables, and we'd have
> > to
> > make this a fixed width layout like the one in that patch I
> > suspect.
> > Danilo - any advice on how you did that other table conversion? I
> > just
> > did a pandoc docbook->markdown_github and it looks some way there -
> > but
> > of course seems to have not honored the multi-column items, of
> > which
> > there are a few. It's probably not too bad to fix up by hand - I'll
> > see
> > if I can get that to work...
> 
> Hi Graham,
> 
> To be honest I didn't have to do any conversion as that table was
> already in the header file. I just added 4 spaces so it would be
> transformed into fixed width.
> 
> However, there's tool you can use to help you: http://pandoc.org/try/
> I did a lot of translation there. If your table doesn't have any
> spancells, you can put the HTML code there and get the Markdown for
> free.
> 
> Danilo
Thanks,
 I got to have a look at this yesterday. I did a text render from the
html using 'links' that worked surprisingly well, but the table has
many spancells (both vertical and horizontal), and some other issues
arose. I'll do an email later with some details of what I've found, but
right now I'm not hopeful that it will be practical to move that large
KMS Properties table to markdown. More later.

 Graham

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

Re: [Intel-gfx] About the iGVT-g's requirement to pin guest contexts in VM

[Zhiyuan Lv]

Hi Daniel,

Thanks for the comments! And my reply in line:

On Wed, Sep 02, 2015 at 10:19:03AM +0200, Daniel Vetter wrote:
> > > 
> > > Also you obviously have to complete the copying from shadow->guest ctx
> > > before you send the irq to the guest to signal ctx completion. Which means
> > > there's really no overall problem here from a design pov, the only thing
> > 
> > Right. We cannot control when guest driver sees seqno change, but we
> > can control when guest sees context interrupts. The guest CSB update
> > and interrupt injection will be after we finish writing guest
> > contexts.
> > 
> > So right now we have two options of context shadowing: one is to track
> > the whole life-cycle of guest context, and another is to do the shadow
> > work in context schedule-in/schedule-out time. Zhi draws a nice
> > picture of them.
> > 
> > Currently we do not have concrete performance comparison of the two
> > approaches. We will have a try and see. And about this patchset, I
> > will remove the "context notification" part and send out an updated
> > version. Thanks!
> > 
> > > you have to do is fix up bugs in the host code (probably you should just
> > > write through the ggtt).
> > 
> > Sorry could you elaborate a little more about this? Guest context may
> > not always be in aperture right?
> 
> Yeah the high-level problem is that global gtt is contended (we already
> have trouble with that on xengt and there's the ongoing but unfished
> partial mmap support for that). And permanently pinning execlist contexts
> will cause lots of troubles.
> 
> Windows can do this because it segments the global gtt into different
> parts (at least last time I looked at their memory manager), which means
> execlist will never sit in the middle of the range used for mmaps. But
> linux has a unified memory manager, which means execlist can sit anywhere,
> and therefore badly fragment the global gtt. If we pin them then that will
> cause trouble after long system uptime. And afaiui xengt is mostly aimed
> at servers, where the uptime assumption should be "runs forever".

In server side, we do not expect host to run much graphics workloads
(all should be in virtual machines with shorter uptime). But yeah, gm
fragmentation is still an issue. Thanks for the explanation!

> 
> Compounding factor is that despite that I raised this in the original
> review execlist is still not yet using the active list in upstream and
> instead does short-time pinning. It's better than pinning forever but
> still breaks the eviction logic.
> 
> What Chris Wilson and I talked about forever is adding an object-specific
> global_gtt_unbind hook. The idea is that this would be called when
> unbinding/evicting a special object (e.g. hw context), and you could use
> that to do the host signalling. That would be the perfect combination of
> both approaches:

Thanks for the suggestion! That sounds great! Right now in XenGT part
we still plan to try the shadow context work in context
schedule-in/out time. With this way, we do not need to pin context as
well as the host notification. We will collect some performance data
to see how it works.

I sent out v2 patch set which has removed the pin/unpin of execlist
contexts. The patchset addressed review comments from you, Chris and
Joonas(Sorry I forgot to add CC to related people). Is that patch set
OK to be merged? Thanks!

Regards,
-Zhiyuan

> 
> - Fast: host signalling (and therefore shadow context recreation) would
>   only be done when the execlist context has actually moved around. That
>   almost never happens, and hence per-execbuf overhead would be as low as
>   with your pinning solution.
> 
> - Flexible: The i915 memory manager is still in full control since we
>   don't pin any objects unecessarily.
> 
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Wed, 02 Sep 2015 10:32:34 +0200,
Daniel Vetter wrote:
> 
> On Wed, Sep 02, 2015 at 10:03:55AM +0200, Takashi Iwai wrote:
> > On Wed, 02 Sep 2015 10:00:44 +0200,
> > Daniel Vetter wrote:
> > > 
> > > On Fri, Aug 28, 2015 at 04:10:36PM +0300, Jani Nikula wrote:
> > > > On Thu, 20 Aug 2015, Takashi Iwai  wrote:
> > > > > On Thu, 20 Aug 2015 11:41:42 +0200,
> > > > > David Henningsson wrote:
> > > > >> 
> > > > >> 
> > > > >> 
> > > > >> On 2015-08-20 11:28, Takashi Iwai wrote:
> > > > >> > On Wed, 19 Aug 2015 10:48:58 +0200,
> > > > >> > David Henningsson wrote:
> > > > >> >>
> > > > >> >> Whenever there is an event from the i915 driver, wake the codec
> > > > >> >> and recheck plug/unplug + ELD status.
> > > > >> >>
> > > > >> >> This fixes the issue with lost unsol events in power save mode,
> > > > >> >> the codec and controller can now sleep in D3 and still know when
> > > > >> >> the HDMI monitor has been connected.
> > > > >> >>
> > > > >> >> Signed-off-by: David Henningsson 
> > > > >> >
> > > > >> > This addition looks fine, but then we'll get double notification 
> > > > >> > for
> > > > >> > the normal hotplug/unplug, one via component ops and another via 
> > > > >> > unsol
> > > > >> > event?
> > > > >> 
> > > > >> Right, in case the unsol event actually works...
> > > > >> 
> > > > >> I would argue that the normal case would be that the controller and 
> > > > >> codec is in D3 which means that the unsol event never gets through - 
> > > > >> due 
> > > > >> to hw limitations - which is what triggered this patch set in the 
> > > > >> first 
> > > > >> place.
> > > > >> 
> > > > >> But yes, in some case we might get double notification, but this 
> > > > >> should 
> > > > >> not cause any trouble in practice. The unsol event could be turned 
> > > > >> off, 
> > > > >> but would it be okay to save that for a later patch set (so I don't 
> > > > >> miss 
> > > > >> the upcoming merge window)?
> > > > >
> > > > > In that case, it should be mentioned in the changelog at least.
> > > > >
> > > > > This series came a bit too late for the merge window, so I'm not sure
> > > > > whether this can get in.  I personally find it OK, so take my ack for
> > > > > ALSA parts (patch 3/4), but the rest need review and ack from i915
> > > > > guys.  And we don't know who to merge this, if any.  The changes are
> > > > > almost even to i915 and hda.  I don't mind either way, via drm or
> > > > > sound tree.
> > > > 
> > > > Personally I'm fine with this still going for v4.3 since to me it looks
> > > > like any regressions this might cause will be on your side. *grin*.
> > > 
> > > The only bit I want is some decent kerneldoc for the ad-hoc growing
> > > i915/hda-intel interfaces. But that can be done in follow-up patches and
> > > needs to be coordinated with the audio rate handling series anyway. So ack
> > > from my side for all getting merged through alsa trees too.
> > 
> > Are you going to merge Libin's patchset?  If yes, it's better to align
> > both patchsets through a single tree.  It'll make merges easier, as
> > both touch the similar place.
> 
> Oh that was an ack for merging it all through your tree. If you punt it to
> 4.4 I might ask you for a stable tree to pull in in case I get conflicts.

OK, then I'll merge David's patchset now for the upcoming pull request
for 4.3-rc1.


thanks,

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

Re: [Intel-gfx] About the iGVT-g's requirement to pin guest contexts in VM

[Daniel Vetter]

On Wed, Sep 02, 2015 at 05:20:34PM +0800, Zhiyuan Lv wrote:
> Hi Daniel,
> 
> Thanks for the comments! And my reply in line:
> 
> On Wed, Sep 02, 2015 at 10:19:03AM +0200, Daniel Vetter wrote:
> > > > 
> > > > Also you obviously have to complete the copying from shadow->guest ctx
> > > > before you send the irq to the guest to signal ctx completion. Which 
> > > > means
> > > > there's really no overall problem here from a design pov, the only thing
> > > 
> > > Right. We cannot control when guest driver sees seqno change, but we
> > > can control when guest sees context interrupts. The guest CSB update
> > > and interrupt injection will be after we finish writing guest
> > > contexts.
> > > 
> > > So right now we have two options of context shadowing: one is to track
> > > the whole life-cycle of guest context, and another is to do the shadow
> > > work in context schedule-in/schedule-out time. Zhi draws a nice
> > > picture of them.
> > > 
> > > Currently we do not have concrete performance comparison of the two
> > > approaches. We will have a try and see. And about this patchset, I
> > > will remove the "context notification" part and send out an updated
> > > version. Thanks!
> > > 
> > > > you have to do is fix up bugs in the host code (probably you should just
> > > > write through the ggtt).
> > > 
> > > Sorry could you elaborate a little more about this? Guest context may
> > > not always be in aperture right?
> > 
> > Yeah the high-level problem is that global gtt is contended (we already
> > have trouble with that on xengt and there's the ongoing but unfished
> > partial mmap support for that). And permanently pinning execlist contexts
> > will cause lots of troubles.
> > 
> > Windows can do this because it segments the global gtt into different
> > parts (at least last time I looked at their memory manager), which means
> > execlist will never sit in the middle of the range used for mmaps. But
> > linux has a unified memory manager, which means execlist can sit anywhere,
> > and therefore badly fragment the global gtt. If we pin them then that will
> > cause trouble after long system uptime. And afaiui xengt is mostly aimed
> > at servers, where the uptime assumption should be "runs forever".
> 
> In server side, we do not expect host to run much graphics workloads
> (all should be in virtual machines with shorter uptime). But yeah, gm
> fragmentation is still an issue. Thanks for the explanation!

Fragmentation is a lot worse on the guest side (due to the reduce global
gtt space due to ballooning). Host isn't really any different.

> > Compounding factor is that despite that I raised this in the original
> > review execlist is still not yet using the active list in upstream and
> > instead does short-time pinning. It's better than pinning forever but
> > still breaks the eviction logic.
> > 
> > What Chris Wilson and I talked about forever is adding an object-specific
> > global_gtt_unbind hook. The idea is that this would be called when
> > unbinding/evicting a special object (e.g. hw context), and you could use
> > that to do the host signalling. That would be the perfect combination of
> > both approaches:
> 
> Thanks for the suggestion! That sounds great! Right now in XenGT part
> we still plan to try the shadow context work in context
> schedule-in/out time. With this way, we do not need to pin context as
> well as the host notification. We will collect some performance data
> to see how it works.
> 
> I sent out v2 patch set which has removed the pin/unpin of execlist
> contexts. The patchset addressed review comments from you, Chris and
> Joonas(Sorry I forgot to add CC to related people). Is that patch set
> OK to be merged? Thanks!

I'll defer to detailed reviewers, but if the static pinning is gone then
I'm ok. We can add the optimization I described here later on.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] dma-buf mmap

[Daniel Vetter]

On Thu, Aug 27, 2015 at 07:48:49PM -0300, Tiago Vignatti wrote:
> Hi,
> 
> Here's the igt side of the work I sent yesterday to dri-devel:
> 
> http://lists.freedesktop.org/archives/dri-devel/2015-August/089263.html
> 
> I've addressed all the commentaries made in the previous igt patchset and I
> believe that all tests now run fine in older kernels that don't support
> dma-buf mmap functionality -- hint hint could be applied right now in igt main
> repo hint hint :)

Merge order is:
0. Full stack is ready&reviewed, from kernel to userspace including tests
and all.
1. Kernel patches go in (for ioctl allocations).
2. Then and only then userspace gets merged.

Otherwise ioctl allocation clashes and that's no fun.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Enable full ppgtt for vgpu on Broadwell

[Daniel Vetter]

On Mon, Aug 31, 2015 at 03:55:58PM +0300, Joonas Lahtinen wrote:
> On pe, 2015-08-28 at 15:41 +0800, Zhiyuan Lv wrote:
> > The full ppgtt is supported now in Intel GVT-g device model.
> > Broadwell
> > is allowed to use it in virtual machines.
> > 
> > v2:
> > - Keep backward compatibility on HSW with old device model (daniel)
> > 
> > Signed-off-by: Zhiyuan Lv 
> > Signed-off-by: Zhi Wang 
> > Reviewed-by: Joonas Lahtinen 
> 
> It's a good idea to add the version reviewed after Reviewed-by, when
> adding a new revision. This is not to make it look like the new
> revision had already been reviewed too.
> 
> I this case:
> 
> Reviewed-by: Joonas Lahtinen  (v1)
> 
> Would have been appropriate.
> 
> But you can now leave it as it is, as this patch seems fine, too. Maybe
> could still add a comment in the code what makes Haswell special.
> 
> Regards, Joonas
> 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index ed10e77..56cc8e8 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -108,8 +108,8 @@ static int sanitize_enable_ppgtt(struct
> > drm_device *dev, int enable_ppgtt)
> > has_aliasing_ppgtt = INTEL_INFO(dev)->gen >= 6;
> > has_full_ppgtt = INTEL_INFO(dev)->gen >= 7;
> >  
> > -   if (intel_vgpu_active(dev))
> > -   has_full_ppgtt = false; /* emulation is too hard */
> > +   if (intel_vgpu_active(dev) && (IS_HASWELL(dev)))
> > +   has_full_ppgtt = false;

I'd say the real check here should be for INTEL_INFO(dev)->gen < 8. Only
checking for hsw is a bit confusing since then people wonder why hsw is
special. But the only reason is that vgpu isn't supported on pre-hsw.

Using the gen check instead will make it clear that this is a generic
issue with pre-gen8 hw (no execlists) and imo be less confusing. Maybe
even add a comment like:

/* virtualizing ppgtt with execlists is too hard */
> >  
> > /*
> >  * We don't allow disabling PPGTT for gen9+ as it's a
> > requirement for
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Allow Broadwell guest with Intel GVT-g

[Daniel Vetter]

On Fri, Aug 28, 2015 at 03:41:19PM +0800, Zhiyuan Lv wrote:
> I915 Broadwell guest driver is now supported to run inside a VM with
> Intel GVT-g
> 
> v2:
> - Introduce HAS_VGPU macro (Zhenyu Wang)
> 
> Signed-off-by: Zhiyuan Lv 
> Signed-off-by: Zhi Wang 
> Reviewed-by: Joonas Lahtinen 

I'll hold of on this one for the polished version of patch 2, but all
others are merged to dinq.

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
>  drivers/gpu/drm/i915/i915_vgpu.h | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 5eee75b..f98a979 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -66,7 +66,7 @@ void i915_check_vgpu(struct drm_device *dev)
>  
>   BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
>  
> - if (!IS_HASWELL(dev))
> + if (!HAS_VGPU(dev))
>   return;
>  
>   magic = readq(dev_priv->regs + vgtif_reg(magic));
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.h 
> b/drivers/gpu/drm/i915/i915_vgpu.h
> index 21c97f4..9a9eb57 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.h
> +++ b/drivers/gpu/drm/i915/i915_vgpu.h
> @@ -114,6 +114,8 @@ struct vgt_if {
>  #define VGT_DRV_DISPLAY_NOT_READY 0
>  #define VGT_DRV_DISPLAY_READY 1  /* ready for display switch */
>  
> +#define HAS_VGPU(dev)(IS_HASWELL(dev) || IS_BROADWELL(dev))
> +
>  extern void i915_check_vgpu(struct drm_device *dev);
>  extern int intel_vgt_balloon(struct drm_device *dev);
>  extern void intel_vgt_deballoon(void);
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Detect virtual south bridge

[Daniel Vetter]

On Fri, Aug 28, 2015 at 01:10:22PM +0100, robert.beck...@intel.com wrote:
> From: Robert Beckett 
> 
> Virtualized systems often use a virtual P2X4 south bridge.
> Detect this in intel_detect_pch and make a best guess as to which PCH
> we should be using.
> 
> This was seen on vmware esxi hypervisor. When passing the graphics device
> through to a guest, it can not pass through the PCH. Instead it simulates
> a P2X4 southbridge.
> 
> Signed-off-by: Robert Beckett 

What changed here compared to your earlier submission a day before?
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.c |   30 ++
>  drivers/gpu/drm/i915/i915_drv.h |1 +
>  2 files changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ce3bd0c..8e158b3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -443,6 +443,34 @@ static const struct pci_device_id pciidlist[] = {
> /* aka */
>  
>  MODULE_DEVICE_TABLE(pci, pciidlist);
>  
> +static enum intel_pch intel_virt_detect_pch(struct drm_device *dev)
> +{
> + enum intel_pch ret = PCH_NOP;
> +
> + /*
> +  * In a virtualized passthrough environment we can be in a
> +  * setup where the ISA bridge is not able to be passed through.
> +  * In this case, a south bridge can be emulated and we have to
> +  * make an educated guess as to which PCH is really there.
> +  */
> +
> + if (IS_GEN5(dev)) {
> + ret = PCH_IBX;
> + DRM_DEBUG_KMS("Assuming Ibex Peak PCH\n");
> + } else if (IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
> + ret = PCH_CPT;
> + DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
> + } else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
> + ret = PCH_LPT;
> + DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
> + } else if (IS_SKYLAKE(dev)) {
> + ret = PCH_SPT;
> + DRM_DEBUG_KMS("Assuming SunrisePoint PCH\n");
> + }
> +
> + return ret;
> +}
> +
>  void intel_detect_pch(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -503,6 +531,8 @@ void intel_detect_pch(struct drm_device *dev)
>   dev_priv->pch_type = PCH_SPT;
>   DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
>   WARN_ON(!IS_SKYLAKE(dev));
> + } else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE) {
> + dev_priv->pch_type = intel_virt_detect_pch(dev);
>   } else
>   continue;
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8c93845..6eb0230 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2584,6 +2584,7 @@ struct drm_i915_cmd_table {
>  #define INTEL_PCH_LPT_LP_DEVICE_ID_TYPE  0x9c00
>  #define INTEL_PCH_SPT_DEVICE_ID_TYPE 0xA100
>  #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE  0x9D00
> +#define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
>  
>  #define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
>  #define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
> -- 
> 1.7.9.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [RFC 1/3] drm/i915: Roll intel_crtc->atomic into intel_crtc_state

[Ville Syrjälä]

On Wed, Sep 02, 2015 at 07:15:25AM +0200, Maarten Lankhorst wrote:
> Op 01-09-15 om 17:48 schreef Ville Syrjälä:
> > On Tue, Sep 01, 2015 at 08:30:05AM -0700, Matt Roper wrote:
> >> On Tue, Sep 01, 2015 at 07:24:19AM +0200, Maarten Lankhorst wrote:
> >>> Op 29-08-15 om 01:57 schreef Matt Roper:
>  Way back at the beginning of i915's atomic conversion I added
>  intel_crtc->atomic as a temporary dumping ground for "stuff to do
>  outside vblank evasion" flags since CRTC states weren't properly wired
>  up and tracked at that time.  We've had proper CRTC state tracking for a
>  while now, so there's really no reason for this hack to continue to
>  exist.  Moving forward we want to store intermediate crtc/plane state
>  data for modesets in addition to the final state, so moving these fields
>  into the proper state object allows us to properly compute them for both
>  the intermediate and final state.
> 
>  Signed-off-by: Matt Roper 
>  ---
> >>> Can I shoot this patch down? It's better to add a field 'wm_changed'
> >>> to the crtc_state, which gets reset to false for each crtc_state
> >>> duplication. It's needed for checking if a cs pageflip can be done for
> >>> atomic. It would remove the duplication of some checks there.
> >>>
> >>> The other atomic state members will die soon. I already have some
> >>> patches to achieve that. :)
> >>>
> >>> I'm not sure if an intermediate state is a good idea. Any code that
> >>> disables a crtc should only be looking at the old state.
> >>> pre_plane_update runs all stuff in preparation for disabling planes,
> >>> while post_plane_update runs everything needed for enabling planes. So
> >>> no need to split it up I think, maybe put in some intermediate
> >>> watermarks in intel_atomic_state, but no need for a full crtc_state.
> >> Well, the intermediate state stuff was requested by Ville in response to
> >> my watermark series, so I posted these patches as an RFC to make sure I
> >> was understanding what he was looking for properly.
> >>
> >> Ville, can you comment?
> > My opinion is that the current "disable is special" way of doing things
> > is quite horrible. For one it makes it really hard to reason about what
> > happens to a plane or crtc during the modeset. It's not just off->on,
> > on->off, or same->same, but can be on->off->on. With the intermediate
> > state in place, there can only be one transition, so really easy to
> > think about what's going on.
> pre_plane_update deals with all stuff related to disabling planes, while 
> post_plane_update deals with changes after enabling.
> 
> If the crtc goes from on -> off only you could just hammer in the final 
> values after the disable.
> 
> While for off->on or on->off->on you can put in the final values in 
> .crtc_enable before lighting the pipe. I don't see why wm's would need more 
> transitions.

One special case after another. Yuck. Not to mention that the plane
disable isn't even atomic in the current code, which can look ugly.

> > It'll also mean don't have to sprinkle silly wm update calls all over
> > the modeset path. They will just get updated in response to the plane
> > state changes. Same for IPS/FBC etc.
> IPS and FBC are already calculated correctly in response to modesets.

Correctly perhaps, but not in an obvious way.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 1/3] drm/i915: Roll intel_crtc->atomic into intel_crtc_state

[Maarten Lankhorst]

Op 02-09-15 om 12:35 schreef Ville Syrjälä:
> On Wed, Sep 02, 2015 at 07:15:25AM +0200, Maarten Lankhorst wrote:
>> Op 01-09-15 om 17:48 schreef Ville Syrjälä:
>>> On Tue, Sep 01, 2015 at 08:30:05AM -0700, Matt Roper wrote:
 On Tue, Sep 01, 2015 at 07:24:19AM +0200, Maarten Lankhorst wrote:
> Op 29-08-15 om 01:57 schreef Matt Roper:
>> Way back at the beginning of i915's atomic conversion I added
>> intel_crtc->atomic as a temporary dumping ground for "stuff to do
>> outside vblank evasion" flags since CRTC states weren't properly wired
>> up and tracked at that time.  We've had proper CRTC state tracking for a
>> while now, so there's really no reason for this hack to continue to
>> exist.  Moving forward we want to store intermediate crtc/plane state
>> data for modesets in addition to the final state, so moving these fields
>> into the proper state object allows us to properly compute them for both
>> the intermediate and final state.
>>
>> Signed-off-by: Matt Roper 
>> ---
> Can I shoot this patch down? It's better to add a field 'wm_changed'
> to the crtc_state, which gets reset to false for each crtc_state
> duplication. It's needed for checking if a cs pageflip can be done for
> atomic. It would remove the duplication of some checks there.
>
> The other atomic state members will die soon. I already have some
> patches to achieve that. :)
>
> I'm not sure if an intermediate state is a good idea. Any code that
> disables a crtc should only be looking at the old state.
> pre_plane_update runs all stuff in preparation for disabling planes,
> while post_plane_update runs everything needed for enabling planes. So
> no need to split it up I think, maybe put in some intermediate
> watermarks in intel_atomic_state, but no need for a full crtc_state.
 Well, the intermediate state stuff was requested by Ville in response to
 my watermark series, so I posted these patches as an RFC to make sure I
 was understanding what he was looking for properly.

 Ville, can you comment?
>>> My opinion is that the current "disable is special" way of doing things
>>> is quite horrible. For one it makes it really hard to reason about what
>>> happens to a plane or crtc during the modeset. It's not just off->on,
>>> on->off, or same->same, but can be on->off->on. With the intermediate
>>> state in place, there can only be one transition, so really easy to
>>> think about what's going on.
>> pre_plane_update deals with all stuff related to disabling planes, while 
>> post_plane_update deals with changes after enabling.
>>
>> If the crtc goes from on -> off only you could just hammer in the final 
>> values after the disable.
>>
>> While for off->on or on->off->on you can put in the final values in 
>> .crtc_enable before lighting the pipe. I don't see why wm's would need more 
>> transitions.
> One special case after another. Yuck. Not to mention that the plane
> disable isn't even atomic in the current code, which can look ugly.
That's easily fixed by adding a pipe_update_start/end pair.
>>> It'll also mean don't have to sprinkle silly wm update calls all over
>>> the modeset path. They will just get updated in response to the plane
>>> state changes. Same for IPS/FBC etc.
>> IPS and FBC are already calculated correctly in response to modesets.
> Correctly perhaps, but not in an obvious way.
It will become more obvious again when pre_plane_update and post_plane_update 
are loops
instead of being precalculated from intel_plane_atomic_calc_changes.

But if you can precalculate fb_bits and know of wm changed post commit then 
post_plane_update
only cares about primary plane state.

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

Re: [Intel-gfx] [RFC 1/3] drm/i915: Roll intel_crtc->atomic into intel_crtc_state

[Ville Syrjälä]

On Wed, Sep 02, 2015 at 01:08:31PM +0200, Maarten Lankhorst wrote:
> Op 02-09-15 om 12:35 schreef Ville Syrjälä:
> > On Wed, Sep 02, 2015 at 07:15:25AM +0200, Maarten Lankhorst wrote:
> >> Op 01-09-15 om 17:48 schreef Ville Syrjälä:
> >>> On Tue, Sep 01, 2015 at 08:30:05AM -0700, Matt Roper wrote:
>  On Tue, Sep 01, 2015 at 07:24:19AM +0200, Maarten Lankhorst wrote:
> > Op 29-08-15 om 01:57 schreef Matt Roper:
> >> Way back at the beginning of i915's atomic conversion I added
> >> intel_crtc->atomic as a temporary dumping ground for "stuff to do
> >> outside vblank evasion" flags since CRTC states weren't properly wired
> >> up and tracked at that time.  We've had proper CRTC state tracking for 
> >> a
> >> while now, so there's really no reason for this hack to continue to
> >> exist.  Moving forward we want to store intermediate crtc/plane state
> >> data for modesets in addition to the final state, so moving these 
> >> fields
> >> into the proper state object allows us to properly compute them for 
> >> both
> >> the intermediate and final state.
> >>
> >> Signed-off-by: Matt Roper 
> >> ---
> > Can I shoot this patch down? It's better to add a field 'wm_changed'
> > to the crtc_state, which gets reset to false for each crtc_state
> > duplication. It's needed for checking if a cs pageflip can be done for
> > atomic. It would remove the duplication of some checks there.
> >
> > The other atomic state members will die soon. I already have some
> > patches to achieve that. :)
> >
> > I'm not sure if an intermediate state is a good idea. Any code that
> > disables a crtc should only be looking at the old state.
> > pre_plane_update runs all stuff in preparation for disabling planes,
> > while post_plane_update runs everything needed for enabling planes. So
> > no need to split it up I think, maybe put in some intermediate
> > watermarks in intel_atomic_state, but no need for a full crtc_state.
>  Well, the intermediate state stuff was requested by Ville in response to
>  my watermark series, so I posted these patches as an RFC to make sure I
>  was understanding what he was looking for properly.
> 
>  Ville, can you comment?
> >>> My opinion is that the current "disable is special" way of doing things
> >>> is quite horrible. For one it makes it really hard to reason about what
> >>> happens to a plane or crtc during the modeset. It's not just off->on,
> >>> on->off, or same->same, but can be on->off->on. With the intermediate
> >>> state in place, there can only be one transition, so really easy to
> >>> think about what's going on.
> >> pre_plane_update deals with all stuff related to disabling planes, while 
> >> post_plane_update deals with changes after enabling.
> >>
> >> If the crtc goes from on -> off only you could just hammer in the final 
> >> values after the disable.
> >>
> >> While for off->on or on->off->on you can put in the final values in 
> >> .crtc_enable before lighting the pipe. I don't see why wm's would need 
> >> more transitions.
> > One special case after another. Yuck. Not to mention that the plane
> > disable isn't even atomic in the current code, which can look ugly.
> That's easily fixed by adding a pipe_update_start/end pair.
> >>> It'll also mean don't have to sprinkle silly wm update calls all over
> >>> the modeset path. They will just get updated in response to the plane
> >>> state changes. Same for IPS/FBC etc.
> >> IPS and FBC are already calculated correctly in response to modesets.
> > Correctly perhaps, but not in an obvious way.
> It will become more obvious again when pre_plane_update and post_plane_update 
> are loops
> instead of being precalculated from intel_plane_atomic_calc_changes.

It'll never be obvious as long as the on->off->on case exists.

> 
> But if you can precalculate fb_bits and know of wm changed post commit then 
> post_plane_update
> only cares about primary plane state.
> 
> ~Maarten

-- 
Ville Syrjälä
Intel OTC
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

Re: [Intel-gfx] Request Linux Graphic Driver for Intel GMA 3150

[David Ho]

Dear Rodrigo,

Is it possible to obtain the "raw" driver and to install it manually, without 
installing it through the Installer?

Regards,
David


-Original Message-
From: Vivi, Rodrigo [mailto:rodrigo.v...@intel.com] 
Sent: 01 September 2015 23:04
To: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; 
hupernikao...@gmail.com
Subject: Re: [Intel-gfx] Request Linux Graphic Driver for Intel GMA 3150

On Tue, 2015-09-01 at 09:59 +0300, Jani Nikula wrote:
> On Sat, 22 Aug 2015, David Ho  wrote:
> > REQUEST
> > 
> > May I please request support for driver of Intel GMA 3150 for Ubuntu 
> > 14.04.3
> > 32 bit (Trusty Tahr)?
> > 
> > I installed "Intel Graphic Installer for Linux" from 01.org, but it 
> > stops at the very first step saying "Distribution not supported".
> 
> Rodrigo (Cc'd) knows this stuff better, but I don't think it's likely 
> old (from upstream POV) distros will be supported. In that regard, 
> you're probably better off asking help from your distro vendor.

Unfortunately Installer aims to support just latest versions of Ubuntu and 
Fedora when it is being prepared for release, regardless distros LTS.
In the past we supported LTS, but with time official updates conflicted with 
installer packages and caused more issues to users.

> > BACKGROUND
> > 
> > After fresh install of 14.04, the mouse pointer is not showing up 
> > and the display change (when scrolling, moving between windows, etc) 
> > is very slow (even only for regular application, never tried to 
> > watch video yet). I concluded that this is the driver issue.
> 
> Does it work on a newer Ubuntu install? Or can you try a new kernel? 
> If
> you can reproduce this on a new kernel, please file a bug at [1].

> BR,
> Jani.
> 
> 
> 
> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=
> DRM/Intel
> 
> 
> > 
> > I must install it for around 20 PCs.
> > 
> > Please help me to get the correct driver.
> > 
> >  
> > 
> > Thank you.
> > 
> >  
> > 
> > Regards,
> > 
> > David Ho
> > 
> >  
> > 
> >  
> > 
> > -Original Message-
> > From: Chacn Limn, DanielX [mailto:danielx.chacn.l...@intel.com]
> > Sent: 21 Agustus 2015 22:05
> > To: hupernikao...@gmail.com
> > Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Diaz, Victor H
> > Subject: RE: [Contact] Intel GMA 3150 for Ubuntu 14.04.3Trusty Tahr 
> > 32bit
> > 
> >  
> > 
> > Hi David,
> > 
> > Thank you for contacting us.
> > 
> >  
> > 
> > For help or more information about Linux Graphics drivers please 
> > contact the Team in charge through their mailing list:
> > 
> >  
> > intel-gfx@lists.freedesktop.org
> > 
> >  
> > 
> > Regards,
> > 
> > Daniel.
> > 
> >  
> > 
> > [.MESSAGES TRUNCATED]
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

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

Re: [Intel-gfx] [PATCH] drm/i915: Update ring space correctly on lrc context reset

[Arun Siluvery]

On 20/08/2015 16:27, Chris Wilson wrote:

On Thu, Aug 20, 2015 at 05:34:59PM +0300, Mika Kuoppala wrote:

If we leave the last_retired_head to pre-reset value, we might
end up in a situation where intel_ring_space() returns wrong
value on next hardware init.


http://patchwork.freedesktop.org/patch/46612/
and earlier
-Chris


Hi Chris,

I see the warning even with below batch,

[Intel-gfx] [PATCH 50/70] drm/i915: The argument for postfix is redundant
http://patchwork.freedesktop.org/patch/46601/

the following patch need to be updated as it uses olr,
[Intel-gfx] [PATCH 51/70] drm/i915: Record the position of the start of 
the request

http://patchwork.freedesktop.org/patch/46612/

Do we need some of the previous patches in series as well?

This patch is fixing the issue in the current code, do you think we can 
get this in its current state?


regards
Arun

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

[Intel-gfx] [PATCH] drm/i915: Fix cmdparser STORE/LOAD command descriptors

[Chris Wilson]

Fixes regression from
commit f1afe24f0e736b9d7f2275e2b1504af3fe612f2a
Author: Arun Siluvery 
Date:   Tue Aug 4 16:22:20 2015 +0100

drm/i915: Change SRM, LRM instructions to use correct length

which forgot to account for the length bias when declaring the fixed
length.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91844
Reported-by: Andreas Reis 
Signed-off-by: Chris Wilson 
Cc: Dave Gordon 
Cc: Arun Siluvery 
Cc: Mika Kuoppala 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index ad7d7ab76d3f..09932cab1a3f 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -124,14 +124,14 @@ static const struct drm_i915_cmd_descriptor common_cmds[] 
= {
CMD(  MI_STORE_DWORD_INDEX, SMI,   !F,  0xFF,   R  ),
CMD(  MI_LOAD_REGISTER_IMM(1),  SMI,   !F,  0xFF,   W,
  .reg = { .offset = 1, .mask = 0x007C, .step = 2 }),
-   CMD(  MI_STORE_REGISTER_MEM,SMI,F,  1, W | B,
+   CMD(  MI_STORE_REGISTER_MEM,SMI,F,  3, W | B,
  .reg = { .offset = 1, .mask = 0x007C },
  .bits = {{
.offset = 0,
.mask = MI_GLOBAL_GTT,
.expected = 0,
  }},  ),
-   CMD(  MI_LOAD_REGISTER_MEM, SMI,F,  1, W | B,
+   CMD(  MI_LOAD_REGISTER_MEM, SMI,F,  3, W | B,
  .reg = { .offset = 1, .mask = 0x007C },
  .bits = {{
.offset = 0,
-- 
2.5.1

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

[Intel-gfx] [PATCH] uapi/drm/i915_drm.h: fix userspace compilation.

[Artem Savkov]

Patch "drm/i915: Use expcitly fixed type in compat32 structs" changed the type
of param field in drm_i915_getparam from int to s32. This header is exported to
userspace and needs to use userspace type __s32 instead.

This fixes userspace compilation errors like the following:
include/drm/i915_drm.h:361:2: error: unknown type name 's32'
  s32 param;

Signed-off-by: Artem Savkov 
---
 include/uapi/drm/i915_drm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index dbd16a2..fd5aa47 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -358,7 +358,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_RESOURCE_STREAMER 36
 
 typedef struct drm_i915_getparam {
-   s32 param;
+   __s32 param;
/*
 * WARNING: Using pointers instead of fixed-size u64 means we need to 
write
 * compat32 code. Don't repeat this mistake.
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Add audio pin sense / ELD callback

[Daniel Vetter]

On Fri, Aug 28, 2015 at 07:02:27PM +0200, David Henningsson wrote:
> This callback will be called by the i915 driver to notify the hda
> driver that its HDMI information needs to be refreshed, i e,
> that audio output is now available (or unavailable) - usually as a
> result of a monitor being plugged in (or unplugged).
> 
> Reviewed-by: Jani Nikula 
> Signed-off-by: David Henningsson 
> ---
>  include/drm/i915_component.h | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index c9a8b64..c0f4d45 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -34,6 +34,22 @@ struct i915_audio_component {
>   void (*codec_wake_override)(struct device *, bool enable);
>   int (*get_cdclk_freq)(struct device *);
>   } *ops;
> +
> + const struct i915_audio_component_audio_ops {
> + /**
> +  * @audio_ptr:
> +  *
> +  * Pointer to pass when calling pin_eld_notify.
> +  */
> + void *audio_ptr;
> + /**
> +  * @pin_eld_notify:
> +  *
> +  * Called from i915 driver, notifying the HDA driver that
> +  * pin sense and/or ELD information has changed.
> +  */
> + void (*pin_eld_notify)(void *audio_ptr, int port);

Kerneldoc looks good now, but it won't be of much use with an include
directive into the drm.tmpl docbook. Can you please coordinate with Libin
on that?

Thanks, Daniel

> + } *audio_ops;
>  };
>  
>  #endif /* _I915_COMPONENT_H_ */
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[Daniel Vetter]

On Fri, Aug 28, 2015 at 08:14:48PM +0300, Jani Nikula wrote:
> On Fri, 28 Aug 2015, David Henningsson  
> wrote:
> > Hopefully last version? :-)
> >
> >  * Added commit text about duplicate events (patch 4/4)
> >  * Added locks in bind/unbind on i915 side (patch 2/4)
> >  * Fixed docbook comments in i915 struct (patch 1/4)
> >  * Removed port_mst_streaming parameter (patch 1/4)
> >  * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
> >Hopefully this was correct, otherwise feel free to adjust
> >yourself before committing.
> >
> > Both Jani and Takashi seem okay with this going into 4.3. 
> > Nobody has said which tree you prefer to take it through, so
> > how about Takashi merging it?
> 
> I think there's a slight conflict with Libin's series [1], so both
> should probably go through the same tree. I'm fine with either.

Yeah makes sense. Takashi can you please pull in this entire series into
your tree too?

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

[Intel-gfx] [PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave -

i915 display fixes headed for v4.3. Mostly SKL, but some regression
fixes too.

BR,
Jani.

The following changes since commit 26951caf55d73ceb1967b0bf12f6d0b96853508e:

  drm/i915/skl: enable DDI-E hotplug (2015-08-26 10:24:25 +0300)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-09-02

for you to fetch changes up to 6fa2d197936ba0b8936e813d0adecefac160062b:

  i915: Set ddi_pll_sel in DP MST path (2015-09-01 12:42:27 +0300)


Ander Conselvan de Oliveira (1):
  i915: Set ddi_pll_sel in DP MST path

Gary Wang (1):
  drm/i915: set CDCLK if DPLL0 enabled during resuming from S3

Imre Deak (1):
  drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre 
GEN6

Lukas Wunner (1):
  drm/i915: Preserve SSC earlier

Rodrigo Vivi (2):
  drm/i915/skl: Enable DDI-E
  drm/i915: eDP can be present on DDI-E

Ville Syrjälä (2):
  drm/i915: Check DP link status on long hpd too
  drm/i915: Don't use link_bw for PLL setup

Xiong Zhang (2):
  drm/i915: Enable HDMI on DDI-E
  drm/i915/skl: Adding DDI_E power well domain

 drivers/gpu/drm/i915/i915_debugfs.c |  2 +
 drivers/gpu/drm/i915/i915_drv.c | 15 +---
 drivers/gpu/drm/i915/i915_drv.h |  6 +++
 drivers/gpu/drm/i915/intel_bios.c   | 39 +--
 drivers/gpu/drm/i915/intel_bios.h   |  7 +---
 drivers/gpu/drm/i915/intel_ddi.c| 11 ++
 drivers/gpu/drm/i915/intel_display.c| 54 +--
 drivers/gpu/drm/i915/intel_dp.c | 66 -
 drivers/gpu/drm/i915/intel_dp_mst.c |  5 +++
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_hdmi.c   | 21 +++
 drivers/gpu/drm/i915/intel_runtime_pm.c |  2 +
 12 files changed, 147 insertions(+), 82 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP

[Daniel Vetter]

On Mon, Aug 31, 2015 at 02:35:32PM +0530, Sonika Jindal wrote:
> From: Durgadoss R 
> 
> Currently, HDMI hotplug with eDP as local panel is failing
> because the HDMI hpd is detected as a long hpd for eDP; and is
> thus rightfully ignored. But, it should really be handled as
> an interrupt on port B for HDMI (due to BXT A1 platform having
> HPD pins A and B swapped). This patch sets the irq_port[PORT_A]
> to NULL in case eDP is on port A so that irq handler does not
> treat it as a 'dig_port' interrupt.
> 
> v2 (Sonika): Moving the setting of irq_port for BXT WA outside so that this
> can be set for both hdmi or dp ports. For HDMI this is required
> because we get interrupts for portB on the hpd line of portA for
> BXT A0/A1.
> This issue occurred because hpd on edp was not disabled
> which was done as part of "drm/i915: Dont enable hpd for eDP" from
> the series:
> http://lists.freedesktop.org/archives/intel-gfx/2015-August/073266.html
> 
> This patch can be squashed to :
> commit cf1d58833f07afbb4534b15caa3fd48baa313b2c
> Author: Sonika Jindal 
> Date:   Mon Aug 10 10:35:36 2015 +0530
> 
> drm/i915/bxt: WA for swapped HPD pins in A stepping
> 
> Signed-off-by: Durgadoss R 
> Signed-off-by: Sonika Jindal 

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_ddi.c |   21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 56d778f..bba0cb6 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3242,15 +3242,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
> port)
>   goto err;
>  
>   intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> - /*
> -  * On BXT A0/A1, sw needs to activate DDIA HPD logic and
> -  * interrupts to check the external panel connection.
> -  */
> - if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)
> -  && port == PORT_B)
> - dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> - else
> - dev_priv->hotplug.irq_port[port] = intel_dig_port;
> + dev_priv->hotplug.irq_port[port] = intel_dig_port;
>   }
>  
>   /* In theory we don't need the encoder->type check, but leave it just in
> @@ -3259,6 +3251,17 @@ void intel_ddi_init(struct drm_device *dev, enum port 
> port)
>   if (!intel_ddi_init_hdmi_connector(intel_dig_port))
>   goto err;
>   }
> + /*
> +  * On BXT A0/A1, sw needs to activate DDIA HPD logic and
> +  * interrupts to check the external panel connection.
> +  */
> + if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
> + if (port == PORT_B) {
> + dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> + intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> + } else if (intel_encoder->type == INTEL_OUTPUT_EDP)
> + dev_priv->hotplug.irq_port[port] = NULL;
> + }
>  
>   return;
>  
> -- 
> 1.7.10.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP

[Jindal, Sonika]

:( This had a hole..
Please drop this patch..

I am going to send another patch tested with hdmi optimization series for bxt.

Regards,
Sonika

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, September 2, 2015 5:17 PM
To: Jindal, Sonika
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP

On Mon, Aug 31, 2015 at 02:35:32PM +0530, Sonika Jindal wrote:
> From: Durgadoss R 
> 
> Currently, HDMI hotplug with eDP as local panel is failing because the 
> HDMI hpd is detected as a long hpd for eDP; and is thus rightfully 
> ignored. But, it should really be handled as an interrupt on port B 
> for HDMI (due to BXT A1 platform having HPD pins A and B swapped). 
> This patch sets the irq_port[PORT_A] to NULL in case eDP is on port A 
> so that irq handler does not treat it as a 'dig_port' interrupt.
> 
> v2 (Sonika): Moving the setting of irq_port for BXT WA outside so that 
> this can be set for both hdmi or dp ports. For HDMI this is required 
> because we get interrupts for portB on the hpd line of portA for BXT 
> A0/A1.
> This issue occurred because hpd on edp was not disabled which was done 
> as part of "drm/i915: Dont enable hpd for eDP" from the series:
> http://lists.freedesktop.org/archives/intel-gfx/2015-August/073266.htm
> l
> 
> This patch can be squashed to :
> commit cf1d58833f07afbb4534b15caa3fd48baa313b2c
> Author: Sonika Jindal 
> Date:   Mon Aug 10 10:35:36 2015 +0530
> 
> drm/i915/bxt: WA for swapped HPD pins in A stepping
> 
> Signed-off-by: Durgadoss R 
> Signed-off-by: Sonika Jindal 

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_ddi.c |   21 -
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 56d778f..bba0cb6 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3242,15 +3242,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
> port)
>   goto err;
>  
>   intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> - /*
> -  * On BXT A0/A1, sw needs to activate DDIA HPD logic and
> -  * interrupts to check the external panel connection.
> -  */
> - if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)
> -  && port == PORT_B)
> - dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> - else
> - dev_priv->hotplug.irq_port[port] = intel_dig_port;
> + dev_priv->hotplug.irq_port[port] = intel_dig_port;
>   }
>  
>   /* In theory we don't need the encoder->type check, but leave it 
> just in @@ -3259,6 +3251,17 @@ void intel_ddi_init(struct drm_device *dev, 
> enum port port)
>   if (!intel_ddi_init_hdmi_connector(intel_dig_port))
>   goto err;
>   }
> + /*
> +  * On BXT A0/A1, sw needs to activate DDIA HPD logic and
> +  * interrupts to check the external panel connection.
> +  */
> + if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
> + if (port == PORT_B) {
> + dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> + intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> + } else if (intel_encoder->type == INTEL_OUTPUT_EDP)
> + dev_priv->hotplug.irq_port[port] = NULL;
> + }
>  
>   return;
>  
> --
> 1.7.10.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP

[Daniel Vetter]

On Wed, Sep 02, 2015 at 11:48:36AM +, Jindal, Sonika wrote:
> :( This had a hole..
> Please drop this patch..

What kind of hole? It sounds like we need this to avoid blowing up when we
handle the edp hpd interrupt everywhere? Please explain so I can
understand what I've missed here ...

Thanks, Daniel

> 
> I am going to send another patch tested with hdmi optimization series for bxt.
> 
> Regards,
> Sonika
> 
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Wednesday, September 2, 2015 5:17 PM
> To: Jindal, Sonika
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP
> 
> On Mon, Aug 31, 2015 at 02:35:32PM +0530, Sonika Jindal wrote:
> > From: Durgadoss R 
> > 
> > Currently, HDMI hotplug with eDP as local panel is failing because the 
> > HDMI hpd is detected as a long hpd for eDP; and is thus rightfully 
> > ignored. But, it should really be handled as an interrupt on port B 
> > for HDMI (due to BXT A1 platform having HPD pins A and B swapped). 
> > This patch sets the irq_port[PORT_A] to NULL in case eDP is on port A 
> > so that irq handler does not treat it as a 'dig_port' interrupt.
> > 
> > v2 (Sonika): Moving the setting of irq_port for BXT WA outside so that 
> > this can be set for both hdmi or dp ports. For HDMI this is required 
> > because we get interrupts for portB on the hpd line of portA for BXT 
> > A0/A1.
> > This issue occurred because hpd on edp was not disabled which was done 
> > as part of "drm/i915: Dont enable hpd for eDP" from the series:
> > http://lists.freedesktop.org/archives/intel-gfx/2015-August/073266.htm
> > l
> > 
> > This patch can be squashed to :
> > commit cf1d58833f07afbb4534b15caa3fd48baa313b2c
> > Author: Sonika Jindal 
> > Date:   Mon Aug 10 10:35:36 2015 +0530
> > 
> > drm/i915/bxt: WA for swapped HPD pins in A stepping
> > 
> > Signed-off-by: Durgadoss R 
> > Signed-off-by: Sonika Jindal 
> 
> Queued for -next, thanks for the patch.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c |   21 -
> >  1 file changed, 12 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 56d778f..bba0cb6 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -3242,15 +3242,7 @@ void intel_ddi_init(struct drm_device *dev, enum 
> > port port)
> > goto err;
> >  
> > intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> > -   /*
> > -* On BXT A0/A1, sw needs to activate DDIA HPD logic and
> > -* interrupts to check the external panel connection.
> > -*/
> > -   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)
> > -&& port == PORT_B)
> > -   dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> > -   else
> > -   dev_priv->hotplug.irq_port[port] = intel_dig_port;
> > +   dev_priv->hotplug.irq_port[port] = intel_dig_port;
> > }
> >  
> > /* In theory we don't need the encoder->type check, but leave it 
> > just in @@ -3259,6 +3251,17 @@ void intel_ddi_init(struct drm_device *dev, 
> > enum port port)
> > if (!intel_ddi_init_hdmi_connector(intel_dig_port))
> > goto err;
> > }
> > +   /*
> > +* On BXT A0/A1, sw needs to activate DDIA HPD logic and
> > +* interrupts to check the external panel connection.
> > +*/
> > +   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
> > +   if (port == PORT_B) {
> > +   dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> > +   intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> > +   } else if (intel_encoder->type == INTEL_OUTPUT_EDP)
> > +   dev_priv->hotplug.irq_port[port] = NULL;
> > +   }
> >  
> > return;
> >  
> > --
> > 1.7.10.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Also record time difference if vblank evasion fails, v2.

[Daniel Vetter]

On Tue, Sep 01, 2015 at 12:15:33PM +0200, Maarten Lankhorst wrote:
> This makes the error message slightly more useful.
> 
> Changes since v1:
> - Use ktime_get() while irqs are still disabled. (vsyrjala)
> 
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Ville Syrjälä 

Both applied to dinq, thanks.
-Daniel

> ---
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 63f0d5850cdf..b0c3a3af7ed2 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -563,6 +563,8 @@ struct intel_crtc {
>   int scanline_offset;
>  
>   unsigned start_vbl_count;
> + ktime_t start_vbl_time;
> +
>   struct intel_crtc_atomic_commit atomic;
>  
>   /* scalers available on this crtc */
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 63fba42be2cf..9387af5ef1b8 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -134,6 +134,7 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
>  
>   drm_crtc_vblank_put(&crtc->base);
>  
> + crtc->start_vbl_time = ktime_get();
>   crtc->start_vbl_count = dev->driver->get_vblank_counter(dev, pipe);
>  
>   trace_i915_pipe_update_vblank_evaded(crtc, min, max,
> @@ -154,14 +155,16 @@ void intel_pipe_update_end(struct intel_crtc *crtc)
>   struct drm_device *dev = crtc->base.dev;
>   enum pipe pipe = crtc->pipe;
>   u32 end_vbl_count = dev->driver->get_vblank_counter(dev, pipe);
> + ktime_t end_vbl_time = ktime_get();
>  
>   trace_i915_pipe_update_end(crtc, end_vbl_count);
>  
>   local_irq_enable();
>  
>   if (crtc->start_vbl_count && crtc->start_vbl_count != end_vbl_count)
> - DRM_ERROR("Atomic update failure on pipe %c (start=%u 
> end=%u)\n",
> -   pipe_name(pipe), crtc->start_vbl_count, 
> end_vbl_count);
> + DRM_ERROR("Atomic update failure on pipe %c (start=%u end=%u) 
> time %lld us\n",
> +   pipe_name(pipe), crtc->start_vbl_count, end_vbl_count,
> +   ktime_us_delta(end_vbl_time, crtc->start_vbl_time));
>  }
>  
>  static void
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Always mark the object as dirty when used by the GPU

[Daniel Vetter]

On Mon, Aug 31, 2015 at 03:10:39PM +0100, Chris Wilson wrote:
> There have been many hard to track down bugs whereby userspace forgot to
> flag a write buffer and then cause graphics corruption or a hung GPU
> when that buffer was later purged under memory pressure (as the buffer
> appeared clean, its pages would have been evicted rather than preserved
> and any changes more recent than in the backing storage would be lost).
> In retrospect this is a rare optimisation against memory pressure,
> already the slow path. If we always mark the buffer as dirty when
> accessed by the GPU, anything not used can still be evicted cheaply
> (ideal behaviour for mark-and-sweep eviction) but we do not run the risk
> of corruption. For correct read serialisation, userspace still has to
> notify when the GPU writes to an object. However, there are certain
> situations under which userspace may wish to tell white lies to the
> kernel...
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Kristian Høgsberg 
> Cc: Jesse Barnes 
> Cc: "Goel, Akash" 
> Cc: Michał Winiarski 
> Cc: sta...@vger.kernel.org

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 923a3c4bf0b7..a953d4975b8c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1032,6 +1032,7 @@ i915_gem_execbuffer_move_to_active(struct list_head 
> *vmas,
>   u32 old_read = obj->base.read_domains;
>   u32 old_write = obj->base.write_domain;
>  
> + obj->dirty = 1; /* be paranoid  */
>   obj->base.write_domain = obj->base.pending_write_domain;
>   if (obj->base.write_domain == 0)
>   obj->base.pending_read_domains |= 
> obj->base.read_domains;
> @@ -1039,7 +1040,6 @@ i915_gem_execbuffer_move_to_active(struct list_head 
> *vmas,
>  
>   i915_vma_move_to_active(vma, req);
>   if (obj->base.write_domain) {
> - obj->dirty = 1;
>   i915_gem_request_assign(&obj->last_write_req, req);
>  
>   intel_fb_obj_invalidate(obj, ORIGIN_CS);
> -- 
> 2.5.1
> 

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

Re: [Intel-gfx] [PATCH] uapi/drm/i915_drm.h: fix userspace compilation.

[Ville Syrjälä]

On Wed, Sep 02, 2015 at 01:41:18PM +0200, Artem Savkov wrote:
> Patch "drm/i915: Use expcitly fixed type in compat32 structs" changed the type
> of param field in drm_i915_getparam from int to s32. This header is exported 
> to
> userspace and needs to use userspace type __s32 instead.
> 
> This fixes userspace compilation errors like the following:
> include/drm/i915_drm.h:361:2: error: unknown type name 's32'
>   s32 param;
> 
> Signed-off-by: Artem Savkov 
> ---
>  include/uapi/drm/i915_drm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index dbd16a2..fd5aa47 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -358,7 +358,7 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_HAS_RESOURCE_STREAMER 36
>  
>  typedef struct drm_i915_getparam {
> - s32 param;
> + __s32 param;

Hmm. I don't understand why this one in particular got changed to s32
when there are other ioctl structs still using int.

>   /*
>* WARNING: Using pointers instead of fixed-size u64 means we need to 
> write
>* compat32 code. Don't repeat this mistake.
> -- 
> 2.1.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm: Add a non-locking version of drm_kms_helper_poll_enable().

[Daniel Vetter]

On Tue, Sep 01, 2015 at 10:21:32PM +0200, Egbert Eich wrote:
> drm_kms_helper_poll_enable() was converted to lock the mode_config
> mutex in commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
> ("drm/probe-helper: Grab mode_config.mutex in poll_init/enable").
> 
> This disregarded the cases where this function is called from a context
> where this mutex is already locked.
> 
> Add a non-locking version as well.
> 
> Signed-off-by: Egbert Eich 
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 19 ---
>  include/drm/drm_crtc_helper.h  |  1 +
>  2 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index d734780..a93ad1b 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -93,8 +93,19 @@ static int drm_helper_probe_add_cmdline_mode(struct 
> drm_connector *connector)
>   return 1;
>  }
>  
> +/**
> + * drm_kms_helper_poll_enable_no_lock - re-enable output polling.
> + * @dev: drm_device
> + *
> + * This function re-enables the output polling work without
> + * locking the mode_config mutex.
> + *
> + * This is like drm_kms_helper_poll_enable() however it is to be
> + * called from a context where the mode_config mutex is locked
> + * already.
> + */
>  #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
> -static void __drm_kms_helper_poll_enable(struct drm_device *dev)
> +void drm_kms_helper_poll_enable_no_lock(struct drm_device *dev)

Please use _locked to stay consistent with other such functions. With that
address this lgtm.
-Daniel

>  {
>   bool poll = false;
>   struct drm_connector *connector;
> @@ -113,6 +124,8 @@ static void __drm_kms_helper_poll_enable(struct 
> drm_device *dev)
>   if (poll)
>   schedule_delayed_work(&dev->mode_config.output_poll_work, 
> DRM_OUTPUT_POLL_PERIOD);
>  }
> +EXPORT_SYMBOL(drm_kms_helper_poll_enable_no_lock);
> +
>  
>  static int drm_helper_probe_single_connector_modes_merge_bits(struct 
> drm_connector *connector,
> uint32_t maxX, 
> uint32_t maxY, bool merge_type_bits)
> @@ -174,7 +187,7 @@ static int 
> drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
>  
>   /* Re-enable polling in case the global poll config changed. */
>   if (drm_kms_helper_poll != dev->mode_config.poll_running)
> - __drm_kms_helper_poll_enable(dev);
> + drm_kms_helper_poll_enable_no_lock(dev);
>  
>   dev->mode_config.poll_running = drm_kms_helper_poll;
>  
> @@ -428,7 +441,7 @@ EXPORT_SYMBOL(drm_kms_helper_poll_disable);
>  void drm_kms_helper_poll_enable(struct drm_device *dev)
>  {
>   mutex_lock(&dev->mode_config.mutex);
> - __drm_kms_helper_poll_enable(dev);
> + drm_kms_helper_poll_enable_no_lock(dev);
>   mutex_unlock(&dev->mode_config.mutex);
>  }
>  EXPORT_SYMBOL(drm_kms_helper_poll_enable);
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 2a747a9..f96703d 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -240,5 +240,6 @@ extern void drm_kms_helper_hotplug_event(struct 
> drm_device *dev);
>  
>  extern void drm_kms_helper_poll_disable(struct drm_device *dev);
>  extern void drm_kms_helper_poll_enable(struct drm_device *dev);
> +extern void drm_kms_helper_poll_enable_no_lock(struct drm_device *dev);
>  
>  #endif
> -- 
> 1.8.4.5
> 

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Call non-locking version of drm_kms_helper_poll_enable()

[Daniel Vetter]

On Tue, Sep 01, 2015 at 10:21:33PM +0200, Egbert Eich wrote:
> drm_kms_helper_poll_enable() is called from a context in
> intel_hpd_irq_storm_disable() where the the mode_config mutex is
> already locked.
> When this function was converted to lock this mutex in:
> 
> commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
> Author: Daniel Vetter 
> Date:   Thu Jul 9 23:44:26 2015 +0200
> 
> drm/probe-helper: Grab mode_config.mutex in poll_init/enable
> 
> a deadlock occurred.
> Call the newly implemented non-locking version of this function.
> 
> Signed-off-by: Egbert Eich 

Oops. Reviewed-by: Daniel Vetter  if you do the
s/_no_lock/_locked/ for consistency on both patch 1&2.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 53c0173..77dd5b6 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -180,7 +180,7 @@ static void intel_hpd_irq_storm_disable(struct 
> drm_i915_private *dev_priv)
>  
>   /* Enable polling and queue hotplug re-enabling. */
>   if (hpd_disabled) {
> - drm_kms_helper_poll_enable(dev);
> + drm_kms_helper_poll_enable_no_lock(dev);
>   mod_delayed_work(system_wq, &dev_priv->hotplug.reenable_work,
>msecs_to_jiffies(HPD_STORM_REENABLE_DELAY));
>   }
> -- 
> 1.8.4.5
> 

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

Re: [Intel-gfx] [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[Takashi Iwai]

On Wed, 02 Sep 2015 13:45:03 +0200,
Daniel Vetter wrote:
> 
> On Fri, Aug 28, 2015 at 08:14:48PM +0300, Jani Nikula wrote:
> > On Fri, 28 Aug 2015, David Henningsson  
> > wrote:
> > > Hopefully last version? :-)
> > >
> > >  * Added commit text about duplicate events (patch 4/4)
> > >  * Added locks in bind/unbind on i915 side (patch 2/4)
> > >  * Fixed docbook comments in i915 struct (patch 1/4)
> > >  * Removed port_mst_streaming parameter (patch 1/4)
> > >  * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
> > >Hopefully this was correct, otherwise feel free to adjust
> > >yourself before committing.
> > >
> > > Both Jani and Takashi seem okay with this going into 4.3. 
> > > Nobody has said which tree you prefer to take it through, so
> > > how about Takashi merging it?
> > 
> > I think there's a slight conflict with Libin's series [1], so both
> > should probably go through the same tree. I'm fine with either.
> 
> Yeah makes sense. Takashi can you please pull in this entire series into
> your tree too?

Do you mean Libin's series or David's?  I already applied David's
patches (including drm/i915 changes) to for-next of sound git tree
now.  Shall I merge Libin's patches to my branch, too?

The branch is supposed to be stable, so feel free to pull into your
testing branch.


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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP

[Jindal, Sonika]

When hpd occurs on port_b, due to the below assignment, it calls 
digital_port_wok_func first.
There it tries to check the connector status for port B (actually checking port 
A's HPD pin due to the BXT WA).
It finds it connected and continues to read the dpcd. Since this port was only 
initialized as HDMI and not initialized as DP, we haven't initialized the aux 
and causes crash in the case when the port is only enumerated as HDMI alone.
So, this part needs to be moved under the init_dp check itself.
I will be posting Durga's original patch along with hdmi patches because this 
is required for hdmi to work on bxt.

Regards,
Sonika

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Wednesday, September 2, 2015 5:21 PM
To: Jindal, Sonika
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP

On Wed, Sep 02, 2015 at 11:48:36AM +, Jindal, Sonika wrote:
> :( This had a hole..
> Please drop this patch..

What kind of hole? It sounds like we need this to avoid blowing up when we 
handle the edp hpd interrupt everywhere? Please explain so I can understand 
what I've missed here ...

Thanks, Daniel

> 
> I am going to send another patch tested with hdmi optimization series for bxt.
> 
> Regards,
> Sonika
> 
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of 
> Daniel Vetter
> Sent: Wednesday, September 2, 2015 5:17 PM
> To: Jindal, Sonika
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix irq_port for eDP
> 
> On Mon, Aug 31, 2015 at 02:35:32PM +0530, Sonika Jindal wrote:
> > From: Durgadoss R 
> > 
> > Currently, HDMI hotplug with eDP as local panel is failing because 
> > the HDMI hpd is detected as a long hpd for eDP; and is thus 
> > rightfully ignored. But, it should really be handled as an interrupt 
> > on port B for HDMI (due to BXT A1 platform having HPD pins A and B swapped).
> > This patch sets the irq_port[PORT_A] to NULL in case eDP is on port 
> > A so that irq handler does not treat it as a 'dig_port' interrupt.
> > 
> > v2 (Sonika): Moving the setting of irq_port for BXT WA outside so 
> > that this can be set for both hdmi or dp ports. For HDMI this is 
> > required because we get interrupts for portB on the hpd line of 
> > portA for BXT A0/A1.
> > This issue occurred because hpd on edp was not disabled which was 
> > done as part of "drm/i915: Dont enable hpd for eDP" from the series:
> > http://lists.freedesktop.org/archives/intel-gfx/2015-August/073266.h
> > tm
> > l
> > 
> > This patch can be squashed to :
> > commit cf1d58833f07afbb4534b15caa3fd48baa313b2c
> > Author: Sonika Jindal 
> > Date:   Mon Aug 10 10:35:36 2015 +0530
> > 
> > drm/i915/bxt: WA for swapped HPD pins in A stepping
> > 
> > Signed-off-by: Durgadoss R 
> > Signed-off-by: Sonika Jindal 
> 
> Queued for -next, thanks for the patch.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c |   21 -
> >  1 file changed, 12 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 56d778f..bba0cb6 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -3242,15 +3242,7 @@ void intel_ddi_init(struct drm_device *dev, enum 
> > port port)
> > goto err;
> >  
> > intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> > -   /*
> > -* On BXT A0/A1, sw needs to activate DDIA HPD logic and
> > -* interrupts to check the external panel connection.
> > -*/
> > -   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)
> > -&& port == PORT_B)
> > -   dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> > -   else
> > -   dev_priv->hotplug.irq_port[port] = intel_dig_port;
> > +   dev_priv->hotplug.irq_port[port] = intel_dig_port;
> > }
> >  
> > /* In theory we don't need the encoder->type check, but leave it 
> > just in @@ -3259,6 +3251,17 @@ void intel_ddi_init(struct drm_device *dev, 
> > enum port port)
> > if (!intel_ddi_init_hdmi_connector(intel_dig_port))
> > goto err;
> > }
> > +   /*
> > +* On BXT A0/A1, sw needs to activate DDIA HPD logic and
> > +* interrupts to check the external panel connection.
> > +*/
> > +   if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) {
> > +   if (port == PORT_B) {
> > +   dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port;
> > +   intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
> > +   } else if (intel_encoder->type == INTEL_OUTPUT_EDP)
> > +   dev_priv->hotplug.irq_port[port] = NULL;
> > +   }
> >  
> > return;
> >  
> > --
> > 1.7.10.4

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use the correct hpd_status list for non-G4xx/VLV

[Daniel Vetter]

On Tue, Sep 01, 2015 at 10:21:34PM +0200, Egbert Eich wrote:
> This copy-and-past error was introduced in:
> 
> commit fd63e2a972c670887e5e8a08440111d3812c0996
> Author: Imre Deak 
> Date:   Tue Jul 21 15:32:44 2015 -0700
> 
> drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins
> 
> Signed-off-by: Egbert Eich 

I recommend to cc: the authors/reviewers of the patch which broke things
so they have a better chance to spot your patch and make amends by quickly
reviewing your fix. Anyway Reviewed-by: Daniel Vetter 

Jani, this all seems to be for you.
-Daniel
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 8485bea..ad99dae 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1559,7 +1559,7 @@ static void i9xx_hpd_irq_handler(struct drm_device *dev)
>   u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
>  
>   intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> -hotplug_trigger, hpd_status_g4x,
> +hotplug_trigger, hpd_status_i915,
>  i9xx_port_hotplug_long_detect);
>   intel_hpd_irq_handler(dev, pin_mask, long_mask);
>   }
> -- 
> 1.8.4.5
> 

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt

[Daniel Vetter]

On Tue, Sep 01, 2015 at 10:21:35PM +0200, Egbert Eich wrote:
> A HPD interrupt may fire during intel_crt_detect_hotplug() - especially
> when HPD interrupt storms occur.
> Since the interrupt handler changes the enabled interrupt lines when it
> detects a storm this races with intel_crt_detect_hotplug().
> To avoid this, shiled the rmw cycles with IRQ save spinlocks.
> 
> Signed-off-by: Egbert Eich 

I think this only reduces one source of such races, but fundamentally we
can't avoid them. E.g. if you're _very_ unlucky you might cause a real hpd
right when the strom code frobs around. Plugging the race with this known
interrupt source here doesn't fix the fundamental issue.

Also I think the actual interrupt deliver is fairly asynchronous, both in
the hardware and in the sw handling. E.g. spin_lock_irq does not
synchronize with the interrupt handler on SMP systems, it only guarantees
that it's not running concurrently on the same cpu (which would deadlock).

I think fundamentally this race is unfixable.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_crt.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index af5e43b..685f3de 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -376,9 +376,10 @@ static bool intel_crt_detect_hotplug(struct 
> drm_connector *connector)
>  {
>   struct drm_device *dev = connector->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - u32 hotplug_en, orig, stat;
> + u32 hotplug_en, stat;
>   bool ret = false;
>   int i, tries = 0;
> + unsigned long irqflags;
>  
>   if (HAS_PCH_SPLIT(dev))
>   return intel_ironlake_crt_detect_hotplug(connector);
> @@ -395,12 +396,14 @@ static bool intel_crt_detect_hotplug(struct 
> drm_connector *connector)
>   tries = 2;
>   else
>   tries = 1;
> - hotplug_en = orig = I915_READ(PORT_HOTPLUG_EN);
> - hotplug_en |= CRT_HOTPLUG_FORCE_DETECT;
>  
>   for (i = 0; i < tries ; i++) {
>   /* turn on the FORCE_DETECT */
> - I915_WRITE(PORT_HOTPLUG_EN, hotplug_en);
> + spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> + hotplug_en = I915_READ(PORT_HOTPLUG_EN);
> + I915_WRITE(PORT_HOTPLUG_EN, hotplug_en |
> +CRT_HOTPLUG_FORCE_DETECT);
> + spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
>   /* wait for FORCE_DETECT to go off */
>   if (wait_for((I915_READ(PORT_HOTPLUG_EN) &
> CRT_HOTPLUG_FORCE_DETECT) == 0,
> @@ -416,7 +419,11 @@ static bool intel_crt_detect_hotplug(struct 
> drm_connector *connector)
>   I915_WRITE(PORT_HOTPLUG_STAT, CRT_HOTPLUG_INT_STATUS);
>  
>   /* and put the bits back */
> - I915_WRITE(PORT_HOTPLUG_EN, orig);
> + spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> + hotplug_en = I915_READ(PORT_HOTPLUG_EN);
> + hotplug_en &= ~CRT_HOTPLUG_FORCE_DETECT;
> + I915_WRITE(PORT_HOTPLUG_EN, hotplug_en);
> + spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
>  
>   return ret;
>  }
> -- 
> 1.8.4.5
> 

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

Re: [Intel-gfx] [PATCH 0/4 v5] i915 to call hda driver on HDMI plug/unplug

[Daniel Vetter]

On Wed, Sep 02, 2015 at 01:59:30PM +0200, Takashi Iwai wrote:
> On Wed, 02 Sep 2015 13:45:03 +0200,
> Daniel Vetter wrote:
> > 
> > On Fri, Aug 28, 2015 at 08:14:48PM +0300, Jani Nikula wrote:
> > > On Fri, 28 Aug 2015, David Henningsson  
> > > wrote:
> > > > Hopefully last version? :-)
> > > >
> > > >  * Added commit text about duplicate events (patch 4/4)
> > > >  * Added locks in bind/unbind on i915 side (patch 2/4)
> > > >  * Fixed docbook comments in i915 struct (patch 1/4)
> > > >  * Removed port_mst_streaming parameter (patch 1/4)
> > > >  * Added Reviewed-by - 1 & 2 by Jani, 3 & 4 by Takashi.
> > > >Hopefully this was correct, otherwise feel free to adjust
> > > >yourself before committing.
> > > >
> > > > Both Jani and Takashi seem okay with this going into 4.3. 
> > > > Nobody has said which tree you prefer to take it through, so
> > > > how about Takashi merging it?
> > > 
> > > I think there's a slight conflict with Libin's series [1], so both
> > > should probably go through the same tree. I'm fine with either.
> > 
> > Yeah makes sense. Takashi can you please pull in this entire series into
> > your tree too?
> 
> Do you mean Libin's series or David's?  I already applied David's
> patches (including drm/i915 changes) to for-next of sound git tree
> now.  Shall I merge Libin's patches to my branch, too?

I was a few days behind on mails and made a bit a mess between these two
patch series. I thought both David's and Libin's series is ready, but
let's ask Jani to confirm ;-)

> The branch is supposed to be stable, so feel free to pull into your
> testing branch.

Ok. I'll ping you if I do pull something which isn't in upstream just in.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: add kerneldoc for i915_audio_component

[Daniel Vetter]

On Wed, Sep 02, 2015 at 02:12:24PM +0800, libin.y...@intel.com wrote:
> From: Libin Yang 
> 
> Add the kerneldoc for i915_audio_component in i915_component.h
> 
> Signed-off-by: Libin Yang 
> ---
>  include/drm/i915_component.h | 39 ---
>  1 file changed, 24 insertions(+), 15 deletions(-)
> 
> diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> index 8ad6f1b..187acc8 100644
> --- a/include/drm/i915_component.h
> +++ b/include/drm/i915_component.h
> @@ -24,23 +24,32 @@
>  #ifndef _I915_COMPONENT_H_
>  #define _I915_COMPONENT_H_
>  
> +/**
> + * struct i915_audio_component_ops - callbacks defined in gfx driver
> + * @owner: the module owner
> + * @get_power: get the POWER_DOMAIN_AUDIO power well
> + * @put_power: put the POWER_DOMAIN_AUDIO power well
> + * @codec_wake_override: Enable/Disable generating the codec wake signal
> + * @get_cdclk_freq: get the Core Display Clock in KHz
> + * @sync_audio_rate: set n/cts based on the sample rate
> + */
> +struct i915_audio_component_ops {
> + struct module *owner;

New kerneldoc in 4.3 allows you to split structure documentation up into
per-member comments. Especially with vtables I think this makes a lot of
sense, since then you have enough space to document where and how exactly
a given hook is called (looks, place in the overall sequence).

Also please include your stancas in the drm.tmpl docbook template,
otherwise it won't be included in the html docs. And finally please add a
DOC: overview section which explains at a high level how i915 and
hda-intel corporate for hdmi/dp audio.

Thanks, Daniel

> + void (*get_power)(struct device *);
> + void (*put_power)(struct device *);
> + void (*codec_wake_override)(struct device *, bool enable);
> + int (*get_cdclk_freq)(struct device *);
> + int (*sync_audio_rate)(struct device *, int port, int rate);
> +};
> +
> +/**
> + * struct i915_audio_component - used for audio video interaction
> + * @dev: the device from gfx driver
> + * @ops: callback for audio driver calling
> + */
>  struct i915_audio_component {
>   struct device *dev;
> -
> - const struct i915_audio_component_ops {
> - struct module *owner;
> - void (*get_power)(struct device *);
> - void (*put_power)(struct device *);
> - void (*codec_wake_override)(struct device *, bool enable);
> - int (*get_cdclk_freq)(struct device *);
> - /**
> -  * @sync_audio_rate: set n/cts based on the sample rate
> -  *
> -  * Called from audio driver. After audio driver sets the
> -  * sample rate, it will call this function to set n/cts
> -  */
> - int (*sync_audio_rate)(struct device *, int port, int rate);
> - } *ops;
> + const struct i915_audio_component_ops *ops;
>  };
>  
>  #endif /* _I915_COMPONENT_H_ */
> -- 
> 1.9.1
> 

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

Re: [Intel-gfx] [PATCH] uapi/drm/i915_drm.h: fix userspace compilation.

[Daniel Vetter]

On Wed, Sep 02, 2015 at 02:52:19PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 02, 2015 at 01:41:18PM +0200, Artem Savkov wrote:
> > Patch "drm/i915: Use expcitly fixed type in compat32 structs" changed the 
> > type
> > of param field in drm_i915_getparam from int to s32. This header is 
> > exported to
> > userspace and needs to use userspace type __s32 instead.
> > 
> > This fixes userspace compilation errors like the following:
> > include/drm/i915_drm.h:361:2: error: unknown type name 's32'
> >   s32 param;
> > 
> > Signed-off-by: Artem Savkov 
> > ---
> >  include/uapi/drm/i915_drm.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index dbd16a2..fd5aa47 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -358,7 +358,7 @@ typedef struct drm_i915_irq_wait {
> >  #define I915_PARAM_HAS_RESOURCE_STREAMER 36
> >  
> >  typedef struct drm_i915_getparam {
> > -   s32 param;
> > +   __s32 param;
> 
> Hmm. I don't understand why this one in particular got changed to s32
> when there are other ioctl structs still using int.

Mostly me being incompetent.

Reviewed-by: Daniel Vetter  on this one, not that
it seems to be worth much ...
-Daniel

> 
> > /*
> >  * WARNING: Using pointers instead of fixed-size u64 means we need to 
> > write
> >  * compat32 code. Don't repeat this mistake.
> > -- 
> > 2.1.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use the correct hpd_status list for non-G4xx/VLV

[Imre Deak]

On ke, 2015-09-02 at 14:00 +0200, Daniel Vetter wrote:
> On Tue, Sep 01, 2015 at 10:21:34PM +0200, Egbert Eich wrote:
> > This copy-and-past error was introduced in:
> > 
> > commit fd63e2a972c670887e5e8a08440111d3812c0996
> > Author: Imre Deak 
> > Date:   Tue Jul 21 15:32:44 2015 -0700
> > 
> > drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins
> > 
> > Signed-off-by: Egbert Eich 
> 
> I recommend to cc: the authors/reviewers of the patch which broke things
> so they have a better chance to spot your patch and make amends by quickly
> reviewing your fix. Anyway Reviewed-by: Daniel Vetter 

Thanks for catching this. Ville also noticed it and has sent already a
fix for it:
http://lists.freedesktop.org/archives/intel-gfx/2015-August/074676.html

--Imre

> 
> Jani, this all seems to be for you.
> -Daniel
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 8485bea..ad99dae 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1559,7 +1559,7 @@ static void i9xx_hpd_irq_handler(struct drm_device 
> > *dev)
> > u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
> >  
> > intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> > -  hotplug_trigger, hpd_status_g4x,
> > +  hotplug_trigger, hpd_status_i915,
> >i9xx_port_hotplug_long_detect);
> > intel_hpd_irq_handler(dev, pin_mask, long_mask);
> > }
> > -- 
> > 1.8.4.5
> > 
> 


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

Re: [Intel-gfx] [PATCH] uapi/drm/i915_drm.h: fix userspace compilation.

[Jani Nikula]

On Wed, 02 Sep 2015, Daniel Vetter  wrote:
> On Wed, Sep 02, 2015 at 02:52:19PM +0300, Ville Syrjälä wrote:
>> On Wed, Sep 02, 2015 at 01:41:18PM +0200, Artem Savkov wrote:
>> > Patch "drm/i915: Use expcitly fixed type in compat32 structs" changed the 
>> > type
>> > of param field in drm_i915_getparam from int to s32. This header is 
>> > exported to
>> > userspace and needs to use userspace type __s32 instead.
>> > 
>> > This fixes userspace compilation errors like the following:
>> > include/drm/i915_drm.h:361:2: error: unknown type name 's32'
>> >   s32 param;
>> > 
>> > Signed-off-by: Artem Savkov 
>> > ---
>> >  include/uapi/drm/i915_drm.h | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
>> > index dbd16a2..fd5aa47 100644
>> > --- a/include/uapi/drm/i915_drm.h
>> > +++ b/include/uapi/drm/i915_drm.h
>> > @@ -358,7 +358,7 @@ typedef struct drm_i915_irq_wait {
>> >  #define I915_PARAM_HAS_RESOURCE_STREAMER 36
>> >  
>> >  typedef struct drm_i915_getparam {
>> > -  s32 param;
>> > +  __s32 param;
>> 
>> Hmm. I don't understand why this one in particular got changed to s32
>> when there are other ioctl structs still using int.
>
> Mostly me being incompetent.
>
> Reviewed-by: Daniel Vetter  on this one, not that
> it seems to be worth much ...

Pushed to drm-intel-next-fixes, thanks for the patch and review.

BR,
Jani.


> -Daniel
>
>> 
>> >/*
>> > * WARNING: Using pointers instead of fixed-size u64 means we need to 
>> > write
>> > * compat32 code. Don't repeat this mistake.
>> > -- 
>> > 2.1.0
>> > 
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> 
>> -- 
>> Ville Syrjälä
>> Intel OTC
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Always mark the object as dirty when used by the GPU

[Jani Nikula]

On Wed, 02 Sep 2015, Daniel Vetter  wrote:
> On Mon, Aug 31, 2015 at 03:10:39PM +0100, Chris Wilson wrote:
>> There have been many hard to track down bugs whereby userspace forgot to
>> flag a write buffer and then cause graphics corruption or a hung GPU
>> when that buffer was later purged under memory pressure (as the buffer
>> appeared clean, its pages would have been evicted rather than preserved
>> and any changes more recent than in the backing storage would be lost).
>> In retrospect this is a rare optimisation against memory pressure,
>> already the slow path. If we always mark the buffer as dirty when
>> accessed by the GPU, anything not used can still be evicted cheaply
>> (ideal behaviour for mark-and-sweep eviction) but we do not run the risk
>> of corruption. For correct read serialisation, userspace still has to
>> notify when the GPU writes to an object. However, there are certain
>> situations under which userspace may wish to tell white lies to the
>> kernel...
>> 
>> Signed-off-by: Chris Wilson 
>> Cc: Daniel Vetter 
>> Cc: Kristian Høgsberg 
>> Cc: Jesse Barnes 
>> Cc: "Goel, Akash" 
>> Cc: Michał Winiarski 
>> Cc: sta...@vger.kernel.org
>
> Reviewed-by: Daniel Vetter 

Pushed to drm-intel-next-fixes, thanks for the patch and review.

BR,
Jani.

>
>> ---
>>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
>> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> index 923a3c4bf0b7..a953d4975b8c 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>> @@ -1032,6 +1032,7 @@ i915_gem_execbuffer_move_to_active(struct list_head 
>> *vmas,
>>  u32 old_read = obj->base.read_domains;
>>  u32 old_write = obj->base.write_domain;
>>  
>> +obj->dirty = 1; /* be paranoid  */
>>  obj->base.write_domain = obj->base.pending_write_domain;
>>  if (obj->base.write_domain == 0)
>>  obj->base.pending_read_domains |= 
>> obj->base.read_domains;
>> @@ -1039,7 +1040,6 @@ i915_gem_execbuffer_move_to_active(struct list_head 
>> *vmas,
>>  
>>  i915_vma_move_to_active(vma, req);
>>  if (obj->base.write_domain) {
>> -obj->dirty = 1;
>>  i915_gem_request_assign(&obj->last_write_req, req);
>>  
>>  intel_fb_obj_invalidate(obj, ORIGIN_CS);
>> -- 
>> 2.5.1
>> 
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset

[Takashi Iwai]

On Wed, 02 Sep 2015 11:02:42 +0200,
Jani Nikula wrote:
> 
> >> Nitpick. I'd prefer some sharing with the similar blocks from the
> >> earlier patch. Also a debug message on n == 0 would be nice; you
> >> probably didn't notice your audio_config_get_rate() wasn't working
> >> right
> >> because this silently fell back to the automatic mode here.
> >
> > OK, I will add the msg. As you and Ville are insisting on
> > sharing code, I will do it in next version.
> 
> Well, really, I'm fine with having that part duplicated as-is for now,
> we can fix it later. More important to focus on getting
> audio_config_get_rate() right.
> 
> I don't know if you're still targeting v4.3 with this (up to Takashi I
> guess) we'll really need to wrap this up soon.

I'm in favor of merging this into 4.3, so it'd be appreciated if Libin
can prepare the fixed version soonish, indeed.


thanks,

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

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Pass hpd_status_i915[] to intel_get_hpd_pins() in pre-g4x

[Jani Nikula]

On Sat, 29 Aug 2015, Paulo Zanoni  wrote:
> 2015-08-27 17:56 GMT-03:00  :
>> From: Ville Syrjälä 
>>
>> Pass the correct hpd[] array to intel_get_hpd_pins() on pre-g4x
>> platforms.
>>
>> This got broken in the following commit:
>> commit fd63e2a972c670887e5e8a08440111d3812c0996
>> Author: Imre Deak 
>> Date:   Tue Jul 21 15:32:44 2015 -0700
>>
>> drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins
>
> The good & old "copy, paste, then adjust only one of the two variable
> names" error.
>
> Reviewed-by: Paulo Zanoni 

Pushed this one patch to drm-intel-next-fixes, thanks for the patch and
review.

I took the liberty of adding Reviewed-by also from Egbert and Daniel, as
Egbert submitted an identical patch [1] which Daniel reviewed. Patch
selection was purely on a first come first applied basis.

BR,
Jani.

[1] http://mid.gmane.org/1441138895-23732-4-git-send-email-e...@suse.de


>
>>
>> Cc: Imre Deak 
>> Signed-off-by: Ville Syrjälä 
>> ---
>>  drivers/gpu/drm/i915/i915_irq.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 1a29dfd..9866739 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -1644,7 +1644,7 @@ static void i9xx_hpd_irq_handler(struct drm_device 
>> *dev)
>> u32 hotplug_trigger = hotplug_status & 
>> HOTPLUG_INT_STATUS_I915;
>>
>> intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
>> -  hotplug_trigger, hpd_status_g4x,
>> +  hotplug_trigger, hpd_status_i915,
>>i9xx_port_hotplug_long_detect);
>> intel_hpd_irq_handler(dev, pin_mask, long_mask);
>> }
>> --
>> 2.4.6
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> -- 
> Paulo Zanoni
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use the correct hpd_status list for non-G4xx/VLV

[Jani Nikula]

On Wed, 02 Sep 2015, Imre Deak  wrote:
> On ke, 2015-09-02 at 14:00 +0200, Daniel Vetter wrote:
>> On Tue, Sep 01, 2015 at 10:21:34PM +0200, Egbert Eich wrote:
>> > This copy-and-past error was introduced in:
>> > 
>> > commit fd63e2a972c670887e5e8a08440111d3812c0996
>> > Author: Imre Deak 
>> > Date:   Tue Jul 21 15:32:44 2015 -0700
>> > 
>> > drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins
>> > 
>> > Signed-off-by: Egbert Eich 
>> 
>> I recommend to cc: the authors/reviewers of the patch which broke things
>> so they have a better chance to spot your patch and make amends by quickly
>> reviewing your fix. Anyway Reviewed-by: Daniel Vetter 
>> 
>
> Thanks for catching this. Ville also noticed it and has sent already a
> fix for it:
> http://lists.freedesktop.org/archives/intel-gfx/2015-August/074676.html

I pushed that one as it came first.

BR,
Jani.


>
> --Imre
>
>> 
>> Jani, this all seems to be for you.
>> -Daniel
>> > ---
>> >  drivers/gpu/drm/i915/i915_irq.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> > b/drivers/gpu/drm/i915/i915_irq.c
>> > index 8485bea..ad99dae 100644
>> > --- a/drivers/gpu/drm/i915/i915_irq.c
>> > +++ b/drivers/gpu/drm/i915/i915_irq.c
>> > @@ -1559,7 +1559,7 @@ static void i9xx_hpd_irq_handler(struct drm_device 
>> > *dev)
>> >u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
>> >  
>> >intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
>> > - hotplug_trigger, hpd_status_g4x,
>> > + hotplug_trigger, hpd_status_i915,
>> >   i9xx_port_hotplug_long_detect);
>> >intel_hpd_irq_handler(dev, pin_mask, long_mask);
>> >}
>> > -- 
>> > 1.8.4.5
>> > 
>> 
>
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915/gtt: Avoid calling kcalloc in a loop when allocating temp bitmaps

[Michel Thierry]

On 9/1/2015 10:06 AM, Michał Winiarski wrote:

On each call to gen8_alloc_va_range_3lvl we're allocating temporary
bitmaps needed for error handling. Unfortunately, when we increase
address space size (48b ppgtt) we do additional (512 - 4) calls to
kcalloc, increasing latency between exec and actual start of execution
on the GPU. Let's just do a single kcalloc, we can also drop the size
from free_gen8_temp_bitmaps since it's no longer used.

v2: Use GFP_TEMPORARY to make the allocations reclaimable.
v3: Drop the 2D array, just allocate a single block.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Signed-off-by: Michał Winiarski 


Unless Chris thinks otherwise, I see Michał already addressed his comments.

Reviewed-by: Michel Thierry 


---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 45 +
  1 file changed, 16 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4a76807..f810762 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1126,13 +1126,8 @@ unwind_out:
  }

  static void
-free_gen8_temp_bitmaps(unsigned long *new_pds, unsigned long **new_pts,
-  uint32_t pdpes)
+free_gen8_temp_bitmaps(unsigned long *new_pds, unsigned long *new_pts)
  {
-   int i;
-
-   for (i = 0; i < pdpes; i++)
-   kfree(new_pts[i]);
kfree(new_pts);
kfree(new_pds);
  }
@@ -1142,29 +1137,20 @@ free_gen8_temp_bitmaps(unsigned long *new_pds, unsigned 
long **new_pts,
   */
  static
  int __must_check alloc_gen8_temp_bitmaps(unsigned long **new_pds,
-unsigned long ***new_pts,
+unsigned long **new_pts,
 uint32_t pdpes)
  {
-   int i;
unsigned long *pds;
-   unsigned long **pts;
+   unsigned long *pts;

-   pds = kcalloc(BITS_TO_LONGS(pdpes), sizeof(unsigned long), GFP_KERNEL);
+   pds = kcalloc(BITS_TO_LONGS(pdpes), sizeof(unsigned long), 
GFP_TEMPORARY);
if (!pds)
return -ENOMEM;

-   pts = kcalloc(pdpes, sizeof(unsigned long *), GFP_KERNEL);
-   if (!pts) {
-   kfree(pds);
-   return -ENOMEM;
-   }
-
-   for (i = 0; i < pdpes; i++) {
-   pts[i] = kcalloc(BITS_TO_LONGS(I915_PDES),
-sizeof(unsigned long), GFP_KERNEL);
-   if (!pts[i])
-   goto err_out;
-   }
+   pts = kcalloc(pdpes * BITS_TO_LONGS(I915_PDES),
+   sizeof(unsigned long), GFP_TEMPORARY);
+   if (!pts)
+   goto err_out;

*new_pds = pds;
*new_pts = pts;
@@ -1172,7 +1158,7 @@ int __must_check alloc_gen8_temp_bitmaps(unsigned long 
**new_pds,
return 0;

  err_out:
-   free_gen8_temp_bitmaps(pds, pts, pdpes);
+   free_gen8_temp_bitmaps(pds, pts);
return -ENOMEM;
  }

@@ -1193,7 +1179,7 @@ static int gen8_alloc_va_range_3lvl(struct 
i915_address_space *vm,
  {
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
-   unsigned long *new_page_dirs, **new_page_tables;
+   unsigned long *new_page_dirs, *new_page_tables;
struct drm_device *dev = vm->dev;
struct i915_page_directory *pd;
const uint64_t orig_start = start;
@@ -1220,14 +1206,14 @@ static int gen8_alloc_va_range_3lvl(struct 
i915_address_space *vm,
ret = gen8_ppgtt_alloc_page_directories(vm, pdp, start, length,
new_page_dirs);
if (ret) {
-   free_gen8_temp_bitmaps(new_page_dirs, new_page_tables, pdpes);
+   free_gen8_temp_bitmaps(new_page_dirs, new_page_tables);
return ret;
}

/* For every page directory referenced, allocate page tables */
gen8_for_each_pdpe(pd, pdp, start, length, temp, pdpe) {
ret = gen8_ppgtt_alloc_pagetabs(vm, pd, start, length,
-   new_page_tables[pdpe]);
+   new_page_tables + pdpe * 
BITS_TO_LONGS(I915_PDES));
if (ret)
goto err_out;
}
@@ -1278,20 +1264,21 @@ static int gen8_alloc_va_range_3lvl(struct 
i915_address_space *vm,
gen8_setup_page_directory(ppgtt, pdp, pd, pdpe);
}

-   free_gen8_temp_bitmaps(new_page_dirs, new_page_tables, pdpes);
+   free_gen8_temp_bitmaps(new_page_dirs, new_page_tables);
mark_tlbs_dirty(ppgtt);
return 0;

  err_out:
while (pdpe--) {
-   for_each_set_bit(temp, new_page_tables[pdpe], I915_PDES)
+   for_each_set_bit(temp, new_page_tables + pdpe *
+   BITS_TO_LONGS(I915_PDES), I915_PDES)
free_pt(dev, 
pdp->page_dir

Re: [Intel-gfx] [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset

[Jani Nikula]

On Wed, 02 Sep 2015, Takashi Iwai  wrote:
> On Wed, 02 Sep 2015 11:02:42 +0200,
> Jani Nikula wrote:
>> 
>> >> Nitpick. I'd prefer some sharing with the similar blocks from the
>> >> earlier patch. Also a debug message on n == 0 would be nice; you
>> >> probably didn't notice your audio_config_get_rate() wasn't working
>> >> right
>> >> because this silently fell back to the automatic mode here.
>> >
>> > OK, I will add the msg. As you and Ville are insisting on
>> > sharing code, I will do it in next version.
>> 
>> Well, really, I'm fine with having that part duplicated as-is for now,
>> we can fix it later. More important to focus on getting
>> audio_config_get_rate() right.
>> 
>> I don't know if you're still targeting v4.3 with this (up to Takashi I
>> guess) we'll really need to wrap this up soon.
>
> I'm in favor of merging this into 4.3, so it'd be appreciated if Libin
> can prepare the fixed version soonish, indeed.

IIUC patches 1-3 would be useful on their own already, and a fixed
version of patch 4 could follow. Just a thought.

BR,
Jani.

>
>
> thanks,
>
> Takashi

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset

[Takashi Iwai]

On Wed, 02 Sep 2015 15:44:34 +0200,
Jani Nikula wrote:
> 
> On Wed, 02 Sep 2015, Takashi Iwai  wrote:
> > On Wed, 02 Sep 2015 11:02:42 +0200,
> > Jani Nikula wrote:
> >> 
> >> >> Nitpick. I'd prefer some sharing with the similar blocks from the
> >> >> earlier patch. Also a debug message on n == 0 would be nice; you
> >> >> probably didn't notice your audio_config_get_rate() wasn't working
> >> >> right
> >> >> because this silently fell back to the automatic mode here.
> >> >
> >> > OK, I will add the msg. As you and Ville are insisting on
> >> > sharing code, I will do it in next version.
> >> 
> >> Well, really, I'm fine with having that part duplicated as-is for now,
> >> we can fix it later. More important to focus on getting
> >> audio_config_get_rate() right.
> >> 
> >> I don't know if you're still targeting v4.3 with this (up to Takashi I
> >> guess) we'll really need to wrap this up soon.
> >
> > I'm in favor of merging this into 4.3, so it'd be appreciated if Libin
> > can prepare the fixed version soonish, indeed.
> 
> IIUC patches 1-3 would be useful on their own already, and a fixed
> version of patch 4 could follow. Just a thought.

That's good, then I can take the first three patches.

Daniel, would you like to review these three before I merge them?
I assumed your previous mail as a kind of ack to this series, too.


thanks,

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

Re: [Intel-gfx] [PATCH v3] drm/i915/gtt: Avoid calling kcalloc in a loop when allocating temp bitmaps

[Chris Wilson]

On Wed, Sep 02, 2015 at 02:40:03PM +0100, Michel Thierry wrote:
> On 9/1/2015 10:06 AM, Michał Winiarski wrote:
> >On each call to gen8_alloc_va_range_3lvl we're allocating temporary
> >bitmaps needed for error handling. Unfortunately, when we increase
> >address space size (48b ppgtt) we do additional (512 - 4) calls to
> >kcalloc, increasing latency between exec and actual start of execution
> >on the GPU. Let's just do a single kcalloc, we can also drop the size
> >from free_gen8_temp_bitmaps since it's no longer used.
> >
> >v2: Use GFP_TEMPORARY to make the allocations reclaimable.
> >v3: Drop the 2D array, just allocate a single block.
> >
> >Cc: Chris Wilson 
> >Cc: Mika Kuoppala 
> >Cc: Michel Thierry 
> >Signed-off-by: Michał Winiarski 
> 
> Unless Chris thinks otherwise, I see Michał already addressed his comments.

I think I spotted a misaligned bracket... ;)
Reviewed-by: Chris Wilson 
-Chri

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC] Docs: drm: Move KMS properties table out to source files

[Graham Whaley]

(RFC/test - not for merging)
The below is a test of moving the large HTML KMS properties table out
to markdown style in the appropriate files.
In the test we only use the first few rows of the existing KMS table
an example.
We use a fixed width table as the other styles of table supported by
pandoc markdown do not support multi-column cells.

The test shows a couple of issues:
 1) double quote characters are being expanded in the fixed width table
 which then breaks the table alignment and leaves html style  tags
 in the text

 2) Cramming the seven columns into the apprx 80ish column width makes
 some entries fairly impractical - one word per row. For reference,
 pdfdocs rendering clips the fixed text tables at around 80 characters.

If we can:
 a) Resolve (1) above
and
 b) Agree that we are OK with comment fields extending beyond the 80th
 column significantly

then maybe we can continue looking at moving the KMS properties table out
of drm.tmpl and into markdown format fragments in the source files.
If not, then maybe we go back to considering the conversion of the KMS
table to docbook CALS format.
---
 Documentation/DocBook/drm.tmpl | 925 +
 drivers/gpu/drm/drm_crtc.c |  16 +
 2 files changed, 17 insertions(+), 924 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 66bc646..ecfd084 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2573,930 +2573,7 @@ void intel_crt_init(struct drm_device *dev)
The following table gives description of drm properties exposed by 
various
modules/drivers.

-   
-   
-   
-   Owner Module/Drivers
-   Group
-   Property Name
-   Type
-   Property Values
-   Object attached
-   Description/Restrictions
-   
-   
-   DRM
-   Generic
-   “rotation”
-   BITMASK
-   { 0, "rotate-0" },
-   { 1, "rotate-90" },
-   { 2, "rotate-180" },
-   { 3, "rotate-270" },
-   { 4, "reflect-x" },
-   { 5, "reflect-y" }
-   CRTC, Plane
-   rotate-(degrees) rotates the image by the specified 
amount in degrees
-   in counter clockwise direction. reflect-x and reflect-y reflects the
-   image along the specified axis prior to rotation
-   
-   
-   Connector
-   “EDID”
-   BLOB | IMMUTABLE
-   0
-   Connector
-   Contains id of edid blob ptr object.
-   
-   
-   “DPMS”
-   ENUM
-   { “On”, “Standby”, “Suspend”, “Off” }
-   Connector
-   Contains DPMS operation mode value.
-   
-   
-   “PATH”
-   BLOB | IMMUTABLE
-   0
-   Connector
-   Contains topology path to a connector.
-   
-   
-   “TILE”
-   BLOB | IMMUTABLE
-   0
-   Connector
-   Contains tiling information for a connector.
-   
-   
-   “CRTC_ID”
-   OBJECT
-   DRM_MODE_OBJECT_CRTC
-   Connector
-   CRTC that connector is attached to (atomic)
-   
-   
-   Plane
-   “type”
-   ENUM | IMMUTABLE
-   { "Overlay", "Primary", "Cursor" }
-   Plane
-   Plane type
-   
-   
-   “SRC_X”
-   RANGE
-   Min=0, Max=UINT_MAX
-   Plane
-   Scanout source x coordinate in 16.16 fixed point 
(atomic)
-   
-   
-   “SRC_Y”
-   RANGE
-   Min=0, Max=UINT_MAX
-   Plane
-   Scanout source y coordinate in 16.16 fixed point 
(atomic)
-   
-   
-   “SRC_W”
-   RANGE
-   Min=0, Max=UINT_MAX
-   Plane
-   Scanout source width in 16.16 fixed point 
(atomic)
-   
-   
-   “SRC_H”
-   RANGE
-   Min=0, Max=UINT_MAX
-   Plane
-   Scanout source height in 16.16 fixed point 
(atomic)
-   
-   
-   “CRTC_X”
-   SIGNED_RANGE
-   Min=INT_MIN, Max=INT_MAX
-   Plane
-   Scanout CRTC (destination) x coordinate (atomic)
-   
-   
-   “CRTC_Y”
-   SIGNED_RANGE
-   Min=INT_MIN, Max=INT_MAX
-   Plane
-   Scanout CRTC (destination) y coordinate (atomic)
-   
-   
-   “CRTC_W”
-   RANGE
-   Min=0, Max=UINT_MAX
-   Plane
-   Scanout CRTC (destination) width (atomic)
-   
-   
-   “CRTC_H”
-   RANGE
-   Min=0, Max=UINT_MAX
-   Plane
-   Scanout CRTC (destination) height (atomic)
-   
-   
-   “FB_ID”
-   OBJECT
-   DRM_MODE_OBJECT_FB
-   Plane
-   Scanout framebuffer (atomic)
-   
-   
-   “CRTC_ID”
-   OBJECT
-   DRM_MODE_OBJECT_CRTC
-   Plane
-   CRTC that plane is attached to (atomic)
-   
-   
-   DVI-I
-   “subconnector”
-   ENUM
-   { “Unknown”, “DVI-D”, “DVI-A” }
-   Connector
-   TBD
-   
-   
-   “select subconnector”
-   ENUM
-   { “Automatic”, “DVI-D”, “DVI-A” }
-   Connector
-   TBD
-   
-   
-   TV
-  

[Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subslice and EU count for BDW

[Łukasz Daniluk]

Added checks for available slices, subslices and EUs for Broadwell. This
information is filled in intel_device_info and is available to user with
GET_PARAM.
Added checks for enabled slices, subslices and EU for Broadwell. This
information is based on available counts but takes power gated slices
into account. It can be read in debugfs.
Introduce new register defines that contain information on slices on
Broadwell.

v2:
- Introduce GT_SLICE_INFO register
- Change Broadwell sseu_device_status function to use GT_SLICE_INFO
  register instead of RPCS register
- Undo removal of dev_priv variables in Cherryview and Gen9
  sseu_device_satus functions

Cc: Jeff Mcgee 
Signed-off-by: Łukasz Daniluk 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 29 +++-
 drivers/gpu/drm/i915/i915_dma.c | 89 +
 drivers/gpu/drm/i915/i915_reg.h | 22 -
 3 files changed, 137 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307..e8a62ef 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4932,13 +4932,38 @@ static void gen9_sseu_device_status(struct drm_device 
*dev,
}
 }
 
+static void broadwell_sseu_device_status(struct drm_device *dev,
+struct sseu_dev_status *stat)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int s;
+   u32 slice_info = I915_READ(GEN8_GT_SLICE_INFO);
+
+   stat->slice_total =
+   hweight32(slice_info & GEN8_LSLICESTAT_MASK);
+
+   if (stat->slice_total)
+   {
+   stat->subslice_per_slice = INTEL_INFO(dev)->subslice_per_slice;
+   stat->eu_per_subslice = INTEL_INFO(dev)->eu_per_subslice;
+   stat->subslice_total = stat->slice_total * 
stat->subslice_per_slice;
+   stat->eu_total = stat->eu_per_subslice * stat->subslice_total;
+
+   /* subtract fused off EU(s) from enabled slice(s) */
+   for (s = 0; s < stat->slice_total; s++) {
+   u8 subslice_7eu = INTEL_INFO(dev)->subslice_7eu[s];
+   stat->eu_total -= hweight8(subslice_7eu);
+   }
+   }
+}
+
 static int i915_sseu_status(struct seq_file *m, void *unused)
 {
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
struct sseu_dev_status stat;
 
-   if ((INTEL_INFO(dev)->gen < 8) || IS_BROADWELL(dev))
+   if (INTEL_INFO(dev)->gen < 8)
return -ENODEV;
 
seq_puts(m, "SSEU Device Info\n");
@@ -4963,6 +4988,8 @@ static int i915_sseu_status(struct seq_file *m, void 
*unused)
memset(&stat, 0, sizeof(stat));
if (IS_CHERRYVIEW(dev)) {
cherryview_sseu_device_status(dev, &stat);
+   } else if (IS_BROADWELL(dev)) {
+   broadwell_sseu_device_status(dev, &stat);
} else if (INTEL_INFO(dev)->gen >= 9) {
gen9_sseu_device_status(dev, &stat);
}
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ab37d11..2d52b1e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -705,6 +705,93 @@ static void gen9_sseu_info_init(struct drm_device *dev)
info->has_eu_pg = (info->eu_per_subslice > 2);
 }
 
+static void broadwell_sseu_info_init(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_device_info *info;
+   const int s_max = 3, ss_max = 3, eu_max = 8;
+   int s, ss;
+   u32 fuse2, eu_disable[s_max], s_enable, ss_disable;
+
+   fuse2 = I915_READ(GEN8_FUSE2);
+   s_enable = (fuse2 & GEN8_F2_S_ENA_MASK) >>
+   GEN8_F2_S_ENA_SHIFT;
+   ss_disable = (fuse2 & GEN8_F2_SS_DIS_MASK) >>
+   GEN8_F2_SS_DIS_SHIFT;
+
+   eu_disable[0] = I915_READ(GEN8_EU_DISABLE0) &
+   GEN8_EU_DIS0_S0_MASK;
+   eu_disable[1] = (I915_READ(GEN8_EU_DISABLE0) >>
+   GEN8_EU_DIS0_S1_SHIFT) |
+   ((I915_READ(GEN8_EU_DISABLE1) &
+ GEN8_EU_DIS1_S1_MASK) <<
+(32 - GEN8_EU_DIS0_S1_SHIFT));
+   eu_disable[2] = (I915_READ(GEN8_EU_DISABLE1) >>
+   GEN8_EU_DIS1_S2_SHIFT) |
+   ((I915_READ(GEN8_EU_DISABLE2) &
+ GEN8_EU_DIS2_S2_MASK) <<
+(32 - GEN8_EU_DIS1_S2_SHIFT));
+
+
+   info = (struct intel_device_info *)&dev_priv->info;
+   info->slice_total = hweight32(s_enable);
+
+   /*
+* The subslice disable field is global, i.e. it applies
+* to each of the enabled slices.
+*/
+   info->subslice_per_slice = ss_max - hweight32(ss_disable);
+   info->subslice_total = info->slice_total *
+   info->subslice_per_slice;
+
+   /*
+* Iterate through enabled slices and 

Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subslice and EU count for BDW

[Chris Wilson]

On Wed, Sep 02, 2015 at 05:47:58PM +0200, Łukasz Daniluk wrote:
> +static void broadwell_sseu_device_status(struct drm_device *dev,

Why pass in dev if you only use dev_priv (and commit the sin of
repeatedly retrieving dev->dev_priv)?

> +  struct sseu_dev_status *stat)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + int s;
> + u32 slice_info = I915_READ(GEN8_GT_SLICE_INFO);
> +
> + stat->slice_total =
> + hweight32(slice_info & GEN8_LSLICESTAT_MASK);
> +
> + if (stat->slice_total)
> + {
Missed.

> + stat->subslice_per_slice = INTEL_INFO(dev)->subslice_per_slice;
> + stat->eu_per_subslice = INTEL_INFO(dev)->eu_per_subslice;
> + stat->subslice_total = stat->slice_total * 
> stat->subslice_per_slice;
> + stat->eu_total = stat->eu_per_subslice * stat->subslice_total;
> +
> + /* subtract fused off EU(s) from enabled slice(s) */
> + for (s = 0; s < stat->slice_total; s++) {
> + u8 subslice_7eu = INTEL_INFO(dev)->subslice_7eu[s];
> + stat->eu_total -= hweight8(subslice_7eu);
> + }

So why are we computing this twice? Is the debugfs to show the hw
registers or the sw tracking? Where do I see what we actually report? If
it is for the hw registers, report them. A perfect function here would
report the actual register values (possibly decoding them) and show what
the internal values are.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] Documentation: drm: Convert KMS Properties HTML table to CALS

[Graham Whaley]

On Tue, 2015-09-01 at 14:56 -0300, Danilo Cesar Lemes de Paula wrote:
> On 08/25/2015 01:10 PM, Graham Whaley wrote:
> > On Tue, 2015-08-25 at 16:29 +0200, Daniel Vetter wrote:
> > > On Tue, Aug 25, 2015 at 10:26:44AM +0100, Graham Whaley wrote:
> > > > The KMS Properties table is in HTML format, which is not
> > > > supported
> > > > for building pdfdocs, resulting in the following types of
> > > > errors:
> > > > 
> > > >  jade:/Documentation/DocBook/drm.xml:34413:15:E: there is no
> > > > attribute
> > > >  "border"
> > > >  jade:/Documentation/DocBook/drm.xml:34413:31:E: there is no
> > > > attribute
> > > >  "cellpadding"
> > > >  jade:/Documentation/DocBook/drm.xml:34413:47:E: there is no
> > > > attribute
> > > >  "cellspacing"
> > > >  jade:/Documentation/DocBook/drm.xml:34414:7:E: document type
> > > > does
> > > > not
> > > >  allow element "tbody" here
> > > > 
> > > > Convert the table over to a CALS format table
> > > 
> > > Hm, long-term plan was to move this table into DOC: comments in
> > > the
> > > source-code using markdown, which we now have (at least in
> > > drm-intel-nightly and also planned to be merged into 4.4). Since
> > > this
> > > is
> > > both a lot of churn I'd like to get there in just 1 step ...
> > > -Daniel
> > First - I've just noted an erroneous debug comment (or two) left in
> > this patch as well, so looks like I will have to re-issue the
> > series
> > anyway.
> > 
> > OK. I guess this comes down to a matter of timing...
> > From Danilos patch of: f6d6913 (drm/doc: Convert to markdown)
> > we can see markdown does not natively support tables, and we'd have
> > to
> > make this a fixed width layout like the one in that patch I
> > suspect.
> > Danilo - any advice on how you did that other table conversion? I
> > just
> > did a pandoc docbook->markdown_github and it looks some way there -
> > but
> > of course seems to have not honored the multi-column items, of
> > which
> > there are a few. It's probably not too bad to fix up by hand - I'll
> > see
> > if I can get that to work...
> 
> Hi Graham,
> 
> To be honest I didn't have to do any conversion as that table was
> already in the header file. I just added 4 spaces so it would be
> transformed into fixed width.
> 
> However, there's tool you can use to help you: http://pandoc.org/try/
> I did a lot of translation there. If your table doesn't have any
> spancells, you can put the HTML code there and get the Markdown for
> free.
> 
> Danilo

Hi,
 following this email should be an [RFC] patch with the subject:
  [RFC] Docs: drm: Move KMS properties table out to source files

This is not a fix - it is an example to show that maybe this table does
not migrate well to markdown. Danilo, if you have any thoughts about
the 'quote expansion' detailed in the patch I'd be interested. Daniel,
we should probably consider if moving this table to markdown will work
out given the width of the table and the restrictions of having to use
fixed width for multi-row markdown table representation.

 Graham




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

Re: [Intel-gfx] [PATCH] drm/i915: Fix broken mst get_hw_state.

[Ander Conselvan De Oliveira]

On Thu, 2015-08-27 at 13:13 +0200, Maarten Lankhorst wrote:
> connector->encoder is initialized as NULL. Fix this by setting it in
> during pre enable. MST connectors are not read out during initial hw
> readout, and have no fixed encoder mappings. So it's harmless to
> return false when the connector has never been assigned to an encoder.
>
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 738178a0ac96..e3922d973db0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6283,7 +6283,7 @@ static void intel_connector_check_state(struct 
> intel_connector *connector)
> connector->base.name);
>  
>   if (connector->get_hw_state(connector)) {
> - struct drm_encoder *encoder = &connector->encoder->base;
> + struct intel_encoder *encoder = connector->encoder;
>   struct drm_connector_state *conn_state = connector->base.state;
>  
>   I915_STATE_WARN(!crtc,
> @@ -6295,13 +6295,13 @@ static void intel_connector_check_state(struct 
> intel_connector *connector)
>   I915_STATE_WARN(!crtc->state->active,
> "connector is active, but attached crtc isn't\n");
>  
> - if (!encoder)
> + if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST)
>   return;
>  
> - I915_STATE_WARN(conn_state->best_encoder != encoder,
> + I915_STATE_WARN(conn_state->best_encoder != &encoder->base,
>   "atomic encoder doesn't match attached encoder\n");
>  
> - I915_STATE_WARN(conn_state->crtc != encoder->crtc,
> + I915_STATE_WARN(conn_state->crtc != encoder->base.crtc,
>   "attached encoder crtc differs from connector crtc\n");
>   } else {
>   I915_STATE_WARN(crtc && crtc->state->active,
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index ebf205462631..d606721b1788 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -159,6 +159,11 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
> *encoder)
>   return;
>   }
>  
> + /* MST encoders are bound to a crtc, not to a connector,
> +  * force the mapping here for get_hw_state.
> +  */
> + found->encoder = encoder;
> +
>   DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
>   intel_mst->port = found->port;
>  
> @@ -392,7 +397,7 @@ static const struct drm_encoder_funcs 
> intel_dp_mst_enc_funcs = {
>  
>  static bool intel_dp_mst_get_hw_state(struct intel_connector *connector)
>  {
> - if (connector->encoder) {
> + if (connector->encoder && connector->base.state->crtc) {

Is this here to cover the case where we disable this connector and assign the 
encoder to a different
connector? I guess this should work since if we disable the connector than crtc 
will be null, and
we'll assign a proper encoder when re-enabling. But now I'm wondering if it 
would make sense to set
connector->encoder back to NULL in post_disable.

Ander

>   enum pipe pipe;
>   if (!connector->encoder->get_hw_state(connector->encoder, 
> &pipe))
>   return false;
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH] drm/i915: Use universal planes for cursor on skylake.

[Maarten Lankhorst]

Op 02-09-15 om 11:15 schreef Daniel Vetter:
> On Thu, Aug 27, 2015 at 12:08:30PM +0200, Maarten Lankhorst wrote:
>> This appears to make all the cursor tests really slow because of the many 
>> calls to skl_update_wm
>> when the cursor plane visibility is changed. It performs does 3 vblanks each 
>> time it's called, and
>> it's probably called more than once on each update.
> On all other platforms wm updates (right now at least) don't do any vblank
> waits, which means changing cursors actually _does_ cause tons of
> underruns. Can we perhaps add a hack in skl to do the same (maybe just for
> cursors) so that we can get this in? There's lots other work that really
> wants proper universal planes ...
>
Well this is easily fixed by moving it to unpin_work, so it runs after the next 
vblank interrupt.

If that patch series is too far out annotate wm changed,
kill all intel_wait_vblank calls inside post_plane_update and run that function 
after drm_atomic_helper_wait_for_vblanks.

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

Re: [Intel-gfx] [RFC] Docs: drm: Move KMS properties table out to source files

[Jani Nikula]

On Wed, 02 Sep 2015, Graham Whaley  wrote:
>  Documentation/DocBook/drm.tmpl | 925 
> +
>  drivers/gpu/drm/drm_crtc.c |  16 +
>  2 files changed, 17 insertions(+), 924 deletions(-)

I like this already.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix broken mst get_hw_state.

[Maarten Lankhorst]

Op 02-09-15 om 16:07 schreef Ander Conselvan De Oliveira:
> On Thu, 2015-08-27 at 13:13 +0200, Maarten Lankhorst wrote:
>> connector->encoder is initialized as NULL. Fix this by setting it in
>> during pre enable. MST connectors are not read out during initial hw
>> readout, and have no fixed encoder mappings. So it's harmless to
>> return false when the connector has never been assigned to an encoder.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 738178a0ac96..e3922d973db0 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -6283,7 +6283,7 @@ static void intel_connector_check_state(struct 
>> intel_connector *connector)
>>connector->base.name);
>>  
>>  if (connector->get_hw_state(connector)) {
>> -struct drm_encoder *encoder = &connector->encoder->base;
>> +struct intel_encoder *encoder = connector->encoder;
>>  struct drm_connector_state *conn_state = connector->base.state;
>>  
>>  I915_STATE_WARN(!crtc,
>> @@ -6295,13 +6295,13 @@ static void intel_connector_check_state(struct 
>> intel_connector *connector)
>>  I915_STATE_WARN(!crtc->state->active,
>>"connector is active, but attached crtc isn't\n");
>>  
>> -if (!encoder)
>> +if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST)
>>  return;
>>  
>> -I915_STATE_WARN(conn_state->best_encoder != encoder,
>> +I915_STATE_WARN(conn_state->best_encoder != &encoder->base,
>>  "atomic encoder doesn't match attached encoder\n");
>>  
>> -I915_STATE_WARN(conn_state->crtc != encoder->crtc,
>> +I915_STATE_WARN(conn_state->crtc != encoder->base.crtc,
>>  "attached encoder crtc differs from connector crtc\n");
>>  } else {
>>  I915_STATE_WARN(crtc && crtc->state->active,
>> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
>> b/drivers/gpu/drm/i915/intel_dp_mst.c
>> index ebf205462631..d606721b1788 100644
>> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
>> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
>> @@ -159,6 +159,11 @@ static void intel_mst_pre_enable_dp(struct 
>> intel_encoder *encoder)
>>  return;
>>  }
>>  
>> +/* MST encoders are bound to a crtc, not to a connector,
>> + * force the mapping here for get_hw_state.
>> + */
>> +found->encoder = encoder;
>> +
>>  DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
>>  intel_mst->port = found->port;
>>  
>> @@ -392,7 +397,7 @@ static const struct drm_encoder_funcs 
>> intel_dp_mst_enc_funcs = {
>>  
>>  static bool intel_dp_mst_get_hw_state(struct intel_connector *connector)
>>  {
>> -if (connector->encoder) {
>> +if (connector->encoder && connector->base.state->crtc) {
> Is this here to cover the case where we disable this connector and assign the 
> encoder to a different
> connector? I guess this should work since if we disable the connector than 
> crtc will be null, and
> we'll assign a proper encoder when re-enabling. But now I'm wondering if it 
> would make sense to set
> connector->encoder back to NULL in post_disable.
>
Yes, it's harmless to keep it non-null if conn_state->crtc is checked though. 
Saves another pointless loop.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt

[Egbert Eich]

Daniel Vetter writes:
 > On Tue, Sep 01, 2015 at 10:21:35PM +0200, Egbert Eich wrote:
 > > A HPD interrupt may fire during intel_crt_detect_hotplug() - especially
 > > when HPD interrupt storms occur.
 > > Since the interrupt handler changes the enabled interrupt lines when it
 > > detects a storm this races with intel_crt_detect_hotplug().
 > > To avoid this, shiled the rmw cycles with IRQ save spinlocks.
 > > 
 > > Signed-off-by: Egbert Eich 
 > 
 > I think this only reduces one source of such races, but fundamentally we
 > can't avoid them. E.g. if you're _very_ unlucky you might cause a real hpd
 > right when the strom code frobs around. Plugging the race with this known

This is exactly the scenatio I'm getting here. I get HPD interrupts at an 
order of 10^4 / sec.

 > interrupt source here doesn't fix the fundamental issue.
 > 
 > Also I think the actual interrupt deliver is fairly asynchronous, both in
 > the hardware and in the sw handling. E.g. spin_lock_irq does not
 > synchronize with the interrupt handler on SMP systems, it only guarantees
 > that it's not running concurrently on the same cpu (which would deadlock).
 > 
 > I think fundamentally this race is unfixable.


There is one important race we avoid with this patch: It is that
we change the PORT_HOTPLUG_EN concurrently in the interrupt handler
(thru xxx_hpd_irq_setup() and in intel_crt_detect_hotplug()).

With the test system that I have here the old version of the code
easily runs into this as the time spent inside intel_crt_detect_hotplug() 
is quite long - especially when no CRT is connected.

What happens intel_crt_detect_hotplug() reads the value of PORT_HOTPLUG_EN
at entry, then frobs around for ages, during this time several HPD interrupts
occur, the storm is detected, the bit related to the stormy line is unset
then after ages intel_crt_detect_hotplug() decides to give up and restores
the value it read on entry.

To remedy this this patch reads the value of PORT_HOTPLUG_EN whenever 
it is going to change it and adds the spin locks to make sure the 
read-modify-write cycles don't happen concurrently.

PORT_HOTPLUG_EN is only touched in two places: in xxx_hpd_irq_setup()
and in intel_crt_detect_hotplug(), the former can be called from an
interrupt handler.

Not sure why you see a problem here.

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

Re: [Intel-gfx] [PATCH] scripts/kernel-doc: Improve Markdown results

[Jonathan Corbet]

On Tue, 1 Sep 2015 14:57:33 -0300
Danilo Cesar Lemes de Paula  wrote:

> Did you find time to check this patch? As you mentioned that you applied
> the Markdown support for the linux-next tree, this patch might be needed
> (maybe "wanted" is a better word).

Not quite what I said...I said I'd apply it right after the merge window
so it can sit in linux-next through the full cycle.  It's a bit early to
be pushing 4.4 stuff into linux-next now...

Beyond that, I wasn't sure where things stand with fixes... Can you send
me a new patch set with this fix (and any others that might
exist) integrated in?

Thanks,

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

Re: [Intel-gfx] [RFC 1/3] drm/i915: Roll intel_crtc->atomic into intel_crtc_state

[Maarten Lankhorst]

Op 02-09-15 om 13:15 schreef Ville Syrjälä:
> On Wed, Sep 02, 2015 at 01:08:31PM +0200, Maarten Lankhorst wrote:
>> Op 02-09-15 om 12:35 schreef Ville Syrjälä:
>>> On Wed, Sep 02, 2015 at 07:15:25AM +0200, Maarten Lankhorst wrote:
 Op 01-09-15 om 17:48 schreef Ville Syrjälä:
> On Tue, Sep 01, 2015 at 08:30:05AM -0700, Matt Roper wrote:
>> On Tue, Sep 01, 2015 at 07:24:19AM +0200, Maarten Lankhorst wrote:
>>> Op 29-08-15 om 01:57 schreef Matt Roper:
 Way back at the beginning of i915's atomic conversion I added
 intel_crtc->atomic as a temporary dumping ground for "stuff to do
 outside vblank evasion" flags since CRTC states weren't properly wired
 up and tracked at that time.  We've had proper CRTC state tracking for 
 a
 while now, so there's really no reason for this hack to continue to
 exist.  Moving forward we want to store intermediate crtc/plane state
 data for modesets in addition to the final state, so moving these 
 fields
 into the proper state object allows us to properly compute them for 
 both
 the intermediate and final state.

 Signed-off-by: Matt Roper 
 ---
>>> Can I shoot this patch down? It's better to add a field 'wm_changed'
>>> to the crtc_state, which gets reset to false for each crtc_state
>>> duplication. It's needed for checking if a cs pageflip can be done for
>>> atomic. It would remove the duplication of some checks there.
>>>
>>> The other atomic state members will die soon. I already have some
>>> patches to achieve that. :)
>>>
>>> I'm not sure if an intermediate state is a good idea. Any code that
>>> disables a crtc should only be looking at the old state.
>>> pre_plane_update runs all stuff in preparation for disabling planes,
>>> while post_plane_update runs everything needed for enabling planes. So
>>> no need to split it up I think, maybe put in some intermediate
>>> watermarks in intel_atomic_state, but no need for a full crtc_state.
>> Well, the intermediate state stuff was requested by Ville in response to
>> my watermark series, so I posted these patches as an RFC to make sure I
>> was understanding what he was looking for properly.
>>
>> Ville, can you comment?
> My opinion is that the current "disable is special" way of doing things
> is quite horrible. For one it makes it really hard to reason about what
> happens to a plane or crtc during the modeset. It's not just off->on,
> on->off, or same->same, but can be on->off->on. With the intermediate
> state in place, there can only be one transition, so really easy to
> think about what's going on.
 pre_plane_update deals with all stuff related to disabling planes, while 
 post_plane_update deals with changes after enabling.

 If the crtc goes from on -> off only you could just hammer in the final 
 values after the disable.

 While for off->on or on->off->on you can put in the final values in 
 .crtc_enable before lighting the pipe. I don't see why wm's would need 
 more transitions.
>>> One special case after another. Yuck. Not to mention that the plane
>>> disable isn't even atomic in the current code, which can look ugly.
>> That's easily fixed by adding a pipe_update_start/end pair.
> It'll also mean don't have to sprinkle silly wm update calls all over
> the modeset path. They will just get updated in response to the plane
> state changes. Same for IPS/FBC etc.
 IPS and FBC are already calculated correctly in response to modesets.
>>> Correctly perhaps, but not in an obvious way.
>> It will become more obvious again when pre_plane_update and 
>> post_plane_update are loops
>> instead of being precalculated from intel_plane_atomic_calc_changes.
> It'll never be obvious as long as the on->off->on case exists.
>
But On -> off will always be a special case because any enable might depend on 
the disable, for example taking over the pll or cdclk changes.
It can never be the same, so why pretend it is?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt

[Jani Nikula]

On Wed, 02 Sep 2015, Egbert Eich  wrote:
> This is exactly the scenatio I'm getting here. I get HPD interrupts at an 
> order of 10^4 / sec.

Makes you wonder if either you have faulty hardware or we are
configuring the hardware wrong (we overlook some configuration about
some voltage/duration threshold maybe, or get irqs from a line that's
floating, or something).

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Make prepare_fb/cleanup_fb only take state, v3.

[Daniel Stone]

On 2 September 2015 at 09:42, Maarten Lankhorst
 wrote:
> This removes the need to separately track fb changes i915.
> That will be done as a separate commit, however.
>
> Changes since v1:
> - Add dri-devel to cc.
> - Fix a check in intel's prepare and cleanup fb to take rotation
>   into account.
> Changes since v2:
> - Split out i915 changes to a separate commit.
>
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Maarten Lankhorst 

I'd probably prefer to see the change to call them unconditionally
(regardless of fb != NULL) in a separate patch, but with or without:
Reviewed-by: Daniel Stone 

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

Re: [Intel-gfx] [PATCH] drm/i915: Update comments around base bpp

[Daniel Vetter]

On Wed, Aug 26, 2015 at 06:57:26PM +0200, Daniel Vetter wrote:
> Forgot to do that in
> 
> commit d328c9d78d64ca11e744fe227096990430a88477
> Author: Daniel Vetter 
> Date:   Fri Apr 10 16:22:37 2015 +0200
> 
> drm/i915: Select starting pipe bpp irrespective or the primary plane
> 
> and it's confusing. Fix it.
> 
> Cc: Jesse Barnes 
> Signed-off-by: Daniel Vetter 

Merged to dinq with Jesse's irc ack.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 384c575ae65f..957a3680381c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12112,10 +12112,6 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
> (DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC)))
>   pipe_config->base.adjusted_mode.flags |= DRM_MODE_FLAG_NVSYNC;
>  
> - /* Compute a starting value for pipe_config->pipe_bpp taking the source
> -  * plane pixel format and any sink constraints into account. Returns the
> -  * source plane bpp so that dithering can be selected on mismatches
> -  * after encoders and crtc also have had their say. */
>   base_bpp = compute_baseline_pipe_bpp(to_intel_crtc(crtc),
>pipe_config);
>   if (base_bpp < 0)
> @@ -12184,7 +12180,7 @@ encoder_retry:
>   /* Dithering seems to not pass-through bits correctly when it should, so
>* only enable it on 6bpc panels. */
>   pipe_config->dither = pipe_config->pipe_bpp == 6*3;
> - DRM_DEBUG_KMS("plane bpp: %i, pipe bpp: %i, dithering: %i\n",
> + DRM_DEBUG_KMS("hw max bpp: %i, pipe bpp: %i, dithering: %i\n",
> base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
>  
>  fail:
> -- 
> 2.5.0
> 

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt

[Daniel Vetter]

On Wed, Sep 02, 2015 at 04:19:00PM +0200, Egbert Eich wrote:
> Daniel Vetter writes:
>  > On Tue, Sep 01, 2015 at 10:21:35PM +0200, Egbert Eich wrote:
>  > > A HPD interrupt may fire during intel_crt_detect_hotplug() - especially
>  > > when HPD interrupt storms occur.
>  > > Since the interrupt handler changes the enabled interrupt lines when it
>  > > detects a storm this races with intel_crt_detect_hotplug().
>  > > To avoid this, shiled the rmw cycles with IRQ save spinlocks.
>  > > 
>  > > Signed-off-by: Egbert Eich 
>  > 
>  > I think this only reduces one source of such races, but fundamentally we
>  > can't avoid them. E.g. if you're _very_ unlucky you might cause a real hpd
>  > right when the strom code frobs around. Plugging the race with this known
> 
> This is exactly the scenatio I'm getting here. I get HPD interrupts at an 
> order of 10^4 / sec.
> 
>  > interrupt source here doesn't fix the fundamental issue.
>  > 
>  > Also I think the actual interrupt deliver is fairly asynchronous, both in
>  > the hardware and in the sw handling. E.g. spin_lock_irq does not
>  > synchronize with the interrupt handler on SMP systems, it only guarantees
>  > that it's not running concurrently on the same cpu (which would deadlock).
>  > 
>  > I think fundamentally this race is unfixable.
> 
> 
> There is one important race we avoid with this patch: It is that
> we change the PORT_HOTPLUG_EN concurrently in the interrupt handler
> (thru xxx_hpd_irq_setup() and in intel_crt_detect_hotplug()).
> 
> With the test system that I have here the old version of the code
> easily runs into this as the time spent inside intel_crt_detect_hotplug() 
> is quite long - especially when no CRT is connected.
> 
> What happens intel_crt_detect_hotplug() reads the value of PORT_HOTPLUG_EN
> at entry, then frobs around for ages, during this time several HPD interrupts
> occur, the storm is detected, the bit related to the stormy line is unset
> then after ages intel_crt_detect_hotplug() decides to give up and restores
> the value it read on entry.
> 
> To remedy this this patch reads the value of PORT_HOTPLUG_EN whenever 
> it is going to change it and adds the spin locks to make sure the 
> read-modify-write cycles don't happen concurrently.
> 
> PORT_HOTPLUG_EN is only touched in two places: in xxx_hpd_irq_setup()
> and in intel_crt_detect_hotplug(), the former can be called from an
> interrupt handler.
> 
> Not sure why you see a problem here.

Hm I missed that this same register is also accessed by the irq handler
code, and it's not just that touching these bits can cause interrupts. So
yeah we need your patch, but it needs to be clearer in the commit message
that there's also trouble with concurrent register access to
PORT_HOTPLUG_EN.

Also I think a commen in the code why we grab that spinlock would be good.
For that extracting a small helper to manipulate the register (like we do
with other irq mask registers with functions like ilk_update_gt_irq) would
be good - then we have just one place to put that commment.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix broken mst get_hw_state.

[Daniel Vetter]

On Wed, Sep 02, 2015 at 04:14:27PM +0200, Maarten Lankhorst wrote:
> Op 02-09-15 om 16:07 schreef Ander Conselvan De Oliveira:
> > On Thu, 2015-08-27 at 13:13 +0200, Maarten Lankhorst wrote:
> >> connector->encoder is initialized as NULL. Fix this by setting it in
> >> during pre enable. MST connectors are not read out during initial hw
> >> readout, and have no fixed encoder mappings. So it's harmless to
> >> return false when the connector has never been assigned to an encoder.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 738178a0ac96..e3922d973db0 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -6283,7 +6283,7 @@ static void intel_connector_check_state(struct 
> >> intel_connector *connector)
> >>  connector->base.name);
> >>  
> >>if (connector->get_hw_state(connector)) {
> >> -  struct drm_encoder *encoder = &connector->encoder->base;
> >> +  struct intel_encoder *encoder = connector->encoder;
> >>struct drm_connector_state *conn_state = connector->base.state;
> >>  
> >>I915_STATE_WARN(!crtc,
> >> @@ -6295,13 +6295,13 @@ static void intel_connector_check_state(struct 
> >> intel_connector *connector)
> >>I915_STATE_WARN(!crtc->state->active,
> >>  "connector is active, but attached crtc isn't\n");
> >>  
> >> -  if (!encoder)
> >> +  if (!encoder || encoder->type == INTEL_OUTPUT_DP_MST)
> >>return;
> >>  
> >> -  I915_STATE_WARN(conn_state->best_encoder != encoder,
> >> +  I915_STATE_WARN(conn_state->best_encoder != &encoder->base,
> >>"atomic encoder doesn't match attached encoder\n");
> >>  
> >> -  I915_STATE_WARN(conn_state->crtc != encoder->crtc,
> >> +  I915_STATE_WARN(conn_state->crtc != encoder->base.crtc,
> >>"attached encoder crtc differs from connector crtc\n");
> >>} else {
> >>I915_STATE_WARN(crtc && crtc->state->active,
> >> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> >> b/drivers/gpu/drm/i915/intel_dp_mst.c
> >> index ebf205462631..d606721b1788 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> >> @@ -159,6 +159,11 @@ static void intel_mst_pre_enable_dp(struct 
> >> intel_encoder *encoder)
> >>return;
> >>}
> >>  
> >> +  /* MST encoders are bound to a crtc, not to a connector,
> >> +   * force the mapping here for get_hw_state.
> >> +   */
> >> +  found->encoder = encoder;
> >> +
> >>DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
> >>intel_mst->port = found->port;
> >>  
> >> @@ -392,7 +397,7 @@ static const struct drm_encoder_funcs 
> >> intel_dp_mst_enc_funcs = {
> >>  
> >>  static bool intel_dp_mst_get_hw_state(struct intel_connector *connector)
> >>  {
> >> -  if (connector->encoder) {
> >> +  if (connector->encoder && connector->base.state->crtc) {
> > Is this here to cover the case where we disable this connector and assign 
> > the encoder to a different
> > connector? I guess this should work since if we disable the connector than 
> > crtc will be null, and
> > we'll assign a proper encoder when re-enabling. But now I'm wondering if it 
> > would make sense to set
> > connector->encoder back to NULL in post_disable.
> >
> Yes, it's harmless to keep it non-null if conn_state->crtc is checked though. 
> Saves another pointless loop.

Hm in get_hw_state functions we really shouldn't look at state pointers
like connector->encoder or state->crtc at all. It /should/ be all
free-standing for fastboot to actually work.

But I guess that's a lot more than just one patch ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt

[Egbert Eich]

Jani Nikula writes:
 > On Wed, 02 Sep 2015, Egbert Eich  wrote:
 > > This is exactly the scenatio I'm getting here. I get HPD interrupts at an 
 > > order of 10^4 / sec.
 > 
 > Makes you wonder if either you have faulty hardware or we are
 > configuring the hardware wrong (we overlook some configuration about
 > some voltage/duration threshold maybe, or get irqs from a line that's
 > floating, or something).

It is faulty hardware. But it is not a single machine that broke.
It is an entire series. IMHO due to bad signal routing and poor shilding
there is crosstalk on the SDVO lines signaling the plug status.
Since SDVO uses PCIe lines it is AC coupled, if I recall correctly
from reading the specs long time ago, one status is signalled by a
10MHz signal, the other by 20MHz.

At the time when I implemented this I've seen other reports from systems 
which showed similar problems under certain conditions(*) - although not 
quite as bad, therefore I thought of a general solution to get rid of 
this once and for all. If this had only been one system with this problem, 
I would just have blacklisted it.

(*) It seems that this somewhat depends on the video mode set (supports
the crosstalk theory) but I also had a report where this occurred at
certain charging levels and whether a power supply was connected or
not.

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

Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subslice and EU count for BDW

[Arun Siluvery]

On 02/09/2015 16:47, Łukasz Daniluk wrote:

Added checks for available slices, subslices and EUs for Broadwell. This
information is filled in intel_device_info and is available to user with
GET_PARAM.
Added checks for enabled slices, subslices and EU for Broadwell. This
information is based on available counts but takes power gated slices
into account. It can be read in debugfs.
Introduce new register defines that contain information on slices on
Broadwell.

v2:
- Introduce GT_SLICE_INFO register
- Change Broadwell sseu_device_status function to use GT_SLICE_INFO
   register instead of RPCS register
- Undo removal of dev_priv variables in Cherryview and Gen9
   sseu_device_satus functions

Cc: Jeff Mcgee 
Signed-off-by: Łukasz Daniluk 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 29 +++-
  drivers/gpu/drm/i915/i915_dma.c | 89 +
  drivers/gpu/drm/i915/i915_reg.h | 22 -
  3 files changed, 137 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307..e8a62ef 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4932,13 +4932,38 @@ static void gen9_sseu_device_status(struct drm_device 
*dev,
}
  }

+static void broadwell_sseu_device_status(struct drm_device *dev,
+struct sseu_dev_status *stat)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int s;
+   u32 slice_info = I915_READ(GEN8_GT_SLICE_INFO);

I don't see this register (0x138064 as defined below) in bdw spec.


+
+   stat->slice_total =
+   hweight32(slice_info & GEN8_LSLICESTAT_MASK);


why not in a single line, seems to fit under 80 chars.


+
+   if (stat->slice_total)
+   {
+   stat->subslice_per_slice = INTEL_INFO(dev)->subslice_per_slice;
+   stat->eu_per_subslice = INTEL_INFO(dev)->eu_per_subslice;
+   stat->subslice_total = stat->slice_total * 
stat->subslice_per_slice;
+   stat->eu_total = stat->eu_per_subslice * stat->subslice_total;
+
Please reorder such that all subslice values are populated first 
followed by EUs to follow an order.



+   /* subtract fused off EU(s) from enabled slice(s) */
+   for (s = 0; s < stat->slice_total; s++) {
+   u8 subslice_7eu = INTEL_INFO(dev)->subslice_7eu[s];
+   stat->eu_total -= hweight8(subslice_7eu);
+   }
+   }
+}
+
  static int i915_sseu_status(struct seq_file *m, void *unused)
  {
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
struct sseu_dev_status stat;

-   if ((INTEL_INFO(dev)->gen < 8) || IS_BROADWELL(dev))
+   if (INTEL_INFO(dev)->gen < 8)
return -ENODEV;

seq_puts(m, "SSEU Device Info\n");
@@ -4963,6 +4988,8 @@ static int i915_sseu_status(struct seq_file *m, void 
*unused)
memset(&stat, 0, sizeof(stat));
if (IS_CHERRYVIEW(dev)) {
cherryview_sseu_device_status(dev, &stat);
+   } else if (IS_BROADWELL(dev)) {
+   broadwell_sseu_device_status(dev, &stat);
} else if (INTEL_INFO(dev)->gen >= 9) {
gen9_sseu_device_status(dev, &stat);
}
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ab37d11..2d52b1e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -705,6 +705,93 @@ static void gen9_sseu_info_init(struct drm_device *dev)
info->has_eu_pg = (info->eu_per_subslice > 2);
  }

+static void broadwell_sseu_info_init(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_device_info *info;
+   const int s_max = 3, ss_max = 3, eu_max = 8;

I only see max of 2 slices for bdw in spec.


+   int s, ss;
+   u32 fuse2, eu_disable[s_max], s_enable, ss_disable;
+
+   fuse2 = I915_READ(GEN8_FUSE2);
+   s_enable = (fuse2 & GEN8_F2_S_ENA_MASK) >>
+   GEN8_F2_S_ENA_SHIFT;
+   ss_disable = (fuse2 & GEN8_F2_SS_DIS_MASK) >>
+   GEN8_F2_SS_DIS_SHIFT;
+
+   eu_disable[0] = I915_READ(GEN8_EU_DISABLE0) &
+   GEN8_EU_DIS0_S0_MASK;
+   eu_disable[1] = (I915_READ(GEN8_EU_DISABLE0) >>
+   GEN8_EU_DIS0_S1_SHIFT) |
+   ((I915_READ(GEN8_EU_DISABLE1) &
+ GEN8_EU_DIS1_S1_MASK) <<
+(32 - GEN8_EU_DIS0_S1_SHIFT));
+   eu_disable[2] = (I915_READ(GEN8_EU_DISABLE1) >>
+   GEN8_EU_DIS1_S2_SHIFT) |
+   ((I915_READ(GEN8_EU_DISABLE2) &
+ GEN8_EU_DIS2_S2_MASK) <<
+(32 - GEN8_EU_DIS1_S2_SHIFT));
+


GEN9_EU_DISABLE(slice) is already available, since the register 
addresses are same maybe it can be reused after renaming it to 

Re: [Intel-gfx] [PATCH 18/17] drm/i915: Don't call intel_get_hpd_pins() when there's no hotplug interrupt

[Daniel Vetter]

On Fri, Aug 28, 2015 at 07:15:15PM -0300, Paulo Zanoni wrote:
> 2015-08-28 16:59 GMT-03:00  :
> > From: Ville Syrjälä 
> >
> > On GMCH plaforms we are now getting the following spew on aux
> > interrupts:
> > [drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 
> > 0x, pins 0x
> > [drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 
> > 0x, pins 0x
> > [drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 
> > 0x, pins 0x
> > [drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 
> > 0x, pins 0x
> > [drm:intel_get_hpd_pins] hotplug event received, stat 0x, dig 
> > 0x, pins 0x
> > [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064
> >
> > Prevent it by not calling intel_get_hpd_pins() unless one of the HPD
> > interrupt bits are actually set.
> >
> > I already fixed similar annoyance once with
> > 4bca26d0a6518d51a9abe64fbde4b12f04c74053 drm/i915: Use 
> > HOTPLUG_INT_STATUS_G4X on VLV/CHV
> >
> > but another source for it got added in
> > fd63e2a972c670887e5e8a08440111d3812c0996 drm/i915: combine 
> > i9xx_get_hpd_pins and pch_get_hpd_pins
> >
> > due to pch_get_hpd_pins() being chosen over i9xx_get_hpd_pins() to
> > serve as the new unified piece of code. pch_get_hpd_pins() had the debug
> > print, and i9xx_get_hpd_pins() didn't.
> >
> > Cc: Imre Deak 
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Paulo Zanoni 

All applied to dinq except for one patch that Jani picked up to -fixes.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 22 ++
> >  1 file changed, 14 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 610d301..07e539d 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1639,20 +1639,26 @@ static void i9xx_hpd_irq_handler(struct drm_device 
> > *dev)
> > if (IS_G4X(dev) || IS_VALLEYVIEW(dev)) {
> > u32 hotplug_trigger = hotplug_status & 
> > HOTPLUG_INT_STATUS_G4X;
> >
> > -   intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> > -  hotplug_trigger, hpd_status_g4x,
> > -  i9xx_port_hotplug_long_detect);
> > -   intel_hpd_irq_handler(dev, pin_mask, long_mask);
> > +   if (hotplug_trigger) {
> > +   intel_get_hpd_pins(&pin_mask, &long_mask, 
> > hotplug_trigger,
> > +  hotplug_trigger, hpd_status_g4x,
> > +  i9xx_port_hotplug_long_detect);
> > +
> > +   intel_hpd_irq_handler(dev, pin_mask, long_mask);
> > +   }
> >
> > if (hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
> > dp_aux_irq_handler(dev);
> > } else {
> > u32 hotplug_trigger = hotplug_status & 
> > HOTPLUG_INT_STATUS_I915;
> >
> > -   intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
> > -  hotplug_trigger, hpd_status_i915,
> > -  i9xx_port_hotplug_long_detect);
> > -   intel_hpd_irq_handler(dev, pin_mask, long_mask);
> > +   if (hotplug_trigger) {
> > +   intel_get_hpd_pins(&pin_mask, &long_mask, 
> > hotplug_trigger,
> > +  hotplug_trigger, hpd_status_i915,
> > +  i9xx_port_hotplug_long_detect);
> > +
> > +   intel_hpd_irq_handler(dev, pin_mask, long_mask);
> > +   }
> > }
> >  }
> >
> > --
> > 2.4.6
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 
> -- 
> Paulo Zanoni
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v3] drm/i915/gtt: Avoid calling kcalloc in a loop when allocating temp bitmaps

[Daniel Vetter]

On Wed, Sep 02, 2015 at 02:46:41PM +0100, Chris Wilson wrote:
> On Wed, Sep 02, 2015 at 02:40:03PM +0100, Michel Thierry wrote:
> > On 9/1/2015 10:06 AM, Michał Winiarski wrote:
> > >On each call to gen8_alloc_va_range_3lvl we're allocating temporary
> > >bitmaps needed for error handling. Unfortunately, when we increase
> > >address space size (48b ppgtt) we do additional (512 - 4) calls to
> > >kcalloc, increasing latency between exec and actual start of execution
> > >on the GPU. Let's just do a single kcalloc, we can also drop the size
> > >from free_gen8_temp_bitmaps since it's no longer used.
> > >
> > >v2: Use GFP_TEMPORARY to make the allocations reclaimable.
> > >v3: Drop the 2D array, just allocate a single block.
> > >
> > >Cc: Chris Wilson 
> > >Cc: Mika Kuoppala 
> > >Cc: Michel Thierry 
> > >Signed-off-by: Michał Winiarski 
> > 
> > Unless Chris thinks otherwise, I see Michał already addressed his comments.
> 
> I think I spotted a misaligned bracket... ;)

checkpatch didn't spot it and neither me ...

> Reviewed-by: Chris Wilson 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt

[Egbert Eich]

Daniel Vetter writes:
 > On Wed, Sep 02, 2015 at 04:19:00PM +0200, Egbert Eich wrote:
 > 
 > Hm I missed that this same register is also accessed by the irq handler
 > code, and it's not just that touching these bits can cause interrupts. So
 > yeah we need your patch, but it needs to be clearer in the commit message
 > that there's also trouble with concurrent register access to
 > PORT_HOTPLUG_EN.
 > 
 > Also I think a commen in the code why we grab that spinlock would be good.
 > For that extracting a small helper to manipulate the register (like we do
 > with other irq mask registers with functions like ilk_update_gt_irq) would
 > be good - then we have just one place to put that commment.

OK, I will come up with a suggestion.

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

Re: [Intel-gfx] [PATCH v6 4/4] drm/i915: set proper N/CTS in modeset

[Daniel Vetter]

On Wed, Sep 02, 2015 at 03:46:40PM +0200, Takashi Iwai wrote:
> On Wed, 02 Sep 2015 15:44:34 +0200,
> Jani Nikula wrote:
> > 
> > On Wed, 02 Sep 2015, Takashi Iwai  wrote:
> > > On Wed, 02 Sep 2015 11:02:42 +0200,
> > > Jani Nikula wrote:
> > >> 
> > >> >> Nitpick. I'd prefer some sharing with the similar blocks from the
> > >> >> earlier patch. Also a debug message on n == 0 would be nice; you
> > >> >> probably didn't notice your audio_config_get_rate() wasn't working
> > >> >> right
> > >> >> because this silently fell back to the automatic mode here.
> > >> >
> > >> > OK, I will add the msg. As you and Ville are insisting on
> > >> > sharing code, I will do it in next version.
> > >> 
> > >> Well, really, I'm fine with having that part duplicated as-is for now,
> > >> we can fix it later. More important to focus on getting
> > >> audio_config_get_rate() right.
> > >> 
> > >> I don't know if you're still targeting v4.3 with this (up to Takashi I
> > >> guess) we'll really need to wrap this up soon.
> > >
> > > I'm in favor of merging this into 4.3, so it'd be appreciated if Libin
> > > can prepare the fixed version soonish, indeed.
> > 
> > IIUC patches 1-3 would be useful on their own already, and a fixed
> > version of patch 4 could follow. Just a thought.
> 
> That's good, then I can take the first three patches.
> 
> Daniel, would you like to review these three before I merge them?
> I assumed your previous mail as a kind of ack to this series, too.

fwiw ack on that plan, but given how much I made a mess out of these two
series and mixed them up I wouldn't trust me anyway ;-)

Once the code settles I'll rebase/backmerge so that I can apply the
follow-up documentation/kerneldoc work that's still getting done.

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

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Make prepare_fb/cleanup_fb only take state, v3.

[Daniel Vetter]

On Wed, Sep 02, 2015 at 03:36:33PM +0100, Daniel Stone wrote:
> On 2 September 2015 at 09:42, Maarten Lankhorst
>  wrote:
> > This removes the need to separately track fb changes i915.
> > That will be done as a separate commit, however.
> >
> > Changes since v1:
> > - Add dri-devel to cc.
> > - Fix a check in intel's prepare and cleanup fb to take rotation
> >   into account.
> > Changes since v2:
> > - Split out i915 changes to a separate commit.
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Maarten Lankhorst 
> 
> I'd probably prefer to see the change to call them unconditionally
> (regardless of fb != NULL) in a separate patch, but with or without:
> Reviewed-by: Daniel Stone 

Applied to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915/gtt: Avoid calling kcalloc in a loop when allocating temp bitmaps

[Daniel Vetter]

On Wed, Sep 02, 2015 at 05:13:29PM +0200, Daniel Vetter wrote:
> On Wed, Sep 02, 2015 at 02:46:41PM +0100, Chris Wilson wrote:
> > On Wed, Sep 02, 2015 at 02:40:03PM +0100, Michel Thierry wrote:
> > > On 9/1/2015 10:06 AM, Michał Winiarski wrote:
> > > >On each call to gen8_alloc_va_range_3lvl we're allocating temporary
> > > >bitmaps needed for error handling. Unfortunately, when we increase
> > > >address space size (48b ppgtt) we do additional (512 - 4) calls to
> > > >kcalloc, increasing latency between exec and actual start of execution
> > > >on the GPU. Let's just do a single kcalloc, we can also drop the size
> > > >from free_gen8_temp_bitmaps since it's no longer used.
> > > >
> > > >v2: Use GFP_TEMPORARY to make the allocations reclaimable.
> > > >v3: Drop the 2D array, just allocate a single block.
> > > >
> > > >Cc: Chris Wilson 
> > > >Cc: Mika Kuoppala 
> > > >Cc: Michel Thierry 
> > > >Signed-off-by: Michał Winiarski 
> > > 
> > > Unless Chris thinks otherwise, I see Michał already addressed his 
> > > comments.
> > 
> > I think I spotted a misaligned bracket... ;)
> 
> checkpatch didn't spot it and neither me ...
> 
> > Reviewed-by: Chris Wilson 
> 
> Queued for -next, thanks for the patch.

Strike that, patch doesn't compile too well on plain dinq. What's going on
here? And there doesn't seem to be anything in -nightly which isn't in
dinq ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] Docs: drm: Move KMS properties table out to source files

[Daniel Vetter]

On Wed, Sep 02, 2015 at 05:14:35PM +0300, Jani Nikula wrote:
> On Wed, 02 Sep 2015, Graham Whaley  wrote:
> >  Documentation/DocBook/drm.tmpl | 925 
> > +
> >  drivers/gpu/drm/drm_crtc.c |  16 +
> >  2 files changed, 17 insertions(+), 924 deletions(-)
> 
> I like this already.

Well the patch removes the entire table but only adds the entry for
rotation property.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx