Re: [Intel-gfx] v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control interrupt lied (SDE)! [regression]

[Miramontes Caton, Jairo Daniel]

Created bug in fdo bugzilla to keep track of this regression: 
https://bugs.freedesktop.org/show_bug.cgi?id=92454
Regards

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, October 12, 2015 2:06 AM
To: Darren Hart
Cc: Linux Kernel Mailing List; Vetter, Daniel; Daniel Vetter; Jani Nikula; 
David Airlie; intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
Miramontes Caton, Jairo Daniel
Subject: Re: v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control 
interrupt lied (SDE)! [regression]

Another regression for Jairo to track.
-Daniel

On Sat, Oct 10, 2015 at 12:08:43PM -0700, Darren Hart wrote:
> The Debian 3.16.0 kernel does not emit the error, but I have not 
> attempted a bisection.
> 
> The warning was added by:
> 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
>  2014-06-18 (1 year, 4 months ago), Oscar Mateo 
> 
> 
> Follows: v3.15-rc8
> Preceedes: 3.17-rc1
> 
> This is not present in v3.16, so perhaps not present in the Debian 
> kernel and this is not a regression, but just reporting the condition as 
> intended.
> 
> Linux Version: v4.3-rc4
> Platform: Lenovo ThinkPad Yoga 12
> OS: Debian 8.2
> 
> $ dmesg | grep -i drm
> [   10.918367] [drm] Initialized drm 1.1.0 20060810
> [   11.235005] [drm] Memory usable by graphics device = 4096M
> [   11.235009] fb: switching to inteldrmfb from simple
> [   11.235093] [drm] Replacing VGA console driver
> [   11.241160] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   11.241162] [drm] Driver supports precise vblank timestamp query.
> [   11.256249] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: 
> Can't calculate constants, dotclock = 0!
> [   11.326946] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit 
> banging on pin 5
> [   11.344097] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on 
> minor 0
> [   11.344913] fbcon: inteldrmfb (fb0) is primary device
> [   12.462509] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   12.466498] i915 :00:02.0: fb0: inteldrmfb frame buffer device
> [   12.794359] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.869733] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.869894] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.870058] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   22.656986] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506246] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506415] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506584] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506746] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722570] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722744] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722908] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776390] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 4057.592685] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> 
> --
> Darren Hart
> Intel Open Source Technology Center

--
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] [PATCH] MAINTAINERS: add link to the Intel Graphics for Linux web site

[Jani Nikula]

There's plenty of drm/i915 related hardware and software documentation,
and firmware downloads for the latest platforms.

Cc: Daniel Vetter 
Signed-off-by: Jani Nikula 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5f467845ef72..95c6bcb6bf22 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3584,6 +3584,7 @@ M:Daniel Vetter 
 M: Jani Nikula 
 L: intel-gfx@lists.freedesktop.org
 L: dri-de...@lists.freedesktop.org
+W: https://01.org/linuxgraphics/
 Q: http://patchwork.freedesktop.org/project/intel-gfx/
 T: git git://anongit.freedesktop.org/drm-intel
 S: Supported
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap

[Daniel Vetter]

On Mon, Oct 12, 2015 at 09:12:57PM +, Williams, Dan J wrote:
> On Mon, 2015-10-12 at 09:01 +0200, Daniel Vetter wrote:
> > On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
> > > i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> > > map it with memremap rather than the implied cache setting of
> > > acpi_os_ioremap().
> > > 
> > > Cc: Daniel Vetter 
> > > Cc: Jani Nikula 
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Cc: David Airlie 
> > > Cc: dri-de...@lists.freedesktop.org
> > > Signed-off-by: Dan Williams 
> > 
> > Assuming you've run sparse over this to make sure you've caught them all,
> > and with the nit below addressed this is
> > 
> > Reviewed-by: Daniel Vetter 
> 
> Indeed, re-running sparse again found a few conversions of ioread* I
> missed as well as moving the force casting out of validate_vbt() to
> find_vbt().
> 
> > Feel free to pull v2 into whatever tree you think it's suitable for (but
> > you can also resend and I'll pick it up).
> 
> Please pick up v2 below.

Queued for -next, thanks for the patch. Aside: Attached or separate mail
seems easier, somehow git apply-mbox can't auto-eat this for of patch.
-Daniel

> 
> > 
> > > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> > > b/drivers/gpu/drm/i915/intel_panel.c
> > > index e2ab3f6ed022..c8444d5f549f 100644
> > > --- a/drivers/gpu/drm/i915/intel_panel.c
> > > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > > @@ -387,7 +387,7 @@ intel_panel_detect(struct drm_device *dev)
> > >  
> > >   /* Assume that the BIOS does not lie through the OpRegion... */
> > >   if (!i915.panel_ignore_lid && dev_priv->opregion.lid_state) {
> > > - return ioread32(dev_priv->opregion.lid_state) & 0x1 ?
> > > + return *(dev_priv->opregion.lid_state) & 0x1 ?
> > 
> > () are redundant now here.
> 
> Yup, fixed.
> 
> 8<
> Subject: i915: switch from acpi_os_ioremap to memremap
> 
> From: Dan Williams 
> 
> i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> map it with memremap rather than the implied cache setting of
> acpi_os_ioremap().
> 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: intel-gfx@lists.freedesktop.org
> Cc: David Airlie 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Dan Williams 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   |2 -
>  drivers/gpu/drm/i915/i915_drv.h   |   12 ++---
>  drivers/gpu/drm/i915/intel_bios.c |   25 +-
>  drivers/gpu/drm/i915/intel_opregion.c |   83 
> -
>  drivers/gpu/drm/i915/intel_panel.c|2 -
>  5 files changed, 62 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e3ec9049081f..15989cc16e92 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1849,7 +1849,7 @@ static int i915_opregion(struct seq_file *m, void 
> *unused)
>   goto out;
>  
>   if (opregion->header) {
> - memcpy_fromio(data, opregion->header, OPREGION_SIZE);
> + memcpy(data, opregion->header, OPREGION_SIZE);
>   seq_write(m, data, OPREGION_SIZE);
>   }
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e1db8de52851..d8684634a31d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -444,14 +444,14 @@ struct opregion_swsci;
>  struct opregion_asle;
>  
>  struct intel_opregion {
> - struct opregion_header __iomem *header;
> - struct opregion_acpi __iomem *acpi;
> - struct opregion_swsci __iomem *swsci;
> + struct opregion_header *header;
> + struct opregion_acpi *acpi;
> + struct opregion_swsci *swsci;
>   u32 swsci_gbda_sub_functions;
>   u32 swsci_sbcb_sub_functions;
> - struct opregion_asle __iomem *asle;
> - void __iomem *vbt;
> - u32 __iomem *lid_state;
> + struct opregion_asle *asle;
> + void *vbt;
> + u32 *lid_state;
>   struct work_struct asle_work;
>  };
>  #define OPREGION_SIZE(8*1024)
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index c19e669ffe50..f6762a5faee8 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1231,20 +1231,13 @@ static const struct dmi_system_id 
> intel_no_opregion_vbt[] = {
>   { }
>  };
>  
> -static const struct bdb_header *validate_vbt(const void __iomem *_base,
> +static const struct bdb_header *validate_vbt(const void *base,
>size_t size,
> -  const void __iomem *_vbt,
> +  const 

Re: [Intel-gfx] 4.2-rc4 kernel warnings on HSW laptop [regression]

[Daniel Vetter]

On Mon, Oct 12, 2015 at 02:29:19PM +0200, Takashi Iwai wrote:
> On Mon, 12 Oct 2015 09:04:20 +0200,
> Daniel Vetter wrote:
> > 
> > Another pile of regressions for Jairo to track ...
> > 
> > On Sat, Oct 10, 2015 at 11:46:29AM +0200, Takashi Iwai wrote:
> > > Hi,
> > > 
> > > I noticed that a HSW laptop gets a few new warnings since 4.2-rc
> > > kernels.  One error messages pops at each boot time:
> > > 
> > >  Console: switching to colour dummy device 80x25
> > >  [drm] Replacing VGA console driver
> > >  [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > >  [drm] Driver supports precise vblank timestamp query.
> > >  vgaarb: device changed decodes: 
> > > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> > >  [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't 
> > > calculate constants, dotclock = 0!
> > 
> > There's patches for this one already, but I accidentally applied them for
> > -next, not -fixes. They should land for -rc6.
> 
> Could you point commit ids?

It was wishful thinking on my side, mixed them up with other patches. I
think this one's still open :(
-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: Hold dev->event_lock whilst inspecting intel_crtc->unpin_work

[Ville Syrjälä]

On Sat, Oct 10, 2015 at 10:44:32AM +0100, Chris Wilson wrote:
> We should serialise access to the intel_crtc->unpin_work through the
> dev->event_lock spinlock. It should not be possible for it to disappear
> without severe error as the mmio_flip worker has not tagged the
> unpin_work pending flip-completion. Similarly if the error exists, just
> taking the unpin_work whilst holding the spinlock and then using it
> unserialised just masks the race. (It is supposed to be valid as the
> unpin_work exists until the flip completion interrupt which should not
> fire until we flush the mmio writes to update the display base which is
> the last time we access the unpin_work from the kthread.)
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=92335
> Signed-off-by: Chris Wilson 

So not sure what's going on yet?

Patch looks OK anyway so
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 57 
> 
>  1 file changed, 32 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index cddb0c692334..71d7298648e0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10848,11 +10848,11 @@ void intel_prepare_page_flip(struct drm_device 
> *dev, int plane)
>   spin_unlock_irqrestore(>event_lock, flags);
>  }
>  
> -static inline void intel_mark_page_flip_active(struct intel_crtc *intel_crtc)
> +static inline void intel_mark_page_flip_active(struct intel_unpin_work *work)
>  {
>   /* Ensure that the work item is consistent when activating it ... */
>   smp_wmb();
> - atomic_set(_crtc->unpin_work->pending, INTEL_FLIP_PENDING);
> + atomic_set(>pending, INTEL_FLIP_PENDING);
>   /* and that it is marked active as soon as the irq could fire. */
>   smp_wmb();
>  }
> @@ -10888,7 +10888,7 @@ static int intel_gen2_queue_flip(struct drm_device 
> *dev,
>   intel_ring_emit(ring, intel_crtc->unpin_work->gtt_offset);
>   intel_ring_emit(ring, 0); /* aux display base address, unused */
>  
> - intel_mark_page_flip_active(intel_crtc);
> + intel_mark_page_flip_active(intel_crtc->unpin_work);
>   return 0;
>  }
>  
> @@ -10920,7 +10920,7 @@ static int intel_gen3_queue_flip(struct drm_device 
> *dev,
>   intel_ring_emit(ring, intel_crtc->unpin_work->gtt_offset);
>   intel_ring_emit(ring, MI_NOOP);
>  
> - intel_mark_page_flip_active(intel_crtc);
> + intel_mark_page_flip_active(intel_crtc->unpin_work);
>   return 0;
>  }
>  
> @@ -10959,7 +10959,7 @@ static int intel_gen4_queue_flip(struct drm_device 
> *dev,
>   pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff;
>   intel_ring_emit(ring, pf | pipesrc);
>  
> - intel_mark_page_flip_active(intel_crtc);
> + intel_mark_page_flip_active(intel_crtc->unpin_work);
>   return 0;
>  }
>  
> @@ -10995,7 +10995,7 @@ static int intel_gen6_queue_flip(struct drm_device 
> *dev,
>   pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff;
>   intel_ring_emit(ring, pf | pipesrc);
>  
> - intel_mark_page_flip_active(intel_crtc);
> + intel_mark_page_flip_active(intel_crtc->unpin_work);
>   return 0;
>  }
>  
> @@ -11090,7 +11090,7 @@ static int intel_gen7_queue_flip(struct drm_device 
> *dev,
>   intel_ring_emit(ring, intel_crtc->unpin_work->gtt_offset);
>   intel_ring_emit(ring, (MI_NOOP));
>  
> - intel_mark_page_flip_active(intel_crtc);
> + intel_mark_page_flip_active(intel_crtc->unpin_work);
>   return 0;
>  }
>  
> @@ -11121,7 +11121,8 @@ static bool use_mmio_flip(struct intel_engine_cs 
> *ring,
>   return ring != i915_gem_request_get_ring(obj->last_write_req);
>  }
>  
> -static void skl_do_mmio_flip(struct intel_crtc *intel_crtc)
> +static void skl_do_mmio_flip(struct intel_crtc *intel_crtc,
> +  struct intel_unpin_work *work)
>  {
>   struct drm_device *dev = intel_crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -11162,11 +11163,12 @@ static void skl_do_mmio_flip(struct intel_crtc 
> *intel_crtc)
>   I915_WRITE(PLANE_CTL(pipe, 0), ctl);
>   I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
>  
> - I915_WRITE(PLANE_SURF(pipe, 0), intel_crtc->unpin_work->gtt_offset);
> + I915_WRITE(PLANE_SURF(pipe, 0), work->gtt_offset);
>   POSTING_READ(PLANE_SURF(pipe, 0));
>  }
>  
> -static void ilk_do_mmio_flip(struct intel_crtc *intel_crtc)
> +static void ilk_do_mmio_flip(struct intel_crtc *intel_crtc,
> +  struct intel_unpin_work *work)
>  {
>   struct drm_device *dev = intel_crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -11186,31 +11188,36 @@ static void ilk_do_mmio_flip(struct intel_crtc 
> *intel_crtc)
>  
>   I915_WRITE(reg, dspcntr);
>  
> - 

Re: [Intel-gfx] [PATCH v2] drm/i915: Improve kernel-doc for i915_audio_component struct

[Takashi Iwai]

On Mon, 12 Oct 2015 10:17:51 +0200,
David Henningsson wrote:
> 
> 
> 
> On 2015-10-12 10:07, David Henningsson wrote:
> > To make kernel-doc happy, the i915_audio_component_audio_ops struct
> > cannot be nested.
> >
> > Signed-off-by: David Henningsson 
> > ---
> 
> Changes since v1:
> 
>   * Added a notice about when pin_eld_notify is called
> 
>   * Uses new inline struct member style
> 
> Verified with "make htmldocs", looks fine to me.
> 
> Also, applies to Takashi's tree (master branch), maybe we should take it 
> through Takashi's tree to avoid conflicts, especially as there might be 
> more stuff coming that way (dp mst support from Mengdong, and perhaps 
> info retrieval from me).

I'm fine to take it, just let me know (and give acks).


thanks,

Takashi


> 
> 
> >   Documentation/DocBook/drm.tmpl |  1 +
> >   include/drm/i915_component.h   | 92 
> > ++
> >   2 files changed, 67 insertions(+), 26 deletions(-)
> >
> > diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> > index 9ddf8c6..f16e4e8 100644
> > --- a/Documentation/DocBook/drm.tmpl
> > +++ b/Documentation/DocBook/drm.tmpl
> > @@ -4051,6 +4051,7 @@ int num_ioctls;
> > High Definition Audio
> >   !Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and 
> > Display Port
> >   !Idrivers/gpu/drm/i915/intel_audio.c
> > +!Iinclude/drm/i915_component.h
> > 
> > 
> > Panel Self Refresh PSR (PSR/SRD)
> > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> > index 89dc7d6..76c10c8 100644
> > --- a/include/drm/i915_component.h
> > +++ b/include/drm/i915_component.h
> > @@ -30,38 +30,78 @@
> >*/
> >   #define MAX_PORTS 5
> >
> > +/**
> > + * struct i915_audio_component_ops - Ops implemented by i915 driver, 
> > called by hda driver
> > + */
> > +struct i915_audio_component_ops {
> > +   /**
> > +* @owner: i915 module
> > +*/
> > +   struct module *owner;
> > +   /**
> > +* @get_power: Request that power well is to be turned on
> > +*/
> > +   void (*get_power)(struct device *);
> > +   /**
> > +* @put_power: Allow the power well to be turned off
> > +*/
> > +   void (*put_power)(struct device *);
> > +   /**
> > +* @codec_wake_override: Force the audio codec to stay awake
> > +*/
> > +   void (*codec_wake_override)(struct device *, bool enable);
> > +   /**
> > +* @get_cdclk_freq: Query the i915 driver about the current cdclk 
> > frequency
> > +*/
> > +   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);
> > +};
> > +
> > +/**
> > + * struct i915_audio_component_audio_ops - Ops implemented by hda driver, 
> > called by i915 driver
> > + */
> > +struct i915_audio_component_audio_ops {
> > +   /**
> > +* @audio_ptr: Pointer to be used in call to pin_eld_notify
> > +*/
> > +   void *audio_ptr;
> > +   /**
> > +* @pin_eld_notify: Notify the HDA driver that pin sense and/or ELD 
> > information has changed
> > +*
> > +* Called when the i915 driver has set up audio pipeline or has just
> > +* begun to tear it down. This allows the HDA driver to update its
> > +* status accordingly (even when the HDA controller is in power save
> > +* mode).
> > +*/
> > +   void (*pin_eld_notify)(void *audio_ptr, int port);
> > +};
> > +
> > +/**
> > + * struct i915_audio_component - Used for direct communication between 
> > i915 and hda drivers
> > + */
> >   struct i915_audio_component {
> > +   /**
> > +* @dev: i915 device, used as parameter for ops
> > +*/
> > struct device *dev;
> > /**
> >  * @aud_sample_rate: the array of audio sample rate per port
> >  */
> > int aud_sample_rate[MAX_PORTS];
> > -
> > -   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_audio_ops {
> > -   void *audio_ptr;
> > -   /**
> > -* Call from i915 driver, notifying the HDA driver that
> > -* pin sense and/or ELD information has 

[Intel-gfx] [PATCH] drm/i915: Log correct start and length in pte map trace

[Michel Thierry]

The PTE_map trace added in commit 4c06ec8d13d2 ("drm/i915/gen8: Add
dynamic page trace events") was using the full start and length values,
instead of the page directory ones.

Since this is just a trace, I don't think it requires cc'ing stable.

Cc: Akash Goel 
Signed-off-by: Michel Thierry 
---
 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 e81990d..642fe87 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1305,8 +1305,8 @@ static int gen8_alloc_va_range_3lvl(struct 
i915_address_space *vm,
page_directory[pde] = gen8_pde_encode(px_dma(pt),
  I915_CACHE_LLC);
trace_i915_page_table_entry_map(>base, pde, pt,
-   gen8_pte_index(start),
-   gen8_pte_count(start, 
length),
+   
gen8_pte_index(pd_start),
+   
gen8_pte_count(pd_start, pd_len),
GEN8_PTES);
 
/* NB: We haven't yet mapped ptes to pages. At this
-- 
2.6.0

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

Re: [Intel-gfx] [PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction

[Sharma, Shashank]

Regards
Shashank

On 10/12/2015 11:39 PM, Rob Bradford wrote:

On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:

BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit Split Gamma mode
3. 12-bit mode

This patch does the following:
1. Adds the core function to program Gamma correction values
for BDW/SKL/BXT platforms
2. Adds Gamma correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
  drivers/gpu/drm/i915/i915_reg.h|  25 ++-
  drivers/gpu/drm/i915/intel_color_manager.c | 248
+
  drivers/gpu/drm/i915/intel_color_manager.h |   6 +
  3 files changed, 277 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 5825ab2..ed50f75 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5647,11 +5647,15 @@ enum skl_disp_power_wells {
  /* legacy palette */
  #define _LGC_PALETTE_A   0x4a000
  #define _LGC_PALETTE_B   0x4a800
-#define LGC_PALETTE(pipe, i) (_PIPE(pipe, _LGC_PALETTE_A,
_LGC_PALETTE_B) + (i) * 4)
+#define _LGC_PALETTE_C   0x4b000
+#define LGC_PALETTE(pipe, i) (_PIPE3(pipe, _LGC_PALETTE_A,
_LGC_PALETTE_B, \
+_LGC_PALETTE_C) + (i) * 4)

  #define _GAMMA_MODE_A 0x4a480
  #define _GAMMA_MODE_B 0x4ac80
-#define GAMMA_MODE(pipe) _PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
+#define _GAMMA_MODE_C  0x4b480
+#define GAMMA_MODE(pipe) \
+   _PIPE3(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B, _GAMMA_MODE_C)
  #define GAMMA_MODE_MODE_MASK  (3 << 0)
  #define GAMMA_MODE_MODE_8BIT  (0 << 0)
  #define GAMMA_MODE_MODE_10BIT (1 << 0)
@@ -8062,6 +8066,23 @@ enum skl_disp_power_wells {
  #define _PIPE_CSC_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))

+/* BDW gamma correction */
+#define PAL_PREC_INDEX_A   0x4A400
+#define PAL_PREC_INDEX_B   0x4AC00
+#define PAL_PREC_INDEX_C   0x4B400
+#define PAL_PREC_DATA_A0x4A404
+#define PAL_PREC_DATA_B0x4AC04
+#define PAL_PREC_DATA_C0x4B404
+#define PAL_PREC_GCMAX_A   0x4A410
+#define PAL_PREC_GCMAX_B   0x4AC10
+#define PAL_PREC_GCMAX_C   0x4B410
+
+#define _PREC_PAL_INDEX(pipe) \
+   (_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B,
PAL_PREC_INDEX_C))
+#define _PREC_PAL_DATA(pipe) \
+   (_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B,
PAL_PREC_DATA_C))
+#define _PREC_PAL_GCMAX(pipe) \
+   (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B,
PAL_PREC_GCMAX_C))


  #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index d5315b2..74f8fc3 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -26,6 +26,252 @@
   */

  #include "intel_color_manager.h"
+static void bdw_write_10bit_gamma_precision(struct drm_device *dev,
+   struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
+   u32 no_of_coeff)
+{
+   u16 blue_fract, green_fract, red_fract;
+   u32 word = 0;
+   u32 count = 0;
+   u32 blue, green, red;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   while (count < no_of_coeff) {
+
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   /*
+   * Maximum possible gamma correction value supported
+   * for BDW is 0x, so clip the values
accordingly
+   */


I think you mean clamp not clip.

Yes, will fix this.



+   if (blue >= BDW_MAX_GAMMA)
+   blue = BDW_MAX_GAMMA;
+   if (green >= BDW_MAX_GAMMA)
+   green = BDW_MAX_GAMMA;
+   if (red >= BDW_MAX_GAMMA)
+   red = BDW_MAX_GAMMA;


So this handles the issue that was raised before that 1.0 in 8.24
should map to 1023.

Yes.



+
+   /*
+   * Gamma correction values are sent in 8.24 format
+   * with 8 int and 24 fraction bits. BDW 10 bit gamma
+   * unit expects correction registers to be programmed
in
+   * 0.10 format, with 0 int and 16 fraction bits. So
take
+   * MSB 10 bit values(bits 23-14) from the fraction
part and
+   * prepare the correction registers.
+   */
+   blue_fract = GET_BITS(blue, 14, 10);
+   green_fract = GET_BITS(green, 14, 10);
+   red_fract = GET_BITS(red, 14, 10);
+


I think this should round to the nearest rather than floor.


Why ? we are getting the exact 

Re: [Intel-gfx] [PATCH 20/22] drm/i915: BDW: Load degamma correction values

[Sharma, Shashank]

Regards
Shashank

On 10/12/2015 11:43 PM, Rob Bradford wrote:

On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:

I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.

This patch adds the no of coefficients(65) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.


Did you copy and paste this from the CHV version? The only constant you
add for degamma here is 512?
Oops, side effects of too many code-refactoring without proper sleep :) 
will fix this.


Rob



Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
  drivers/gpu/drm/i915/i915_drv.c| 7 +++
  drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
  2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 4fa046f..ebf4910 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -303,6 +303,7 @@ static const struct intel_device_info
intel_broadwell_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -316,6 +317,7 @@ static const struct intel_device_info
intel_broadwell_m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -329,6 +331,7 @@ static const struct intel_device_info
intel_broadwell_gt3d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING
| BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -342,6 +345,7 @@ static const struct intel_device_info
intel_broadwell_gt3m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING
| BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -368,6 +372,7 @@ static const struct intel_device_info
intel_skylake_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -382,6 +387,7 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING
| BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -396,6 +402,7 @@ static const struct intel_device_info
intel_broxton_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
index 6c7cb08..e0c486e 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -98,3 +98,6 @@
  #define BDW_MAX_GAMMA ((1 << 24) - 1)
  #define BDW_INDEX_AUTO_INCREMENT   (1 << 15)
  #define BDW_INDEX_SPLIT_MODE   (1 << 31)
+
+/* Degamma on BDW */
+#define BDW_DEGAMMA_MAX_VALS   512

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

Re: [Intel-gfx] [PATCH] drm/i915: Hold dev->event_lock whilst inspecting intel_crtc->unpin_work

[Daniel Vetter]

On Tue, Oct 13, 2015 at 12:23:38PM +0300, Ville Syrjälä wrote:
> On Sat, Oct 10, 2015 at 10:44:32AM +0100, Chris Wilson wrote:
> > We should serialise access to the intel_crtc->unpin_work through the
> > dev->event_lock spinlock. It should not be possible for it to disappear
> > without severe error as the mmio_flip worker has not tagged the
> > unpin_work pending flip-completion. Similarly if the error exists, just
> > taking the unpin_work whilst holding the spinlock and then using it
> > unserialised just masks the race. (It is supposed to be valid as the
> > unpin_work exists until the flip completion interrupt which should not
> > fire until we flush the mmio writes to update the display base which is
> > the last time we access the unpin_work from the kthread.)
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=92335
> > Signed-off-by: Chris Wilson 
> 
> So not sure what's going on yet?
> 
> Patch looks OK anyway so
> Reviewed-by: Ville Syrjälä 

Merged to dinq since it's unclear still.

Thanks, Daniel

> 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 57 
> > 
> >  1 file changed, 32 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index cddb0c692334..71d7298648e0 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10848,11 +10848,11 @@ void intel_prepare_page_flip(struct drm_device 
> > *dev, int plane)
> > spin_unlock_irqrestore(>event_lock, flags);
> >  }
> >  
> > -static inline void intel_mark_page_flip_active(struct intel_crtc 
> > *intel_crtc)
> > +static inline void intel_mark_page_flip_active(struct intel_unpin_work 
> > *work)
> >  {
> > /* Ensure that the work item is consistent when activating it ... */
> > smp_wmb();
> > -   atomic_set(_crtc->unpin_work->pending, INTEL_FLIP_PENDING);
> > +   atomic_set(>pending, INTEL_FLIP_PENDING);
> > /* and that it is marked active as soon as the irq could fire. */
> > smp_wmb();
> >  }
> > @@ -10888,7 +10888,7 @@ static int intel_gen2_queue_flip(struct drm_device 
> > *dev,
> > intel_ring_emit(ring, intel_crtc->unpin_work->gtt_offset);
> > intel_ring_emit(ring, 0); /* aux display base address, unused */
> >  
> > -   intel_mark_page_flip_active(intel_crtc);
> > +   intel_mark_page_flip_active(intel_crtc->unpin_work);
> > return 0;
> >  }
> >  
> > @@ -10920,7 +10920,7 @@ static int intel_gen3_queue_flip(struct drm_device 
> > *dev,
> > intel_ring_emit(ring, intel_crtc->unpin_work->gtt_offset);
> > intel_ring_emit(ring, MI_NOOP);
> >  
> > -   intel_mark_page_flip_active(intel_crtc);
> > +   intel_mark_page_flip_active(intel_crtc->unpin_work);
> > return 0;
> >  }
> >  
> > @@ -10959,7 +10959,7 @@ static int intel_gen4_queue_flip(struct drm_device 
> > *dev,
> > pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff;
> > intel_ring_emit(ring, pf | pipesrc);
> >  
> > -   intel_mark_page_flip_active(intel_crtc);
> > +   intel_mark_page_flip_active(intel_crtc->unpin_work);
> > return 0;
> >  }
> >  
> > @@ -10995,7 +10995,7 @@ static int intel_gen6_queue_flip(struct drm_device 
> > *dev,
> > pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff;
> > intel_ring_emit(ring, pf | pipesrc);
> >  
> > -   intel_mark_page_flip_active(intel_crtc);
> > +   intel_mark_page_flip_active(intel_crtc->unpin_work);
> > return 0;
> >  }
> >  
> > @@ -11090,7 +11090,7 @@ static int intel_gen7_queue_flip(struct drm_device 
> > *dev,
> > intel_ring_emit(ring, intel_crtc->unpin_work->gtt_offset);
> > intel_ring_emit(ring, (MI_NOOP));
> >  
> > -   intel_mark_page_flip_active(intel_crtc);
> > +   intel_mark_page_flip_active(intel_crtc->unpin_work);
> > return 0;
> >  }
> >  
> > @@ -11121,7 +11121,8 @@ static bool use_mmio_flip(struct intel_engine_cs 
> > *ring,
> > return ring != i915_gem_request_get_ring(obj->last_write_req);
> >  }
> >  
> > -static void skl_do_mmio_flip(struct intel_crtc *intel_crtc)
> > +static void skl_do_mmio_flip(struct intel_crtc *intel_crtc,
> > +struct intel_unpin_work *work)
> >  {
> > struct drm_device *dev = intel_crtc->base.dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > @@ -11162,11 +11163,12 @@ static void skl_do_mmio_flip(struct intel_crtc 
> > *intel_crtc)
> > I915_WRITE(PLANE_CTL(pipe, 0), ctl);
> > I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
> >  
> > -   I915_WRITE(PLANE_SURF(pipe, 0), intel_crtc->unpin_work->gtt_offset);
> > +   I915_WRITE(PLANE_SURF(pipe, 0), work->gtt_offset);
> > POSTING_READ(PLANE_SURF(pipe, 0));
> >  }
> >  
> > -static void ilk_do_mmio_flip(struct intel_crtc *intel_crtc)
> > +static void ilk_do_mmio_flip(struct intel_crtc *intel_crtc,
> > +struct intel_unpin_work *work)
> 

Re: [Intel-gfx] [BXT DSI timing fixes v1 2/3] drm/i915/bxt: Get pipe timing for BXT DSI

[Shankar, Uma]

>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Monday, October 12, 2015 10:54 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Kumar, Shobhit
>Subject: Re: [Intel-gfx] [BXT DSI timing fixes v1 2/3] drm/i915/bxt: Get pipe
>timing for BXT DSI
>
>On Mon, Oct 12, 2015 at 10:55:02PM +0530, Uma Shankar wrote:
>> For BXT DSI, vtotal, vactive, hactive registers are different.
>> Making changes to intel_crtc_mode_get() and get_pipe_timings(), to
>> read the correct registers for BXT DSI.
>>
>> Signed-off-by: Uma Shankar 
>> Signed-off-by: Vandana Kannan 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c |   48
>+++---
>>  1 file changed, 45 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 75c60b8..2717823 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -7708,6 +7708,7 @@ static void intel_get_pipe_timings(struct intel_crtc
>*crtc,
>>  struct drm_device *dev = crtc->base.dev;
>>  struct drm_i915_private *dev_priv = dev->dev_private;
>>  enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
>> +bool is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
>>  uint32_t tmp;
>>
>>  tmp = I915_READ(HTOTAL(cpu_transcoder));
>> @@ -7736,6 +7737,26 @@ static void intel_get_pipe_timings(struct intel_crtc
>*crtc,
>>  pipe_config->base.adjusted_mode.crtc_vblank_end += 1;
>>  }
>>
>> +if (IS_BROXTON(dev) && is_dsi) {
>> +struct intel_encoder *encoder;
>> +
>> +for_each_encoder_on_crtc(dev, >base, encoder) {
>> +struct intel_dsi *intel_dsi =
>> +enc_to_intel_dsi(>base);
>> +enum port port;
>> +
>> +for_each_dsi_port(port, intel_dsi->ports) {
>> +pipe_config->base.adjusted_mode.crtc_hdisplay
>=
>> +
>   I915_READ(BXT_MIPI_TRANS_HACTIVE(port));
>> +pipe_config->base.adjusted_mode.crtc_vdisplay
>=
>> +
>   I915_READ(BXT_MIPI_TRANS_VACTIVE(port));
>> +pipe_config->base.adjusted_mode.crtc_vtotal =
>> +
>   I915_READ(BXT_MIPI_TRANS_VTOTAL(port));
>> +}
>> +}
>> +
>> +}
>
>I think I already asked this earlier when this patch was posted; Don't the 
>normal
>pipe timing registers contain the same values? And if so, why would you need to
>read them out from the DSI speciific registers?
>

Normal pipe timing registers like HTOTAL etc. is not used by MIPI DSI for BXT. 
Hence getting the data from
DSI specific registers for BXT. Separate MIPI transcoder is used for BXT.

Regards,
Uma Shankar

>> +
>>  tmp = I915_READ(PIPESRC(crtc->pipe));
>>  pipe_config->pipe_src_h = (tmp & 0x) + 1;
>>  pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1; @@ -10664,6
>> +10685,7 @@ struct drm_display_mode *intel_crtc_mode_get(struct
>drm_device *dev,
>>  int vtot = I915_READ(VTOTAL(cpu_transcoder));
>>  int vsync = I915_READ(VSYNC(cpu_transcoder));
>>  enum pipe pipe = intel_crtc->pipe;
>> +bool is_dsi = intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DSI);
>>
>>  mode = kzalloc(sizeof(*mode), GFP_KERNEL);
>>  if (!mode)
>> @@ -10684,15 +10706,35 @@ struct drm_display_mode
>*intel_crtc_mode_get(struct drm_device *dev,
>>  i9xx_crtc_clock_get(intel_crtc, _config);
>>
>>  mode->clock = pipe_config.port_clock / pipe_config.pixel_multiplier;
>> -mode->hdisplay = (htot & 0x) + 1;
>>  mode->htotal = ((htot & 0x) >> 16) + 1;
>>  mode->hsync_start = (hsync & 0x) + 1;
>>  mode->hsync_end = ((hsync & 0x) >> 16) + 1;
>> -mode->vdisplay = (vtot & 0x) + 1;
>> -mode->vtotal = ((vtot & 0x) >> 16) + 1;
>>  mode->vsync_start = (vsync & 0x) + 1;
>>  mode->vsync_end = ((vsync & 0x) >> 16) + 1;
>>
>> +if (IS_BROXTON(dev) && is_dsi) {
>> +struct intel_encoder *encoder;
>> +
>> +for_each_encoder_on_crtc(dev, _crtc->base, encoder) {
>> +struct intel_dsi *intel_dsi =
>> +enc_to_intel_dsi(>base);
>> +enum port port;
>> +
>> +for_each_dsi_port(port, intel_dsi->ports) {
>> +mode->vtotal =
>> +
>   I915_READ(BXT_MIPI_TRANS_VTOTAL(port));
>> +mode->hdisplay =
>> +
>   I915_READ(BXT_MIPI_TRANS_HACTIVE(port));
>> +mode->vdisplay =
>> +
>   I915_READ(BXT_MIPI_TRANS_VACTIVE(port));
>> +}
>> +}
>> +} else {
>> +mode->vtotal = ((vtot & 0x) >> 16) + 1;
>> +mode->hdisplay = (htot & 0x) + 1;
>> +mode->vdisplay = 

Re: [Intel-gfx] [PATCH 21/22] drm/i915: BDW: Pipe level degamma correction

[Sharma, Shashank]

Thanks for the review Rob.

Regards
Shashank
On 10/12/2015 11:38 PM, Rob Bradford wrote:

On Sat, 2015-10-10 at 00:59 +0530, Shashank Sharma wrote:

BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be applied before Color Transformation.

This patch does the following:
1. Adds the core function to program DeGamma correction values for
BDW/SKL/BXT platform
2. Adds DeGamma correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
  drivers/gpu/drm/i915/intel_color_manager.c | 59
++
  1 file changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 74f8fc3..e659382 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -273,6 +273,63 @@ static int bdw_set_gamma(struct drm_device *dev,
struct drm_property_blob *blob,
return 0;
  }

+static int bdw_set_degamma(struct drm_device *dev,
+   struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+   enum pipe pipe;
+   int num_samples, length;
+   u32 index, mode;
+   u32 pal_prec_index, pal_prec_data;
+   struct drm_palette *degamma_data;
+   struct drm_crtc_state *state = crtc->state;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_r32g32b32 *correction_values = NULL;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   degamma_data = (struct drm_palette *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   num_samples = degamma_data->num_samples;
+
+   if (num_samples == GAMMA_DISABLE_VALS) {
+   /* Disable degamma on Pipe */
+   mode = I915_READ(GAMMA_MODE(pipe)) &
~GAMMA_MODE_MODE_MASK;
+   I915_WRITE(GAMMA_MODE(pipe), mode |
GAMMA_MODE_MODE_8BIT);


When you turn off gamma you call bdw_reset_gamma() should you do the
same for degamma?

No, we tested this part, its not required, its only required for 12 bit 
gamma.

+
+   state->palette_before_ctm_blob = NULL;
+   DRM_DEBUG_DRIVER("Disabling degamma on Pipe %c\n",
+   pipe_name(pipe));
+   return 0;
+   }
+
+   if (num_samples != BDW_SPLITGAMMA_MAX_VALS) {
+   DRM_ERROR("Invalid number of samples\n");
+   return -EINVAL;
+   }
+
+   length = num_samples * sizeof(struct drm_r32g32b32);


Uh, you calculate this length and don't use it anywhere? Was your
intention to check the blob length? And the length check should be in
the generic DRM code anyway...


Yes, this was left over from the previous patch set, will remove this.

I think it was suggested in the past that the number of samples could
be derived from the length of the data allowing the removal of the
struct member.

Right now, its better to have the no of samples coming from userspace. 
As the platform is under development, its good to have this control 
available so that userspace will be clear on what it wants to do, I have 
added this in my to do list, when we are sure that we dont need it, we 
will remove and optimize it.

+   mode = I915_READ(GAMMA_MODE(pipe));


Move this closer to where you use it?


Agree.

+   pal_prec_index = _PREC_PAL_INDEX(pipe);
+   pal_prec_data = _PREC_PAL_DATA(pipe);
+
+   correction_values = (struct drm_r32g32b32 *)_data
->lut;


Why do you need this cast?


Not required, agree, will remove.

+   index = I915_READ(pal_prec_index);
+   index |= BDW_INDEX_AUTO_INCREMENT | BDW_INDEX_SPLIT_MODE;
+   I915_WRITE(pal_prec_index, index);
+
+   bdw_write_10bit_gamma_precision(dev, correction_values,
+   pal_prec_data, BDW_SPLITGAMMA_MAX_VALS);
+
+   /* Enable DeGamma on Pipe */
+   mode &= ~GAMMA_MODE_MODE_MASK;
+   I915_WRITE(GAMMA_MODE(pipe), mode | GAMMA_MODE_MODE_SPLIT);
+   DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",


Choose your capitalisation DeGamma or degamma. Pick one and use it
consistently to make it easier to grep through the code.


Will stick with degamma now.

It also looks like you should check if the gamma mode is not something
other than split / off. Otherwise strange things could happen.
Similarly in the gamma code you shouldn't be able to program something
other than split if you have a degamma mode set.

We discussed this in the design phase itself. This decision has to go to 
userspcae only, whom should know, what its doing. There are various 
permutation and combinations possbile which make kernel code unnecessary 
complex. Kernel will just follow what is being requested from usp.

+   pipe_name(pipe));
+
+   return 0;
+}
+
  static s16 chv_prepare_csc_coeff(s64 csc_value)
  {
s32 csc_int_value;
@@ -579,6 +636,8 @@ void intel_color_manager_crtc_commit(struct

Re: [Intel-gfx] [PATCH] drm/i915: Reset dpll_hw_state when selecting a new pll on hsw

[Daniel Vetter]

On Tue, Oct 13, 2015 at 03:18:16PM +0200, Maarten Lankhorst wrote:
> Op 23-09-15 om 17:34 schreef Gabriel Feceoru:
> > Using 2 connectors (DVI and VGA) will cause wrpll to be set for
> > INTEL_OUTPUT_HDMI but never reset if switching to INTEL_OUTPUT_VGA
> >
> > Supresses errors like these:
> > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
> > dpll_hw_state.wrpll
> >
> Looks like a good idea to always zero it.

Except that we still have a bunch of cases where we recompute clock state
but only partially. Can we just move them all up into a common place
please? That would also catch cases where we simply forget to fill this
out at all.

One case I noticed is edp in skl_ddi_pll_select, but there's probably
more.
-Daniel
> 
> Reviewed-by: Maarten Lankhorst 
> ___
> 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 21/22] drm/i915: BDW: Pipe level degamma correction

[Emil Velikov]

On 10 October 2015 at 06:31, Sharma, Shashank  wrote:
> On 10/10/2015 5:19 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma 
>> wrote:
>>>
>>> BDW/SKL/BXT supports Degamma color correction feature, which
>>> linearizes the non-linearity due to gamma encoded color values.
>>> This will be applied before Color Transformation.
>>>
>>> This patch does the following:
>>> 1. Adds the core function to program DeGamma correction values for
>>> BDW/SKL/BXT platform
>>> 2. Adds DeGamma correction macros/defines
>>>
>>> Signed-off-by: Shashank Sharma 
>>> Signed-off-by: Kausal Malladi 
>>> ---
[snip]
>> Why don't you use switch statement here ?
>>
> Same as CHV degamma. Degamma has only 3 conditions (enable/disable and
> invalid), and we generally try to accommodate upto 3 condition within if ...
> else.
That rule sounds a bit funny bth. I'm not sure where it comes from,
but as is the codeflow isn't that obvious and the patches look
inconsistent with one another.

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

Re: [Intel-gfx] [PATCH 16/22] drm/i915: Commit color correction to CRTC

[Sharma, Shashank]

Regards
Shashank

On 10/13/2015 6:47 PM, Emil Velikov wrote:

On 10 October 2015 at 06:20, Sharma, Shashank  wrote:

On 10/10/2015 4:54 AM, Emil Velikov wrote:


Hi Shashank,

On 9 October 2015 at 20:29, Shashank Sharma 
wrote:


The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
   drivers/gpu/drm/i915/intel_color_manager.c | 44
++
   drivers/gpu/drm/i915/intel_display.c   |  2 ++
   drivers/gpu/drm/i915/intel_drv.h   |  3 ++
   3 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 433e50a..d5315b2 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -307,6 +307,50 @@ static int chv_set_gamma(struct drm_device *dev,
struct drm_property_blob *blob,
  return ret;
   }

+void intel_color_manager_crtc_commit(struct drm_device *dev,
+   struct drm_crtc_state *crtc_state)
+{
+   struct drm_property_blob *blob;
+   struct drm_crtc *crtc = crtc_state->crtc;
+   int ret = -EINVAL;


Most places/people advise against pre-emptively initializing ret.


Just in this case, if makes sense to keep one, coz there might be multiple
blobs which we are applying in the commit action, and every blob can return
error, from the core function.
Assume that there is a situation where both palette_after_ctm(gamma) and CTM
is in place, then we will be going through multiple if() cases and have to
check the return values.

When you have an exception of any rule, this implies that you are
using a suboptimal way of doing things.

Not sure, but if you think its that serious, I will gladly change it to 
as you suggested :)


+
+   blob = crtc_state->palette_after_ctm_blob;
+   if (blob) {
+   /* Gamma correction is platform specific */
+   if (IS_CHERRYVIEW(dev))
+   ret = chv_set_gamma(dev, blob, crtc);
+
+   if (ret)
+   DRM_ERROR("set Gamma correction failed\n");


Do we really want to spam dmesg on for each non Cherryview device ?


If you see the complete implementation, as IS_GEN8()/IS_SKL is coming up
here after IS_CHV(patch 19,20,21) which will cover BDW/SKL/BXT. Anything
else which comes here, deserves a DRM_ERROR() as this platform will not be
supported.


Your patches should be independent changes. You cannot say "I'm adding
something iffy here, but it will be fixed with another patch".
Otherwise you'll get developer/user X bisecting the kernel, which will
end up with broken system (flooded dmesg in this case) half way
through the bisect.


There is no confusion here, and its an independent change.
Till this patch, we have color management implemented for CHV only and 
any other platforms, should not even register this property, so 
naturally it must not hit this part of code. If its hitting, yes I would 
like to show this DRM_ERROR. So there is nothing wrong even if we bisect.



Regards,
Emil


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

Re: [Intel-gfx] [PATCH 22/22] drm/i915: BDW: Pipe level CSC correction

[Emil Velikov]

On 10 October 2015 at 06:34, Sharma, Shashank  wrote:
> On 10/10/2015 5:24 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma 
>> wrote:
>>>
>>> BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
>>> that needs to be programmed into respective CSC registers.
>>>
>>> This patch does the following:
>>> 1. Adds the core function to program CSC correction values for
>>> BDW/SKL/BXT platform
>>> 2. Adds CSC correction macros/defines
>>>
>>> Signed-off-by: Shashank Sharma 
>>> Signed-off-by: Kausal Malladi 
>>> Signed-off-by: Kumar, Kiran S 
>>> ---
>>>   drivers/gpu/drm/i915/i915_reg.h|   7 ++
>>>   drivers/gpu/drm/i915/intel_color_manager.c | 114
>>> -
>>>   drivers/gpu/drm/i915/intel_color_manager.h |  12 ++-
>>>   3 files changed, 129 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index ed50f75..0e9d252 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -8085,4 +8085,11 @@ enum skl_disp_power_wells {
>>>  (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B,
>>> PAL_PREC_GCMAX_C))
>>>
>>>
>>> +/* BDW CSC correction */
>>> +#define CSC_COEFF_A0x49010
>>> +#define CSC_COEFF_B0x49110
>>> +#define CSC_COEFF_C0x49210
>>> +#define _PIPE_CSC_COEFF(pipe) \
>>> +   (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
>>> +
>>>   #endif /* _I915_REG_H_ */
>>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>>> b/drivers/gpu/drm/i915/intel_color_manager.c
>>> index e659382..0a6c00c 100644
>>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>>> @@ -330,11 +330,119 @@ static int bdw_set_degamma(struct drm_device *dev,
>>>  return 0;
>>>   }
>>>
>>> -static s16 chv_prepare_csc_coeff(s64 csc_value)
>>
>> As mentioned previously, this should be part of the respective patch.
>>
> Agree. Looks like diff is messing up a bit. Will take care of this.
>
>>> +static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
>>> +{
>>> +   uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
>>> +   int32_t mantissa;
>>> +   uint64_t abs_coeff;
>>> +
>>> +   coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
>>> +   coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
>>> +
>>> +   abs_coeff = abs(coeff);
>>> +   if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
>>> +   /* abs_coeff < 0.125 */
>>> +   exponent_bits = 3;
>>> +   ls_bit_pos = 19;
>>> +   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
>>> +   abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
>>> +   /* abs_coeff >= 0.125 && val < 0.25 */
>>> +   exponent_bits = 2;
>>> +   ls_bit_pos = 20;
>>> +   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
>>> +   && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
>>> +   /* abs_coeff >= 0.25 && val < 0.5 */
>>> +   exponent_bits = 1;
>>> +   ls_bit_pos = 21;
>>> +   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
>>> +   && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
>>> +   /* abs_coeff >= 0.5 && val < 1.0 */
>>> +   exponent_bits = 0;
>>> +   ls_bit_pos = 22;
>>> +   } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
>>> +   abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
>>> +   /* abs_coeff >= 1.0 && val < 2.0 */
>>> +   exponent_bits = 7;
>>> +   ls_bit_pos = 23;
>>> +   } else {
>>> +   /* abs_coeff >= 2.0 && val < 4.0 */
>>> +   exponent_bits = 6;
>>> +   ls_bit_pos = 24;
>>> +   }
>>> +
>>> +   mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos,
>>> CSC_MAX_VALS);
>>> +   if (coeff < 0) {
>>> +   sign_bit = 1;
>>> +   mantissa = -mantissa;
>>> +   mantissa &= ((1 << CSC_MAX_VALS) - 1);
>>
>> I think there is a macro for this already ?
>>
> Thats for GAMMA_MAX, not for CSC_MAX. Or you mean the whole (1 <<
> CSC_MAX_VALS -1) to be replaced with GET/SET bits ?
What I mean is - the above looks exactly like the GET_BIT_MASK (which
you introduced). Perhaps you can use it ?

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix kerneldoc for i915_gem_shrink_all

[Jani Nikula]

On Tue, 06 Oct 2015, Daniel Vetter  wrote:
> I've botched this, so let's fix it.
>
> Signed-off-by: Daniel Vetter 

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

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index f6ecbda2c604..674341708033 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -143,7 +143,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
>  }
>  
>  /**
> - * i915_gem_shrink - Shrink buffer object caches completely
> + * i915_gem_shrink_all - Shrink buffer object caches completely
>   * @dev_priv: i915 device
>   *
>   * This is a simple wraper around i915_gem_shrink() to aggressively shrink 
> all
> -- 
> 2.5.1
>
> ___
> 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: Reset dpll_hw_state when selecting a new pll on hsw

[Daniel Vetter]

On Tue, Oct 13, 2015 at 03:43:28PM +0200, Maarten Lankhorst wrote:
> Op 13-10-15 om 15:35 schreef Daniel Vetter:
> > On Tue, Oct 13, 2015 at 03:18:16PM +0200, Maarten Lankhorst wrote:
> >> Op 23-09-15 om 17:34 schreef Gabriel Feceoru:
> >>> Using 2 connectors (DVI and VGA) will cause wrpll to be set for
> >>> INTEL_OUTPUT_HDMI but never reset if switching to INTEL_OUTPUT_VGA
> >>>
> >>> Supresses errors like these:
> >>> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
> >>> dpll_hw_state.wrpll
> >>>
> >> Looks like a good idea to always zero it.
> > Except that we still have a bunch of cases where we recompute clock state
> > but only partially. Can we just move them all up into a common place
> > please? That would also catch cases where we simply forget to fill this
> > out at all.
> >
> > One case I noticed is edp in skl_ddi_pll_select, but there's probably
> > more.
> >
> Something like below, with all the memsets for dpll_hw_state removed?

I think this will blow up since we recompute clock state only when
needs_modeset is true. So needs a bit more intelligence in deciding when
to clear it I think.
-Daniel
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 633da693fed8..956b7ffab32f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11911,7 +11911,6 @@ clear_intel_crtc_state(struct intel_crtc_state 
> *crtc_state)
>  {
>   struct drm_crtc_state tmp_state;
>   struct intel_crtc_scaler_state scaler_state;
> - struct intel_dpll_hw_state dpll_hw_state;
>   enum intel_dpll_id shared_dpll;
>   uint32_t ddi_pll_sel;
>   bool force_thru;
> @@ -11924,7 +11923,6 @@ clear_intel_crtc_state(struct intel_crtc_state 
> *crtc_state)
>   tmp_state = crtc_state->base;
>   scaler_state = crtc_state->scaler_state;
>   shared_dpll = crtc_state->shared_dpll;
> - dpll_hw_state = crtc_state->dpll_hw_state;
>   ddi_pll_sel = crtc_state->ddi_pll_sel;
>   force_thru = crtc_state->pch_pfit.force_thru;
>  
> 

-- 
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 10/22] drm/i915: Register color correction capabilities

[Sharma, Shashank]

> Do you have a link handy ? I suspect that something else was mentioned in 
> that comment as splitting function declaration and definition is extremely 
> uncommon
Yep, maybe I misunderstood. I will add the definition here. 

Regards
Shashank
-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com] 
Sent: Tuesday, October 13, 2015 7:24 PM
To: Sharma, Shashank
Cc: Matheson, Annie J; Bradford, Robert; Palleti, Avinash Reddy; 
intel-gfx@lists.freedesktop.org; ML dri-devel; Mukherjee, Indranil; Bish, Jim; 
Barnes, Jesse; Smith, Gary K; Kausal Malladi; Vetter, Daniel; Kumar, Kiran S
Subject: Re: [PATCH 10/22] drm/i915: Register color correction capabilities

On 13 October 2015 at 14:36, Sharma, Shashank  wrote:
> On 10/13/2015 6:33 PM, Emil Velikov wrote:
>>
>> On 10 October 2015 at 06:01, Sharma, Shashank 
>> 
>> wrote:
>>>
>>> On 10/10/2015 3:51 AM, Emil Velikov wrote:


 Hi Shashank,

 On 9 October 2015 at 20:29, Shashank Sharma 
 
 wrote:
>
>
>   From DRM color management:
> 
> DRM color manager supports these color properties:
> 1. "ctm": Color transformation matrix property, where a
>  color transformation matrix of 9 correction values gets
>  applied as correction.
> 2. "palette_before_ctm": for corrections which get applied
>  beore color transformation matrix correction.
> 3. "palette_after_ctm": for corrections which get applied
>  after color transformation matrix correction.
>
> These color correction capabilities may differ per platform, 
> supporting various different no. of correction coefficients. So 
> DRM color manager support few properties using which a user space 
> can query the platform's capability, and prepare color correction 
> accordingly.
> These query properties are:
> 1. cm_coeff_after_ctm_property
> 2. cm_coeff_before_ctm_property
> (CTM is fix to 9 coefficients across industry)
>
> Now, Intel color manager registers:
> ==
> 1. Gamma correction property as "palette_after_ctm" property 2. 
> Degamma correction capability as "palette_bafore_ctm" property
>  capability as "palette_after_ctm" DRM color property hook.
> 3. CSC as "ctm" property.
>
> So finally, This patch does the following:
> 1. Add a function which loads the platform's color correction
>  capabilities in the cm_crtc_palette_capabilities_property
> structure.
> 2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
>  getting initiaized.
> 3. Adds two new parameters "num_samples_after_ctm" and
>  "num_samples_before_ctm" in intel_device_info as gamma and
>  degamma coefficients vary per platform basis.
>
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>drivers/gpu/drm/i915/i915_drv.h|  2 ++
>drivers/gpu/drm/i915/intel_color_manager.c | 33
> +-
>2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> b/drivers/gpu/drm/i915/i915_drv.h index ad37b25..8bf1d6f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -798,6 +798,8 @@ struct intel_device_info {
>   u8 num_sprites[I915_MAX_PIPES];
>   u8 gen;
>   u8 ring_mask; /* Rings supported by the HW */
> +   u16 num_samples_after_ctm;
> +   u16 num_samples_before_ctm;
>   DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
>   /* Register offsets for the various display pipes and 
> transcoders */
>   int pipe_offsets[I915_MAX_TRANSCODERS];
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 7357d99..e466748 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -28,6 +28,37 @@
>#include "intel_color_manager.h"
>
>void intel_attach_color_properties_to_crtc(struct drm_device *dev,
> -   struct drm_mode_object *mode_obj)
> +   struct drm_crtc *crtc)
>{
> +   struct drm_mode_config *config = >mode_config;
> +   struct drm_mode_object *mode_obj = >base;
> +
> +   /*
> +* Register:
> +* =
> +* Gamma correction as palette_after_ctm property
> +* Degamma correction as palette_before_ctm property
> +*
> +* Load:
> +* =
> +* no. of coefficients supported on this platform for gamma
> +* 

Re: [Intel-gfx] [PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction

[Emil Velikov]

On 13 October 2015 at 14:40, Sharma, Shashank  wrote:

> I am not sure if I915 follows a general rule of using for(...) over while(),
> coz I see many instances of using a while in i915_gem, i915_drv, i915_irq
> etc, so it should be good. I would see if someone else can suggest another
> good reason.
I'm not saying "you should never use while loops", but more of "people
use for loops when accessing arrays of information". I cannot see any
cases of the latter in i915. Perhaps I'm looking at some old code ?

The point I'm trying to make here is that people are unlikely to make
comments about such trivial nitpicks (bikeshedding), but new
contributions should stick with the existing approach, rather than
going for "I like XXX" :)

Take any and all of my with a grain of salt, just in case.

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

[Intel-gfx] 4.3-rc5 triggering warning in i915 driver

[Oliver Neukum]

Hi,

I got this warning, which 4.2 didn't show on boot:

[6.882835] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch
in has_drrs (expected 1, found 0)
[6.882836] [ cut here ]
[6.882854] WARNING: CPU: 0 PID: 6 at
drivers/gpu/drm/i915/intel_display.c:12691 intel_modeset_check_state
+0x4c7/0x8e0 [i915]()
[6.882855] pipe state doesn't match!
[6.882863] Modules linked in: crc32c_intel(E) ahci(E) libahci(E)
libata(E) i915(E) i2c_algo_bit(E) drm_kms_helper(E) syscopyarea(E)
sysfillrect(E) ehci_pci(E) sysimgblt(E) fb_sys_fops(E) ehci_hcd(E)
usbcore(E) drm(E) usb_common(E) wmi(E) video(E) button(E) sg(E)
scsi_mod(E) autofs4(E)
[6.882865] CPU: 0 PID: 6 Comm: kworker/u16:0 Tainted: GE
4.3.0-rc5-default+ #4
[6.882865] Hardware name: Hewlett-Packard HP EliteBook 8780w/190A,
BIOS L70 Ver. 93.01 05/17/2013
[6.882870] Workqueue: events_unbound async_run_entry_fn
[6.882872]  a02863f0 880692cc3878 812e3e26
880692cc38c0
[6.882872]  880692cc38b0 810647a6 880691f37400
88068de86000
[6.882873]  880692eeec00  88068e568a00
880692cc3910
[6.882874] Call Trace:
[6.882878]  [] dump_stack+0x44/0x5e
[6.882881]  [] warn_slowpath_common+0x86/0xc0
[6.882882]  [] warn_slowpath_fmt+0x4c/0x50
[6.882897]  [] intel_modeset_check_state
+0x4c7/0x8e0 [i915]
[6.882914]  [] intel_atomic_commit+0x598/0x5f0
[i915]
[6.882928]  [] drm_atomic_commit+0x37/0x60 [drm]
[6.882933]  [] drm_atomic_helper_set_config
+0x38e/0x400 [drm_kms_helper]
[6.882941]  [] drm_mode_set_config_internal
+0x64/0x100 [drm]
[6.882945]  [] restore_fbdev_mode+0xab/0x110
[drm_kms_helper]
[6.882949]  []
drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper]
[6.882952]  [] drm_fb_helper_set_par+0x2c/0x50
[drm_kms_helper]
[6.882972]  [] intel_fbdev_set_par+0x1a/0x60
[i915]
[6.882974]  [] fbcon_init+0x4c6/0x550
[6.882976]  [] visual_init+0xca/0x130
[6.882977]  [] do_bind_con_driver+0x146/0x310
[6.882979]  [] do_take_over_console+0x141/0x1b0
[6.882980]  [] do_fbcon_takeover+0x57/0xb0
[6.882981]  [] fbcon_event_notify+0x60b/0x750
[6.882983]  [] notifier_call_chain+0x49/0x70
[6.882984]  [] __blocking_notifier_call_chain
+0x4d/0x70
[6.882985]  [] blocking_notifier_call_chain
+0x16/0x20
[6.882987]  [] fb_notifier_call_chain+0x1b/0x20
[6.882988]  [] register_framebuffer+0x1de/0x300
[6.882991]  [] drm_fb_helper_initial_config
+0x257/0x3a0 [drm_kms_helper]
[6.883008]  [] intel_fbdev_initial_config
+0x1b/0x20 [i915]
[6.883010]  [] async_run_entry_fn+0x48/0x150
[6.883012]  [] process_one_work+0x149/0x3e0
[6.883014]  [] worker_thread+0x11a/0x460
[6.883015]  [] ? max_active_store+0x60/0x60
[6.883016]  [] kthread+0xc9/0xe0
[6.883017]  [] ? kthread_park+0x60/0x60
[6.883019]  [] ret_from_fork+0x3f/0x70
[6.883020]  [] ? kthread_park+0x60/0x60
[6.883021] ---[ end trace 2a13d8ac0ddd1cac ]---
[6.886953] Console: switching to colour frame buffer device 200x56
[6.889577] i915 :00:02.0: fb0: inteldrmfb frame buffer device


00:02.0 0300: 8086:0416 (rev 06) (prog-if 00 [VGA controller])
Subsystem: 103c:190a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR-  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00018  Data: 
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
Kernel modules: i915

01:00.0 0300: 10de:11b6 (rev a1) (prog-if 00 [VGA controller])
Subsystem: 103c:190a
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
Capabilities: [100 v1] Virtual Channel
Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
Arb:Fixed- WRR32- WRR64- WRR128-
Ctrl:   ArbSelect=Fixed
Status: InProgress-
VC0:Caps:   PATOffset=00 MaxTimeSlots=1
RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128-
WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [128 v1] Power Budgeting 
Capabilities: [600 v1] Vendor Specific Information: ID=0001
Rev=1 Len=024 
Capabilities: [900 v1] #19

Re: [Intel-gfx] [PATCH] RFC drm/i915: Stop the machine whilst capturing the GPU crash dump

[Chris Wilson]

On Tue, Oct 13, 2015 at 02:52:46PM +0100, Chris Wilson wrote:
> On Tue, Oct 13, 2015 at 03:52:08PM +0200, Daniel Vetter wrote:
> > Yeah, hence using _rcu list macros. They have the relevant barriers
> > already and should work. The only difference is that instead of
> > synchronize_rcu on the write side before kfree, we'll use stop_machine on
> > the read side. It's still RCU, but with all the cost moved to the read
> > side while still keeping the benefit that the read side can be done
> > locklessly.
> 
> They imply a mb() on every write not just a barrier(), and we do a fair few
> list updates on each buffer.

Daniel pointed out that I was reading the version for pentium pro. But
the next question will be when does that actually get set?
-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 1/2] drm/i915: Restore lost DPLL register write on gen2-4

[Jani Nikula]

On Tue, 13 Oct 2015, Daniel Vetter  wrote:
> On Tue, Oct 13, 2015 at 04:10:19PM +0300, Jani Nikula wrote:
>> On Thu, 08 Oct 2015, Ville Syrjälä  wrote:
>> > On Thu, Oct 08, 2015 at 10:17:30AM +0200, Daniel Vetter wrote:
>> >> On Wed, Oct 07, 2015 at 10:08:24PM +0300, ville.syrj...@linux.intel.com 
>> >> wrote:
>> >> > From: Ville Syrjälä 
>> >> > 
>> >> > We accidentally lost the initial DPLL register write in
>> >> > 1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M
>> >> > 
>> >> > The "three times for luck" hack probably saved us from a total
>> >> > disaster. But anyway, bring the initial write back so that the
>> >> > code actually makes some sense.
>> >> > 
>> >> > Cc: sta...@vger.kernel.org
>> >> > Cc: Nick Bowler 
>> >> Reported-and-tested-by: Nick Bowler 
>> >> References: 
>> >> http://lists.freedesktop.org/archives/intel-gfx/2015-October/077463.html
>> >> 
>> >> > Signed-off-by: Ville Syrjälä 
>> >> > ---
>> >> >  drivers/gpu/drm/i915/intel_display.c | 2 ++
>> >> >  1 file changed, 2 insertions(+)
>> >> > 
>> >> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> >> > b/drivers/gpu/drm/i915/intel_display.c
>> >> > index 147e700..f4fdff9 100644
>> >> > --- a/drivers/gpu/drm/i915/intel_display.c
>> >> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> >> > @@ -1743,6 +1743,8 @@ static void i9xx_enable_pll(struct intel_crtc 
>> >> > *crtc)
>> >> >I915_READ(DPLL(!crtc->pipe)) | 
>> >> > DPLL_DVO_2X_MODE);
>> >> 
>> >> Don't we also need a POSTING_READ here to make sure the two-step 2x mode
>> >> sequence is still followed?
>> >
>> > We don't do write combining on registers, and there are no shadow
>> > register type of things to consider in this case either.
>> >
>> >> 
>> >> With that addressed Reviewed-by: Daniel Vetter 
>> 
>> 
>> Daniel, are you happy with the responses about posting reads, for both
>> patches?
>
> Yeah, acked on irc but forgot to follow up.

Both pushed to drm-intel-fixes, thanks for the patches and review.

BR,
Jani.


> -Daniel
> -- 
> 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] drm/i915: Deny wrapping an userptr into a framebuffer

[Tvrtko Ursulin]

On 13/10/15 15:00, Tvrtko Ursulin wrote:


On 13/10/15 14:22, Chris Wilson wrote:

Pinning a userptr onto the hardware raises interesting questions about
the lifetime of such a surface as the framebuffer extends that life
beyond the client's address space. That is the hardware will need to
keep scanning out from the backing storage even after the client wants
to remap its address space. As the hardware pins the backing storage,


P.S.
Or even after the client exits in the new world order!

Regards,

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/bxt: add revision id for A1 stepping and use it

[Ville Syrjälä]

On Tue, Oct 13, 2015 at 04:16:47PM +0300, Jani Nikula wrote:
> On Wed, 07 Oct 2015, Jani Nikula  wrote:
> > On Tue, 06 Oct 2015, Ville Syrjälä  wrote:
> >> On Tue, Oct 06, 2015 at 04:43:11PM +0300, Jani Nikula wrote:
> >>> On Tue, 06 Oct 2015, Ville Syrjälä  wrote:
> >>> > On Tue, Oct 06, 2015 at 02:41:15PM +0300, Jani Nikula wrote:
> >>> >> Prefer inclusive ranges for revision checks rather than "below B0". Per
> >>> >> specs A2 is not used, so revid <= A1 matches revid < B0.
> >>> >
> >>> > The w/a db would say UNTIL_B0 etc., so might be easier to check against
> >>> > it if we keep to the same convention.
> >>> 
> >>> So I wanted to double check what the convention is. I picked
> >>> WaRsDisableCoarsePowerGating.
> >>> 
> >>> KBL - SIWA_FOREVER
> >>> BXT - SI_WA_BEFORE(BXT_REV_ID_B0)
> >>> SKL - SIWA_UNTIL_SKL_E0
> >>> 
> >>> Description "Disable coarse power gating for GT4 until GT F0 stepping."
> >>> 
> >>> *rolls eyes*
> >>> 
> >>> So is that "until" there inclusive or non-inclusive? The db is
> >>> contradicting itself...
> >>
> >> Hmm. My recollection was that it's exclusive, but now that I look at
> >> your findings and some other workarounds, it does look a bit more like
> >> inclusive.
> >>
> >> I would think the exclusive thing would be easier to maintain since
> >> the hsd specifies the stepping in which stuff got fixed, and the
> >> exclusive convention would then have the same stepping listed. Eg. if
> >> the hsd says fixed in E0, but the w/a db says UNTIL_D0, then one is
> >> left wondering about D1+ But perhaps such steppings didn't even exist.
> >>
> >> Well, in reality it's all over the place. Eg. looking at the BDW UNTIL_D0
> >> stuff, some are fixed in E0, some are fixed in D0, and at least one was
> >> fixed in B0 according to hsd. So I'm starting to think that the meaning
> >> of the tag depends entirely on the person who pushed the change.
> >
> > With that, I stand by the patches I submitted as they are.
> 
> Ville, opinions, r-b, nak, ack, crap, what? ;)

Yeah, I guess it's all good.

Acked-by: Ville Syrjälä 

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

[Intel-gfx] [PATCH] drm/i915: track relative-constants-mode per-context not per-device

[Dave Gordon]

'relative_constants_mode' has always been tracked per-device, but this
is wrong in execlists (or GuC) mode, as INSTPM is saved and restored
with the logical context, and the per-context value could therefore get
out of sync with the tracked value. This patch moves the tracking
element from the dev_priv structure into the intel_context structure,
with corresponding adjustments to the code that initialises and uses it.

Test case (if anyone wants to write it) would be to create two contexts,
submit a batch with a non-default mode in the first context, submit a
batch with the default mode in the other context, submit another batch
in the first context, but this time in default mode. The driver will
fail to insert the instructions to reset INSTPM into the first context's
ringbuffer.

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

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_drv.h| 4 ++--
 drivers/gpu/drm/i915/i915_gem.c| 2 --
 drivers/gpu/drm/i915/i915_gem_context.c| 3 +++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +++---
 drivers/gpu/drm/i915/intel_lrc.c   | 6 +++---
 5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 51eea29..2917370 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -872,6 +872,8 @@ struct intel_context {
struct i915_ctx_hang_stats hang_stats;
struct i915_hw_ppgtt *ppgtt;
 
+   int relative_constants_mode;
+
/* Legacy ring buffer submission */
struct {
struct drm_i915_gem_object *rcs_state;
@@ -1707,8 +1709,6 @@ struct drm_i915_private {
 
const struct intel_device_info info;
 
-   int relative_constants_mode;
-
void __iomem *regs;
 
struct intel_uncore uncore;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f0cfbb9..374af2d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4894,8 +4894,6 @@ i915_gem_load(struct drm_device *dev)
  i915_gem_idle_work_handler);
init_waitqueue_head(_priv->gpu_error.reset_queue);
 
-   dev_priv->relative_constants_mode = I915_EXEC_CONSTANTS_REL_GENERAL;
-
if (INTEL_INFO(dev)->gen >= 7 && !IS_VALLEYVIEW(dev))
dev_priv->num_fence_regs = 32;
else if (INTEL_INFO(dev)->gen >= 4 || IS_I945G(dev) || IS_I945GM(dev) 
|| IS_G33(dev))
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 74aa0c9..465e3e0 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -222,6 +222,9 @@ __create_hw_context(struct drm_device *dev,
 * is no remap info, it will be a NOP. */
ctx->remap_slice = (1 << NUM_L3_SLICES(dev)) - 1;
 
+   /* First execbuffer will override this */
+   ctx->relative_constants_mode = -1;
+
ctx->hang_stats.ban_period_seconds = DRM_I915_CTX_BAN_PERIOD;
 
return ctx;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index edc17be..9833c8a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1283,7 +1283,7 @@ i915_gem_ringbuffer_submission(struct 
i915_execbuffer_params *params,
goto error;
}
 
-   if (instp_mode != dev_priv->relative_constants_mode) {
+   if (instp_mode != params->ctx->relative_constants_mode) {
if (INTEL_INFO(dev)->gen < 4) {
DRM_DEBUG("no rel constants on pre-gen4\n");
ret = -EINVAL;
@@ -1309,7 +1309,7 @@ i915_gem_ringbuffer_submission(struct 
i915_execbuffer_params *params,
}
 
if (ring == _priv->ring[RCS] &&
-   instp_mode != dev_priv->relative_constants_mode) {
+   instp_mode != params->ctx->relative_constants_mode) {
ret = intel_ring_begin(params->request, 4);
if (ret)
goto error;
@@ -1320,7 +1320,7 @@ i915_gem_ringbuffer_submission(struct 
i915_execbuffer_params *params,
intel_ring_emit(ring, instp_mask << 16 | instp_mode);
intel_ring_advance(ring);
 
-   dev_priv->relative_constants_mode = instp_mode;
+   params->ctx->relative_constants_mode = instp_mode;
}
 
if (args->flags & I915_EXEC_GEN7_SOL_RESET) {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 825fa7a..9ff409d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -889,7 +889,7 @@ int intel_execlists_submission(struct 
i915_execbuffer_params *params,
return -EINVAL;
}
 
-   

Re: [Intel-gfx] [PATCH 19/22] drm/i915: BDW: Pipe level Gamma correction

[Emil Velikov]

On 10 October 2015 at 06:21, Sharma, Shashank  wrote:
> On 10/10/2015 5:09 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma 
[snip]
>>> +   switch (num_samples) {
>>> +   case GAMMA_DISABLE_VALS:
>>> +
>>> +   /* Disable Gamma functionality on Pipe */
>>
>> Drop the extra newline between the case and the comment ? Here and below.
>>
> I was trying to make it look good :(
Beauty is in the eye of the beholder. The most important part here is
consistency.
Afaict there isn't (m)any i915 code the uses this approach, is there ?
Some of your other patches use this approach while others don't.

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

Re: [Intel-gfx] [PATCH 15/22] drm/i915: CHV: Pipe level CSC correction

[Emil Velikov]

On 10 October 2015 at 06:26, Sharma, Shashank  wrote:
> On 10/10/2015 5:13 AM, Emil Velikov wrote:
>>
>> On 9 October 2015 at 20:29, Shashank Sharma 
>> wrote:
>>>
>>> CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
>>> that needs to be programmed into CGM (Color Gamut Mapping) registers.
>>>
>>> This patch does the following:
>>> 1. Attaches CSC property to CRTC
>>> 2. Adds the core function to program CSC correction values
>>> 3. Adds CSC correction macros
>>>
>>> Signed-off-by: Shashank Sharma 
>>> Signed-off-by: Kausal Malladi 
>>> Signed-off-by: Kumar, Kiran S 
>>> ---
>>>   drivers/gpu/drm/i915/i915_reg.h|  8 +++
>>>   drivers/gpu/drm/i915/intel_color_manager.c | 94
>>> ++
>>>   drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
>>>   3 files changed, 121 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h
>>> index c32e35d..5825ab2 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -8056,4 +8056,12 @@ enum skl_disp_power_wells {
>>>   #define _PIPE_DEGAMMA_BASE(pipe) \
>>>  (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA,
>>> PIPEC_CGM_DEGAMMA))
>>>
>>> +#define PIPEA_CGM_CSC  (VLV_DISPLAY_BASE +
>>> 0x67900)
>>> +#define PIPEB_CGM_CSC  (VLV_DISPLAY_BASE +
>>> 0x69900)
>>> +#define PIPEC_CGM_CSC  (VLV_DISPLAY_BASE +
>>> 0x6B900)
>>> +#define _PIPE_CSC_BASE(pipe) \
>>> +   (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
>>> +
>>> +
>>> +
>>>   #endif /* _I915_REG_H_ */
>>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>>> b/drivers/gpu/drm/i915/intel_color_manager.c
>>> index bbfe185..433e50a 100644
>>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>>> @@ -27,6 +27,93 @@
>>>
>>>   #include "intel_color_manager.h"
>>>
>>> +static s16 chv_prepare_csc_coeff(s64 csc_value)
>>> +{
>>> +   s32 csc_int_value;
>>> +   u32 csc_fract_value;
>>> +   s16 csc_s3_12_format;
>>
>> The type of csc_s3_12_format and chv_prepare_csc_coeff() does not see
>> correct. Seem like the fix got merged into another patch :\
>>
> Can you please elaborate this comment, I dont get it.
>
You have two typos above s16 > s32 which you've fixed in the next
patch. That fix should belong here imho.

[snip]
>>> +   while (count < CSC_MAX_VALS) {
>>> +   temp = chv_prepare_csc_coeff(
>>> +   csc_data->ctm_coeff[count]);
>>> +   SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
>>> +
>>> +   /*
>>> +* Last value to be written in 1 register.
>>> +* Otherwise, each pair of CSC values go
>>> +* into 1 register
>>> +*/
>>> +   if (count != (CSC_MAX_VALS - 1)) {
>>> +   count++;
>>> +   temp = chv_prepare_csc_coeff(
>>> +   csc_data->ctm_coeff[count]);
>>> +   SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
>>> +   }
>>
>> This looks a bit odd. Use the same approach as in
>> bdw_write_12bit_gamma_precision() ?
>
> Again, can you please give little more details here ?
Take a look at the loop construct in bdw_write_12bit_gamma_precision()
- both of them are essentially doing the same thing.

Here you have
while(i < odd_number) {
  foo()
  if (if != odd_number-1) {
I++
foo()
  }
}

while in the mentioned function

while (i < odd_number -1) {
  foo()
  foo()
  i++
}
foo()

Normally you'd use one or the other. Esp. since this is a single
patchset :-) I'm leaning towards the latter as it's more obvious but
others may prefer the former approach.

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

Re: [Intel-gfx] [PATCH 10/22] drm/i915: Register color correction capabilities

[Sharma, Shashank]

Regards
Shashank

On 10/13/2015 6:33 PM, Emil Velikov wrote:

On 10 October 2015 at 06:01, Sharma, Shashank  wrote:

On 10/10/2015 3:51 AM, Emil Velikov wrote:


Hi Shashank,

On 9 October 2015 at 20:29, Shashank Sharma 
wrote:


  From DRM color management:

DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
 color transformation matrix of 9 correction values gets
 applied as correction.
2. "palette_before_ctm": for corrections which get applied
 beore color transformation matrix correction.
3. "palette_after_ctm": for corrections which get applied
 after color transformation matrix correction.

These color correction capabilities may differ per platform, supporting
various different no. of correction coefficients. So DRM color manager
support few properties using which a user space can query the platform's
capability, and prepare color correction accordingly.
These query properties are:
1. cm_coeff_after_ctm_property
2. cm_coeff_before_ctm_property
(CTM is fix to 9 coefficients across industry)

Now, Intel color manager registers:
==
1. Gamma correction property as "palette_after_ctm" property
2. Degamma correction capability as "palette_bafore_ctm" property
 capability as "palette_after_ctm" DRM color property hook.
3. CSC as "ctm" property.

So finally, This patch does the following:
1. Add a function which loads the platform's color correction
 capabilities in the cm_crtc_palette_capabilities_property structure.
2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
 getting initiaized.
3. Adds two new parameters "num_samples_after_ctm" and
 "num_samples_before_ctm" in intel_device_info as gamma and
 degamma coefficients vary per platform basis.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
   drivers/gpu/drm/i915/i915_drv.h|  2 ++
   drivers/gpu/drm/i915/intel_color_manager.c | 33
+-
   2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index ad37b25..8bf1d6f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -798,6 +798,8 @@ struct intel_device_info {
  u8 num_sprites[I915_MAX_PIPES];
  u8 gen;
  u8 ring_mask; /* Rings supported by the HW */
+   u16 num_samples_after_ctm;
+   u16 num_samples_before_ctm;
  DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
  /* Register offsets for the various display pipes and
transcoders */
  int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index 7357d99..e466748 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -28,6 +28,37 @@
   #include "intel_color_manager.h"

   void intel_attach_color_properties_to_crtc(struct drm_device *dev,
-   struct drm_mode_object *mode_obj)
+   struct drm_crtc *crtc)
   {
+   struct drm_mode_config *config = >mode_config;
+   struct drm_mode_object *mode_obj = >base;
+
+   /*
+* Register:
+* =
+* Gamma correction as palette_after_ctm property
+* Degamma correction as palette_before_ctm property
+*
+* Load:
+* =
+* no. of coefficients supported on this platform for gamma
+* and degamma with the query properties. A user
+* space agent should read these query property, and prepare
+* the color correction values accordingly. Its expected from the
+* driver to load the right number of coefficients during the
init
+* phase.
+*/
+   if (config->cm_coeff_after_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_coeff_after_ctm_property,
+   INTEL_INFO(dev)->num_samples_after_ctm);
+   DRM_DEBUG_DRIVER("Gamma query property initialized\n");
+   }
+
+   if (config->cm_coeff_before_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_coeff_before_ctm_property,
+   INTEL_INFO(dev)->num_samples_before_ctm);
+   DRM_DEBUG_DRIVER("Degamma query property initialized\n");
+   }


Shouldn't this commit be squashed with the previous ? You're also
missing the function declaration.


Please see the history of the review comments, initially this patch was like
as you suggested. But one of the previous review comments, suggested to
split that into two, as it was 'overdoing' stuff. So I had split it into two
separate ones, so I think this is ok :)


Sorry did 

Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

[Daniel Vetter]

On Tue, Oct 13, 2015 at 02:09:48PM +0100, Chris Wilson wrote:
> On Tue, Oct 13, 2015 at 02:23:57PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 13, 2015 at 12:44:05PM +0100, Chris Wilson wrote:
> > > On Tue, Oct 13, 2015 at 01:26:36PM +0200, Daniel Vetter wrote:
> > > > On Mon, Oct 12, 2015 at 10:31:35AM +0100, Chris Wilson wrote:
> > > > > On Mon, Oct 12, 2015 at 10:06:23AM +0100, Tvrtko Ursulin wrote:
> > > > > > 
> > > > > > On 09/10/15 18:26, Chris Wilson wrote:
> > > > > > >On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote:
> > > > > > >>On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote:
> > > > > > >>>
> > > > > > >>>On 09/10/15 09:55, Daniel Vetter wrote:
> > > > > > On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote:
> > > > > > >On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote:
> > > > > > >>On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin 
> > > > > > >>wrote:
> > > > > > >>The concern is that this isn't how SIG_SEGV works, it's a 
> > > > > > >>signal the
> > > > > > >>thread who made the invalid access gets directly. You never 
> > > > > > >>get a SIG_SEGV
> > > > > > >>for bad access someone else has made. So essentially it's new 
> > > > > > >>ABI.
> > > > > > >
> > > > > > >SIGBUS. For which the answer is yes, you can and do get SIGBUS 
> > > > > > >for
> > > > > > >actions taken by other processes.
> > > > > > 
> > > > > > Oh right I always forget that SIGBUS aliases with SIGIO. Anyway 
> > > > > > if
> > > > > > userspace wants SIGIO we just need to provide it with a 
> > > > > > pollable fd and
> > > > > > then it can use fcntl to make that happen. That's imo a much 
> > > > > > better api
> > > > > > than unconditionally throwing around signals. Also we already 
> > > > > > have the
> > > > > > reset stats ioctl to tell userspace that its gpu context is 
> > > > > > toats. If
> > > > > > anyone wants that to be pollable (or even send SIGIO) I think 
> > > > > > we should
> > > > > > extend that, with all the usual "needs userspace" stuff on 
> > > > > > top.
> > > > > > >>>
> > > > > > >>>I don't see that this notification can be optional. Process is 
> > > > > > >>>confused
> > > > > > >>>about its memory map use so should die. :)
> > > > > > >>>
> > > > > > >>>This is not a GPU error/hang - this is the process doing stupid 
> > > > > > >>>things.
> > > > > > >>>
> > > > > > >>>MMU notifiers do not support decision making otherwise we could 
> > > > > > >>>say
> > > > > > >>>-ETXTBUSY or something on munmap, but we can't. Not even sure 
> > > > > > >>>that it would
> > > > > > >>>help in all cases, would have to fail clone as well and who 
> > > > > > >>>knows what.
> > > > > > >>
> > > > > > >>So what happens if the gpu just keeps using the memory? It'll all 
> > > > > > >>be
> > > > > > >>horribly undefined behaviour and eventually it'll die on an 
> > > > > > >>-EFAULT in
> > > > > > >>execbuf, but does anything else bad happen?
> > > > > > >
> > > > > > >We don't see an EFAULT unless a miracle occurs, and the stale pages
> > > > > > >continue to be read/written by other processes (as well as the 
> > > > > > >client).
> > > > > > >Horribly undefined behaviour with a misinformation leak.
> > > > > > 
> > > > > > What other processes? Pages will still be referenced so won't be
> > > > > > reused so there is not information leak across unrelated processes.
> > > > > > Unless you meant ones involved in object sharing?
> > > > > 
> > > > > This client is trying to replace the userptr with a fresh set of 
> > > > > pages.
> > > > > The GPU and other processes continue to see the old pages i.e. old
> > > > > information (misinformation :) leaks.
> > > > 
> > > > userptr explicitly doesn't support this. You need to tear down the
> > > > existing userptr object and then create a new one if you change the
> > > > mmap'ing. So that's really just a bug in userspace, and the question is
> > > > how do we tell userspace best that it's done something stupid.
> > > 
> > > Pardon? Note this also affects munmap if you don't accept mremap (which
> > > is not explicitly unsupported as it fits quite nicely within the
> > > existing rules).
> > > 
> > > > My stance that the best one is to either kill any ctx using that object 
> > > > or
> > > > at least indicate there's trouble using reset stats. But sending a
> > > > SIGBUS/SIG_SEGV (which can only happen to the thread that does a memory
> > > > access, not any other thread that's accidentally in the same process
> > > > group) is imo abuse.
> > > 
> > > The signal is sent to everything that inherited the mm, not bound to the
> > > single thread.
> > > 
> > > > Or we just need to make sure we do get the EFAULT on
> > > > the next execbuffer.
> > > > 
> > > > Or maybe it just doesn't matter, i.e. where is the userspace which a) 
> > > > does
> > > > silly stuff like this b) wants 

Re: [Intel-gfx] [PATCH 13/22] drm/i915: CHV: Pipe level Gamma correction

[Sharma, Shashank]

Regards
Shashank

On 10/13/2015 6:38 PM, Emil Velikov wrote:

On 10 October 2015 at 06:09, Sharma, Shashank  wrote:

On 10/10/2015 4:37 AM, Emil Velikov wrote:


Hi Shashank,

On 9 October 2015 at 20:29, Shashank Sharma 
wrote:


CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode

This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macros

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---

[snip]

+   length = num_samples * sizeof(struct drm_r32g32b32);


Calculation can overflow.


good catch, will take care of this.

Actually we do not at all here as the variable is unused. Same applies
for patch 21/22.

Yep, Rob mentioned that in his comment, I have removed this in the 
latest patch set I have sent.

[snip]

+   while (count < num_samples) {


Using for(i = 0;) loop seems the more common approach ?


Nah, we are good with while. The whole color management series prefers while
(and me too :))

Hmm... so you'd prefer your approach/coding style over the one already
in i915? Feels a bit strange but as long as others are happy fine go
with it.

I am not sure if I915 follows a general rule of using for(...) over 
while(), coz I see many instances of using a while in i915_gem, 
i915_drv, i915_irq etc, so it should be good. I would see if someone 
else can suggest another good reason.

Regards,
Emil


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

Re: [Intel-gfx] [PATCH] drm/i915: Reset dpll_hw_state when selecting a new pll on hsw

[Daniel Vetter]

On Tue, Oct 13, 2015 at 03:35:01PM +0200, Daniel Vetter wrote:
> On Tue, Oct 13, 2015 at 03:18:16PM +0200, Maarten Lankhorst wrote:
> > Op 23-09-15 om 17:34 schreef Gabriel Feceoru:
> > > Using 2 connectors (DVI and VGA) will cause wrpll to be set for
> > > INTEL_OUTPUT_HDMI but never reset if switching to INTEL_OUTPUT_VGA
> > >
> > > Supresses errors like these:
> > > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
> > > dpll_hw_state.wrpll
> > >
> > Looks like a good idea to always zero it.
> 
> Except that we still have a bunch of cases where we recompute clock state
> but only partially. Can we just move them all up into a common place
> please? That would also catch cases where we simply forget to fill this
> out at all.
> 
> One case I noticed is edp in skl_ddi_pll_select, but there's probably
> more.

Specifically I think we should move the memset into
intel_modeset_pipe_config and remove it from all the clock compute/pll
select functions. Last time we wanted to do that it wasn't yet possible
because the atomice modeset conversion and shared dpll tracking needed the
old values, but that should be fixed now with crtc_state structures being
completely free-standing.
-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 09/22] drm/i915: Create color management files

[Sharma, Shashank]

Thanks for the review Emil.
Please find my comments inline

Regards
Shashank
On 10/13/2015 6:29 PM, Emil Velikov wrote:

On 10 October 2015 at 05:55, Sharma, Shashank  wrote:

On 10/10/2015 4:17 AM, Emil Velikov wrote:


Hi Shashank,

On 9 October 2015 at 20:28, Shashank Sharma 
wrote:
[snip]


+
+/* Color management bit utilities */
+#define GET_BIT_MASK(n) ((1 << n) - 1)
+
+/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
+#define GET_BITS(x, start, nbits) ((x >> start) & GET_BIT_MASK(nbits))
+
+/* Round off by adding 1 to the immediate lower bit */
+#define GET_BITS_ROUNDOFF(x, start, nbits) \
+   ((GET_BITS(x, start, (nbits + 1)) + 1) >> 1)
+
+/* Clear bits of a word from bit no. 'start' till nbits */
+#define CLEAR_BITS(x, start, nbits) ( \
+   x &= ~((GET_BIT_MASK(nbits) << start)))
+
+/* Write bit_pattern of no_bits bits in a target word */
+#define SET_BITS(target, bit_pattern, start_bit, no_bits) \
+   do { \
+   CLEAR_BITS(target, start_bit, no_bits); \
+   target |= (bit_pattern << start_bit);  \
+   } while (0)


It feels suspicious that the kernel does not have macros for either
one of these.

I would invite you to take a look at include/linux/bitops.h and other
kernel headers.


Thanks for pointing this out, but if you closely observe, these macros are
well tested, and created for color management operations, which have
specific requirements, like:
- pick 8 bits from 16th bit onwards, make them LSB, and give result:
GET_BITS
- take these 8 bits and move to bit 17th of the word, clearing the existing
ones: SET_BITS
For core register programming, this was required, so we created it. I would
still have a look
at the existing ones which you pointed out to avoid any duplication, if they
fall directly in the implementation, else I would like to continue with
these.

Unless I'm missing something, these are generic bit manipulation
macros, are they not ? As such I'd imagine we have some of these
already available, but I cannot say which ones off-hand.

If you closely observe, what set_bit does is picks up the bit pattern 
from nth to n+reqd bit, moves it to LSB and returns it. similarly set 
bits clears the bits, then copy the bit pattern in the respective bits 
and manipulates the shifts. I could not find any such examples which I 
can directly use from suggested macros.



Regards,
Emil


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

Re: [Intel-gfx] [PATCH] drm/i915: Flush pipecontrol post-sync writes

[Daniel Vetter]

On Tue, Oct 13, 2015 at 03:45:58PM +0300, Jani Nikula wrote:
> On Wed, 26 Aug 2015, Chris Wilson  wrote:
> > On Wed, Aug 26, 2015 at 11:16:34AM +0200, Daniel Vetter wrote:
> >> On Fri, Aug 21, 2015 at 04:08:41PM +0100, Chris Wilson wrote:
> >> > In order to flush the results from in-batch pipecontrol writes (used for
> >> > example in glQuery) before declaring the batch complete (and so declaring
> >> > the query results coherent), we need to set the FlushEnable bit in our
> >> > flushing pipecontrol. The FlushEnable bit "waits until all previous
> >> > writes of immediate data from post-sync circles are complete before
> >> > executing the next command".
> >> > 
> >> > Signed-off-by: Chris Wilson 
> >> > Cc: sta...@vger.kernel.org
> >> 
> >> Do we have an igt/piglit failing somewhere (igt kinda preferred) or a
> >> bugzilla or why is this cc: stable?
> >
> > I get GPU hangs on byt without flushing these writes (running ue4).
> > piglit has examples where the flush is required for correct rendering.
> 
> Daniel, does this satisfy your question? We've had an r-b from Ville for
> a long time.

Yeah, just add that bit to the commit message to justify cc: stable.
-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 19/22] drm/i915: BDW: Pipe level Gamma correction

[Sharma, Shashank]

Regards
Shashank

On 10/13/2015 6:53 PM, Emil Velikov wrote:

On 10 October 2015 at 06:21, Sharma, Shashank  wrote:

On 10/10/2015 5:09 AM, Emil Velikov wrote:


Hi Shashank,

On 9 October 2015 at 20:29, Shashank Sharma 

[snip]

+   switch (num_samples) {
+   case GAMMA_DISABLE_VALS:
+
+   /* Disable Gamma functionality on Pipe */


Drop the extra newline between the case and the comment ? Here and below.


I was trying to make it look good :(

Beauty is in the eye of the beholder. The most important part here is
consistency.
Afaict there isn't (m)any i915 code the uses this approach, is there ?
Some of your other patches use this approach while others don't.

I prefer to leave one extra line when I have a comment, so that comment 
is more visible, instead of being sandwiched between lines of C code. 
May be I missed some places, so I can make it consistent.

Regards,
Emil


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

Re: [Intel-gfx] [PATCH] drm/i915: Flush pipecontrol post-sync writes

[Jani Nikula]

On Tue, 13 Oct 2015, Daniel Vetter  wrote:
> On Tue, Oct 13, 2015 at 03:45:58PM +0300, Jani Nikula wrote:
>> On Wed, 26 Aug 2015, Chris Wilson  wrote:
>> > On Wed, Aug 26, 2015 at 11:16:34AM +0200, Daniel Vetter wrote:
>> >> On Fri, Aug 21, 2015 at 04:08:41PM +0100, Chris Wilson wrote:
>> >> > In order to flush the results from in-batch pipecontrol writes (used for
>> >> > example in glQuery) before declaring the batch complete (and so 
>> >> > declaring
>> >> > the query results coherent), we need to set the FlushEnable bit in our
>> >> > flushing pipecontrol. The FlushEnable bit "waits until all previous
>> >> > writes of immediate data from post-sync circles are complete before
>> >> > executing the next command".
>> >> > 
>> >> > Signed-off-by: Chris Wilson 
>> >> > Cc: sta...@vger.kernel.org
>> >> 
>> >> Do we have an igt/piglit failing somewhere (igt kinda preferred) or a
>> >> bugzilla or why is this cc: stable?
>> >
>> > I get GPU hangs on byt without flushing these writes (running ue4).
>> > piglit has examples where the flush is required for correct rendering.
>> 
>> Daniel, does this satisfy your question? We've had an r-b from Ville for
>> a long time.
>
> Yeah, just add that bit to the commit message to justify cc: stable.

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

BR,
Jani.

> -Daniel
> -- 
> 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 1/2] drm/i915: Restore lost DPLL register write on gen2-4

[Daniel Vetter]

On Tue, Oct 13, 2015 at 04:10:19PM +0300, Jani Nikula wrote:
> On Thu, 08 Oct 2015, Ville Syrjälä  wrote:
> > On Thu, Oct 08, 2015 at 10:17:30AM +0200, Daniel Vetter wrote:
> >> On Wed, Oct 07, 2015 at 10:08:24PM +0300, ville.syrj...@linux.intel.com 
> >> wrote:
> >> > From: Ville Syrjälä 
> >> > 
> >> > We accidentally lost the initial DPLL register write in
> >> > 1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M
> >> > 
> >> > The "three times for luck" hack probably saved us from a total
> >> > disaster. But anyway, bring the initial write back so that the
> >> > code actually makes some sense.
> >> > 
> >> > Cc: sta...@vger.kernel.org
> >> > Cc: Nick Bowler 
> >> Reported-and-tested-by: Nick Bowler 
> >> References: 
> >> http://lists.freedesktop.org/archives/intel-gfx/2015-October/077463.html
> >> 
> >> > Signed-off-by: Ville Syrjälä 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_display.c | 2 ++
> >> >  1 file changed, 2 insertions(+)
> >> > 
> >> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> > b/drivers/gpu/drm/i915/intel_display.c
> >> > index 147e700..f4fdff9 100644
> >> > --- a/drivers/gpu/drm/i915/intel_display.c
> >> > +++ b/drivers/gpu/drm/i915/intel_display.c
> >> > @@ -1743,6 +1743,8 @@ static void i9xx_enable_pll(struct intel_crtc 
> >> > *crtc)
> >> > I915_READ(DPLL(!crtc->pipe)) | 
> >> > DPLL_DVO_2X_MODE);
> >> 
> >> Don't we also need a POSTING_READ here to make sure the two-step 2x mode
> >> sequence is still followed?
> >
> > We don't do write combining on registers, and there are no shadow
> > register type of things to consider in this case either.
> >
> >> 
> >> With that addressed Reviewed-by: Daniel Vetter 
> 
> 
> Daniel, are you happy with the responses about posting reads, for both
> patches?

Yeah, acked on irc but forgot to follow up.
-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 22/22] drm/i915: BDW: Pipe level CSC correction

[Sharma, Shashank]

Regards
Shashank

On 10/13/2015 7:15 PM, Emil Velikov wrote:

On 10 October 2015 at 06:34, Sharma, Shashank  wrote:

On 10/10/2015 5:24 AM, Emil Velikov wrote:


Hi Shashank,

On 9 October 2015 at 20:29, Shashank Sharma 
wrote:


BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.

This patch does the following:
1. Adds the core function to program CSC correction values for
 BDW/SKL/BXT platform
2. Adds CSC correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
Signed-off-by: Kumar, Kiran S 
---
   drivers/gpu/drm/i915/i915_reg.h|   7 ++
   drivers/gpu/drm/i915/intel_color_manager.c | 114
-
   drivers/gpu/drm/i915/intel_color_manager.h |  12 ++-
   3 files changed, 129 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index ed50f75..0e9d252 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8085,4 +8085,11 @@ enum skl_disp_power_wells {
  (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B,
PAL_PREC_GCMAX_C))


+/* BDW CSC correction */
+#define CSC_COEFF_A0x49010
+#define CSC_COEFF_B0x49110
+#define CSC_COEFF_C0x49210
+#define _PIPE_CSC_COEFF(pipe) \
+   (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
+
   #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index e659382..0a6c00c 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -330,11 +330,119 @@ static int bdw_set_degamma(struct drm_device *dev,
  return 0;
   }

-static s16 chv_prepare_csc_coeff(s64 csc_value)


As mentioned previously, this should be part of the respective patch.


Agree. Looks like diff is messing up a bit. Will take care of this.


+static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
+{
+   uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
+   int32_t mantissa;
+   uint64_t abs_coeff;
+
+   coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
+   coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
+
+   abs_coeff = abs(coeff);
+   if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
+   /* abs_coeff < 0.125 */
+   exponent_bits = 3;
+   ls_bit_pos = 19;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
+   abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
+   /* abs_coeff >= 0.125 && val < 0.25 */
+   exponent_bits = 2;
+   ls_bit_pos = 20;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
+   && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
+   /* abs_coeff >= 0.25 && val < 0.5 */
+   exponent_bits = 1;
+   ls_bit_pos = 21;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
+   && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
+   /* abs_coeff >= 0.5 && val < 1.0 */
+   exponent_bits = 0;
+   ls_bit_pos = 22;
+   } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
+   abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
+   /* abs_coeff >= 1.0 && val < 2.0 */
+   exponent_bits = 7;
+   ls_bit_pos = 23;
+   } else {
+   /* abs_coeff >= 2.0 && val < 4.0 */
+   exponent_bits = 6;
+   ls_bit_pos = 24;
+   }
+
+   mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos,
CSC_MAX_VALS);
+   if (coeff < 0) {
+   sign_bit = 1;
+   mantissa = -mantissa;
+   mantissa &= ((1 << CSC_MAX_VALS) - 1);


I think there is a macro for this already ?


Thats for GAMMA_MAX, not for CSC_MAX. Or you mean the whole (1 <<
CSC_MAX_VALS -1) to be replaced with GET/SET bits ?

What I mean is - the above looks exactly like the GET_BIT_MASK (which
you introduced). Perhaps you can use it ?

Yes, Agree. but in later code review phase we realized that we dont even 
need this masking for mantissa. New patch set doesnt have this , so 
we dont need this.

Regards,
Emil


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

[Intel-gfx] Video freezing after activating XScreensaver

[Chris]

This is an issue that has been ongoing for over 1 1/2 years now. I have
tried kernel after kernel and whether it's a Ubuntu kernel such as the
one in my sig or a kernel from here -
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/ the video
will intermittently freeze. Running XScreensaver causes it to freeze
when switching between the different screen savers showing a black
screen and the mouse cursor. The cursor can be moved and will switch
between the arrow and the hand tool if hovering over a clickable area on
the desktop even though it can't be seen. Giving an error output in my
syslog of 

kernel: [578631.820045] [drm:i915_hangcheck_elapsed [i915]] *ERROR*
Hangcheck timer elapsed... render ring idle

I was able to reproduce this yesterday by starting XScreensaver at
9:43am and at 13:44pm the video froze giving the above error. At other
times when XScreensaver is not running the video will still randomly
freeze however there is no specific time frame for this to happen. I've
seen it go 2 days then freeze and have also seen it go 16 days then
freeze. As I've said previously all background operations continue to
run as just the video is frozen.

I have had the random freeze happen when running this kernelkernel
4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015 which Chris Wilson from this list had me run kernel
kernel 4.0.0-997-generic #201503310205 SMP Tue Mar
31 02:07:04 UTC 2015 however when I attempted to file a bug report at
Ubuntu Launchpad it was not accepted so the Ubuntu kernel folks had me
switch to kernel 4.2.3-040203-generic #201510030832 SMP Sat Oct 3
12:34:31 UTC 2015 which although is an upstream kernel is what they
wanted me to run. The bug report that I've filed on Launchpad is
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1497627 

I've attempted to boot into the following Ubuntu upstream kernels:

v4.3-rc5-unstable - Boot process would begin but would not complete
v4.3-rc4-unstable - same as above
v4.3-rc3-unstable - same as above
v4.3-rc2-unstable - Same as above
v4.3-rc1-unstable - Same as above

I also attempted last night to boot into

v4.3-rc5-unstable from
http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D which gave the
same results. The boot process would begin but then go to just a black
screen without completing. 

I have either filed or commented on the following bugs also:

https://bugs.freedesktop.org/show_bug.cgi?id=75394
https://bugs.freedesktop.org/show_bug.cgi?id=89290
https://bugs.freedesktop.org/show_bug.cgi?id=91495

System info is:

Dell Optiplex 780
Bios A15
Ubuntu 14.04.3 LTS
Gnome 3.12.2

Am I still the only one who is experiencing this issue? 
-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11°N 97.89°W (Elev. 1092 ft)
07:57:25 up 11:34, 1 user, load average: 0.37, 0.41, 0.33
Ubuntu 14.04.3 LTS, kernel 4.2.3-040203-generic #201510030832 SMP Sat
Oct 3 12:34:31 UTC 2015

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/bxt: add revision id for A1 stepping and use it

[Jani Nikula]

On Wed, 07 Oct 2015, Jani Nikula  wrote:
> On Tue, 06 Oct 2015, Ville Syrjälä  wrote:
>> On Tue, Oct 06, 2015 at 04:43:11PM +0300, Jani Nikula wrote:
>>> On Tue, 06 Oct 2015, Ville Syrjälä  wrote:
>>> > On Tue, Oct 06, 2015 at 02:41:15PM +0300, Jani Nikula wrote:
>>> >> Prefer inclusive ranges for revision checks rather than "below B0". Per
>>> >> specs A2 is not used, so revid <= A1 matches revid < B0.
>>> >
>>> > The w/a db would say UNTIL_B0 etc., so might be easier to check against
>>> > it if we keep to the same convention.
>>> 
>>> So I wanted to double check what the convention is. I picked
>>> WaRsDisableCoarsePowerGating.
>>> 
>>> KBL - SIWA_FOREVER
>>> BXT - SI_WA_BEFORE(BXT_REV_ID_B0)
>>> SKL - SIWA_UNTIL_SKL_E0
>>> 
>>> Description "Disable coarse power gating for GT4 until GT F0 stepping."
>>> 
>>> *rolls eyes*
>>> 
>>> So is that "until" there inclusive or non-inclusive? The db is
>>> contradicting itself...
>>
>> Hmm. My recollection was that it's exclusive, but now that I look at
>> your findings and some other workarounds, it does look a bit more like
>> inclusive.
>>
>> I would think the exclusive thing would be easier to maintain since
>> the hsd specifies the stepping in which stuff got fixed, and the
>> exclusive convention would then have the same stepping listed. Eg. if
>> the hsd says fixed in E0, but the w/a db says UNTIL_D0, then one is
>> left wondering about D1+ But perhaps such steppings didn't even exist.
>>
>> Well, in reality it's all over the place. Eg. looking at the BDW UNTIL_D0
>> stuff, some are fixed in E0, some are fixed in D0, and at least one was
>> fixed in B0 according to hsd. So I'm starting to think that the meaning
>> of the tag depends entirely on the person who pushed the change.
>
> With that, I stand by the patches I submitted as they are.

Ville, opinions, r-b, nak, ack, crap, what? ;)

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 16/22] drm/i915: Commit color correction to CRTC

[Emil Velikov]

On 10 October 2015 at 06:20, Sharma, Shashank  wrote:
> On 10/10/2015 4:54 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma 
>> wrote:
>>>
>>> The color correction blob values are loaded during set_property
>>> calls. This patch adds a function to find the blob and apply the
>>> correction values to the display registers, during the atomic
>>> commit call.
>>>
>>> Signed-off-by: Shashank Sharma 
>>> Signed-off-by: Kausal Malladi 
>>> ---
>>>   drivers/gpu/drm/i915/intel_color_manager.c | 44
>>> ++
>>>   drivers/gpu/drm/i915/intel_display.c   |  2 ++
>>>   drivers/gpu/drm/i915/intel_drv.h   |  3 ++
>>>   3 files changed, 49 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>>> b/drivers/gpu/drm/i915/intel_color_manager.c
>>> index 433e50a..d5315b2 100644
>>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>>> @@ -307,6 +307,50 @@ static int chv_set_gamma(struct drm_device *dev,
>>> struct drm_property_blob *blob,
>>>  return ret;
>>>   }
>>>
>>> +void intel_color_manager_crtc_commit(struct drm_device *dev,
>>> +   struct drm_crtc_state *crtc_state)
>>> +{
>>> +   struct drm_property_blob *blob;
>>> +   struct drm_crtc *crtc = crtc_state->crtc;
>>> +   int ret = -EINVAL;
>>
>> Most places/people advise against pre-emptively initializing ret.
>>
> Just in this case, if makes sense to keep one, coz there might be multiple
> blobs which we are applying in the commit action, and every blob can return
> error, from the core function.
> Assume that there is a situation where both palette_after_ctm(gamma) and CTM
> is in place, then we will be going through multiple if() cases and have to
> check the return values.
When you have an exception of any rule, this implies that you are
using a suboptimal way of doing things.

>>>
>>> +
>>> +   blob = crtc_state->palette_after_ctm_blob;
>>> +   if (blob) {
>>> +   /* Gamma correction is platform specific */
>>> +   if (IS_CHERRYVIEW(dev))
>>> +   ret = chv_set_gamma(dev, blob, crtc);
>>> +
>>> +   if (ret)
>>> +   DRM_ERROR("set Gamma correction failed\n");
>>
>> Do we really want to spam dmesg on for each non Cherryview device ?
>
> If you see the complete implementation, as IS_GEN8()/IS_SKL is coming up
> here after IS_CHV(patch 19,20,21) which will cover BDW/SKL/BXT. Anything
> else which comes here, deserves a DRM_ERROR() as this platform will not be
> supported.
>
Your patches should be independent changes. You cannot say "I'm adding
something iffy here, but it will be fixed with another patch".
Otherwise you'll get developer/user X bisecting the kernel, which will
end up with broken system (flooded dmesg in this case) half way
through the bisect.

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

Re: [Intel-gfx] [PATCH] drm/i915: Reset dpll_hw_state when selecting a new pll on hsw

[Maarten Lankhorst]

Op 23-09-15 om 17:34 schreef Gabriel Feceoru:
> Using 2 connectors (DVI and VGA) will cause wrpll to be set for
> INTEL_OUTPUT_HDMI but never reset if switching to INTEL_OUTPUT_VGA
>
> Supresses errors like these:
> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.wrpll
>
Looks like a good idea to always zero it.

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

[Intel-gfx] [PATCH] drm/i915: Deny wrapping an userptr into a framebuffer

[Chris Wilson]

Pinning a userptr onto the hardware raises interesting questions about
the lifetime of such a surface as the framebuffer extends that life
beyond the client's address space. That is the hardware will need to
keep scanning out from the backing storage even after the client wants
to remap its address space. As the hardware pins the backing storage,
the userptr becomes invalid and this raises a WARN when the clients
tries to unmap its address space. The situation can be even more
complicated when the buffer is passed between processes, between a
client and display server, where the lifetime and hardware access is
even more confusing. Deny it.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: Michał Winiarski 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 5 -
 drivers/gpu/drm/i915/intel_display.c| 5 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 2dd911ab3019..3ce1b557f7c4 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -974,7 +974,10 @@ out:
  * Also note, that the object created here is not currently a "first class"
  * object, in that several ioctls are banned. These are the CPU access
  * ioctls: mmap(), pwrite and pread. In practice, you are expected to use
- * direct access via your pointer rather than use those ioctls.
+ * direct access via your pointer rather than use those ioctls. Another
+ * restriction is that we do not allow userptr surfaces to be pinned to the
+ * hardware and so we reject any attempt to create a framebuffer out of a
+ * userptr.
  *
  * If you think this is a good interface to use to pass GPU memory between
  * drivers, please use dma-buf instead. In fact, wherever possible use
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b89131654a0e..d1deaedcc4ce 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14116,6 +14116,11 @@ static int intel_user_framebuffer_create_handle(struct 
drm_framebuffer *fb,
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb->obj;
 
+   if (obj->userptr.mm) {
+   DRM_DEBUG("attempting to use a userptr for a framebuffer, 
denied\n");
+   return -EINVAL;
+   }
+
return drm_gem_handle_create(file, >base, handle);
 }
 
-- 
2.6.1

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

Re: [Intel-gfx] [BXT DSI timing fixes v1 2/3] drm/i915/bxt: Get pipe timing for BXT DSI

[Shankar, Uma]

>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, October 13, 2015 4:54 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; Kumar, Shobhit
>Subject: Re: [Intel-gfx] [BXT DSI timing fixes v1 2/3] drm/i915/bxt: Get pipe
>timing for BXT DSI
>
>On Tue, Oct 13, 2015 at 11:03:27AM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >Sent: Monday, October 12, 2015 10:54 PM
>> >To: Shankar, Uma
>> >Cc: intel-gfx@lists.freedesktop.org; Kumar, Shobhit
>> >Subject: Re: [Intel-gfx] [BXT DSI timing fixes v1 2/3] drm/i915/bxt:
>> >Get pipe timing for BXT DSI
>> >
>> >On Mon, Oct 12, 2015 at 10:55:02PM +0530, Uma Shankar wrote:
>> >> For BXT DSI, vtotal, vactive, hactive registers are different.
>> >> Making changes to intel_crtc_mode_get() and get_pipe_timings(), to
>> >> read the correct registers for BXT DSI.
>> >>
>> >> Signed-off-by: Uma Shankar 
>> >> Signed-off-by: Vandana Kannan 
>> >> ---
>> >>  drivers/gpu/drm/i915/intel_display.c |   48
>> >+++---
>> >>  1 file changed, 45 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> >> b/drivers/gpu/drm/i915/intel_display.c
>> >> index 75c60b8..2717823 100644
>> >> --- a/drivers/gpu/drm/i915/intel_display.c
>> >> +++ b/drivers/gpu/drm/i915/intel_display.c
>> >> @@ -7708,6 +7708,7 @@ static void intel_get_pipe_timings(struct
>> >> intel_crtc
>> >*crtc,
>> >>   struct drm_device *dev = crtc->base.dev;
>> >>   struct drm_i915_private *dev_priv = dev->dev_private;
>> >>   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
>> >> + bool is_dsi = intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI);
>> >>   uint32_t tmp;
>> >>
>> >>   tmp = I915_READ(HTOTAL(cpu_transcoder));
>> >> @@ -7736,6 +7737,26 @@ static void intel_get_pipe_timings(struct
>> >> intel_crtc
>> >*crtc,
>> >>   pipe_config->base.adjusted_mode.crtc_vblank_end += 1;
>> >>   }
>> >>
>> >> + if (IS_BROXTON(dev) && is_dsi) {
>> >> + struct intel_encoder *encoder;
>> >> +
>> >> + for_each_encoder_on_crtc(dev, >base, encoder) {
>> >> + struct intel_dsi *intel_dsi =
>> >> + enc_to_intel_dsi(>base);
>> >> + enum port port;
>> >> +
>> >> + for_each_dsi_port(port, intel_dsi->ports) {
>> >> + pipe_config->base.adjusted_mode.crtc_hdisplay
>> >=
>> >> +
>> >I915_READ(BXT_MIPI_TRANS_HACTIVE(port));
>> >> + pipe_config->base.adjusted_mode.crtc_vdisplay
>> >=
>> >> +
>> >I915_READ(BXT_MIPI_TRANS_VACTIVE(port));
>> >> + pipe_config->base.adjusted_mode.crtc_vtotal =
>> >> +
>> >I915_READ(BXT_MIPI_TRANS_VTOTAL(port));
>> >> + }
>> >> + }
>> >> +
>> >> + }
>> >
>> >I think I already asked this earlier when this patch was posted;
>> >Don't the normal pipe timing registers contain the same values? And
>> >if so, why would you need to read them out from the DSI speciific registers?
>> >
>>
>> Normal pipe timing registers like HTOTAL etc. is not used by MIPI DSI
>> for BXT. Hence getting the data from DSI specific registers for BXT. Separate
>MIPI transcoder is used for BXT.
>
>So calling intel_set_pipe_timings() is pointless (apart from PIPESRC)?
>
>If that's the case then it seems the readback should also read all of it from 
>the
>DSI registers instead of reading some from the pipe timings and some from DSI
>registers.
>

Yes set_pipe_timings is doing only the pipesrc programming which is useful for 
DSI, rest is not needed.

Readback can be rectified to read all other details as well from DSI specific 
registers apart from the ones
currently being used.

>>
>> Regards,
>> Uma Shankar
>>
>> >> +
>> >>   tmp = I915_READ(PIPESRC(crtc->pipe));
>> >>   pipe_config->pipe_src_h = (tmp & 0x) + 1;
>> >>   pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1; @@ -10664,6
>> >> +10685,7 @@ struct drm_display_mode *intel_crtc_mode_get(struct
>> >drm_device *dev,
>> >>   int vtot = I915_READ(VTOTAL(cpu_transcoder));
>> >>   int vsync = I915_READ(VSYNC(cpu_transcoder));
>> >>   enum pipe pipe = intel_crtc->pipe;
>> >> + bool is_dsi = intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DSI);
>> >>
>> >>   mode = kzalloc(sizeof(*mode), GFP_KERNEL);
>> >>   if (!mode)
>> >> @@ -10684,15 +10706,35 @@ struct drm_display_mode
>> >*intel_crtc_mode_get(struct drm_device *dev,
>> >>   i9xx_crtc_clock_get(intel_crtc, _config);
>> >>
>> >>   mode->clock = pipe_config.port_clock / pipe_config.pixel_multiplier;
>> >> - mode->hdisplay = (htot & 0x) + 1;
>> >>   mode->htotal = ((htot & 0x) >> 16) + 1;
>> >>   mode->hsync_start = (hsync & 0x) + 1;
>> >>   mode->hsync_end = ((hsync & 0x) >> 16) + 1;
>> >> - mode->vdisplay = (vtot & 0x) + 1;
>> >> - mode->vtotal = ((vtot & 

Re: [Intel-gfx] [PATCH] drm/i915: Reset dpll_hw_state when selecting a new pll on hsw

[Maarten Lankhorst]

Op 13-10-15 om 15:35 schreef Daniel Vetter:
> On Tue, Oct 13, 2015 at 03:18:16PM +0200, Maarten Lankhorst wrote:
>> Op 23-09-15 om 17:34 schreef Gabriel Feceoru:
>>> Using 2 connectors (DVI and VGA) will cause wrpll to be set for
>>> INTEL_OUTPUT_HDMI but never reset if switching to INTEL_OUTPUT_VGA
>>>
>>> Supresses errors like these:
>>> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
>>> dpll_hw_state.wrpll
>>>
>> Looks like a good idea to always zero it.
> Except that we still have a bunch of cases where we recompute clock state
> but only partially. Can we just move them all up into a common place
> please? That would also catch cases where we simply forget to fill this
> out at all.
>
> One case I noticed is edp in skl_ddi_pll_select, but there's probably
> more.
>
Something like below, with all the memsets for dpll_hw_state removed?

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 633da693fed8..956b7ffab32f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11911,7 +11911,6 @@ clear_intel_crtc_state(struct intel_crtc_state 
*crtc_state)
 {
struct drm_crtc_state tmp_state;
struct intel_crtc_scaler_state scaler_state;
-   struct intel_dpll_hw_state dpll_hw_state;
enum intel_dpll_id shared_dpll;
uint32_t ddi_pll_sel;
bool force_thru;
@@ -11924,7 +11923,6 @@ clear_intel_crtc_state(struct intel_crtc_state 
*crtc_state)
tmp_state = crtc_state->base;
scaler_state = crtc_state->scaler_state;
shared_dpll = crtc_state->shared_dpll;
-   dpll_hw_state = crtc_state->dpll_hw_state;
ddi_pll_sel = crtc_state->ddi_pll_sel;
force_thru = crtc_state->pch_pfit.force_thru;
 

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

Re: [Intel-gfx] [PATCH] RFC drm/i915: Stop the machine whilst capturing the GPU crash dump

[Daniel Vetter]

On Tue, Oct 13, 2015 at 01:24:53PM +0100, Chris Wilson wrote:
> On Tue, Oct 13, 2015 at 02:09:59PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 09, 2015 at 06:55:23PM +0100, Chris Wilson wrote:
> > > On Fri, Oct 09, 2015 at 07:33:23PM +0200, Daniel Vetter wrote:
> > > > On Fri, Oct 09, 2015 at 01:21:45PM +0100, Chris Wilson wrote:
> > > > > The error state is purposefully racy as we expect it to be called at 
> > > > > any
> > > > > time and so have avoided any locking whilst capturing the crash dump.
> > > > > However, with multi-engine GPUs and multiple CPUs, those races can
> > > > > manifest into OOPSes as we attempt to chase dangling pointers freed on
> > > > > other CPUs. Under discussion are lots of ways to slow down normal
> > > > > operation in order to protect the post-mortem error capture, but what 
> > > > > it
> > > > > we take the opposite approach and freeze the machine whilst the error
> > > > > catpure runs (note the GPU may still running, but as long as we don't
> > > > > process any of the results the driver's bookkeeping will be static).
> > > > > 
> > > > > Signed-off-by: Chris Wilson 
> > > > 
> > > > One risk I see is that the list walking might still go off the rails 
> > > > when
> > > > we stop the machine right in the middle of a list_move. With that we 
> > > > might
> > > > start scanning the active list (of objects) on one engine and then 
> > > > midway
> > > > through get to another engine and so never see the list_head again,
> > > > looping forever. No idea yet what to do with that.
> > > 
> > > A move is a del followed by an insertion, you cannot step into an entry
> > > that is the middle of moving lists - don't forget that stop_machine() is
> > > a very heavy memory barrier. Similarly, the list_add() should ensure we
> > > can't step forward into an element that will not lead back to the list.
> > > So I am not convinced that it would be suspectible to that style of
> > > hijacking.
> > 
> > The compiler could do havoc, so I think we need at least somewhat ordered
> > lists updates. Using rcu lists primitives but stop_machine instead of
> > kfree_rcu might do the trick.
> 
> I'd take the compiler barriers, but I don't want the mb() inside every
> list update. And with a barrier, only walking the lists forwards in the
> error capture, and the error capture being inside a stop_machine (so
> mb() and no concurrent access) is safe. (Quite a list of brittle
> caveats.)

Yeah, hence using _rcu list macros. They have the relevant barriers
already and should work. The only difference is that instead of
synchronize_rcu on the write side before kfree, we'll use stop_machine on
the read side. It's still RCU, but with all the cost moved to the read
side while still keeping the benefit that the read side can be done
locklessly.

> > > The only alternative I see to list walking, is not to do any from the
> > > error capture and rely on attaching enough information to the request
> > > (along with register state) to be able to do postmortems.
> > 
> > That still means we need to at least protect the request lists to get at
> > said request. And it sounded like you wouldn't like a kfree_rcu in there
> > that much.
> 
> The burden has to be on the error capture side as having to do any atomic
> operations whilst processing the requests quickly show up in the
> profiles (at the moment here those profiles are dominated by the memory
> access required to update the lists, where once those accesses were
> dwarfed by the locked operations.) so I don't even relish the prospect
> of adding atomic operations around list walking in the normal case.

Yeah, spin_lock_irq would be the horror, and that's the only other solid
plan we have really. One caveat of stop_machine is that we can only use it
in the error capture, not in the hangcheck itself. But at most we'd need
to rcu requests properly, and using a engine-local buffer (to avoid the
risk of jumping off the rails onto another list) for that would fully
mitigate any rcu costs for freeing. But I didn't check the code whether we
even need that ;-)
-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 15/22] drm/i915: CHV: Pipe level CSC correction

[Sharma, Shashank]

Regards
Shashank

On 10/13/2015 7:03 PM, Emil Velikov wrote:

On 10 October 2015 at 06:26, Sharma, Shashank  wrote:

On 10/10/2015 5:13 AM, Emil Velikov wrote:


On 9 October 2015 at 20:29, Shashank Sharma 
wrote:


CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.

This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
Signed-off-by: Kumar, Kiran S 
---
   drivers/gpu/drm/i915/i915_reg.h|  8 +++
   drivers/gpu/drm/i915/intel_color_manager.c | 94
++
   drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
   3 files changed, 121 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index c32e35d..5825ab2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8056,4 +8056,12 @@ enum skl_disp_power_wells {
   #define _PIPE_DEGAMMA_BASE(pipe) \
  (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA,
PIPEC_CGM_DEGAMMA))

+#define PIPEA_CGM_CSC  (VLV_DISPLAY_BASE +
0x67900)
+#define PIPEB_CGM_CSC  (VLV_DISPLAY_BASE +
0x69900)
+#define PIPEC_CGM_CSC  (VLV_DISPLAY_BASE +
0x6B900)
+#define _PIPE_CSC_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+
+
+
   #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index bbfe185..433e50a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,93 @@

   #include "intel_color_manager.h"

+static s16 chv_prepare_csc_coeff(s64 csc_value)
+{
+   s32 csc_int_value;
+   u32 csc_fract_value;
+   s16 csc_s3_12_format;


The type of csc_s3_12_format and chv_prepare_csc_coeff() does not see
correct. Seem like the fix got merged into another patch :\


Can you please elaborate this comment, I dont get it.


You have two typos above s16 > s32 which you've fixed in the next
patch. That fix should belong here imho.


Yes, I got that later, current patch set contains this fix.

[snip]

+   while (count < CSC_MAX_VALS) {
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+
+   /*
+* Last value to be written in 1 register.
+* Otherwise, each pair of CSC values go
+* into 1 register
+*/
+   if (count != (CSC_MAX_VALS - 1)) {
+   count++;
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
+   }


This looks a bit odd. Use the same approach as in
bdw_write_12bit_gamma_precision() ?


Again, can you please give little more details here ?

Take a look at the loop construct in bdw_write_12bit_gamma_precision()
- both of them are essentially doing the same thing.

Here you have
while(i < odd_number) {
   foo()
   if (if != odd_number-1) {
 I++
 foo()
   }
}

while in the mentioned function

while (i < odd_number -1) {
   foo()
   foo()
   i++
}
foo()

Normally you'd use one or the other. Esp. since this is a single
patchset :-) I'm leaning towards the latter as it's more obvious but
others may prefer the former approach.

Yes, I got this one also, later :). New patch set has an implementation 
similar to this, please have a look.



Regards,
Emil


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

Re: [Intel-gfx] [PATCH v2] drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level

[Daniel Vetter]

On Fri, Oct 09, 2015 at 02:43:21PM +0100, Tvrtko Ursulin wrote:
> 
> On 09/10/15 14:11, Chris Wilson wrote:
> >Since the remove of the pin-ioctl, we only care about not changing the
> >cache level on buffers pinned to the hardware as indicated by
> >obj->pin_display. By knowing that only objects pinned to the hardware
> >will have an elevated vma->pin_count, so we can coallesce many of the
> >linear walks over the obj->vma_list.
> >
> >v2: Try and retrospectively add comments explaining the steps in
> >rebinding the active VMA.
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> 
> Very nice!
> 
> Reviewed-by: Tvrtko Ursulin 

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 10/22] drm/i915: Register color correction capabilities

[Emil Velikov]

On 13 October 2015 at 14:36, Sharma, Shashank  wrote:
> On 10/13/2015 6:33 PM, Emil Velikov wrote:
>>
>> On 10 October 2015 at 06:01, Sharma, Shashank 
>> wrote:
>>>
>>> On 10/10/2015 3:51 AM, Emil Velikov wrote:


 Hi Shashank,

 On 9 October 2015 at 20:29, Shashank Sharma 
 wrote:
>
>
>   From DRM color management:
> 
> DRM color manager supports these color properties:
> 1. "ctm": Color transformation matrix property, where a
>  color transformation matrix of 9 correction values gets
>  applied as correction.
> 2. "palette_before_ctm": for corrections which get applied
>  beore color transformation matrix correction.
> 3. "palette_after_ctm": for corrections which get applied
>  after color transformation matrix correction.
>
> These color correction capabilities may differ per platform, supporting
> various different no. of correction coefficients. So DRM color manager
> support few properties using which a user space can query the
> platform's
> capability, and prepare color correction accordingly.
> These query properties are:
> 1. cm_coeff_after_ctm_property
> 2. cm_coeff_before_ctm_property
> (CTM is fix to 9 coefficients across industry)
>
> Now, Intel color manager registers:
> ==
> 1. Gamma correction property as "palette_after_ctm" property
> 2. Degamma correction capability as "palette_bafore_ctm" property
>  capability as "palette_after_ctm" DRM color property hook.
> 3. CSC as "ctm" property.
>
> So finally, This patch does the following:
> 1. Add a function which loads the platform's color correction
>  capabilities in the cm_crtc_palette_capabilities_property
> structure.
> 2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
>  getting initiaized.
> 3. Adds two new parameters "num_samples_after_ctm" and
>  "num_samples_before_ctm" in intel_device_info as gamma and
>  degamma coefficients vary per platform basis.
>
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>drivers/gpu/drm/i915/i915_drv.h|  2 ++
>drivers/gpu/drm/i915/intel_color_manager.c | 33
> +-
>2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index ad37b25..8bf1d6f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -798,6 +798,8 @@ struct intel_device_info {
>   u8 num_sprites[I915_MAX_PIPES];
>   u8 gen;
>   u8 ring_mask; /* Rings supported by the HW */
> +   u16 num_samples_after_ctm;
> +   u16 num_samples_before_ctm;
>   DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
>   /* Register offsets for the various display pipes and
> transcoders */
>   int pipe_offsets[I915_MAX_TRANSCODERS];
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 7357d99..e466748 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -28,6 +28,37 @@
>#include "intel_color_manager.h"
>
>void intel_attach_color_properties_to_crtc(struct drm_device *dev,
> -   struct drm_mode_object *mode_obj)
> +   struct drm_crtc *crtc)
>{
> +   struct drm_mode_config *config = >mode_config;
> +   struct drm_mode_object *mode_obj = >base;
> +
> +   /*
> +* Register:
> +* =
> +* Gamma correction as palette_after_ctm property
> +* Degamma correction as palette_before_ctm property
> +*
> +* Load:
> +* =
> +* no. of coefficients supported on this platform for gamma
> +* and degamma with the query properties. A user
> +* space agent should read these query property, and prepare
> +* the color correction values accordingly. Its expected from
> the
> +* driver to load the right number of coefficients during the
> init
> +* phase.
> +*/
> +   if (config->cm_coeff_after_ctm_property) {
> +   drm_object_attach_property(mode_obj,
> +   config->cm_coeff_after_ctm_property,
> +
> INTEL_INFO(dev)->num_samples_after_ctm);
> +   DRM_DEBUG_DRIVER("Gamma query property initialized\n");
> +   }
> +
> +   if 

Re: [Intel-gfx] [PATCH] RFC drm/i915: Stop the machine whilst capturing the GPU crash dump

[Chris Wilson]

On Tue, Oct 13, 2015 at 03:52:08PM +0200, Daniel Vetter wrote:
> On Tue, Oct 13, 2015 at 01:24:53PM +0100, Chris Wilson wrote:
> > On Tue, Oct 13, 2015 at 02:09:59PM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 09, 2015 at 06:55:23PM +0100, Chris Wilson wrote:
> > > > On Fri, Oct 09, 2015 at 07:33:23PM +0200, Daniel Vetter wrote:
> > > > > On Fri, Oct 09, 2015 at 01:21:45PM +0100, Chris Wilson wrote:
> > > > > > The error state is purposefully racy as we expect it to be called 
> > > > > > at any
> > > > > > time and so have avoided any locking whilst capturing the crash 
> > > > > > dump.
> > > > > > However, with multi-engine GPUs and multiple CPUs, those races can
> > > > > > manifest into OOPSes as we attempt to chase dangling pointers freed 
> > > > > > on
> > > > > > other CPUs. Under discussion are lots of ways to slow down normal
> > > > > > operation in order to protect the post-mortem error capture, but 
> > > > > > what it
> > > > > > we take the opposite approach and freeze the machine whilst the 
> > > > > > error
> > > > > > catpure runs (note the GPU may still running, but as long as we 
> > > > > > don't
> > > > > > process any of the results the driver's bookkeeping will be static).
> > > > > > 
> > > > > > Signed-off-by: Chris Wilson 
> > > > > 
> > > > > One risk I see is that the list walking might still go off the rails 
> > > > > when
> > > > > we stop the machine right in the middle of a list_move. With that we 
> > > > > might
> > > > > start scanning the active list (of objects) on one engine and then 
> > > > > midway
> > > > > through get to another engine and so never see the list_head again,
> > > > > looping forever. No idea yet what to do with that.
> > > > 
> > > > A move is a del followed by an insertion, you cannot step into an entry
> > > > that is the middle of moving lists - don't forget that stop_machine() is
> > > > a very heavy memory barrier. Similarly, the list_add() should ensure we
> > > > can't step forward into an element that will not lead back to the list.
> > > > So I am not convinced that it would be suspectible to that style of
> > > > hijacking.
> > > 
> > > The compiler could do havoc, so I think we need at least somewhat ordered
> > > lists updates. Using rcu lists primitives but stop_machine instead of
> > > kfree_rcu might do the trick.
> > 
> > I'd take the compiler barriers, but I don't want the mb() inside every
> > list update. And with a barrier, only walking the lists forwards in the
> > error capture, and the error capture being inside a stop_machine (so
> > mb() and no concurrent access) is safe. (Quite a list of brittle
> > caveats.)
> 
> Yeah, hence using _rcu list macros. They have the relevant barriers
> already and should work. The only difference is that instead of
> synchronize_rcu on the write side before kfree, we'll use stop_machine on
> the read side. It's still RCU, but with all the cost moved to the read
> side while still keeping the benefit that the read side can be done
> locklessly.

They imply a mb() on every write not just a barrier(), and we do a fair few
list updates on each buffer.

> > > > The only alternative I see to list walking, is not to do any from the
> > > > error capture and rely on attaching enough information to the request
> > > > (along with register state) to be able to do postmortems.
> > > 
> > > That still means we need to at least protect the request lists to get at
> > > said request. And it sounded like you wouldn't like a kfree_rcu in there
> > > that much.
> > 
> > The burden has to be on the error capture side as having to do any atomic
> > operations whilst processing the requests quickly show up in the
> > profiles (at the moment here those profiles are dominated by the memory
> > access required to update the lists, where once those accesses were
> > dwarfed by the locked operations.) so I don't even relish the prospect
> > of adding atomic operations around list walking in the normal case.
> 
> Yeah, spin_lock_irq would be the horror, and that's the only other solid
> plan we have really. One caveat of stop_machine is that we can only use it
> in the error capture, not in the hangcheck itself. But at most we'd need
> to rcu requests properly, and using a engine-local buffer (to avoid the
> risk of jumping off the rails onto another list) for that would fully
> mitigate any rcu costs for freeing. But I didn't check the code whether we
> even need that ;-)

So far we have successfully devised strategies at keeping hangcheck nice
and racy, let's keep believing we can do so in the future.
-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] drm/i915: Reset dpll_hw_state when selecting a new pll on hsw

[Maarten Lankhorst]

Op 13-10-15 om 15:58 schreef Daniel Vetter:
> On Tue, Oct 13, 2015 at 03:43:28PM +0200, Maarten Lankhorst wrote:
>> Op 13-10-15 om 15:35 schreef Daniel Vetter:
>>> On Tue, Oct 13, 2015 at 03:18:16PM +0200, Maarten Lankhorst wrote:
 Op 23-09-15 om 17:34 schreef Gabriel Feceoru:
> Using 2 connectors (DVI and VGA) will cause wrpll to be set for
> INTEL_OUTPUT_HDMI but never reset if switching to INTEL_OUTPUT_VGA
>
> Supresses errors like these:
> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
> dpll_hw_state.wrpll
>
 Looks like a good idea to always zero it.
>>> Except that we still have a bunch of cases where we recompute clock state
>>> but only partially. Can we just move them all up into a common place
>>> please? That would also catch cases where we simply forget to fill this
>>> out at all.
>>>
>>> One case I noticed is edp in skl_ddi_pll_select, but there's probably
>>> more.
>>>
>> Something like below, with all the memsets for dpll_hw_state removed?
> I think this will blow up since we recompute clock state only when
> needs_modeset is true. So needs a bit more intelligence in deciding when
> to clear it I think.
Oops you're right. Maybe intel_modeset_clear_plls because that's where all the 
clock state belongs?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Deny wrapping an userptr into a framebuffer

[Tvrtko Ursulin]

On 13/10/15 14:22, Chris Wilson wrote:

Pinning a userptr onto the hardware raises interesting questions about
the lifetime of such a surface as the framebuffer extends that life
beyond the client's address space. That is the hardware will need to
keep scanning out from the backing storage even after the client wants
to remap its address space. As the hardware pins the backing storage,
the userptr becomes invalid and this raises a WARN when the clients
tries to unmap its address space. The situation can be even more
complicated when the buffer is passed between processes, between a
client and display server, where the lifetime and hardware access is
even more confusing. Deny it.


Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues.

[Chris Wilson]

On Tue, Oct 13, 2015 at 03:46:00PM +0200, Daniel Vetter wrote:
> On Tue, Oct 13, 2015 at 12:45:58PM +0100, Chris Wilson wrote:
> > On Tue, Oct 13, 2015 at 01:46:38PM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 09, 2015 at 09:45:16AM +0100, Chris Wilson wrote:
> > > > On Fri, Oct 09, 2015 at 10:38:18AM +0200, Daniel Vetter wrote:
> > > > > On Thu, Oct 08, 2015 at 07:31:39PM +0100, Tomas Elf wrote:
> > > > > > Grab execlist lock when cleaning up execlist queues after GPU reset 
> > > > > > to avoid
> > > > > > concurrency problems between the context event interrupt handler 
> > > > > > and the reset
> > > > > > path immediately following a GPU reset.
> > > > > > 
> > > > > > Signed-off-by: Tomas Elf 
> > > > > 
> > > > > Should we instead just stop any irqs from the GT completely while we 
> > > > > do
> > > > > the reset (plus a synchronize_irq)? It's a bit heavy-weight, but 
> > > > > probably
> > > > > safer. Well not the entire GT, but all the rings under reset (as prep 
> > > > > for
> > > > > per-ring reset).
> > > > 
> > > > Bah, stopping IRQs is not enough for error state capture though since
> > > > requests complete asynchronously just by polling a memory address. (If
> > > > that is the goal here, this patch just makes execlist_queue access
> > > > consistent and should only be run once the GPU has been reset and so is
> > > > categorically idle.)
> > > 
> > > This is the execlist ELSP tracking, which is execlusively driven by the
> > > CTX_SWITCH interrupt signal from each engine.
> > > 
> > > At least that's been my assumption, and under that assumption I think
> > > stalling interrupts should be good enough.
> > 
> > No, because the requests and vma are not coupled to the interrupt in
> > terms of when they can disappear.
> 
> At least today execlist keeps its own reference on requests until the
> CTX_SWITCH stuff is done to exactly make sure this is the case. And even
> when we have that fixed up I think we do need to exclude this processing
> somehow, and the irqsave spinlock seems ok for that. disabling the
> interrupt itself plus synchronize_irq was really just an idea.

What I meant was that we have this problem with vma/obj disappearing not
simply on execlists because request completion is asynchronous (we just
check for the GPU's breadcrumb). Execlists is slightly special in that
its requests can't disappear, but they can elsewhere.
-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] v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control interrupt lied (SDE)! [regression]

[Jean-Christian de Rivaz]

Le 12. 10. 15 09:06, Daniel Vetter a écrit :

Another regression for Jairo to track.
-Daniel


I get the exact same dmesg too with the 4.3.0-rc5 on a i5-5250U NUC 
using HDMI. The rest is a standard Debian Jessie.



On Sat, Oct 10, 2015 at 12:08:43PM -0700, Darren Hart wrote:

The Debian 3.16.0 kernel does not emit the error, but I have not attempted a
bisection.

The warning was added by:
38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
  2014-06-18 (1 year, 4 months ago), Oscar Mateo 

Follows: v3.15-rc8
Preceedes: 3.17-rc1

This is not present in v3.16, so perhaps not present in the Debian kernel and
this is not a regression, but just reporting the condition as intended.

Linux Version: v4.3-rc4
Platform: Lenovo ThinkPad Yoga 12
OS: Debian 8.2

$ dmesg | grep -i drm
[   10.918367] [drm] Initialized drm 1.1.0 20060810
[   11.235005] [drm] Memory usable by graphics device = 4096M
[   11.235009] fb: switching to inteldrmfb from simple
[   11.235093] [drm] Replacing VGA console driver
[   11.241160] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   11.241162] [drm] Driver supports precise vblank timestamp query.
[   11.256249] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: 
Can't calculate constants, dotclock = 0!
[   11.326946] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit 
banging on pin 5
[   11.344097] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on minor 0
[   11.344913] fbcon: inteldrmfb (fb0) is primary device
[   12.462509] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[   12.466498] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[   12.794359] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[   13.869733] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[   13.869894] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[   13.870058] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[   22.656986] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[  257.506246] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[  257.506415] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[  257.506584] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[  257.506746] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[  278.722570] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[  278.722744] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[  278.722908] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[ 1857.776390] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!
[ 4057.592685] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
interrupt lied (SDE)!

--
Darren Hart
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: Deny wrapping an userptr into a framebuffer

[Jani Nikula]

On Tue, 13 Oct 2015, Tvrtko Ursulin  wrote:
> On 13/10/15 14:22, Chris Wilson wrote:
>> Pinning a userptr onto the hardware raises interesting questions about
>> the lifetime of such a surface as the framebuffer extends that life
>> beyond the client's address space. That is the hardware will need to
>> keep scanning out from the backing storage even after the client wants
>> to remap its address space. As the hardware pins the backing storage,
>> the userptr becomes invalid and this raises a WARN when the clients
>> tries to unmap its address space. The situation can be even more
>> complicated when the buffer is passed between processes, between a
>> client and display server, where the lifetime and hardware access is
>> even more confusing. Deny it.
>
> Reviewed-by: Tvrtko Ursulin 

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

BR,
Jani.

>
> Regards,
>
> Tvrtko
> ___
> 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 13/22] drm/i915: CHV: Pipe level Gamma correction

[Sharma, Shashank]

Regards
Shashank

On 10/13/2015 7:29 PM, Emil Velikov wrote:

On 13 October 2015 at 14:40, Sharma, Shashank  wrote:


I am not sure if I915 follows a general rule of using for(...) over while(),
coz I see many instances of using a while in i915_gem, i915_drv, i915_irq
etc, so it should be good. I would see if someone else can suggest another
good reason.

I'm not saying "you should never use while loops", but more of "people
use for loops when accessing arrays of information". I cannot see any
cases of the latter in i915. Perhaps I'm looking at some old code ?

The point I'm trying to make here is that people are unlikely to make
comments about such trivial nitpicks (bikeshedding), but new
contributions should stick with the existing approach, rather than
going for "I like XXX" :)

Take any and all of my with a grain of salt, just in case.

Its a very well written and logical comment, but I like this last line 
the most :) :)

Regards,
Emil


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

Re: [Intel-gfx] [PATCH] drm/i915: Reset dpll_hw_state when selecting a new pll on hsw

[Daniel Vetter]

On Tue, Oct 13, 2015 at 04:00:37PM +0200, Maarten Lankhorst wrote:
> Op 13-10-15 om 15:58 schreef Daniel Vetter:
> > On Tue, Oct 13, 2015 at 03:43:28PM +0200, Maarten Lankhorst wrote:
> >> Op 13-10-15 om 15:35 schreef Daniel Vetter:
> >>> On Tue, Oct 13, 2015 at 03:18:16PM +0200, Maarten Lankhorst wrote:
>  Op 23-09-15 om 17:34 schreef Gabriel Feceoru:
> > Using 2 connectors (DVI and VGA) will cause wrpll to be set for
> > INTEL_OUTPUT_HDMI but never reset if switching to INTEL_OUTPUT_VGA
> >
> > Supresses errors like these:
> > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in 
> > dpll_hw_state.wrpll
> >
>  Looks like a good idea to always zero it.
> >>> Except that we still have a bunch of cases where we recompute clock state
> >>> but only partially. Can we just move them all up into a common place
> >>> please? That would also catch cases where we simply forget to fill this
> >>> out at all.
> >>>
> >>> One case I noticed is edp in skl_ddi_pll_select, but there's probably
> >>> more.
> >>>
> >> Something like below, with all the memsets for dpll_hw_state removed?
> > I think this will blow up since we recompute clock state only when
> > needs_modeset is true. So needs a bit more intelligence in deciding when
> > to clear it I think.
> Oops you're right. Maybe intel_modeset_clear_plls because that's where all 
> the clock state belongs?

Yeah that might be an even better place, in the loop after the continue;
statement.
-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 33/43] drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKE

[Daniel Vetter]

On Mon, Oct 12, 2015 at 09:12:09AM -0700, Jesse Barnes wrote:
> On 09/18/2015 10:03 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_uncore.c | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index 3294f63..197ca397 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -525,7 +525,7 @@ void assert_forcewakes_inactive(struct drm_i915_private 
> > *dev_priv)
> >  }
> >  
> >  /* We give fast paths for the really cool registers */
> > -#define NEEDS_FORCE_WAKE(dev_priv, reg) \
> > +#define NEEDS_FORCE_WAKE(reg) \
> >  ((reg) < 0x4 && (reg) != FORCEWAKE)
> >  
> >  #define REG_RANGE(reg, start, end) ((reg) >= (start) && (reg) < (end))
> > @@ -727,7 +727,7 @@ static u##x \
> >  gen6_read##x(struct drm_i915_private *dev_priv, off_t reg, bool trace) { \
> > GEN6_READ_HEADER(x); \
> > hsw_unclaimed_reg_debug(dev_priv, reg, true, true); \
> > -   if (NEEDS_FORCE_WAKE((dev_priv), (reg))) \
> > +   if (NEEDS_FORCE_WAKE(reg)) \
> > __force_wake_get(dev_priv, FORCEWAKE_RENDER); \
> > val = __raw_i915_read##x(dev_priv, reg); \
> > hsw_unclaimed_reg_debug(dev_priv, reg, true, false); \
> > @@ -761,7 +761,7 @@ chv_read##x(struct drm_i915_private *dev_priv, off_t 
> > reg, bool trace) { \
> > GEN6_READ_FOOTER; \
> >  }
> >  
> > -#define SKL_NEEDS_FORCE_WAKE(dev_priv, reg)\
> > +#define SKL_NEEDS_FORCE_WAKE(reg) \
> >  ((reg) < 0x4 && !FORCEWAKE_GEN9_UNCORE_RANGE_OFFSET(reg))
> >  
> >  #define __gen9_read(x) \
> > @@ -770,9 +770,9 @@ gen9_read##x(struct drm_i915_private *dev_priv, off_t 
> > reg, bool trace) { \
> > enum forcewake_domains fw_engine; \
> > GEN6_READ_HEADER(x); \
> > hsw_unclaimed_reg_debug(dev_priv, reg, true, true); \
> > -   if (!SKL_NEEDS_FORCE_WAKE((dev_priv), (reg)))   \
> > +   if (!SKL_NEEDS_FORCE_WAKE(reg)) \
> > fw_engine = 0; \
> > -   else if (FORCEWAKE_GEN9_RENDER_RANGE_OFFSET(reg))   \
> > +   else if (FORCEWAKE_GEN9_RENDER_RANGE_OFFSET(reg)) \
> > fw_engine = FORCEWAKE_RENDER; \
> > else if (FORCEWAKE_GEN9_MEDIA_RANGE_OFFSET(reg)) \
> > fw_engine = FORCEWAKE_MEDIA; \
> > @@ -868,7 +868,7 @@ static void \
> >  gen6_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, bool 
> > trace) { \
> > u32 __fifo_ret = 0; \
> > GEN6_WRITE_HEADER; \
> > -   if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
> > +   if (NEEDS_FORCE_WAKE(reg)) { \
> > __fifo_ret = __gen6_gt_wait_for_fifo(dev_priv); \
> > } \
> > __raw_i915_write##x(dev_priv, reg, val); \
> > @@ -883,7 +883,7 @@ static void \
> >  hsw_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, bool 
> > trace) { \
> > u32 __fifo_ret = 0; \
> > GEN6_WRITE_HEADER; \
> > -   if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
> > +   if (NEEDS_FORCE_WAKE(reg)) { \
> > __fifo_ret = __gen6_gt_wait_for_fifo(dev_priv); \
> > } \
> > hsw_unclaimed_reg_debug(dev_priv, reg, false, true); \
> > @@ -985,7 +985,7 @@ gen9_write##x(struct drm_i915_private *dev_priv, off_t 
> > reg, u##x val, \
> > enum forcewake_domains fw_engine; \
> > GEN6_WRITE_HEADER; \
> > hsw_unclaimed_reg_debug(dev_priv, reg, false, true); \
> > -   if (!SKL_NEEDS_FORCE_WAKE((dev_priv), (reg)) || \
> > +   if (!SKL_NEEDS_FORCE_WAKE(reg) || \
> > is_gen9_shadowed(dev_priv, reg)) \
> > fw_engine = 0; \
> > else if (FORCEWAKE_GEN9_RENDER_RANGE_OFFSET(reg)) \
> > 
> 
> Reviewed-by: Jesse Barnes 

Merged all the patches Jesse r-b'ed, 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 3/8] drm/i915: Cope with request list state change during error state capture

[Daniel Vetter]

On Fri, Oct 09, 2015 at 12:45:07PM +0100, Tomas Elf wrote:
> On 09/10/2015 09:28, Daniel Vetter wrote:
> >On Thu, Oct 08, 2015 at 07:31:35PM +0100, Tomas Elf wrote:
> >>Since we're not synchronizing the ring request list during error state 
> >>capture
> >>the request list state might change between the time the corresponding error
> >>request list was allocated and dimensioned to the time when the ring request
> >>list is actually captured into the error state. If this happens, throw a
> >>WARNING and do early exit and be aware that the captured error state might 
> >>not
> >>be fully reliable.
> >
> >Please don't throw a WARNING since this is expected to occasionally
> >happen. DRM_DEBUG_DRIVER is enough imo.
> >-Daniel
> 
> I still don't see how it could happen without leading to reads of
> unallocated memory. The error state request list has been allocated to a
> certain size equal to num_requests and this loop seems to assume that the
> error state request list maintains the same size as the driver request list,
> which is not the case - leading to crashes, which is how I happened to
> notice it.
> 
> I can obviously remove the warning but are you saying we shouldn't even take
> action if it happens? Such as early exit?

Just remove the WARNING since this is a perfectly expected outcome when
error state capture races against request adding. If you want put a
DRM_DEBUG or similar in there, but WARN_ON for stuff that we expect might
happen isn't good - i915.ko is too noisy already as-is.
-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: Unify execlist and legacy request life-cycles

[Chris Wilson]

On Tue, Oct 13, 2015 at 01:29:56PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 06:23:50PM +0100, Chris Wilson wrote:
> > On Fri, Oct 09, 2015 at 07:18:21PM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote:
> > > > On Fri, Oct 09, 2015 at 11:15:08AM +0200, Daniel Vetter wrote:
> > > > > My idea was to create a new request for 3. which gets signalled by the
> > > > > scheduler in intel_lrc_irq_handler. My idea was that we'd only create
> > > > > these when a ctx switch might occur to avoid overhead, but I guess if 
> > > > > we
> > > > > just outright delay all requests a notch if need that might work too. 
> > > > > But
> > > > > I'm really not sure on the implications of that (i.e. does the 
> > > > > hardware
> > > > > really unlod the ctx if it's idle?), and whether that would fly still 
> > > > > with
> > > > > the scheduler.
> > > > >
> > > > > But figuring this one out here seems to be the cornestone of this 
> > > > > reorg.
> > > > > Without it we can't just throw contexts onto the active list.
> > > > 
> > > > (Let me see if I understand it correctly)
> > > > 
> > > > Basically the problem is that we can't trust the context object to be
> > > > synchronized until after the status interrupt. The way we handled that
> > > > for legacy is to track the currently bound context and keep the
> > > > vma->pin_count asserted until the request containing the switch away.
> > > > Doing the same for execlists would trivially fix the issue and if done
> > > > smartly allows us to share more code (been there, done that).
> > > > 
> > > > That satisfies me for keeping requests as a basic fence in the GPU
> > > > timeline and should keep everyone happy that the context can't vanish
> > > > until after it is complete. The only caveat is that we cannot evict the
> > > > most recent context. For legacy, we do a switch back to the always
> > > > pinned default context. For execlists we don't, but it still means we
> > > > should only have one context which cannot be evicted (like legacy). But
> > > > it does leave us with the issue that i915_gpu_idle() returns early and
> > > > i915_gem_context_fini() must keep the explicit gpu reset to be
> > > > absolutely sure that the pending context writes are completed before the
> > > > final context is unbound.
> > > 
> > > Yes, and that was what I originally had in mind. Meanwhile the scheduler
> > > (will) happen and that means we won't have FIFO ordering. Which means when
> > > we switch contexts (as opposed to just adding more to the ringbuffer of
> > > the current one) we won't have any idea which context will be the next
> > > one. Which also means we don't know which request to pick to retire the
> > > old context. Hence why I think we need to be better.
> > 
> > But the scheduler does - it is also in charge of making sure the
> > retirement queue is in order. The essence is that we only actually pin
> > engine->last_context, which is chosen as we submit stuff to the hw.
> 
> Well I'm not sure how much it will reorder, but I'd expect it wants to
> reorder stuff pretty freely. And as soon as it reorders context (ofc they
> can't depend on each another) then the legacy hw ctx tracking won't work.
> 
> I think at least ...

Not the way it is written today, but the principle behind it still
stands. The last_context submitted to the hardware is pinned until a new
one is submitted (such that it remains bound in the GGTT until after the
context switch is complete due to the active reference). Instead of
doing the context tracking at the start of the execbuffer, the context
tracking needs to be pushed down to the submission backend/middleman.
-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 7/8] drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues.

[Daniel Vetter]

On Fri, Oct 09, 2015 at 09:45:16AM +0100, Chris Wilson wrote:
> On Fri, Oct 09, 2015 at 10:38:18AM +0200, Daniel Vetter wrote:
> > On Thu, Oct 08, 2015 at 07:31:39PM +0100, Tomas Elf wrote:
> > > Grab execlist lock when cleaning up execlist queues after GPU reset to 
> > > avoid
> > > concurrency problems between the context event interrupt handler and the 
> > > reset
> > > path immediately following a GPU reset.
> > > 
> > > Signed-off-by: Tomas Elf 
> > 
> > Should we instead just stop any irqs from the GT completely while we do
> > the reset (plus a synchronize_irq)? It's a bit heavy-weight, but probably
> > safer. Well not the entire GT, but all the rings under reset (as prep for
> > per-ring reset).
> 
> Bah, stopping IRQs is not enough for error state capture though since
> requests complete asynchronously just by polling a memory address. (If
> that is the goal here, this patch just makes execlist_queue access
> consistent and should only be run once the GPU has been reset and so is
> categorically idle.)

This is the execlist ELSP tracking, which is execlusively driven by the
CTX_SWITCH interrupt signal from each engine.

At least that's been my assumption, and under that assumption I think
stalling interrupts should be good enough.
-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/8] drm/i915: Migrate to safe iterators in error state capture

[Chris Wilson]

On Tue, Oct 13, 2015 at 01:37:32PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 12:40:51PM +0100, Tomas Elf wrote:
> > On 09/10/2015 09:27, Daniel Vetter wrote:
> > >On Thu, Oct 08, 2015 at 07:31:34PM +0100, Tomas Elf wrote:
> > >>Using safe list iterators alleviates the problem of unsynchronized driver 
> > >>list
> > >>manipulations while error state capture is in the process of traversing 
> > >>lists.
> > >>
> > >>Signed-off-by: Tomas Elf 
> > >>---
> > >>  drivers/gpu/drm/i915/i915_gpu_error.c | 38 
> > >> +--
> > >>  1 file changed, 19 insertions(+), 19 deletions(-)
> > >>
> > >>diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> > >>b/drivers/gpu/drm/i915/i915_gpu_error.c
> > >>index 2f04e4f..32c1799 100644
> > >>--- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > >>+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > >>@@ -718,10 +718,10 @@ static void capture_bo(struct drm_i915_error_buffer 
> > >>*err,
> > >>  static u32 capture_active_bo(struct drm_i915_error_buffer *err,
> > >>   int count, struct list_head *head)
> > >>  {
> > >>- struct i915_vma *vma;
> > >>+ struct i915_vma *vma, *tmpvma;
> > >>  int i = 0;
> > >>
> > >>- list_for_each_entry(vma, head, mm_list) {
> > >>+ list_for_each_entry_safe(vma, tmpvma, head, mm_list) {
> > >
> > >_safe isn't safe against anything, it's only safe against removal of the
> > >current list item done with a list_del/list_move from this thread. I.e.
> > >the only thing it does is have a temporary pointer to the next list
> > >element so if you delete the current one it won't fall over.
> > >
> > >It doesn't protect against anything else, and especially not against other
> > >threads totally stomping the list.
> > 
> > Absolutely! But it's good enough to make the test not fall over within an
> > hour of testing and instead allow it to run for 12+ hours during continuous
> > long-duration testing, which is what I need for the TDR validation.
> 
> Well it looks really suspicious, since the only thing this protects
> against is against deleting the element we look at right now. The only
> sensible theory I can come up with is that this slightly helps when
> starting the list walk, in case someone comes around and deletes the first
> element in the list from the retire worker. Since the retire worker tends
> to do more work per list item than we do that's enough to make the race
> really unlikely. But it's still just duct-tape.
> 
> > >So we need proper protection for these lists, independent of
> > >dev->struct_mutex. The least invasive way to do that is probably rcu,
> > >which only requires us that we release the memory for any object sitting
> > >on these lists with kfree_rcu instead of normal kfree. Another option
> > >might be a spinlock, but that would be a lot more invasive, and Chris
> > >won't like the execbuf overhead this causes ;-)
> > >-Daniel
> > 
> > Awesome! Let's go with that then.
> 
> See our massive irc discussion ... it's more tricky :(
> 
> In short rcu works perfectly if you only have the following lifetime
> sequence:
> - kmalloc object
> - add to list
> - remove from list (eventually)
> - free object
> 
> If you readd an object to a list, or even worse, move it then the rcu list
> helpers won't work. What could happen on the read side is:
> 
> - you walk the rcu list, keeping track of the head element to know when to
>   stop
> - while looking at that list one of the yet untraversed items gets moved
>   to a new list
> 
> -> you'll traverse the new list forever since that one will never hit the
> head element.
> 
> Not a problem for requests/vmas, but a problem for some of the object lists.
> 
> Note that the problem isn't that we re-add the element (if that happens we
> might end up walking parts of the list twice or parts of it not at all),
> but moving to a different list where there's a different head element.
> 
> I haven't checked, but maybe we're lucky and all the object lists we're
> looking at will always have the same head element. Then I think it'll work
> out (albeit racy, but who cares about that for the error capture) and with
> the guarantee (when using rcu delayed freeing) that'll we'll never chase
> freed memory.

Ah, so you agree that stop_machine() is good enough.
-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] RFC drm/i915: Stop the machine whilst capturing the GPU crash dump

[Chris Wilson]

On Tue, Oct 13, 2015 at 02:09:59PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 06:55:23PM +0100, Chris Wilson wrote:
> > On Fri, Oct 09, 2015 at 07:33:23PM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 09, 2015 at 01:21:45PM +0100, Chris Wilson wrote:
> > > > The error state is purposefully racy as we expect it to be called at any
> > > > time and so have avoided any locking whilst capturing the crash dump.
> > > > However, with multi-engine GPUs and multiple CPUs, those races can
> > > > manifest into OOPSes as we attempt to chase dangling pointers freed on
> > > > other CPUs. Under discussion are lots of ways to slow down normal
> > > > operation in order to protect the post-mortem error capture, but what it
> > > > we take the opposite approach and freeze the machine whilst the error
> > > > catpure runs (note the GPU may still running, but as long as we don't
> > > > process any of the results the driver's bookkeeping will be static).
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > 
> > > One risk I see is that the list walking might still go off the rails when
> > > we stop the machine right in the middle of a list_move. With that we might
> > > start scanning the active list (of objects) on one engine and then midway
> > > through get to another engine and so never see the list_head again,
> > > looping forever. No idea yet what to do with that.
> > 
> > A move is a del followed by an insertion, you cannot step into an entry
> > that is the middle of moving lists - don't forget that stop_machine() is
> > a very heavy memory barrier. Similarly, the list_add() should ensure we
> > can't step forward into an element that will not lead back to the list.
> > So I am not convinced that it would be suspectible to that style of
> > hijacking.
> 
> The compiler could do havoc, so I think we need at least somewhat ordered
> lists updates. Using rcu lists primitives but stop_machine instead of
> kfree_rcu might do the trick.

I'd take the compiler barriers, but I don't want the mb() inside every
list update. And with a barrier, only walking the lists forwards in the
error capture, and the error capture being inside a stop_machine (so
mb() and no concurrent access) is safe. (Quite a list of brittle
caveats.)
 
> > The only alternative I see to list walking, is not to do any from the
> > error capture and rely on attaching enough information to the request
> > (along with register state) to be able to do postmortems.
> 
> That still means we need to at least protect the request lists to get at
> said request. And it sounded like you wouldn't like a kfree_rcu in there
> that much.

The burden has to be on the error capture side as having to do any atomic
operations whilst processing the requests quickly show up in the
profiles (at the moment here those profiles are dominated by the memory
access required to update the lists, where once those accesses were
dwarfed by the locked operations.) so I don't even relish the prospect
of adding atomic operations around list walking in the normal case.
-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

[Intel-gfx] [PATCH v5 03/22] drm: Add color correction blobs in CRTC state

[Shashank Sharma]

This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 
 include/drm/drm_crtc.h  |  5 +
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 87a2a44..d73ca9b9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2193,6 +2193,12 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
drm_crtc *crtc,
 
if (state->mode_blob)
drm_property_reference_blob(state->mode_blob);
+   if (state->ctm_blob)
+   drm_property_reference_blob(state->ctm_blob);
+   if (state->palette_after_ctm_blob)
+   drm_property_reference_blob(state->palette_after_ctm_blob);
+   if (state->palette_before_ctm_blob)
+   drm_property_reference_blob(state->palette_before_ctm_blob);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -2238,6 +2244,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct 
drm_crtc *crtc,
 {
if (state->mode_blob)
drm_property_unreference_blob(state->mode_blob);
+   if (state->ctm_blob)
+   drm_property_unreference_blob(state->ctm_blob);
+   if (state->palette_after_ctm_blob)
+   drm_property_unreference_blob(state->palette_after_ctm_blob);
+   if (state->palette_before_ctm_blob)
+   drm_property_unreference_blob(state->palette_before_ctm_blob);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1a56596..d416e20 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -304,6 +304,11 @@ struct drm_crtc_state {
/* blob property to expose current mode to atomic userspace */
struct drm_property_blob *mode_blob;
 
+   /* blob properties to hold the color properties' blobs */
+   struct drm_property_blob *palette_before_ctm_blob;
+   struct drm_property_blob *palette_after_ctm_blob;
+   struct drm_property_blob *ctm_blob;
+
struct drm_pending_vblank_event *event;
 
struct drm_atomic_state *state;
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 02/22] drm: Create Color Management query properties

[Shashank Sharma]

DRM color management is written to extract the color correction
capabilities of various platforms, and every platform can showcase
its capabilities using the query properties.

Different hardwares can have different no of coefficients for palette
correction. Also the correction can be applied after/before color
transformation (CTM) unit in the display pipeline.

This patch adds two new read-only properties,
  - cm_coeff_before_ctm_property: A platform driver should use this
property to show supported no_of_coefficients for palette correction,
which gets applied before ctm correction.
  - cm_coeff_after_ctm_property: A platform driver should use this property
to show supported no_of_coefficients for palette correction, which gets
applied after ctm correction.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_crtc.c | 13 +
 include/drm/drm_crtc.h |  4 
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3644342..ad13630 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1491,6 +1491,19 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.cm_ctm_property = prop;
 
+   /* DRM properties to query color capabilities */
+   prop = drm_property_create(dev, DRM_MODE_PROP_IMMUTABLE,
+   "COEFFICIENTS_BEFORE_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_coeff_before_ctm_property = prop;
+
+   prop = drm_property_create(dev, DRM_MODE_PROP_IMMUTABLE,
+   "COEFFICIENTS_AFTER_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cm_coeff_after_ctm_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5ddc1a2..1a56596 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1153,6 +1153,10 @@ struct drm_mode_config {
struct drm_property *cm_palette_after_ctm_property;
struct drm_property *cm_ctm_property;
 
+   /* Color management capabilities query */
+   struct drm_property *cm_coeff_before_ctm_property;
+   struct drm_property *cm_coeff_after_ctm_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 04/22] drm: Add set property support for color manager

[Shashank Sharma]

As per DRM color manager design, if a userspace wants to set a correction
blob, it prepares it and sends the blob_id to kernel via set_property
call. DRM framework takes this blob_id, gets the blob, and saves it
in the CRTC state, so that, during the atomic_commit, the color correction
values from the blob can referred and applied on display controller
registers.

This patch adds this set_property support for color correction blobs
in drm framework.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal malladi 
---
 drivers/gpu/drm/drm_atomic.c | 53 ++--
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7bb3845..12a34e9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,38 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
 EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
 
 /**
+ * drm_atomic_crtc_set_blob - find and set a blob
+ * @state_blob: reference pointer to the color blob in the crtc_state
+ * @blob_id: blob_id coming from set_property() call
+ *
+ * Set a color correction blob (originating from a set blob property) on the
+ * desired CRTC state. This function will take reference of the blob property
+ * in the CRTC state, finds the blob based on blob_id (which comes from
+ * set_property call) and set the blob at the proper place.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
+static int drm_atomic_crtc_set_blob(struct drm_device *dev,
+   struct drm_property_blob **state_blob, uint32_t blob_id)
+{
+   struct drm_property_blob *blob;
+
+   blob = drm_property_lookup_blob(dev, blob_id);
+   if (!blob) {
+   DRM_DEBUG_KMS("Invalid Blob ID\n");
+   return -EINVAL;
+   }
+
+   if (*state_blob)
+   drm_property_unreference_blob(*state_blob);
+
+   /* Attach the blob to be committed in state */
+   *state_blob = blob;
+   return 0;
+}
+
+/**
  * drm_atomic_crtc_set_property - set property on CRTC
  * @crtc: the drm CRTC to set a property on
  * @state: the state object to update with the new property value
@@ -422,8 +454,25 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
if (mode)
drm_property_unreference_blob(mode);
return ret;
-   }
-   else if (crtc->funcs->atomic_set_property)
+   } else if (property == config->cm_palette_after_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   >palette_after_ctm_blob, val);
+   if (ret)
+   DRM_ERROR("Failed to load blob palette_after_ctm\n");
+   return ret;
+   } else if (property == config->cm_palette_before_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   >palette_before_ctm_blob, val);
+   if (ret)
+   DRM_ERROR("Failed to load blob palette_before_ctm\n");
+   return ret;
+   } else if (property == config->cm_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   >ctm_blob, val);
+   if (ret)
+   DRM_ERROR("Failed to load blob ctm\n");
+   return ret;
+   } else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
return -EINVAL;
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 09/22] drm/i915: Create color management files

[Shashank Sharma]

This patch create new files intel_color_manager.c which
will contain the core color correction code for I915 driver
and its header intel_color_manager.h

The per color property patches coming up in this patch series
will fill the appropriate functions in this file.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/Makefile  |  3 +-
 drivers/gpu/drm/i915/intel_color_manager.c | 33 
 drivers/gpu/drm/i915/intel_color_manager.h | 50 ++
 3 files changed, 85 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 44d290a..56caf9e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -64,7 +64,8 @@ i915-y += intel_audio.o \
  intel_overlay.o \
  intel_psr.o \
  intel_sideband.o \
- intel_sprite.o
+ intel_sprite.o \
+ intel_color_manager.o
 i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
 i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
 
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
new file mode 100644
index 000..7357d99
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -0,0 +1,33 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma 
+ * Kausal Malladi 
+ */
+
+#include "intel_color_manager.h"
+
+void intel_attach_color_properties_to_crtc(struct drm_device *dev,
+   struct drm_mode_object *mode_obj)
+{
+}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
new file mode 100644
index 000..eec52a7
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma 
+ * Kausal Malladi 
+ */
+#include 
+#include 
+#include "i915_drv.h"
+
+/* Color management bit utilities */
+#define GET_BIT_MASK(n) ((1 << n) - 1)
+
+/* Read bits of a word from bit no. 'start'(lsb) till 'n' bits */
+#define GET_BITS(x, start, nbits) ((x >> start) & GET_BIT_MASK(nbits))
+
+/* Round off by adding 1 to the immediate lower bit */
+#define GET_BITS_ROUNDOFF(x, start, nbits) \
+   ((GET_BITS(x, start, (nbits + 1)) + 1) >> 1)
+
+/* Clear bits of a word from bit no. 'start' till nbits */
+#define CLEAR_BITS(x, start, nbits) ( \
+   

[Intel-gfx] [PATCH v5 11/22] drm/i915: CHV: Load gamma color correction values

[Shashank Sharma]

DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_after_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.

This patch adds no of coefficitents for best gamma color correction
modes possible in CHV, in device info structure, which is:
Gamma(10 bit, CGM HW unit): 257 coeff

These values will be loaded in cm_crtc_palette_capabilities_property
during the CRTC init section, by color manager's attach function.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 2 ++
 drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 760e0ce..7780de4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -34,6 +34,7 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
+#include "intel_color_manager.h"
 
 #include 
 #include 
@@ -349,6 +350,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index eec52a7..a378fe1 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -48,3 +48,6 @@
CLEAR_BITS(target, start_bit, no_bits); \
target |= (bit_pattern << start_bit);  \
} while (0)
+
+/* CHV */
+#define CHV_10BIT_GAMMA_MAX_VALS   257
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 08/22] drm/i915: Add set property interface for CRTC

[Shashank Sharma]

This patch adds set property interface for intel CRTC. This
interface will be used for set operation on any DRM properties.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index cddb0c6..d01a524 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13275,6 +13275,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.page_flip = intel_crtc_page_flip,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
+   .set_property = drm_atomic_helper_crtc_set_property,
 };
 
 static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 10/22] drm/i915: Register color correction capabilities

[Shashank Sharma]

From DRM color management:

DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
   color transformation matrix of 9 correction values gets
   applied as correction.
2. "palette_before_ctm": for corrections which get applied
   beore color transformation matrix correction.
3. "palette_after_ctm": for corrections which get applied
   after color transformation matrix correction.

These color correction capabilities may differ per platform, supporting
various different no. of correction coefficients. So DRM color manager
support few properties using which a user space can query the platform's
capability, and prepare color correction accordingly.
These query properties are:
1. cm_coeff_after_ctm_property
2. cm_coeff_before_ctm_property
(CTM is fix to 9 coefficients across industry)

Now, Intel color manager registers:
==
1. Gamma correction property as "palette_after_ctm" property
2. Degamma correction capability as "palette_bafore_ctm" property
   capability as "palette_after_ctm" DRM color property hook.
3. CSC as "ctm" property.

So finally, This patch does the following:
1. Add a function which loads the platform's color correction
   capabilities in the cm_crtc_palette_capabilities_property structure.
2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
   getting initiaized.
3. Adds two new parameters "num_samples_after_ctm" and
   "num_samples_before_ctm" in intel_device_info as gamma and
   degamma coefficients vary per platform basis.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 ++
 drivers/gpu/drm/i915/intel_color_manager.c | 33 +-
 2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bf14096..6044e5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -785,6 +785,8 @@ struct intel_device_info {
u8 num_sprites[I915_MAX_PIPES];
u8 gen;
u8 ring_mask; /* Rings supported by the HW */
+   u16 num_samples_after_ctm;
+   u16 num_samples_before_ctm;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 7357d99..e466748 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -28,6 +28,37 @@
 #include "intel_color_manager.h"
 
 void intel_attach_color_properties_to_crtc(struct drm_device *dev,
-   struct drm_mode_object *mode_obj)
+   struct drm_crtc *crtc)
 {
+   struct drm_mode_config *config = >mode_config;
+   struct drm_mode_object *mode_obj = >base;
+
+   /*
+* Register:
+* =
+* Gamma correction as palette_after_ctm property
+* Degamma correction as palette_before_ctm property
+*
+* Load:
+* =
+* no. of coefficients supported on this platform for gamma
+* and degamma with the query properties. A user
+* space agent should read these query property, and prepare
+* the color correction values accordingly. Its expected from the
+* driver to load the right number of coefficients during the init
+* phase.
+*/
+   if (config->cm_coeff_after_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_coeff_after_ctm_property,
+   INTEL_INFO(dev)->num_samples_after_ctm);
+   DRM_DEBUG_DRIVER("Gamma query property initialized\n");
+   }
+
+   if (config->cm_coeff_before_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_coeff_before_ctm_property,
+   INTEL_INFO(dev)->num_samples_before_ctm);
+   DRM_DEBUG_DRIVER("Degamma query property initialized\n");
+   }
 }
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Postpone plane readout until after encoder readout, v3.

[Jani Nikula]

On Thu, 27 Aug 2015, Maarten Lankhorst  
wrote:
> When reading out hw state for planes we disable inactive planes which in
> turn triggers an update of the watermarks. The update depends on the
> crtc_clock being set which is done when reading out encoders. Thus
> postpone the plane readout until after encoder readout.
>
> This prevents a warning in skl_compute_linetime_wm() where pixel_rate
> becomes 0 when crtc_clock is 0.
>
> Signed-off-by: Patrik Jakobsson 
> Signed-off-by: Maarten Lankhorst 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=91428

Maarten, I presume this patch is superseded by the commits referenced in
that bug. Is that correct?

BR,
Jani.



> ---
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e3922d973db0..118b205e7bd5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15033,30 +15033,6 @@ static bool primary_get_hw_state(struct intel_crtc 
> *crtc)
>   return !!(I915_READ(DSPCNTR(crtc->plane)) & DISPLAY_PLANE_ENABLE);
>  }
>  
> -static void readout_plane_state(struct intel_crtc *crtc,
> - struct intel_crtc_state *crtc_state)
> -{
> - struct intel_plane *p;
> - struct intel_plane_state *plane_state;
> - bool active = crtc_state->base.active;
> -
> - for_each_intel_plane(crtc->base.dev, p) {
> - if (crtc->pipe != p->pipe)
> - continue;
> -
> - plane_state = to_intel_plane_state(p->base.state);
> -
> - if (p->base.type == DRM_PLANE_TYPE_PRIMARY)
> - plane_state->visible = primary_get_hw_state(crtc);
> - else {
> - if (active)
> - p->disable_plane(>base, >base);
> -
> - plane_state->visible = false;
> - }
> - }
> -}
> -
>  static void intel_modeset_readout_hw_state(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -15076,35 +15052,8 @@ static void intel_modeset_readout_hw_state(struct 
> drm_device *dev)
>  
>   crtc->base.state->active = crtc->active;
>   crtc->base.enabled = crtc->active;
> -
> - memset(>base.mode, 0, sizeof(crtc->base.mode));
> - if (crtc->base.state->active) {
> - intel_mode_from_pipe_config(>base.mode, 
> crtc->config);
> - 
> intel_mode_from_pipe_config(>base.state->adjusted_mode, crtc->config);
> - WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, 
> >base.mode));
> -
> - /*
> -  * The initial mode needs to be set in order to keep
> -  * the atomic core happy. It wants a valid mode if the
> -  * crtc's enabled, so we do the above call.
> -  *
> -  * At this point some state updated by the connectors
> -  * in their ->detect() callback has not run yet, so
> -  * no recalculation can be done yet.
> -  *
> -  * Even if we could do a recalculation and modeset
> -  * right now it would cause a double modeset if
> -  * fbdev or userspace chooses a different initial mode.
> -  *
> -  * If that happens, someone indicated they wanted a
> -  * mode change, which means it's safe to do a full
> -  * recalculation.
> -  */
> - crtc->base.state->mode.private_flags = 
> I915_MODE_FLAG_INHERITED;
> - }
> -
> - crtc->base.hwmode = crtc->config->base.adjusted_mode;
> - readout_plane_state(crtc, 
> to_intel_crtc_state(crtc->base.state));
> + to_intel_plane_state(crtc->base.primary->state)->visible =
> + primary_get_hw_state(crtc);
>  
>   DRM_DEBUG_KMS("[CRTC:%d] hw state readout: %s\n",
> crtc->base.base.id,
> @@ -15186,6 +15135,33 @@ intel_modeset_setup_hw_state(struct drm_device *dev)
>  
>   for_each_pipe(dev_priv, pipe) {
>   crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> + crtc->base.hwmode = crtc->config->base.adjusted_mode;
> + memset(>base.mode, 0, sizeof(crtc->base.mode));
> + if (crtc->base.state->active) {
> + intel_mode_from_pipe_config(>base.mode, 
> crtc->config);
> + 
> intel_mode_from_pipe_config(>base.state->adjusted_mode, crtc->config);
> + WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, 
> >base.mode));
> +
> + /*
> +  * The initial mode 

Re: [Intel-gfx] [PATCH 10/22] drm/i915: Register color correction capabilities

[Emil Velikov]

On 10 October 2015 at 06:01, Sharma, Shashank  wrote:
> On 10/10/2015 3:51 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma 
>> wrote:
>>>
>>>  From DRM color management:
>>> 
>>> DRM color manager supports these color properties:
>>> 1. "ctm": Color transformation matrix property, where a
>>> color transformation matrix of 9 correction values gets
>>> applied as correction.
>>> 2. "palette_before_ctm": for corrections which get applied
>>> beore color transformation matrix correction.
>>> 3. "palette_after_ctm": for corrections which get applied
>>> after color transformation matrix correction.
>>>
>>> These color correction capabilities may differ per platform, supporting
>>> various different no. of correction coefficients. So DRM color manager
>>> support few properties using which a user space can query the platform's
>>> capability, and prepare color correction accordingly.
>>> These query properties are:
>>> 1. cm_coeff_after_ctm_property
>>> 2. cm_coeff_before_ctm_property
>>> (CTM is fix to 9 coefficients across industry)
>>>
>>> Now, Intel color manager registers:
>>> ==
>>> 1. Gamma correction property as "palette_after_ctm" property
>>> 2. Degamma correction capability as "palette_bafore_ctm" property
>>> capability as "palette_after_ctm" DRM color property hook.
>>> 3. CSC as "ctm" property.
>>>
>>> So finally, This patch does the following:
>>> 1. Add a function which loads the platform's color correction
>>> capabilities in the cm_crtc_palette_capabilities_property structure.
>>> 2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
>>> getting initiaized.
>>> 3. Adds two new parameters "num_samples_after_ctm" and
>>> "num_samples_before_ctm" in intel_device_info as gamma and
>>> degamma coefficients vary per platform basis.
>>>
>>> Signed-off-by: Shashank Sharma 
>>> Signed-off-by: Kausal Malladi 
>>> ---
>>>   drivers/gpu/drm/i915/i915_drv.h|  2 ++
>>>   drivers/gpu/drm/i915/intel_color_manager.c | 33
>>> +-
>>>   2 files changed, 34 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index ad37b25..8bf1d6f 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -798,6 +798,8 @@ struct intel_device_info {
>>>  u8 num_sprites[I915_MAX_PIPES];
>>>  u8 gen;
>>>  u8 ring_mask; /* Rings supported by the HW */
>>> +   u16 num_samples_after_ctm;
>>> +   u16 num_samples_before_ctm;
>>>  DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
>>>  /* Register offsets for the various display pipes and
>>> transcoders */
>>>  int pipe_offsets[I915_MAX_TRANSCODERS];
>>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
>>> b/drivers/gpu/drm/i915/intel_color_manager.c
>>> index 7357d99..e466748 100644
>>> --- a/drivers/gpu/drm/i915/intel_color_manager.c
>>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>>> @@ -28,6 +28,37 @@
>>>   #include "intel_color_manager.h"
>>>
>>>   void intel_attach_color_properties_to_crtc(struct drm_device *dev,
>>> -   struct drm_mode_object *mode_obj)
>>> +   struct drm_crtc *crtc)
>>>   {
>>> +   struct drm_mode_config *config = >mode_config;
>>> +   struct drm_mode_object *mode_obj = >base;
>>> +
>>> +   /*
>>> +* Register:
>>> +* =
>>> +* Gamma correction as palette_after_ctm property
>>> +* Degamma correction as palette_before_ctm property
>>> +*
>>> +* Load:
>>> +* =
>>> +* no. of coefficients supported on this platform for gamma
>>> +* and degamma with the query properties. A user
>>> +* space agent should read these query property, and prepare
>>> +* the color correction values accordingly. Its expected from the
>>> +* driver to load the right number of coefficients during the
>>> init
>>> +* phase.
>>> +*/
>>> +   if (config->cm_coeff_after_ctm_property) {
>>> +   drm_object_attach_property(mode_obj,
>>> +   config->cm_coeff_after_ctm_property,
>>> +   INTEL_INFO(dev)->num_samples_after_ctm);
>>> +   DRM_DEBUG_DRIVER("Gamma query property initialized\n");
>>> +   }
>>> +
>>> +   if (config->cm_coeff_before_ctm_property) {
>>> +   drm_object_attach_property(mode_obj,
>>> +   config->cm_coeff_before_ctm_property,
>>> +   INTEL_INFO(dev)->num_samples_before_ctm);
>>> +   DRM_DEBUG_DRIVER("Degamma query property initialized\n");
>>> +   }
>>
>> Shouldn't this commit be squashed with 

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Cope with request list state change during error state capture

[Daniel Vetter]

On Fri, Oct 09, 2015 at 12:25:26PM +0100, Tomas Elf wrote:
> On 09/10/2015 08:48, Chris Wilson wrote:
> >On Thu, Oct 08, 2015 at 07:31:35PM +0100, Tomas Elf wrote:
> >>Since we're not synchronizing the ring request list during error state 
> >>capture
> >>the request list state might change between the time the corresponding error
> >>request list was allocated and dimensioned to the time when the ring request
> >>list is actually captured into the error state. If this happens, throw a
> >>WARNING and do early exit and be aware that the captured error state might 
> >>not
> >>be fully reliable.
> >>
> >>Signed-off-by: Tomas Elf 
> >>---
> >>  drivers/gpu/drm/i915/i915_gpu_error.c | 13 +
> >>  1 file changed, 13 insertions(+)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> >>b/drivers/gpu/drm/i915/i915_gpu_error.c
> >>index 32c1799..cc75ca4 100644
> >>--- a/drivers/gpu/drm/i915/i915_gpu_error.c
> >>+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> >>@@ -1071,6 +1071,19 @@ static void i915_gem_record_rings(struct drm_device 
> >>*dev,
> >>list_for_each_entry_safe(request, tmpreq, >request_list, 
> >> list) {
> >>struct drm_i915_error_request *erq;
> >>
> >>+   if (WARN_ON(!request || count >= 
> >>error->ring[i].num_requests)) {
> >
> >Request cannot be null, count can legitmately be more, the WARN on is
> >inappropriate. Again, I sent several patches over the past couple of
> >years to fix this.
> >-Chris
> >
> 
> Ok, so having the driver request list change grow in between the point where
> we allocate and set up the error state request list to the same size as the
> driver request list (since that's what count being larger than the list size
> implies) is legitimate? Traversing into unallocated memory seems pretty
> dodgy to me but if you say so.

We still need to handle it ofc, but just not WARN on this condition since
it can happen.
-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 7/8] drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues.

[Chris Wilson]

On Tue, Oct 13, 2015 at 01:46:38PM +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 09:45:16AM +0100, Chris Wilson wrote:
> > On Fri, Oct 09, 2015 at 10:38:18AM +0200, Daniel Vetter wrote:
> > > On Thu, Oct 08, 2015 at 07:31:39PM +0100, Tomas Elf wrote:
> > > > Grab execlist lock when cleaning up execlist queues after GPU reset to 
> > > > avoid
> > > > concurrency problems between the context event interrupt handler and 
> > > > the reset
> > > > path immediately following a GPU reset.
> > > > 
> > > > Signed-off-by: Tomas Elf 
> > > 
> > > Should we instead just stop any irqs from the GT completely while we do
> > > the reset (plus a synchronize_irq)? It's a bit heavy-weight, but probably
> > > safer. Well not the entire GT, but all the rings under reset (as prep for
> > > per-ring reset).
> > 
> > Bah, stopping IRQs is not enough for error state capture though since
> > requests complete asynchronously just by polling a memory address. (If
> > that is the goal here, this patch just makes execlist_queue access
> > consistent and should only be run once the GPU has been reset and so is
> > categorically idle.)
> 
> This is the execlist ELSP tracking, which is execlusively driven by the
> CTX_SWITCH interrupt signal from each engine.
> 
> At least that's been my assumption, and under that assumption I think
> stalling interrupts should be good enough.

No, because the requests and vma are not coupled to the interrupt in
terms of when they can disappear.
-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] drm/i915: Convert WARNs during userptr revoke to SIGBUS

[Daniel Vetter]

On Tue, Oct 13, 2015 at 12:44:05PM +0100, Chris Wilson wrote:
> On Tue, Oct 13, 2015 at 01:26:36PM +0200, Daniel Vetter wrote:
> > On Mon, Oct 12, 2015 at 10:31:35AM +0100, Chris Wilson wrote:
> > > On Mon, Oct 12, 2015 at 10:06:23AM +0100, Tvrtko Ursulin wrote:
> > > > 
> > > > On 09/10/15 18:26, Chris Wilson wrote:
> > > > >On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote:
> > > > >>On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote:
> > > > >>>
> > > > >>>On 09/10/15 09:55, Daniel Vetter wrote:
> > > > On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote:
> > > > >On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote:
> > > > >>On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote:
> > > > >>The concern is that this isn't how SIG_SEGV works, it's a signal 
> > > > >>the
> > > > >>thread who made the invalid access gets directly. You never get a 
> > > > >>SIG_SEGV
> > > > >>for bad access someone else has made. So essentially it's new ABI.
> > > > >
> > > > >SIGBUS. For which the answer is yes, you can and do get SIGBUS for
> > > > >actions taken by other processes.
> > > > 
> > > > Oh right I always forget that SIGBUS aliases with SIGIO. Anyway if
> > > > userspace wants SIGIO we just need to provide it with a pollable fd 
> > > > and
> > > > then it can use fcntl to make that happen. That's imo a much better 
> > > > api
> > > > than unconditionally throwing around signals. Also we already have 
> > > > the
> > > > reset stats ioctl to tell userspace that its gpu context is toats. 
> > > > If
> > > > anyone wants that to be pollable (or even send SIGIO) I think we 
> > > > should
> > > > extend that, with all the usual "needs userspace" stuff on top.
> > > > >>>
> > > > >>>I don't see that this notification can be optional. Process is 
> > > > >>>confused
> > > > >>>about its memory map use so should die. :)
> > > > >>>
> > > > >>>This is not a GPU error/hang - this is the process doing stupid 
> > > > >>>things.
> > > > >>>
> > > > >>>MMU notifiers do not support decision making otherwise we could say
> > > > >>>-ETXTBUSY or something on munmap, but we can't. Not even sure that 
> > > > >>>it would
> > > > >>>help in all cases, would have to fail clone as well and who knows 
> > > > >>>what.
> > > > >>
> > > > >>So what happens if the gpu just keeps using the memory? It'll all be
> > > > >>horribly undefined behaviour and eventually it'll die on an -EFAULT in
> > > > >>execbuf, but does anything else bad happen?
> > > > >
> > > > >We don't see an EFAULT unless a miracle occurs, and the stale pages
> > > > >continue to be read/written by other processes (as well as the client).
> > > > >Horribly undefined behaviour with a misinformation leak.
> > > > 
> > > > What other processes? Pages will still be referenced so won't be
> > > > reused so there is not information leak across unrelated processes.
> > > > Unless you meant ones involved in object sharing?
> > > 
> > > This client is trying to replace the userptr with a fresh set of pages.
> > > The GPU and other processes continue to see the old pages i.e. old
> > > information (misinformation :) leaks.
> > 
> > userptr explicitly doesn't support this. You need to tear down the
> > existing userptr object and then create a new one if you change the
> > mmap'ing. So that's really just a bug in userspace, and the question is
> > how do we tell userspace best that it's done something stupid.
> 
> Pardon? Note this also affects munmap if you don't accept mremap (which
> is not explicitly unsupported as it fits quite nicely within the
> existing rules).
> 
> > My stance that the best one is to either kill any ctx using that object or
> > at least indicate there's trouble using reset stats. But sending a
> > SIGBUS/SIG_SEGV (which can only happen to the thread that does a memory
> > access, not any other thread that's accidentally in the same process
> > group) is imo abuse.
> 
> The signal is sent to everything that inherited the mm, not bound to the
> single thread.
> 
> > Or we just need to make sure we do get the EFAULT on
> > the next execbuffer.
> > 
> > Or maybe it just doesn't matter, i.e. where is the userspace which a) does
> > silly stuff like this b) wants proper notification? Adding ABI just
> > because we can't isn't going to get merged.
> 
> No client wants to be killed just because it does something stupid, it
> is killed to protect the integrity of the system.

But killing the client won't get rid of the ctx/objects, so won't really
solve all that much? Especially it won't get rid of the framebuffers,
which is the real trouble here it seems. That's because logind keeps a
duped copy of the fd for it's own purposes.

So the better fix would be to make sure we don't accidentally pin a
userptr object, i.e. adding a check in intel_pin_and_fence_fb for that
(plus igt testcase). I somehow missed in all 

Re: [Intel-gfx] 4.2-rc4 kernel warnings on HSW laptop [regression]

[Jani Nikula]

On Tue, 13 Oct 2015, Ville Syrjälä  wrote:
> On Tue, Oct 13, 2015 at 10:24:58AM +0200, Daniel Vetter wrote:
>> On Mon, Oct 12, 2015 at 02:29:19PM +0200, Takashi Iwai wrote:
>> > On Mon, 12 Oct 2015 09:04:20 +0200,
>> > Daniel Vetter wrote:
>> > > 
>> > > Another pile of regressions for Jairo to track ...
>> > > 
>> > > On Sat, Oct 10, 2015 at 11:46:29AM +0200, Takashi Iwai wrote:
>> > > > Hi,
>> > > > 
>> > > > I noticed that a HSW laptop gets a few new warnings since 4.2-rc
>> > > > kernels.  One error messages pops at each boot time:
>> > > > 
>> > > >  Console: switching to colour dummy device 80x25
>> > > >  [drm] Replacing VGA console driver
>> > > >  [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> > > >  [drm] Driver supports precise vblank timestamp query.
>> > > >  vgaarb: device changed decodes: 
>> > > > PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>> > > >  [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't 
>> > > > calculate constants, dotclock = 0!
>> > > 
>> > > There's patches for this one already, but I accidentally applied them for
>> > > -next, not -fixes. They should land for -rc6.
>> > 
>> > Could you point commit ids?
>> 
>> It was wishful thinking on my side, mixed them up with other patches. I
>> think this one's still open :(
>
> 7f4c628 drm/i915: Assign hwmode after encoder state readout
> 0f64614 drm/i915: Fix clock readout when pipes are enabled w/o ports
>
> not enough?

The relevant bug is [1], everyone please let's track this there.

BR,
Jani.


[1] https://bugs.freedesktop.org/show_bug.cgi?id=91428

>
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> 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: Clear PIPE.STAT before IIR on VLV/CHV

[Jani Nikula]

On Tue, 01 Sep 2015, Imre Deak  wrote:
> On pe, 2015-08-14 at 18:24 +0100, Chris Wilson wrote:
>> The PIPE.STAT register contains some interrupt status bits per pipe, and
>> if assert cause the corresponding bit in the IIR to be asserted (thus
>> raising an interrupt). When handling an interrupt, we should clear the
>> PIPE.STAT generator first before clearing the IIR so that we do not miss
>> events or cause spurious work.
>> 
>> This ordering was broken by
>> 
>> commit 27b6c122512ca30399bb1b39cc42eda83901f304
>> Author: Oscar Mateo 
>> Date:   Mon Jun 16 16:11:00 2014 +0100
>> 
>> drm/i915/chv: Ack interrupts before handling them (CHV)
>> 
>> commit 3ff60f89bc4836583f5bd195062f16c563bd97aa
>> Author: Oscar Mateo 
>> Date:   Mon Jun 16 16:10:58 2014 +0100
>> 
>> drm/i915/vlv: Ack interrupts before handling them (VLV)
>> 
>> in attempting to reduce the amount of work done between receiving an
>> interrupt and acknowledging it. In light of this motivation, split the
>> pipestat interrupt handler into two, one to acknowledge and clear the
>> interrupt and a later pass to process it.
>
> Yes, after thinking about hierarchical interrupt clearing/handling this
> makes complete sense. It was even hinted at by Ville in the discussion
> of the above patches, but I missed his point back then.
>
>> Signed-off-by: Chris Wilson 
>> Cc: Oscar Mateo 
>> Cc: Bob Beckett 
>> Cc: Imre Deak 
>> Cc: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/i915/i915_irq.c | 55 
>> +++--
>>  1 file changed, 31 insertions(+), 24 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 66064511cffb..92bdfe6f91d8 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -1457,24 +1457,21 @@ static void gen6_rps_irq_handler(struct 
>> drm_i915_private *dev_priv, u32 pm_iir)
>>  }
>>  }
>>  
>> -static bool intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
>> +static inline bool
>> +intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
>>  {
>> -if (!drm_handle_vblank(dev, pipe))
>> -return false;
>> -
>> -return true;
>> +return drm_handle_vblank(dev, pipe);
>>  }
>>  
>> -static void valleyview_pipestat_irq_handler(struct drm_device *dev, u32 iir)
>> +static void valleyview_pipestat_irq_get(struct drm_i915_private *dev_priv,
>> +u32 iir, u32 *pipe_stats)
>>  {
>> -struct drm_i915_private *dev_priv = dev->dev_private;
>> -u32 pipe_stats[I915_MAX_PIPES] = { };
>>  int pipe;
>>  
>>  spin_lock(_priv->irq_lock);
>>  for_each_pipe(dev_priv, pipe) {
>> +u32 mask, val, iir_bit = 0;
>>  int reg;
>> -u32 mask, iir_bit = 0;
>>  
>>  /*
>>   * PIPESTAT bits get signalled even when the interrupt is
>> @@ -1486,6 +1483,7 @@ static void valleyview_pipestat_irq_handler(struct 
>> drm_device *dev, u32 iir)
>>  
>>  /* fifo underruns are filterered in the underrun handler. */
>>  mask = PIPE_FIFO_UNDERRUN_STATUS;
>> +mask |= PIPESTAT_INT_ENABLE_MASK;
>>  
>>  switch (pipe) {
>>  case PIPE_A:
>> @@ -1501,21 +1499,25 @@ static void valleyview_pipestat_irq_handler(struct 
>> drm_device *dev, u32 iir)
>>  if (iir & iir_bit)
>>  mask |= dev_priv->pipestat_irq_mask[pipe];
>>  
>> -if (!mask)
>> -continue;
>> -
>>  reg = PIPESTAT(pipe);
>> -mask |= PIPESTAT_INT_ENABLE_MASK;
>> -pipe_stats[pipe] = I915_READ(reg) & mask;
>> +val = I915_READ(reg);
>> +pipe_stats[pipe] |= val & mask;
>>  
>>  /*
>>   * Clear the PIPE*STAT regs before the IIR
>>   */
>> -if (pipe_stats[pipe] & (PIPE_FIFO_UNDERRUN_STATUS |
>> -PIPESTAT_INT_STATUS_MASK))
>> -I915_WRITE(reg, pipe_stats[pipe]);
>> +if (val & (PIPE_FIFO_UNDERRUN_STATUS |
>> +   PIPESTAT_INT_STATUS_MASK))
>> +I915_WRITE(reg, val);
>>  }
>>  spin_unlock(_priv->irq_lock);
>> +}
>> +
>> +static void valleyview_pipestat_irq_handler(struct drm_i915_private 
>> *dev_priv,
>> +u32 *pipe_stats)
>> +{
>> +struct drm_device *dev = dev_priv->dev;
>> +int pipe;
>>  
>>  for_each_pipe(dev_priv, pipe) {
>>  if (pipe_stats[pipe] & PIPE_START_VBLANK_INTERRUPT_STATUS &&
>> @@ -1578,6 +1580,7 @@ static irqreturn_t valleyview_irq_handler(int irq, 
>> void *arg)
>>  {
>>  struct drm_device *dev = arg;
>>  struct drm_i915_private *dev_priv = 

Re: [Intel-gfx] [PATCH] drm/i915/guc: Add GuC css header parser

[Dave Gordon]

On 28/09/15 22:30, yu@intel.com wrote:

From: Alex Dai 

The size / offset information of all firmware ingredients are
now caculated from header. Driver will validate the header and
rsa key size. If any component is out of boundary, driver will
reject the loading too.

v4: Now using 'size_dw' for those defined in css_header

v3: 1) Move DOC to intel_guc_fwif.h right before css_header
definition. Add more comments.
 2) Change 'size' to 'len' or 'length' to avoid confusion.
 3) Add UOS_RSA_SCRATCH_MAX_COUNT according to BSpec. And
driver validate size of RSA key now.
 4) Add fw component size/offset info to intel_guc_fw.

v2: Add indent into DOC to make fixed-width format rather than
change the tmpl.

v1: 1) guc_css_header is defined as __packed now
 2) Add and correct GuC related topics in kernel/Doc

Signed-off-by: Alex Dai 
---
  Documentation/DocBook/drm.tmpl  |  9 +++-
  drivers/gpu/drm/i915/i915_debugfs.c |  6 +++
  drivers/gpu/drm/i915/i915_guc_reg.h |  1 +
  drivers/gpu/drm/i915/intel_guc.h|  8 ++-
  drivers/gpu/drm/i915/intel_guc_fwif.h   | 72 +
  drivers/gpu/drm/i915/intel_guc_loader.c | 93 -
  6 files changed, 151 insertions(+), 38 deletions(-)


The code looks OK; the CSS header fields are adequately checked now, so:

Reviewed-by: Dave Gordon 

with one note about the DocBook change below:


diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 308b141..b7d7e13 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4155,14 +4155,19 @@ int num_ioctls;
GuC-based Command Submission

  GuC
-!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
+!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC


Was this intended? "GuC" doesn't convey much, so I'd suggest keep the 
original or shorten it to "GuC Firmware Loader", or even "GuC Loader", 
but not to just "GuC".


.Dave.


  !Idrivers/gpu/drm/i915/intel_guc_loader.c


  GuC Client
-!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison
+!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC Client
  !Idrivers/gpu/drm/i915/i915_guc_submission.c

+  
+GuC Firmware Layout
+!Pdrivers/gpu/drm/i915/intel_guc_fwif.h GuC Firmware Layout
+!Idrivers/gpu/drm/i915/intel_guc_fwif.h
+  
  

  
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index afa7982..02693d6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2396,6 +2396,12 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+   seq_printf(m, "\theader: offset is %d; size = %d\n",
+   guc_fw->header_offset, guc_fw->header_size);
+   seq_printf(m, "\tuCode: offset is %d; size = %d\n",
+   guc_fw->ucode_offset, guc_fw->ucode_size);
+   seq_printf(m, "\tRSA: offset is %d; size = %d\n",
+   guc_fw->rsa_offset, guc_fw->rsa_size);

tmp = I915_READ(GUC_STATUS);

diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index c4cb1c0..b51b828 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -42,6 +42,7 @@
  #define SOFT_SCRATCH(n)   (0xc180 + ((n) * 4))

  #define UOS_RSA_SCRATCH(i)(0xc200 + (i) * 4)
+#define   UOS_RSA_SCRATCH_MAX_COUNT  64
  #define DMA_ADDR_0_LOW0xc300
  #define DMA_ADDR_0_HIGH   0xc304
  #define DMA_ADDR_1_LOW0xc308
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 4ec2d27..63e73f3 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -76,11 +76,17 @@ struct intel_guc_fw {
uint16_tguc_fw_minor_wanted;
uint16_tguc_fw_major_found;
uint16_tguc_fw_minor_found;
+
+   uint32_t header_size;
+   uint32_t header_offset;
+   uint32_t rsa_size;
+   uint32_t rsa_offset;
+   uint32_t ucode_size;
+   uint32_t ucode_offset;
  };

  struct intel_guc {
struct intel_guc_fw guc_fw;
-
uint32_t log_flags;
struct drm_i915_gem_object *log_obj;

diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index e1f47ba..5b4633b 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -122,6 +122,78 @@

  #define GUC_CTL_MAX_DWORDS(GUC_CTL_RSRVD + 1)

+/**
+ * DOC: GuC Firmware 

Re: [Intel-gfx] [PATCH 2/8] drm/i915: Migrate to safe iterators in error state capture

[Daniel Vetter]

On Fri, Oct 09, 2015 at 12:40:51PM +0100, Tomas Elf wrote:
> On 09/10/2015 09:27, Daniel Vetter wrote:
> >On Thu, Oct 08, 2015 at 07:31:34PM +0100, Tomas Elf wrote:
> >>Using safe list iterators alleviates the problem of unsynchronized driver 
> >>list
> >>manipulations while error state capture is in the process of traversing 
> >>lists.
> >>
> >>Signed-off-by: Tomas Elf 
> >>---
> >>  drivers/gpu/drm/i915/i915_gpu_error.c | 38 
> >> +--
> >>  1 file changed, 19 insertions(+), 19 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> >>b/drivers/gpu/drm/i915/i915_gpu_error.c
> >>index 2f04e4f..32c1799 100644
> >>--- a/drivers/gpu/drm/i915/i915_gpu_error.c
> >>+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> >>@@ -718,10 +718,10 @@ static void capture_bo(struct drm_i915_error_buffer 
> >>*err,
> >>  static u32 capture_active_bo(struct drm_i915_error_buffer *err,
> >> int count, struct list_head *head)
> >>  {
> >>-   struct i915_vma *vma;
> >>+   struct i915_vma *vma, *tmpvma;
> >>int i = 0;
> >>
> >>-   list_for_each_entry(vma, head, mm_list) {
> >>+   list_for_each_entry_safe(vma, tmpvma, head, mm_list) {
> >
> >_safe isn't safe against anything, it's only safe against removal of the
> >current list item done with a list_del/list_move from this thread. I.e.
> >the only thing it does is have a temporary pointer to the next list
> >element so if you delete the current one it won't fall over.
> >
> >It doesn't protect against anything else, and especially not against other
> >threads totally stomping the list.
> 
> Absolutely! But it's good enough to make the test not fall over within an
> hour of testing and instead allow it to run for 12+ hours during continuous
> long-duration testing, which is what I need for the TDR validation.

Well it looks really suspicious, since the only thing this protects
against is against deleting the element we look at right now. The only
sensible theory I can come up with is that this slightly helps when
starting the list walk, in case someone comes around and deletes the first
element in the list from the retire worker. Since the retire worker tends
to do more work per list item than we do that's enough to make the race
really unlikely. But it's still just duct-tape.

> >So we need proper protection for these lists, independent of
> >dev->struct_mutex. The least invasive way to do that is probably rcu,
> >which only requires us that we release the memory for any object sitting
> >on these lists with kfree_rcu instead of normal kfree. Another option
> >might be a spinlock, but that would be a lot more invasive, and Chris
> >won't like the execbuf overhead this causes ;-)
> >-Daniel
> 
> Awesome! Let's go with that then.

See our massive irc discussion ... it's more tricky :(

In short rcu works perfectly if you only have the following lifetime
sequence:
- kmalloc object
- add to list
- remove from list (eventually)
- free object

If you readd an object to a list, or even worse, move it then the rcu list
helpers won't work. What could happen on the read side is:

- you walk the rcu list, keeping track of the head element to know when to
  stop
- while looking at that list one of the yet untraversed items gets moved
  to a new list

-> you'll traverse the new list forever since that one will never hit the
head element.

Not a problem for requests/vmas, but a problem for some of the object lists.

Note that the problem isn't that we re-add the element (if that happens we
might end up walking parts of the list twice or parts of it not at all),
but moving to a different list where there's a different head element.

I haven't checked, but maybe we're lucky and all the object lists we're
looking at will always have the same head element. Then I think it'll work
out (albeit racy, but who cares about that for the error capture) and with
the guarantee (when using rcu delayed freeing) that'll we'll never chase
freed memory.
-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 5/8] drm/i915: vma NULL pointer check

[Daniel Vetter]

On Fri, Oct 09, 2015 at 12:59:44PM +0100, Chris Wilson wrote:
> On Fri, Oct 09, 2015 at 12:30:29PM +0100, Tomas Elf wrote:
> > On 09/10/2015 08:48, Chris Wilson wrote:
> > >On Thu, Oct 08, 2015 at 07:31:37PM +0100, Tomas Elf wrote:
> > >>Sometimes the iterated vma objects are NULL apparently. Be aware of this 
> > >>while
> > >>iterating and do early exit instead of causing a NULL pointer exception.
> > >
> > >Wrong.
> > >-Chris
> > >
> > 
> > So the NULL pointer exception that I ran into multiple times during
> > several different test runs on the line that says "vma->pin_count"
> > was not because the vma pointer was NULL. Would you mind sharing
> > your explanation to how this might have happened? Is it because
> > we're not synchronizing and there's no protection against the driver
> > deallocating vmas while we're trying to capture them? If this all
> > ties into the aforementioned RCU-based solution then maybe we should
> > go with that then.
> 
> Correct. The driver is retiring requests whilst the hang check worker is
> running. And you chased a stale pointer, you could have equally chased a
> stale vma->obj, vma->ctx etc pointers.
> 
> What I have done in the past is to serialise the retirement and the
> hangcheck using a spinlock (as adding to the end of the list is safe),
> but there are still weak spots when walking the list of bound vma.
> What I would actually feel more comfortable with is to only record the
> request->batch_vma, at the cost of losing information about the
> currently bound buffers.
> 
> Or we could just stop_machine() whilst running the capture and have the
> machine unresponsive for a few 100ms. I don't think simply RCU the lists
> is enough (VM active_list, request list, bound list) as eventually we
> chase a pointer from obj itself (which means we need to RCU pretty much
> everything).

I discussed stop_machine with Chris a bit - it does avoid some of the
races, but not all of them (since the lists might be in wonky state right
when we stop_machine). And yes rcu means we need to rcu-free any object
that the error state looks at.

What we could do is protect list consistency with rcu (where possible, see
my other mail about possible problems). And use stop_machine to make sure
the underlying objects don't go poof (instead of kfree_rcu).

Not sure where the gap in that idea is yet ;-)
-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: Convert WARNs during userptr revoke to SIGBUS

[Chris Wilson]

On Tue, Oct 13, 2015 at 01:26:36PM +0200, Daniel Vetter wrote:
> On Mon, Oct 12, 2015 at 10:31:35AM +0100, Chris Wilson wrote:
> > On Mon, Oct 12, 2015 at 10:06:23AM +0100, Tvrtko Ursulin wrote:
> > > 
> > > On 09/10/15 18:26, Chris Wilson wrote:
> > > >On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote:
> > > >>On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote:
> > > >>>
> > > >>>On 09/10/15 09:55, Daniel Vetter wrote:
> > > On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote:
> > > >On Fri, Oct 09, 2015 at 09:48:01AM +0200, Daniel Vetter wrote:
> > > >>On Thu, Oct 08, 2015 at 10:45:47AM +0100, Tvrtko Ursulin wrote:
> > > >>The concern is that this isn't how SIG_SEGV works, it's a signal the
> > > >>thread who made the invalid access gets directly. You never get a 
> > > >>SIG_SEGV
> > > >>for bad access someone else has made. So essentially it's new ABI.
> > > >
> > > >SIGBUS. For which the answer is yes, you can and do get SIGBUS for
> > > >actions taken by other processes.
> > > 
> > > Oh right I always forget that SIGBUS aliases with SIGIO. Anyway if
> > > userspace wants SIGIO we just need to provide it with a pollable fd 
> > > and
> > > then it can use fcntl to make that happen. That's imo a much better 
> > > api
> > > than unconditionally throwing around signals. Also we already have the
> > > reset stats ioctl to tell userspace that its gpu context is toats. If
> > > anyone wants that to be pollable (or even send SIGIO) I think we 
> > > should
> > > extend that, with all the usual "needs userspace" stuff on top.
> > > >>>
> > > >>>I don't see that this notification can be optional. Process is confused
> > > >>>about its memory map use so should die. :)
> > > >>>
> > > >>>This is not a GPU error/hang - this is the process doing stupid things.
> > > >>>
> > > >>>MMU notifiers do not support decision making otherwise we could say
> > > >>>-ETXTBUSY or something on munmap, but we can't. Not even sure that it 
> > > >>>would
> > > >>>help in all cases, would have to fail clone as well and who knows what.
> > > >>
> > > >>So what happens if the gpu just keeps using the memory? It'll all be
> > > >>horribly undefined behaviour and eventually it'll die on an -EFAULT in
> > > >>execbuf, but does anything else bad happen?
> > > >
> > > >We don't see an EFAULT unless a miracle occurs, and the stale pages
> > > >continue to be read/written by other processes (as well as the client).
> > > >Horribly undefined behaviour with a misinformation leak.
> > > 
> > > What other processes? Pages will still be referenced so won't be
> > > reused so there is not information leak across unrelated processes.
> > > Unless you meant ones involved in object sharing?
> > 
> > This client is trying to replace the userptr with a fresh set of pages.
> > The GPU and other processes continue to see the old pages i.e. old
> > information (misinformation :) leaks.
> 
> userptr explicitly doesn't support this. You need to tear down the
> existing userptr object and then create a new one if you change the
> mmap'ing. So that's really just a bug in userspace, and the question is
> how do we tell userspace best that it's done something stupid.

Pardon? Note this also affects munmap if you don't accept mremap (which
is not explicitly unsupported as it fits quite nicely within the
existing rules).

> My stance that the best one is to either kill any ctx using that object or
> at least indicate there's trouble using reset stats. But sending a
> SIGBUS/SIG_SEGV (which can only happen to the thread that does a memory
> access, not any other thread that's accidentally in the same process
> group) is imo abuse.

The signal is sent to everything that inherited the mm, not bound to the
single thread.

> Or we just need to make sure we do get the EFAULT on
> the next execbuffer.
> 
> Or maybe it just doesn't matter, i.e. where is the userspace which a) does
> silly stuff like this b) wants proper notification? Adding ABI just
> because we can't isn't going to get merged.

No client wants to be killed just because it does something stupid, it
is killed to protect the integrity of the system.
-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 0/7] Enable SVM for Intel VT-d

[Daniel Vetter]

On Sat, Oct 10, 2015 at 02:17:55PM +0100, David Woodhouse wrote:
> On Fri, 2015-10-09 at 00:50 +0100, David Woodhouse wrote:
> > This patch set enables PASID support for the Intel IOMMU, along with
> > page request support.
> > 
> > Like its AMD counterpart, it exposes an IOMMU-specific API. I believe
> > we'll have a session at the Kernel Summit later this month in which we
> > can work out a generic API which will cover the two (now) existing
> > implementations as well as upcoming ARM (and other?) versions.
> > 
> > For the time being, however, exposing an Intel-specific API is good
> > enough, especially as we don't have the required TLP prefix support on
> > our PCIe root ports and we *can't* support discrete PCIe devices with
> > PASID support. It's purely on-chip stuff right now, which is basically
> > only Intel graphics.
> > 
> > The AMD implementation allows a per-device PASID space, and managing
> > the PASID space is left entirely to the device driver. In contrast,
> > this implementation maintains a per-IOMMU PASID space, and drivers
> > calling intel_svm_bind_mm() will be *given* the PASID that they are to
> > use. In general we seem to be converging on using a single PASID space
> > across *all* IOMMUs in the system, and this will support that mode of
> > operation.
> 
> The other noticeable difference is the lifetime management of the mm.
> My code takes a reference on it, and will only do the mmput() when the
> driver unbinds the PASID. So the mmu_notifier's .release() method won't
> get called before that.
> 
> The AMD version doesn't take that refcount, and its .release() method
> therefore needs to actually call back into the device driver and ensure
> that all access to the mm, including pending page faults, is flushed.
> The locking issues there scare me a little, especially if page faults
> are currently outstanding.
> 
> In the i915 case we have an open file descriptor associated with the
> gfx context. When the process dies, the fd is closed and the driver can
> go and clean up after it.
> 
> The amdkfd driver, on the other hand, keeps the device-side job running
> even after the process has closed its file descriptor. So it *needs*
> the .release() call to happen when the process exits, as it otherwise
> doesn't know when to clean up.
> 
> I am somewhat dubious about that as a design decision. If we're moving
> to a more explicit management of off-cpu tasks with mm access, as is to
> be discussed at the Kernel Summit, then hopefully we can fix that. It's
> a *lot* simpler if we just pin the mm while the device context has
> access to it.

I think acquiring a full reference on the mm makes sense. Conceptually an
svm context is just another compute thread, just not running on the cpu.
The other way round would mean that at mm exit we tear down these
additional threads, which seems a bit backwards.

Of course that special thread is attached to an fd, which has a completely
separate lifetime from threads. There's also the fun that a different mm
could submit commands to a foreign svm context. So no perfect fit, but on
a hunch still feels like grabbing a full reference is the cleaner design.
And it matches the refcounting we do for traditional gpu contexts on the
ppgtt address space they're using.
-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_REDESIGN_V2 01/14] drm/i915/gen9: csr_init after runtime pm enable

[Imre Deak]

On ke, 2015-08-26 at 16:58 +0530, Animesh Manna wrote:
> Skl is fully dependent on dmc for going to low power state (dc5/dc6).
> This requires a trigger from rpm. To ensure the dmc firmware
> is available for runtime pm support rpm-reference-count is used
> by not releasing the rpm reference if firmware loading is
> not completed.

The above doesn't explain to me why we need this change. Looking at the
next patch makes it clearer: we need to move the firmware loading later
since it needs to take a power domain reference instead of an RPM
reference, and power domains are not initialized at this point yet. It's
also worth mentioning in the commit log that this change is needed by an
upcoming patch.

> 
> So moved the intel_csr_ucode_init call after runtime pm enable.
> 
> Cc: Daniel Vetter 
> Cc: Damien Lespiau 
> Cc: Imre Deak 
> Cc: Sunil Kamath 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 2193cc2..48b9792 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -885,9 +885,6 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>  
>   intel_uncore_init(dev);
>  
> - /* Load CSR Firmware for SKL */
> - intel_csr_ucode_init(dev);
> -
>   ret = i915_gem_gtt_init(dev);
>   if (ret)
>   goto out_freecsr;
> @@ -1035,6 +1032,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>  
>   i915_audio_component_init(dev_priv);
>  
> + /* Load CSR Firmware for SKL */
> + intel_csr_ucode_init(dev);

We need to call this function earlier, since there could be a modeset
before this for the console, after which the driver will disable any
unneeded power domains. So this should be called after
intel_power_domains_init_hw() to prevent this.

> +
>   return 0;
>  
>  out_power_well:


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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix primary_get_hw_state for gen9+.

[Jani Nikula]

On Wed, 23 Sep 2015, Maarten Lankhorst  
wrote:
> On skylake and broxton the old registers are no longer in use.
> Instead it uses universal planes, fix primary_get_hw to use the
> correct registers.
>
> Signed-off-by: Maarten Lankhorst 
> Cc: sta...@vger.kernel.org #v4.2+

Maarten, this patch has no reviews and it no longer applies to v4.3
cleanly. Please rebase and repost if it's still valid.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/intel_display.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 854896e4794e..92c96c34085d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15097,7 +15097,10 @@ static bool primary_get_hw_state(struct intel_plane 
> *plane)
>  {
>   struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
>  
> - return I915_READ(DSPCNTR(plane->plane)) & DISPLAY_PLANE_ENABLE;
> + if (INTEL_INFO(dev_priv)->gen >= 9)
> + return I915_READ(PLANE_CTL(plane->plane, 0)) & PLANE_CTL_ENABLE;
> + else
> + return I915_READ(DSPCNTR(plane->plane)) & DISPLAY_PLANE_ENABLE;
>  }
>  
>  /* FIXME read out full plane state for all planes */
> -- 
> 2.1.0
>
> ___
> 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: Flush pipecontrol post-sync writes

[Jani Nikula]

On Wed, 26 Aug 2015, Chris Wilson  wrote:
> On Wed, Aug 26, 2015 at 11:16:34AM +0200, Daniel Vetter wrote:
>> On Fri, Aug 21, 2015 at 04:08:41PM +0100, Chris Wilson wrote:
>> > In order to flush the results from in-batch pipecontrol writes (used for
>> > example in glQuery) before declaring the batch complete (and so declaring
>> > the query results coherent), we need to set the FlushEnable bit in our
>> > flushing pipecontrol. The FlushEnable bit "waits until all previous
>> > writes of immediate data from post-sync circles are complete before
>> > executing the next command".
>> > 
>> > Signed-off-by: Chris Wilson 
>> > Cc: sta...@vger.kernel.org
>> 
>> Do we have an igt/piglit failing somewhere (igt kinda preferred) or a
>> bugzilla or why is this cc: stable?
>
> I get GPU hangs on byt without flushing these writes (running ue4).
> piglit has examples where the flush is required for correct rendering.

Daniel, does this satisfy your question? We've had an r-b from Ville for
a long time.

BR,
Jani.


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

-- 
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: Postpone plane readout until after encoder readout, v3.

[Maarten Lankhorst]

Op 13-10-15 om 14:40 schreef Jani Nikula:
> On Thu, 27 Aug 2015, Maarten Lankhorst  
> wrote:
>> When reading out hw state for planes we disable inactive planes which in
>> turn triggers an update of the watermarks. The update depends on the
>> crtc_clock being set which is done when reading out encoders. Thus
>> postpone the plane readout until after encoder readout.
>>
>> This prevents a warning in skl_compute_linetime_wm() where pixel_rate
>> becomes 0 when crtc_clock is 0.
>>
>> Signed-off-by: Patrik Jakobsson 
>> Signed-off-by: Maarten Lankhorst 
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=91428
> Maarten, I presume this patch is superseded by the commits referenced in
> that bug. Is that correct?
>
Correct. :)

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Restore lost DPLL register write on gen2-4

[Jani Nikula]

On Thu, 08 Oct 2015, Ville Syrjälä  wrote:
> On Thu, Oct 08, 2015 at 10:17:30AM +0200, Daniel Vetter wrote:
>> On Wed, Oct 07, 2015 at 10:08:24PM +0300, ville.syrj...@linux.intel.com 
>> wrote:
>> > From: Ville Syrjälä 
>> > 
>> > We accidentally lost the initial DPLL register write in
>> > 1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M
>> > 
>> > The "three times for luck" hack probably saved us from a total
>> > disaster. But anyway, bring the initial write back so that the
>> > code actually makes some sense.
>> > 
>> > Cc: sta...@vger.kernel.org
>> > Cc: Nick Bowler 
>> Reported-and-tested-by: Nick Bowler 
>> References: 
>> http://lists.freedesktop.org/archives/intel-gfx/2015-October/077463.html
>> 
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/i915/intel_display.c | 2 ++
>> >  1 file changed, 2 insertions(+)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index 147e700..f4fdff9 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -1743,6 +1743,8 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
>> >   I915_READ(DPLL(!crtc->pipe)) | DPLL_DVO_2X_MODE);
>> 
>> Don't we also need a POSTING_READ here to make sure the two-step 2x mode
>> sequence is still followed?
>
> We don't do write combining on registers, and there are no shadow
> register type of things to consider in this case either.
>
>> 
>> With that addressed Reviewed-by: Daniel Vetter 


Daniel, are you happy with the responses about posting reads, for both
patches?

BR,
Jani.





>> >}
>> >  
>> > +  I915_WRITE(reg, dpll);
>> > +
>> >/* Wait for the clocks to stabilize. */
>> >POSTING_READ(reg);
>> >udelay(150);
>> > -- 
>> > 2.4.9
>> > 
>> > ___
>> > 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
>
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> 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 13/22] drm/i915: CHV: Pipe level Gamma correction

[Emil Velikov]

On 10 October 2015 at 06:09, Sharma, Shashank  wrote:
> On 10/10/2015 4:37 AM, Emil Velikov wrote:
>>
>> Hi Shashank,
>>
>> On 9 October 2015 at 20:29, Shashank Sharma 
>> wrote:
>>>
>>> CHV/BSW platform supports two different pipe level gamma
>>> correction modes, which are:
>>> 1. Legacy 8-bit mode
>>> 2. 10-bit CGM (Color Gamut Mapping) mode
>>>
>>> This patch does the following:
>>> 1. Attaches Gamma property to CRTC
>>> 3. Adds the core Gamma correction function for CHV/BSW
>>> 4. Adds Gamma correction macros
>>>
>>> Signed-off-by: Shashank Sharma 
>>> Signed-off-by: Kausal Malladi 
>>> ---
[snip]
>>> +   length = num_samples * sizeof(struct drm_r32g32b32);
>>
>> Calculation can overflow.
>
> good catch, will take care of this.
Actually we do not at all here as the variable is unused. Same applies
for patch 21/22.

[snip]
>>> +   while (count < num_samples) {
>>
>> Using for(i = 0;) loop seems the more common approach ?
>
> Nah, we are good with while. The whole color management series prefers while
> (and me too :))
Hmm... so you'd prefer your approach/coding style over the one already
in i915? Feels a bit strange but as long as others are happy fine go
with it.

Regards,
Emil
___
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: Unify execlist and legacy request life-cycles

[Daniel Vetter]

On Fri, Oct 09, 2015 at 06:23:50PM +0100, Chris Wilson wrote:
> On Fri, Oct 09, 2015 at 07:18:21PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote:
> > > On Fri, Oct 09, 2015 at 11:15:08AM +0200, Daniel Vetter wrote:
> > > > My idea was to create a new request for 3. which gets signalled by the
> > > > scheduler in intel_lrc_irq_handler. My idea was that we'd only create
> > > > these when a ctx switch might occur to avoid overhead, but I guess if we
> > > > just outright delay all requests a notch if need that might work too. 
> > > > But
> > > > I'm really not sure on the implications of that (i.e. does the hardware
> > > > really unlod the ctx if it's idle?), and whether that would fly still 
> > > > with
> > > > the scheduler.
> > > >
> > > > But figuring this one out here seems to be the cornestone of this reorg.
> > > > Without it we can't just throw contexts onto the active list.
> > > 
> > > (Let me see if I understand it correctly)
> > > 
> > > Basically the problem is that we can't trust the context object to be
> > > synchronized until after the status interrupt. The way we handled that
> > > for legacy is to track the currently bound context and keep the
> > > vma->pin_count asserted until the request containing the switch away.
> > > Doing the same for execlists would trivially fix the issue and if done
> > > smartly allows us to share more code (been there, done that).
> > > 
> > > That satisfies me for keeping requests as a basic fence in the GPU
> > > timeline and should keep everyone happy that the context can't vanish
> > > until after it is complete. The only caveat is that we cannot evict the
> > > most recent context. For legacy, we do a switch back to the always
> > > pinned default context. For execlists we don't, but it still means we
> > > should only have one context which cannot be evicted (like legacy). But
> > > it does leave us with the issue that i915_gpu_idle() returns early and
> > > i915_gem_context_fini() must keep the explicit gpu reset to be
> > > absolutely sure that the pending context writes are completed before the
> > > final context is unbound.
> > 
> > Yes, and that was what I originally had in mind. Meanwhile the scheduler
> > (will) happen and that means we won't have FIFO ordering. Which means when
> > we switch contexts (as opposed to just adding more to the ringbuffer of
> > the current one) we won't have any idea which context will be the next
> > one. Which also means we don't know which request to pick to retire the
> > old context. Hence why I think we need to be better.
> 
> But the scheduler does - it is also in charge of making sure the
> retirement queue is in order. The essence is that we only actually pin
> engine->last_context, which is chosen as we submit stuff to the hw.

Well I'm not sure how much it will reorder, but I'd expect it wants to
reorder stuff pretty freely. And as soon as it reorders context (ofc they
can't depend on each another) then the legacy hw ctx tracking won't work.

I think at least ...
-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] RFC drm/i915: Stop the machine whilst capturing the GPU crash dump

[Daniel Vetter]

On Fri, Oct 09, 2015 at 06:55:23PM +0100, Chris Wilson wrote:
> On Fri, Oct 09, 2015 at 07:33:23PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 09, 2015 at 01:21:45PM +0100, Chris Wilson wrote:
> > > The error state is purposefully racy as we expect it to be called at any
> > > time and so have avoided any locking whilst capturing the crash dump.
> > > However, with multi-engine GPUs and multiple CPUs, those races can
> > > manifest into OOPSes as we attempt to chase dangling pointers freed on
> > > other CPUs. Under discussion are lots of ways to slow down normal
> > > operation in order to protect the post-mortem error capture, but what it
> > > we take the opposite approach and freeze the machine whilst the error
> > > catpure runs (note the GPU may still running, but as long as we don't
> > > process any of the results the driver's bookkeeping will be static).
> > > 
> > > Signed-off-by: Chris Wilson 
> > 
> > One risk I see is that the list walking might still go off the rails when
> > we stop the machine right in the middle of a list_move. With that we might
> > start scanning the active list (of objects) on one engine and then midway
> > through get to another engine and so never see the list_head again,
> > looping forever. No idea yet what to do with that.
> 
> A move is a del followed by an insertion, you cannot step into an entry
> that is the middle of moving lists - don't forget that stop_machine() is
> a very heavy memory barrier. Similarly, the list_add() should ensure we
> can't step forward into an element that will not lead back to the list.
> So I am not convinced that it would be suspectible to that style of
> hijacking.

The compiler could do havoc, so I think we need at least somewhat ordered
lists updates. Using rcu lists primitives but stop_machine instead of
kfree_rcu might do the trick.

> The only alternative I see to list walking, is not to do any from the
> error capture and rely on attaching enough information to the request
> (along with register state) to be able to do postmortems.

That still means we need to at least protect the request lists to get at
said request. And it sounded like you wouldn't like a kfree_rcu in there
that much.
-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] vlv eDP BIOS Compatiblity to EMGD generated BIOS

[Jani Nikula]

On Tue, 23 Jun 2015, Andreas Lampersperger 
 wrote:
> When the i915.ko identify an eDP output on a valleyview
> board, it should be more slackly. The reason for that is,
> that BIOS DATA TABLES generated with intel BMP (Binary
> Modification Program) do not set bits for NOT_HDMI or
> DIGITAL_OUTPUT on the device type. Due to Adolfo
> Sanchez from Intel EMGD, this is not possible.
> To solve this problem and enable i915.ko on embedded
> vlv boards with eDP, we ignore this two bits.

Going through some old patches, this should be fixed by

commit 972e7d71c82ea70100b808695d5cf735c1df5ef8
Author: Ville Syrjälä 
Date:   Fri Sep 11 21:04:39 2015 +0300

drm/i915: Ignore "digital output" and "not HDMI output" bits for eDP 
detection

BR,
Jani.

>
> Signed-off-by: Andreas Lampersperger 
> ---
>  drivers/gpu/drm/i915/intel_bios.h | 10 ++
>  drivers/gpu/drm/i915/intel_dp.c   | 10 --
>  2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h 
> b/drivers/gpu/drm/i915/intel_bios.h
> index af0b476..c42161f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -742,6 +742,16 @@ int intel_parse_bios(struct drm_device *dev);
>DEVICE_TYPE_DIGITAL_OUTPUT | \
>DEVICE_TYPE_ANALOG_OUTPUT)
>  
> +/*
> + * We dont look on DEVICE_TYPE_NOT_HDMI_OUTPUT an DEVICE_TYPE_DIGITAL_OUTPUT
> + * on valleyview, because intels BMP-generated BIOS don't sets these 
> + * BITS for eDP ports
> + */ 
> +#define DEVICE_TYPE_eDP_BITS_VLV \
> + (DEVICE_TYPE_eDP_BITS &\
> +  (~ DEVICE_TYPE_NOT_HDMI_OUTPUT ) &\
> +  (~ DEVICE_TYPE_DIGITAL_OUTPUT ) )
> +
>  /* define the DVO port for HDMI output type */
>  #define  DVO_B   1
>  #define  DVO_C   2
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f52eef1..51c753f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5036,6 +5036,7 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port 
> port)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   union child_device_config *p_child;
>   int i;
> + u16 eDP_bits;
>   static const short port_mapping[] = {
>   [PORT_B] = PORT_IDPB,
>   [PORT_C] = PORT_IDPC,
> @@ -5047,13 +5048,18 @@ bool intel_dp_is_edp(struct drm_device *dev, enum 
> port port)
>  
>   if (!dev_priv->vbt.child_dev_num)
>   return false;
> + 
> + if (IS_VALLEYVIEW(dev))
> +   eDP_bits = DEVICE_TYPE_eDP_BITS_VLV;
> + else
> +   eDP_bits = DEVICE_TYPE_eDP_BITS;
>  
>   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
>   p_child = dev_priv->vbt.child_dev + i;
>  
>   if (p_child->common.dvo_port == port_mapping[port] &&
> - (p_child->common.device_type & DEVICE_TYPE_eDP_BITS) ==
> - (DEVICE_TYPE_eDP & DEVICE_TYPE_eDP_BITS))
> + (p_child->common.device_type & eDP_bits) ==
> + (DEVICE_TYPE_eDP & eDP_bits))
>   return true;
>   }
>   return false;
> -- 
> 2.1.4
>
> ___
> 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

[Intel-gfx] [PATCH v5 20/22] drm/i915: BDW: Load degamma correction values

[Shashank Sharma]

I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.

This patch adds the no of coefficients(512) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 7 +++
 drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8beac5c..1c68e91 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -303,6 +303,7 @@ static const struct intel_device_info 
intel_broadwell_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -316,6 +317,7 @@ static const struct intel_device_info 
intel_broadwell_m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -329,6 +331,7 @@ static const struct intel_device_info 
intel_broadwell_gt3d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -342,6 +345,7 @@ static const struct intel_device_info 
intel_broadwell_gt3m_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -368,6 +372,7 @@ static const struct intel_device_info intel_skylake_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -382,6 +387,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -396,6 +402,7 @@ static const struct intel_device_info intel_broxton_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index 6c7cb08..e0c486e 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -98,3 +98,6 @@
 #define BDW_MAX_GAMMA ((1 << 24) - 1)
 #define BDW_INDEX_AUTO_INCREMENT   (1 << 15)
 #define BDW_INDEX_SPLIT_MODE   (1 << 31)
+
+/* Degamma on BDW */
+#define BDW_DEGAMMA_MAX_VALS   512
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 22/22] drm/i915: BDW: Pipe level CSC correction

[Shashank Sharma]

BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.

This patch does the following:
1. Adds the core function to program CSC correction values for
   BDW/SKL/BXT platform
2. Adds CSC correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
Signed-off-by: Kumar, Kiran S 
---
 drivers/gpu/drm/i915/i915_reg.h|   7 ++
 drivers/gpu/drm/i915/intel_color_manager.c | 113 +
 drivers/gpu/drm/i915/intel_color_manager.h |   8 ++
 3 files changed, 128 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 13e268a..fa1703d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8195,4 +8195,11 @@ enum skl_disp_power_wells {
(_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))
 
 
+/* BDW CSC correction */
+#define CSC_COEFF_A0x49010
+#define CSC_COEFF_B0x49110
+#define CSC_COEFF_C0x49210
+#define _PIPE_CSC_COEFF(pipe) \
+   (_PIPE3(pipe, CSC_COEFF_A, CSC_COEFF_B, CSC_COEFF_C))
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 42fd2f5..8fe0c0b 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -366,6 +366,117 @@ static int bdw_set_degamma(struct drm_device *dev,
return 0;
 }
 
+static uint32_t bdw_prepare_csc_coeff(int64_t coeff)
+{
+   uint32_t reg_val, ls_bit_pos, exponent_bits, sign_bit = 0;
+   int32_t mantissa;
+   uint64_t abs_coeff;
+
+   coeff = min_t(int64_t, coeff, BDW_CSC_COEFF_MAX_VAL);
+   coeff = max_t(int64_t, coeff, BDW_CSC_COEFF_MIN_VAL);
+
+   abs_coeff = abs(coeff);
+   if (abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 3)) {
+   /* abs_coeff < 0.125 */
+   exponent_bits = 3;
+   ls_bit_pos = 19;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 3) &&
+   abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 2)) {
+   /* abs_coeff >= 0.125 && val < 0.25 */
+   exponent_bits = 2;
+   ls_bit_pos = 20;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 2)
+   && abs_coeff < (BDW_CSC_COEFF_UNITY_VAL >> 1)) {
+   /* abs_coeff >= 0.25 && val < 0.5 */
+   exponent_bits = 1;
+   ls_bit_pos = 21;
+   } else if (abs_coeff >= (BDW_CSC_COEFF_UNITY_VAL >> 1)
+   && abs_coeff < BDW_CSC_COEFF_UNITY_VAL) {
+   /* abs_coeff >= 0.5 && val < 1.0 */
+   exponent_bits = 0;
+   ls_bit_pos = 22;
+   } else if (abs_coeff >= BDW_CSC_COEFF_UNITY_VAL &&
+   abs_coeff < (BDW_CSC_COEFF_UNITY_VAL << 1)) {
+   /* abs_coeff >= 1.0 && val < 2.0 */
+   exponent_bits = 7;
+   ls_bit_pos = 23;
+   } else {
+   /* abs_coeff >= 2.0 && val < 4.0 */
+   exponent_bits = 6;
+   ls_bit_pos = 24;
+   }
+
+   mantissa = GET_BITS_ROUNDOFF(abs_coeff, ls_bit_pos, CSC_MAX_VALS);
+   if (coeff < 0)
+   sign_bit = 1;
+
+   reg_val = 0;
+   SET_BITS(reg_val, exponent_bits, 12, 3);
+   SET_BITS(reg_val, mantissa, 3, 9);
+   SET_BITS(reg_val, sign_bit, 15, 1);
+   return reg_val;
+}
+
+static int bdw_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+   struct drm_crtc *crtc)
+{
+   enum pipe pipe;
+   enum plane plane;
+   int temp, word;
+   int count = 0;
+   u32 reg, plane_ctl, mode;
+   struct drm_ctm *csc_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   if (blob->length != sizeof(struct drm_ctm)) {
+   DRM_ERROR("Invalid length of data received\n");
+   return -EINVAL;
+   }
+
+   csc_data = (struct drm_ctm *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   plane = to_intel_crtc(crtc)->plane;
+
+   plane_ctl = I915_READ(PLANE_CTL(pipe, plane));
+   plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
+   I915_WRITE(PLANE_CTL(pipe, plane), plane_ctl);
+   reg = _PIPE_CSC_COEFF(pipe);
+
+   /*
+   * BDW CSC correction coefficients are written like this:
+   * first two values go in a pair, into first register(0:15 and 16:31)
+   * third one alone goes into second register (16:31). Same
+   * pattern repeats for 3 times = 3 * 3 = 9 values.
+   */
+   while (count < CSC_MAX_VALS) {
+   word = 0;
+   temp = bdw_prepare_csc_coeff(csc_data->ctm_coeff[count++]);
+   SET_BITS(word, temp, 16, 16);
+
+   

Re: [Intel-gfx] [PATCH] drm/i915: Do not update pipe state when crtc is inactive.

[Jani Nikula]

On Tue, 22 Sep 2015, Maarten Lankhorst  
wrote:
> Nothing good can come from detaching scalers or updating pipe config
> when the crtc is already disabled. Touching registers while the crtc
> and power wells are disabled causes unclaimed register access warnings.
>
> Reported-by: Mika Kuoppala 
> Signed-off-by: Maarten Lankhorst 

Maarten, this patch has no reviews and it no longer applies to v4.3
cleanly. Please rebase and repost if it's still valid.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a4c24e6f5d6f..5a68290bf8c6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13527,7 +13527,7 @@ static void intel_begin_crtc_commit(struct drm_crtc 
> *crtc,
>   /* Perform vblank evasion around commit operation */
>   intel_pipe_update_start(intel_crtc);
>  
> - if (modeset)
> + if (modeset || !crtc->state->active)
>   return;
>  
>   if (to_intel_crtc_state(crtc->state)->update_pipe)
> -- 
> 2.1.0
>
> ___
> 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

[Intel-gfx] [PATCH v5 19/22] drm/i915: BDW: Pipe level Gamma correction

[Shashank Sharma]

BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit mode
3. Split mode
4. 12-bit mode

This patch does the following:
1. Adds the core function to program Gamma correction values
   for BDW/SKL/BXT platforms
2. Adds Gamma correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_reg.h|  25 ++-
 drivers/gpu/drm/i915/intel_color_manager.c | 285 +
 drivers/gpu/drm/i915/intel_color_manager.h |   6 +
 3 files changed, 314 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c395b63..13e268a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5685,11 +5685,15 @@ enum skl_disp_power_wells {
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
-#define LGC_PALETTE(pipe, i) (_PIPE(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B) + 
(i) * 4)
+#define _LGC_PALETTE_C   0x4b000
+#define LGC_PALETTE(pipe, i) (_PIPE3(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B, \
+_LGC_PALETTE_C) + (i) * 4)
 
 #define _GAMMA_MODE_A  0x4a480
 #define _GAMMA_MODE_B  0x4ac80
-#define GAMMA_MODE(pipe) _PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
+#define _GAMMA_MODE_C  0x4b480
+#define GAMMA_MODE(pipe) \
+   _PIPE3(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B, _GAMMA_MODE_C)
 #define GAMMA_MODE_MODE_MASK   (3 << 0)
 #define GAMMA_MODE_MODE_8BIT   (0 << 0)
 #define GAMMA_MODE_MODE_10BIT  (1 << 0)
@@ -8172,6 +8176,23 @@ enum skl_disp_power_wells {
 #define _PIPE_CSC_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
 
+/* BDW gamma correction */
+#define PAL_PREC_INDEX_A   0x4A400
+#define PAL_PREC_INDEX_B   0x4AC00
+#define PAL_PREC_INDEX_C   0x4B400
+#define PAL_PREC_DATA_A0x4A404
+#define PAL_PREC_DATA_B0x4AC04
+#define PAL_PREC_DATA_C0x4B404
+#define PAL_PREC_GCMAX_A   0x4A410
+#define PAL_PREC_GCMAX_B   0x4AC10
+#define PAL_PREC_GCMAX_C   0x4B410
+
+#define _PREC_PAL_INDEX(pipe) \
+   (_PIPE3(pipe, PAL_PREC_INDEX_A, PAL_PREC_INDEX_B, PAL_PREC_INDEX_C))
+#define _PREC_PAL_DATA(pipe) \
+   (_PIPE3(pipe, PAL_PREC_DATA_A, PAL_PREC_DATA_B, PAL_PREC_DATA_C))
+#define _PREC_PAL_GCMAX(pipe) \
+   (_PIPE3(pipe, PAL_PREC_GCMAX_A, PAL_PREC_GCMAX_B, PAL_PREC_GCMAX_C))
 
 
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index fe95762..cf85bc3 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,289 @@
 
 #include "intel_color_manager.h"
 
+static void bdw_write_8bit_gamma_legacy(struct drm_device *dev,
+   struct drm_r32g32b32 *correction_values, u32 palette)
+{
+   u16 blue_fract, green_fract, red_fract;
+   u32 blue, green, red;
+   u32 count = 0;
+   u32 word = 0;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   while (count < BDW_8BIT_GAMMA_MAX_VALS) {
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   /*
+   * Maximum possible gamma correction value supported
+   * for BDW is 0x, so clamp the values accordingly
+   */
+   if (blue >= BDW_MAX_GAMMA)
+   blue = BDW_MAX_GAMMA;
+   if (green >= BDW_MAX_GAMMA)
+   green = BDW_MAX_GAMMA;
+   if (red >= BDW_MAX_GAMMA)
+   red = BDW_MAX_GAMMA;
+
+   blue_fract = GET_BITS(blue, 16, 8);
+   green_fract = GET_BITS(green, 16, 8);
+   red_fract = GET_BITS(red, 16, 8);
+
+   /* Blue (7:0) Green (15:8) and Red (23:16) */
+   SET_BITS(word, blue_fract, 0, 8);
+   SET_BITS(word, green_fract, 8, 8);
+   SET_BITS(word, blue_fract, 16, 8);
+   I915_WRITE(palette, word);
+   palette += 4;
+   count++;
+   }
+}
+
+static void bdw_write_10bit_gamma_precision(struct drm_device *dev,
+   struct drm_r32g32b32 *correction_values, u32 pal_prec_data,
+   u32 no_of_coeff)
+{
+   u16 blue_fract, green_fract, red_fract;
+   u32 word = 0;
+   u32 count = 0;
+   u32 blue, green, red;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   while (count < no_of_coeff) {
+
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = 

[Intel-gfx] [PATCH v5 16/22] drm/i915: Commit color correction to CRTC

[Shashank Sharma]

The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_color_manager.c | 44 ++
 drivers/gpu/drm/i915/intel_display.c   |  2 ++
 drivers/gpu/drm/i915/intel_drv.h   |  3 ++
 3 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 6b17b20..fe95762 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -292,6 +292,50 @@ static int chv_set_gamma(struct drm_device *dev, struct 
drm_property_blob *blob,
}
 }
 
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+   struct drm_crtc_state *crtc_state)
+{
+   struct drm_property_blob *blob;
+   struct drm_crtc *crtc = crtc_state->crtc;
+   int ret = -EINVAL;
+
+   blob = crtc_state->palette_after_ctm_blob;
+   if (blob) {
+   /* Gamma correction is platform specific */
+   if (IS_CHERRYVIEW(dev))
+   ret = chv_set_gamma(dev, blob, crtc);
+
+   if (ret)
+   DRM_ERROR("set Gamma correction failed\n");
+   else
+   DRM_DEBUG_DRIVER("Gamma correction success\n");
+   }
+
+   blob = crtc_state->palette_before_ctm_blob;
+   if (blob) {
+   /* Degamma correction */
+   if (IS_CHERRYVIEW(dev))
+   ret = chv_set_degamma(dev, blob, crtc);
+
+   if (ret)
+   DRM_ERROR("set degamma correction failed\n");
+   else
+   DRM_DEBUG_DRIVER("degamma correction success\n");
+   }
+
+   blob = crtc_state->ctm_blob;
+   if (blob) {
+   /* CSC correction */
+   if (IS_CHERRYVIEW(dev))
+   ret = chv_set_csc(dev, blob, crtc);
+
+   if (ret)
+   DRM_ERROR("set CSC correction failed\n");
+   else
+   DRM_DEBUG_DRIVER("CSC correction success\n");
+   }
+}
+
 void intel_attach_color_properties_to_crtc(struct drm_device *dev,
struct drm_crtc *crtc)
 {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d01a524..8c7f8d3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13564,6 +13564,8 @@ static void intel_begin_crtc_commit(struct drm_crtc 
*crtc,
intel_update_pipe_config(intel_crtc, old_intel_state);
else if (INTEL_INFO(dev)->gen >= 9)
skl_detach_scalers(intel_crtc);
+
+   intel_color_manager_crtc_commit(dev, crtc->state);
 }
 
 static void intel_finish_crtc_commit(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 91b6b40..3e79bb4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1474,4 +1474,7 @@ void intel_plane_destroy_state(struct drm_plane *plane,
   struct drm_plane_state *state);
 extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
 
+/* intel_color_manager.c */
+void intel_color_manager_crtc_commit(struct drm_device *dev,
+   struct drm_crtc_state *crtc_state);
 #endif /* __INTEL_DRV_H__ */
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 15/22] drm/i915: CHV: Pipe level CSC correction

[Shashank Sharma]

CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.

This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
Signed-off-by: Kumar, Kiran S 
---
 drivers/gpu/drm/i915/i915_reg.h|  8 +++
 drivers/gpu/drm/i915/intel_color_manager.c | 99 ++
 drivers/gpu/drm/i915/intel_color_manager.h | 19 ++
 3 files changed, 126 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cbb5fc9..c395b63 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8166,4 +8166,12 @@ enum skl_disp_power_wells {
 #define _PIPE_DEGAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
 
+#define PIPEA_CGM_CSC  (VLV_DISPLAY_BASE + 0x67900)
+#define PIPEB_CGM_CSC  (VLV_DISPLAY_BASE + 0x69900)
+#define PIPEC_CGM_CSC  (VLV_DISPLAY_BASE + 0x6B900)
+#define _PIPE_CSC_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+
+
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 73c0762..6b17b20 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,98 @@
 
 #include "intel_color_manager.h"
 
+static s32 chv_prepare_csc_coeff(s64 csc_value)
+{
+   s32 csc_int_value;
+   u32 csc_fract_value;
+   s32 csc_s3_12_format;
+
+   if (csc_value >= 0) {
+   csc_value += CHV_CSC_FRACT_ROUNDOFF;
+   if (csc_value > CHV_CSC_COEFF_MAX)
+   csc_value = CHV_CSC_COEFF_MAX;
+   } else {
+   csc_value = -csc_value;
+   csc_value += CHV_CSC_FRACT_ROUNDOFF;
+   if (csc_value > CHV_CSC_COEFF_MAX + 1)
+   csc_value = CHV_CSC_COEFF_MAX + 1;
+   csc_value = -csc_value;
+   }
+
+   csc_int_value = csc_value >> CHV_CSC_COEFF_SHIFT;
+   csc_int_value <<= CHV_CSC_COEFF_INT_SHIFT;
+   if (csc_value < 0)
+   csc_int_value |= CSC_COEFF_SIGN;
+
+   csc_fract_value = csc_value;
+   csc_fract_value >>= CHV_CSC_COEFF_FRACT_SHIFT;
+   csc_s3_12_format = csc_int_value | csc_fract_value;
+
+   return csc_s3_12_format;
+}
+
+static int chv_set_csc(struct drm_device *dev, struct drm_property_blob *blob,
+   struct drm_crtc *crtc)
+{
+   struct drm_ctm *csc_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 reg;
+   enum pipe pipe;
+   s32 word = 0, temp;
+   int count = 0;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   if (blob->length != sizeof(struct drm_ctm)) {
+   DRM_ERROR("Invalid length of data received\n");
+   return -EINVAL;
+   }
+
+   csc_data = (struct drm_ctm *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+
+   /* Disable CSC functionality */
+   reg = _PIPE_CGM_CONTROL(pipe);
+   I915_WRITE(reg, I915_READ(reg) & (~CGM_CSC_EN));
+
+   DRM_DEBUG_DRIVER("Disabled CSC Functionality on Pipe %c\n",
+   pipe_name(pipe));
+
+   reg = _PIPE_CSC_BASE(pipe);
+
+   /*
+   * First 8 of 9 CSC correction values go in pair, to first
+   * 4 CSC register (bit 0:15 and 16:31)
+   */
+   while (count < CSC_MAX_VALS - 1) {
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+   count++;
+
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 16, 16);
+   count++;
+
+   I915_WRITE(reg, word);
+   reg += 4;
+   }
+
+   /* 9th coeff goes to 5th register, bit 0:16 */
+   temp = chv_prepare_csc_coeff(
+   csc_data->ctm_coeff[count]);
+   SET_BITS(word, GET_BITS(temp, 16, 16), 0, 16);
+   I915_WRITE(reg, word);
+
+   /* Enable CSC functionality */
+   reg = _PIPE_CGM_CONTROL(pipe);
+   I915_WRITE(reg, I915_READ(reg) | CGM_CSC_EN);
+   DRM_DEBUG_DRIVER("CSC enabled on Pipe %c\n", pipe_name(pipe));
+   return 0;
+}
+
 static int chv_set_degamma(struct drm_device *dev,
struct drm_property_blob *blob, struct drm_crtc *crtc)
 {
@@ -248,4 +340,11 @@ void intel_attach_color_properties_to_crtc(struct 
drm_device *dev,
config->cm_palette_before_ctm_property, 0);
  

[Intel-gfx] [PATCH v5 14/22] drm/i915: CHV: Pipe level degamma correction

[Shashank Sharma]

CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.

This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
   CHV/BSW platform
2. Add DeGamma correction macros/defines

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_reg.h|  6 ++
 drivers/gpu/drm/i915/intel_color_manager.c | 91 ++
 drivers/gpu/drm/i915/intel_color_manager.h |  5 ++
 3 files changed, 102 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8e0a1b1..cbb5fc9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8160,4 +8160,10 @@ enum skl_disp_power_wells {
 #define _PIPE_GAMMA_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
 
+#define PIPEA_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x66000)
+#define PIPEB_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x68000)
+#define PIPEC_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x6A000)
+#define _PIPE_DEGAMMA_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index 498e048..73c0762 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,91 @@
 
 #include "intel_color_manager.h"
 
+static int chv_set_degamma(struct drm_device *dev,
+   struct drm_property_blob *blob, struct drm_crtc *crtc)
+{
+   u16 red_fract, green_fract, blue_fract;
+   u32 red, green, blue;
+   u32 num_samples;
+   u32 word = 0;
+   u32 count, cgm_control_reg, cgm_degamma_reg;
+   u64 length;
+   enum pipe pipe;
+   struct drm_palette *degamma_data;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_r32g32b32 *correction_values = NULL;
+   struct drm_crtc_state *state = crtc->state;
+
+   if (WARN_ON(!blob))
+   return -EINVAL;
+
+   degamma_data = (struct drm_palette *)blob->data;
+   pipe = to_intel_crtc(crtc)->pipe;
+   num_samples = degamma_data->num_samples;
+   length = num_samples * sizeof(struct drm_r32g32b32);
+
+   if (num_samples == GAMMA_DISABLE_VALS) {
+   /* Disable DeGamma functionality on Pipe - CGM Block */
+   cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+   cgm_control_reg &= ~CGM_DEGAMMA_EN;
+   state->palette_before_ctm_blob = NULL;
+
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+   DRM_DEBUG_DRIVER("DeGamma disabled on Pipe %c\n",
+   pipe_name(pipe));
+   return 0;
+   } else if (num_samples == CHV_DEGAMMA_MAX_VALS) {
+   cgm_degamma_reg = _PIPE_DEGAMMA_BASE(pipe);
+
+   count = 0;
+   correction_values = (struct drm_r32g32b32 *)_data->lut;
+   while (count < CHV_DEGAMMA_MAX_VALS) {
+   blue = correction_values[count].b32;
+   green = correction_values[count].g32;
+   red = correction_values[count].r32;
+
+   if (blue > CHV_MAX_GAMMA)
+   blue = CHV_MAX_GAMMA;
+
+   if (green > CHV_MAX_GAMMA)
+   green = CHV_MAX_GAMMA;
+
+   if (red > CHV_MAX_GAMMA)
+   red = CHV_MAX_GAMMA;
+
+   blue_fract = GET_BITS(blue, 8, 14);
+   green_fract = GET_BITS(green, 8, 14);
+   red_fract = GET_BITS(red, 8, 14);
+
+   /* Green (29:16) and Blue (13:0) in DWORD1 */
+   SET_BITS(word, green_fract, 16, 14);
+   SET_BITS(word, green_fract, 0, 14);
+   I915_WRITE(cgm_degamma_reg, word);
+   cgm_degamma_reg += 4;
+
+   /* Red (13:0) to be written to DWORD2 */
+   word = red_fract;
+   I915_WRITE(cgm_degamma_reg, word);
+   cgm_degamma_reg += 4;
+   count++;
+   }
+
+   DRM_DEBUG_DRIVER("DeGamma LUT loaded for Pipe %c\n",
+   pipe_name(pipe));
+
+   /* Enable DeGamma on Pipe */
+   I915_WRITE(_PIPE_CGM_CONTROL(pipe),
+   I915_READ(_PIPE_CGM_CONTROL(pipe)) | CGM_DEGAMMA_EN);
+
+   DRM_DEBUG_DRIVER("DeGamma correction enabled on Pipe %c\n",
+   pipe_name(pipe));
+   return 0;

[Intel-gfx] [PATCH v5 18/22] drm/i915: BDW: Load gamma correction values

[Shashank Sharma]

I915 color manager registers pipe gamma correction as palette
correction after CTM property.

For BDW and higher platforms, split gamma correction is the best
gamma correction. This patch adds the no of coefficients(512) for
split gamma correction as "num_samples_after_ctm" parameter in device
info structures, for all of those.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c| 7 +++
 drivers/gpu/drm/i915/intel_color_manager.h | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6adf002..8beac5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -302,6 +302,7 @@ static const struct intel_device_info 
intel_broadwell_d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -314,6 +315,7 @@ static const struct intel_device_info 
intel_broadwell_m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -326,6 +328,7 @@ static const struct intel_device_info 
intel_broadwell_gt3d_info = {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -338,6 +341,7 @@ static const struct intel_device_info 
intel_broadwell_gt3m_info = {
.gen = 8, .is_mobile = 1, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -363,6 +367,7 @@ static const struct intel_device_info intel_skylake_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -376,6 +381,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.gen = 9, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.has_llc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
@@ -389,6 +395,7 @@ static const struct intel_device_info intel_broxton_info = {
.gen = 9,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h 
b/drivers/gpu/drm/i915/intel_color_manager.h
index 7b96512..271246a 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.h
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -89,3 +89,6 @@
 #define CGM_GAMMA_EN   (1 << 2)
 #define CGM_CSC_EN (1 << 1)
 #define CGM_DEGAMMA_EN (1 << 0)
+
+/* Gamma on BDW */
+#define BDW_SPLITGAMMA_MAX_VALS512
-- 
1.9.1

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

[Intel-gfx] [PATCH v5 17/22] drm/i915: Attach color properties to CRTC

[Shashank Sharma]

Function intel_attach_color_properties_to_crtc attaches a
color property to its CRTC object. This patch calls this
function from crtc initialization sequence.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 drivers/gpu/drm/i915/intel_drv.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8c7f8d3..cc284bcd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13895,6 +13895,7 @@ static void intel_crtc_init(struct drm_device *dev, int 
pipe)
intel_crtc->cursor_size = ~0;
 
intel_crtc->wm.cxsr_allowed = true;
+   intel_attach_color_properties_to_crtc(dev, _crtc->base);
 
BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
   dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3e79bb4..ebe776c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1477,4 +1477,6 @@ extern const struct drm_plane_helper_funcs 
intel_plane_helper_funcs;
 /* intel_color_manager.c */
 void intel_color_manager_crtc_commit(struct drm_device *dev,
struct drm_crtc_state *crtc_state);
+void intel_attach_color_properties_to_crtc(struct drm_device *dev,
+   struct drm_crtc *crtc);
 #endif /* __INTEL_DRV_H__ */
-- 
1.9.1

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