Re: [Intel-gfx] [PATCH 14/15] drm/i915: Track frontbuffer invalidation/flushing
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> +/**
> + * intel_fb_flip_prepare - flip frontbuffer
> + * @obj: GEM object to flush
> + *
> + * This function gets called after scheduling a flip on @obj. The actual
> + * frontbuffer flushing will be delayed until completion is signalled with
> + * intel_frontbuffer_flip_complete. If an invalidate happens in between this
> + * flush will be cancelled.
> + *
> + * Note that the frontbuffer tracking bits in obj->frontbuffer_bits must have
> + * been updated already.
> + */
> +void intel_fb_flip_prepare(struct drm_i915_gem_object *obj)
> +{
> + struct drm_device *dev = obj->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> + WARN_ON(!obj->frontbuffer_bits);
> +
> + mutex_lock(&dev_priv->fb_tracking.lock);
> + dev_priv->fb_tracking.flip_bits
> + |= obj->frontbuffer_bits;
> + mutex_unlock(&dev_priv->fb_tracking.lock);
> +}
> +
> +/**
> + * intel_frontbuffer_flip_complete - complete frontbuffer flip
> + * @dev: DRM device
> + * @frontbuffer_bits: frontbuffer plane tracking bits
> + *
> + * This function gets called after the flip has been latched and will
> complete
> + * on the next vblank. It will execute the fush if it hasn't been cancalled
> yet.
> + *
> + * Can be called without any locks held.
> + */
> +void intel_frontbuffer_flip_complete(struct drm_device *dev,
> + unsigned frontbuffer_bits)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + mutex_lock(&dev_priv->fb_tracking.lock);
> + /* Mask any cancelled flips. */
> + frontbuffer_bits &= dev_priv->fb_tracking.flip_bits;
> + dev_priv->fb_tracking.flip_bits &= ~frontbuffer_bits;
> + mutex_unlock(&dev_priv->fb_tracking.lock);
> +
> + intel_frontbuffer_flush(dev, frontbuffer_bits);
> +}
Let's be consistent and call this intel_fb_flip_complete. I am happy
with the slight confusion between intel_fb and
i915_frontbuffer_tracking, since they are related and it is easy enough
to make the conceptual leap that only the fb that are on the scanout
(ala frontbuffers) need to be tracked - but we only every need to track
fbs...
-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 14/15] drm/i915: Track frontbuffer invalidation/flushing
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote: > +/** > + * intel_frontbuffer_flush - flush frontbuffer > + * @dev: DRM device > + * @frontbuffer_bits: frontbuffer plane tracking bits > + * > + * This function gets called every time rendering on the given planes has > + * completed and frontbuffer caching can be started again. Flushes will get > + * delayed if they're blocked by some oustanding asynchronous rendering. > + * > + * Can be called without any locks held. > + */ > +void intel_frontbuffer_flush(struct drm_device *dev, > + unsigned frontbuffer_bits) intel_fb_complete. -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 14/15] drm/i915: Track frontbuffer invalidation/flushing
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> +static void intel_mark_fb_busy(struct drm_device *dev,
> +unsigned frontbuffer_bits,
> +struct intel_engine_cs *ring)
> {
> - struct drm_device *dev = obj->base.dev;
> enum pipe pipe;
>
> - intel_edp_psr_exit(dev);
> -
> if (!i915.powersave)
> return;
I think this wants to be moved from here down to
intel_increase_pllclock. It's a little dangerous here as we use it
inconsistently, and we certainly want to keep tracking fb bits for other
reasons.
-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 14/15] drm/i915: Track frontbuffer invalidation/flushing
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote: > @@ -2227,6 +2223,9 @@ i915_gem_object_move_to_inactive(struct > drm_i915_gem_object *obj) > list_move_tail(&vma->mm_list, &vm->inactive_list); > } > > + if (obj->frontbuffer_bits) > + intel_fb_flush(obj, true); > + > list_del_init(&obj->ring_list); > obj->ring = NULL; > > @@ -3556,6 +3555,8 @@ i915_gem_object_flush_gtt_write_domain(struct > drm_i915_gem_object *obj) > old_write_domain = obj->base.write_domain; > obj->base.write_domain = 0; > > + intel_fb_flush(obj, false); > + I think it is worth the if (obj->frontbuffer_bit) check everywhere. -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 14/15] drm/i915: Track frontbuffer invalidation/flushing
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote: > @@ -3966,6 +3971,8 @@ i915_gem_object_set_to_cpu_domain(struct > drm_i915_gem_object *obj, bool write) > obj->base.write_domain = I915_GEM_DOMAIN_CPU; > } > /* We do not need to explicitly invalidate the fb when moving to the * CPU domain as it is not coherent with the display. Therefore the user * much flush updates to the scanout through the frontbuffer whilst in * the CPU domain by explicitly flushing it - either by manually moving * to the GTT domain, or by calling sw-finish. */ > + intel_fb_invalidate(obj, NULL); And so kill this. -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 14/15] drm/i915: Track frontbuffer invalidation/flushing
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote: > void i915_gem_release(struct drm_device *dev, struct drm_file *file) > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > index 93d7f7246588..2d06aad4a954 100644 > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > @@ -978,7 +978,7 @@ i915_gem_execbuffer_move_to_active(struct list_head *vmas, > /* check for potential scanout */ > if (i915_gem_obj_ggtt_bound(obj) && > i915_gem_obj_to_ggtt(obj)->pin_count) What is it about these checks you like so much? You haven't taken the patches to convert this to if (obj->pin_display) and you haven't converted them to obj->frontbuffer_bits in this patch either! > - intel_mark_fb_busy(obj, ring); > + intel_fb_invalidate(obj, ring); > > /* update for the implicit flush after a batch */ > obj->base.write_domain &= ~I915_GEM_GPU_DOMAINS; -- 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 04/15] drm/i915: Run psr_setup unconditionally
On Mon, Jun 16, 2014 at 05:03:02PM -0700, Rodrigo Vivi wrote: >On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter ><[1]daniel.vet...@ffwll.ch> wrote: > > static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp) > @@ -1911,9 +1906,6 @@ void intel_edp_psr_exit(struct drm_device *dev, > bool schedule_back) > if (!HAS_PSR(dev)) > return; Whilst you are here, this should just be a if (dev_priv->psr.enabled) check. -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 14/15] drm/i915: Track frontbuffer invalidation/flushing
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 27975c3e21c5..12276c39d14d 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -43,10 +43,26 @@
> #include
> #include "i915_drv.h"
>
> +static int intel_fbdev_set_par(struct fb_info *info)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> + struct intel_fbdev *ifbdev =
> + container_of(fb_helper, struct intel_fbdev, helper);
> + int ret;
> +
> + ret = drm_fb_helper_set_par(info);
> +
> + if (ret == 0)
> + ret = i915_gem_object_set_to_gtt_domain(ifbdev->fb->obj,
> + true);
> +
> + return ret;
> +}
Ah, I had missed you added this. Yes, this is what I had in mind for
fixing fbcon. However, this is worth splitting out into a separate path
as this is about to get hairy!
ret = drm_fb_helper_set_par(info)
if (ret) return ret;
/* Invalidate the fb for all further writes whilst on the console */
if (!in_atomic() && mutex_trylock(&dev->struct_mutex)) {
ret = i915_gem_object_set_tp_gtt_domain(obj, true);
mutex_unlock(&dev->srtuct_mutex);
}
return ret;
-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] drm/i915: Added write-enable pte bit support
From: Akash Goel
This adds support for a write-enable bit in the entry of GTT.
This is handled via a read-only flag in the GEM buffer object which
is then used to see how to set the bit when writing the GTT entries.
Currently by default the Batch buffer & Ring buffers are marked as read only.
v2: Moved the pte override code for read-only bit to 'byt_pte_encode'. (Chris)
Fixed the issue of leaving 'gt_old_ro' as unused. (Chris)
v3: Removed the 'gt_old_ro' field, now setting RO bit only for Ring
Buffers(Daniel).
v4: Added a new 'flags' parameter to all the pte(gen6) encode & insert_entries
functions,
in lieu of overloading the cache_level enum (Daniel).
v5: Removed the superfluous VLV check & changed the definition location of
PTE_READ_ONLY flag (Imre)
Reviewed-by: Imre Deak
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 48 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 5 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
4 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64d520f..7e4c272 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1661,6 +1661,12 @@ struct drm_i915_gem_object {
unsigned int pin_display:1;
/*
+* Is the object to be mapped as read-only to the GPU
+* Only honoured if hardware has relevant pte bit
+*/
+ unsigned long gt_ro:1;
+
+ /*
* Is the GPU currently using a fence to access this buffer,
*/
unsigned int pending_fenced_gpu_access:1;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7f226fa..a4153ee 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -116,7 +116,7 @@ static inline gen8_ppgtt_pde_t gen8_pde_encode(struct
drm_device *dev,
static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
enum i915_cache_level level,
-bool valid)
+bool valid, u32 unused)
{
gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
pte |= GEN6_PTE_ADDR_ENCODE(addr);
@@ -138,7 +138,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
enum i915_cache_level level,
-bool valid)
+bool valid, u32 unused)
{
gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
pte |= GEN6_PTE_ADDR_ENCODE(addr);
@@ -162,7 +162,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
static gen6_gtt_pte_t byt_pte_encode(dma_addr_t addr,
enum i915_cache_level level,
-bool valid)
+bool valid, u32 flags)
{
gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
pte |= GEN6_PTE_ADDR_ENCODE(addr);
@@ -170,7 +170,8 @@ static gen6_gtt_pte_t byt_pte_encode(dma_addr_t addr,
/* Mark the page as writeable. Other platforms don't have a
* setting for read-only/writable, so this matches that behavior.
*/
- pte |= BYT_PTE_WRITEABLE;
+ if (!(flags & PTE_READ_ONLY))
+ pte |= BYT_PTE_WRITEABLE;
if (level != I915_CACHE_NONE)
pte |= BYT_PTE_SNOOPED_BY_CPU_CACHES;
@@ -180,7 +181,7 @@ static gen6_gtt_pte_t byt_pte_encode(dma_addr_t addr,
static gen6_gtt_pte_t hsw_pte_encode(dma_addr_t addr,
enum i915_cache_level level,
-bool valid)
+bool valid, u32 unused)
{
gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
pte |= HSW_PTE_ADDR_ENCODE(addr);
@@ -193,7 +194,7 @@ static gen6_gtt_pte_t hsw_pte_encode(dma_addr_t addr,
static gen6_gtt_pte_t iris_pte_encode(dma_addr_t addr,
enum i915_cache_level level,
- bool valid)
+ bool valid, u32 unused)
{
gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
pte |= HSW_PTE_ADDR_ENCODE(addr);
@@ -307,7 +308,7 @@ static void gen8_ppgtt_clear_range(struct
i915_address_space *vm,
static void gen8_ppgtt_insert_entries(struct i915_address_space *vm,
struct sg_table *pages,
uint64_t start,
- enum i915_cache_level cache_level)
+ enum i915_cache_level cache_level, u32
unused)
{
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
@@ -645,7 +646,7 @@ static void gen6_dump_p
Re: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable for valleyview platform.
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, June 16, 2014 4:18 PM
> To: Wang, Quanxian; Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable
> for valleyview platform.
>
> On Mon, 16 Jun 2014, "Wang, Quanxian" wrote:
> >> -Original Message-
> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> >> Sent: Friday, June 13, 2014 5:12 PM
> >> To: Daniel Vetter; Wang, Quanxian
> >> Cc: intel-gfx@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not
> >> reliable for valleyview platform.
> >>
> >> On Fri, 13 Jun 2014, Daniel Vetter wrote:
> >> > On Fri, Jun 13, 2014 at 02:52:04PM +0800, Quanxian Wang wrote:
> >> >> DP connector will be disconnected after chvt to another console
> >> >> for
> >> >> 10 minutes or more on valleyview platform VTC1010.
> >> >
> >> > This needs _much_ more detail, really.
> >> >
> >> > Also it smells like we work around a sink issue, which means the
> >> > correct quirk is to use some sink id (like OUI), _not_ the platform.
> >> > Since this way you break all DP1.1+ stuff on vlv and if someone
> >> > puts this panel onto a different platform it still doesn't work.
> >>
> >> Furthermore you should end up in this code path *only* if you have a
> >> DP branch device. This shouldn't happen for eDP or native DP
> >> displays. Please confirm what kind of setup you're experiencing issues
> with.
> >>
> >> Frankly I wouldn't be surpised if we do have issues with branch
> >> devices, but this is not the fix.
> > [Wang, Quanxian] Any idea how to do it? Currently in VTC1010 device,
> > we use native DP to connect HDMI monitor.(DP2HDMI) This case will
> happen.
>
> So it's an active adapter?
[Wang, Quanxian] yes.
>
> Please send full dmesg from early booth with drm.debug=0xe module
> parameter set, exhibiting the problem.
[Wang, Quanxian] I will send the dmesg log soon. If open drm.debug=0xe, irq log
will overwrite all the dmesg output. I will have some change to get the
complete log for you. Just wait for a while.
After checking with hardware spec, I have some comment for registers of Display
Port
In i915_reg.h, I found we use PCB_DP_x(address 0xe4100+??, control, data...) to
do the communication and check what the SINK_COUNT. (I found it was defined in
Ivybridge spec 2012)
The process focus on South Display Engine to do the communication.
But in valleyview spec(2014), I don't find 0xe4110, and only 0x64100+xxx for
north display engine are available. (DPx_AUX_CH_CTL series defined in
i915_reg.h)
Question: Is the something changed for that after valleyview or
haswell(2013-2014)?
Thanks
>
> BR,
> Jani.
>
>
>
>
>
>
>
>
> >>
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> >
> >> > Or I completely don't understand this at all.
> >> >
> >> > Also, such a patch needs a full spec quote or a w/a citation or
> >> > something solid if it's a more generic issue.
> >> > -Daniel
> >> >>
> >> >> Signed-off-by: Quanxian Wang
> >> >> ---
> >> >> drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> >> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >> >> b/drivers/gpu/drm/i915/intel_dp.c index 2688f6d..0d127a5 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> >> @@ -2942,6 +2942,7 @@ intel_dp_check_link_status(struct intel_dp
> >> >> *intel_dp) static enum drm_connector_status
> >> >> intel_dp_detect_dpcd(struct intel_dp *intel_dp) {
> >> >> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
> >> >> uint8_t *dpcd = intel_dp->dpcd;
> >> >> uint8_t type;
> >> >>
> >> >> @@ -2953,7 +2954,8 @@ intel_dp_detect_dpcd(struct intel_dp
> *intel_dp)
> >> >> return connector_status_connected;
> >> >>
> >> >> /* If we're HPD-aware, SINK_COUNT changes dynamically */
> >> >> - if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> >> >> + if (!IS_VALLEYVIEW(dev) &&
> >> >> + intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> >> >> intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
> >> >> uint8_t reg;
> >> >> if (!intel_dp_aux_native_read_retry(intel_dp,
> >> DP_SINK_COUNT,
> >> >> --
> >> >> 1.8.1.2
> >> >>
> >> >> ___
> >> >> Intel-gfx mailing list
> >> >> Intel-gfx@lists.freedesktop.org
> >> >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >> >
> >> > --
> >> > Daniel Vetter
> >> > Software Engineer, Intel Corporation
> >> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >> > ___
> >> > Intel-gfx mailing list
> >> > Intel-gfx@lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >>
> >> --
> >> Jani Nikula, Intel Open Source Technology Center
>
> --
> Jani Nikula, Intel Open Source T
Re: [Intel-gfx] [PATCH 08/15] drm/i915: Don't try to disable psr harder from the work item
Now I'm wondering about the psr_updated you removed and without this disabling at this point if you alternate to fbcon you might miss most of screen updates if not all... On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter wrote: > It's disabled already except when we've raced. > > Cc: Rodrigo Vivi > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_dp.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > b/drivers/gpu/drm/i915/intel_dp.c > index 10bcc052df4b..3e0861be9c5d 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1876,9 +1876,7 @@ static void intel_edp_psr_work(struct work_struct > *work) > container_of(work, typeof(*dev_priv), psr.work.work); > struct intel_dp *intel_dp = dev_priv->psr.enabled; > > - if (!intel_edp_psr_match_conditions(intel_dp)) > - intel_edp_psr_disable(intel_dp); > - else > + if (intel_edp_psr_match_conditions(intel_dp)) > intel_edp_psr_do_enable(intel_dp); > } > > -- > 2.0.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/15] drm/i915: Track the psr dp connector in dev_priv->psr.enabled
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> Trying to fish that one out through looping is a bit a locking
> nightmare. So just set it and use it in the work struct.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> drivers/gpu/drm/i915/intel_dp.c | 21 +++--
> 2 files changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index f5db29428406..759f7c6d1622 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -633,10 +633,11 @@ struct i915_drrs {
> struct intel_connector *connector;
> };
>
> +struct intel_dp;
> struct i915_psr {
> bool sink_support;
> bool source_ok;
> - bool enabled;
> + struct intel_dp *enabled;
> bool active;
> struct delayed_work work;
> };
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index ac1cef459a7b..10bcc052df4b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1826,7 +1826,7 @@ static void intel_edp_psr_do_enable(struct intel_dp
> *intel_dp)
> /* Enable PSR on the host */
> intel_edp_psr_enable_source(intel_dp);
>
> - dev_priv->psr.enabled = true;
> + dev_priv->psr.enabled = intel_dp;
>
I liked this very much...
> dev_priv->psr.active = true;
> }
>
> @@ -1867,26 +1867,19 @@ void intel_edp_psr_disable(struct intel_dp
> *intel_dp)
>EDP_PSR_STATUS_STATE_MASK) == 0, 2000, 10))
> DRM_ERROR("Timed out waiting for PSR Idle State\n");
>
> - dev_priv->psr.enabled = false;
> + dev_priv->psr.enabled = NULL;
> }
>
> static void intel_edp_psr_work(struct work_struct *work)
> {
> struct drm_i915_private *dev_priv =
> container_of(work, typeof(*dev_priv), psr.work.work);
> - struct drm_device *dev = dev_priv->dev;
> - struct intel_encoder *encoder;
> - struct intel_dp *intel_dp = NULL;
> -
> - list_for_each_entry(encoder, &dev->mode_config.encoder_list,
> base.head)
> - if (encoder->type == INTEL_OUTPUT_EDP) {
> - intel_dp = enc_to_intel_dp(&encoder->base);
> + struct intel_dp *intel_dp = dev_priv->psr.enabled;
>
>
but I'm afraid to give NULL to below functions...
Shouldn't we add a if(!intel_dp) return; at least just to be on the safe
side?
- if (!intel_edp_psr_match_conditions(intel_dp))
> - intel_edp_psr_disable(intel_dp);
> - else
> - intel_edp_psr_do_enable(intel_dp);
> - }
> + if (!intel_edp_psr_match_conditions(intel_dp))
> + intel_edp_psr_disable(intel_dp);
> + else
> + intel_edp_psr_do_enable(intel_dp);
> }
>
> static void intel_edp_psr_inactivate(struct drm_device *dev)
> --
> 2.0.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/15] drm/i915: Drop schedule_back from psr_exit
There were more reasons for disabling it on Baytrail... but you are right..
disable sequence should be better for those cases.
Reviewed-by: Rodrigo Vivi
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> It doesn't make sense to never again schedule the work, since by the
> time we might want to re-enable psr the world might have changed and
> we can do it again.
>
> The only exception is when we shut down the pipe, but that's an
> entirely different thing and needs to be handled in psr_disable.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem.c | 6 +++---
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> drivers/gpu/drm/i915/intel_dp.c | 7 +++
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_sprite.c | 2 +-
> 5 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 1794a041c13c..f22b4aabb945 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1395,7 +1395,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev,
> void *data,
> goto unlock;
> }
>
> - intel_edp_psr_exit(dev, true);
> + intel_edp_psr_exit(dev);
>
> /* Try to flush the object off the GPU without holding the lock.
> * We will repeat the flush holding the lock in the normal manner
> @@ -1442,7 +1442,7 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev,
> void *data,
> if (ret)
> return ret;
>
> - intel_edp_psr_exit(dev, true);
> + intel_edp_psr_exit(dev);
>
> obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
> if (&obj->base == NULL) {
> @@ -4240,7 +4240,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void
> *data,
> if (ret)
> return ret;
>
> - intel_edp_psr_exit(dev, true);
> + intel_edp_psr_exit(dev);
>
> obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
> if (&obj->base == NULL) {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c27dadebd0dc..6f2588c95248 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8823,7 +8823,7 @@ void intel_mark_fb_busy(struct drm_i915_gem_object
> *obj,
> struct drm_device *dev = obj->base.dev;
> struct drm_crtc *crtc;
>
> - intel_edp_psr_exit(dev, true);
> + intel_edp_psr_exit(dev);
>
> if (!i915.powersave)
> return;
> @@ -9292,7 +9292,7 @@ static int intel_crtc_page_flip(struct drm_crtc
> *crtc,
> return -ENOMEM;
>
> /* Exit PSR early in page flip */
> - intel_edp_psr_exit(dev, true);
> + intel_edp_psr_exit(dev);
>
> work->event = event;
> work->crtc = crtc;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 4ab4757fb53d..c7d625040e3d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1899,7 +1899,7 @@ static void intel_edp_psr_inactivate(struct
> drm_device *dev)
>& ~EDP_PSR_ENABLE);
> }
>
> -void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back)
> +void intel_edp_psr_exit(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> @@ -1911,9 +1911,8 @@ void intel_edp_psr_exit(struct drm_device *dev, bool
> schedule_back)
> if (dev_priv->psr.active)
> intel_edp_psr_inactivate(dev);
>
> - if (schedule_back)
> - schedule_delayed_work(&dev_priv->psr.work,
> - msecs_to_jiffies(100));
> + schedule_delayed_work(&dev_priv->psr.work,
> + msecs_to_jiffies(100));
> }
>
> void intel_edp_psr_init(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 87e83c315c4b..1d45629a6483 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -829,7 +829,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp);
> void intel_edp_psr_enable(struct intel_dp *intel_dp);
> void intel_edp_psr_disable(struct intel_dp *intel_dp);
> void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate);
> -void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back);
> +void intel_edp_psr_exit(struct drm_device *dev);
> void intel_edp_psr_init(struct drm_device *dev);
>
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 2a211c64ec8d..9038e2ab73c8 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1051,7 +1051,7 @@ intel_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
> mutex_unlock(&dev->struct_mutex);
> }
>
> -
Re: [Intel-gfx] [PATCH 04/15] drm/i915: Run psr_setup unconditionally
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> Due to runtime pm and system s/r we need to restore hw state every
> time we enable a pipe again. Hence trying to avoid that is just
> pointless book-keeping which Rodrigo then tried to work around by
> manually adding psr_setup calls to our resume code.
>
> Much simpler to just remove code instead.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/intel_dp.c | 8
> 2 files changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 64d520f7e8d9..f5db29428406 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -636,7 +636,6 @@ struct i915_drrs {
> struct i915_psr {
> bool sink_support;
> bool source_ok;
> - bool setup_done;
> bool enabled;
> bool active;
> struct delayed_work work;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 8717d3b9667c..4ab4757fb53d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1663,9 +1663,6 @@ static void intel_edp_psr_setup(struct intel_dp
> *intel_dp)
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct edp_vsc_psr psr_vsc;
>
> - if (dev_priv->psr.setup_done)
> - return;
> -
> /* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
> memset(&psr_vsc, 0, sizeof(psr_vsc));
> psr_vsc.sdp_header.HB0 = 0;
> @@ -1677,8 +1674,6 @@ static void intel_edp_psr_setup(struct intel_dp
> *intel_dp)
> /* Avoid continuous PSR exit by masking memup and hpd */
> I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
>EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
> -
> - dev_priv->psr.setup_done = true;
> }
>
> static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
> @@ -1911,9 +1906,6 @@ void intel_edp_psr_exit(struct drm_device *dev, bool
> schedule_back)
> if (!HAS_PSR(dev))
> return;
>
> - if (!dev_priv->psr.setup_done)
> - return;
-
>
I'd add here:
+ if (!dev_priv->psr.enabled)
+ return;
> cancel_delayed_work_sync(&dev_priv->psr.work);
>
> if (dev_priv->psr.active)
> --
> 2.0.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-g
>
with or without it:
Reviewed-by: Rodrigo Vivi
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/15] drm/i915: Ditch intel_edp_psr_update
Reviewed-by: Rodrigo Vivi
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> We have _enable/_disable interfaces now for the modeset sequence and
> intel_edp_psr_exit for workarounds.
>
> The callsites in intel_display.c are all redundant with the modeset
> sequence enable/disable calls in intel_ddi.c. The one in
> intel_sprite.c is real and needs to be switched to psr_exit.
>
> If this breaks anything then we need to augment the enable/disable
> functions accordingly.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 -
> drivers/gpu/drm/i915/intel_dp.c | 13 -
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> drivers/gpu/drm/i915/intel_sprite.c | 2 +-
> 4 files changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a0f4709f9479..c27dadebd0dc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2763,7 +2763,6 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x,
> int y,
>
> mutex_lock(&dev->struct_mutex);
> intel_update_fbc(dev);
> - intel_edp_psr_update(dev);
> mutex_unlock(&dev->struct_mutex);
>
> return 0;
> @@ -3943,7 +3942,6 @@ static void intel_crtc_enable_planes(struct drm_crtc
> *crtc)
>
> mutex_lock(&dev->struct_mutex);
> intel_update_fbc(dev);
> - intel_edp_psr_update(dev);
> mutex_unlock(&dev->struct_mutex);
> }
>
> @@ -4236,7 +4234,6 @@ static void ironlake_crtc_disable(struct drm_crtc
> *crtc)
>
> mutex_lock(&dev->struct_mutex);
> intel_update_fbc(dev);
> - intel_edp_psr_update(dev);
> mutex_unlock(&dev->struct_mutex);
> }
>
> @@ -4284,7 +4281,6 @@ static void haswell_crtc_disable(struct drm_crtc
> *crtc)
>
> mutex_lock(&dev->struct_mutex);
> intel_update_fbc(dev);
> - intel_edp_psr_update(dev);
> mutex_unlock(&dev->struct_mutex);
> }
>
> @@ -4836,7 +4832,6 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
>
> mutex_lock(&dev->struct_mutex);
> intel_update_fbc(dev);
> - intel_edp_psr_update(dev);
> mutex_unlock(&dev->struct_mutex);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 90f6f0a42d15..8717d3b9667c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1875,19 +1875,6 @@ void intel_edp_psr_disable(struct intel_dp
> *intel_dp)
> dev_priv->psr.enabled = false;
> }
>
> -void intel_edp_psr_update(struct drm_device *dev)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
> - if (!HAS_PSR(dev))
> - return;
> -
> - if (!dev_priv->psr.setup_done)
> - return;
> -
> - intel_edp_psr_exit(dev, true);
> -}
> -
> static void intel_edp_psr_work(struct work_struct *work)
> {
> struct drm_i915_private *dev_priv =
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0081f79efad4..87e83c315c4b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -828,7 +828,6 @@ void intel_edp_panel_on(struct intel_dp *intel_dp);
> void intel_edp_panel_off(struct intel_dp *intel_dp);
> void intel_edp_psr_enable(struct intel_dp *intel_dp);
> void intel_edp_psr_disable(struct intel_dp *intel_dp);
> -void intel_edp_psr_update(struct drm_device *dev);
> void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate);
> void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back);
> void intel_edp_psr_init(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 404335d53a89..2a211c64ec8d 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1051,7 +1051,7 @@ intel_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
> mutex_unlock(&dev->struct_mutex);
> }
>
> - intel_edp_psr_update(dev);
> + intel_edp_psr_exit(dev, true);
>
> return 0;
> }
> --
> 2.0.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/15] drm/i915: Drop unecessary complexity from psr_inactivate
Reviewed-by: Rodrigo Vivi
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> It's not needed and further more will get in the way of a sane
> locking scheme - psr_exit _can't_ take modeset locks due to lock
> inversion, and at least once dp mst hits the connector list
> is no longer static.
>
> But since we track all state in dev_priv->psr there is no need
> at all.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_dp.c | 24 +++-
> 1 file changed, 3 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 190df701edd5..90f6f0a42d15 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1910,29 +1910,11 @@ static void intel_edp_psr_work(struct work_struct
> *work)
> static void intel_edp_psr_inactivate(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_connector *connector;
> - struct intel_encoder *encoder;
> - struct intel_crtc *intel_crtc;
> - struct intel_dp *intel_dp = NULL;
> -
> - list_for_each_entry(connector, &dev->mode_config.connector_list,
> - base.head) {
>
> - if (connector->base.dpms != DRM_MODE_DPMS_ON)
> - continue;
> -
> - encoder = to_intel_encoder(connector->base.encoder);
> - if (encoder->type == INTEL_OUTPUT_EDP) {
> + dev_priv->psr.active = false;
>
> - intel_dp = enc_to_intel_dp(&encoder->base);
> - intel_crtc = to_intel_crtc(encoder->base.crtc);
> -
> - dev_priv->psr.active = false;
> -
> - I915_WRITE(EDP_PSR_CTL(dev),
> I915_READ(EDP_PSR_CTL(dev))
> - & ~EDP_PSR_ENABLE);
> - }
> - }
> + I915_WRITE(EDP_PSR_CTL(dev), I915_READ(EDP_PSR_CTL(dev))
> + & ~EDP_PSR_ENABLE);
> }
>
> void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back)
> --
> 2.0.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/15] drm/i915: Add missing statics to recent psr functions
Reviewed-by: Rodrigo Vivi
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_dp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index b6b26407f11b..190df701edd5 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1888,7 +1888,7 @@ void intel_edp_psr_update(struct drm_device *dev)
> intel_edp_psr_exit(dev, true);
> }
>
> -void intel_edp_psr_work(struct work_struct *work)
> +static void intel_edp_psr_work(struct work_struct *work)
> {
> struct drm_i915_private *dev_priv =
> container_of(work, typeof(*dev_priv), psr.work.work);
> @@ -1907,7 +1907,7 @@ void intel_edp_psr_work(struct work_struct *work)
> }
> }
>
> -void intel_edp_psr_inactivate(struct drm_device *dev)
> +static void intel_edp_psr_inactivate(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_connector *connector;
> --
> 2.0.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 maintainer-tools] frob-patch-rank: A little script to batch renaming patch files
The "usage" text should explain it all. I found, in my quilt series
handling endeavours, that I wanted to be able to shift the prefix
numbers of a patch series.
v2: Use heredoc for usage string, fix second example, use mv -i (Jani)
v3: Don't use a fancy read for usage() (Jani)
Collect the files to rename in a first pass, or the renaming process
can interfere with listing the next files to rename
Signed-off-by: Damien Lespiau
---
frob-patch-rank | 59 +
1 file changed, 59 insertions(+)
create mode 100755 frob-patch-rank
diff --git a/frob-patch-rank b/frob-patch-rank
new file mode 100755
index 000..c791f8d
--- /dev/null
+++ b/frob-patch-rank
@@ -0,0 +1,59 @@
+#!/bin/sh
+set -e
+
+script=$(basename $0)
+
+function usage() {
+ cat << EOU
+Usage: $script start end expr
+
+ Frob patches.
+
+ This tiny script renames "git format-patch" patches by executing 'expr'
+ on the number that prefix the patch file, but only if the patch file name
+ starts with a number in ['start','end'].
+
+Examples:
+ $ ls *patch
+ 0008-Super-patch.patch
+ 0009-Mega-patch.patch
+ $ $script 8 9 -7
+ $ ls *patch
+ 0001-Super-patch.patch
+ 0002-Mega-patch.patch
+
+ $ ls *patch
+ 0117-Super-patch.patch
+ 0118-Mega-patch.patch
+ $ $script 117 118 +900 -17
+ $ ls *patch
+ 1000-Super-patch.patch
+ 1001-Mega-patch.patch
+EOU
+}
+
+[ $# -ge 3 ] || {
+ usage
+ exit 1
+}
+
+start=$1
+end=$2
+shift 2
+op=$*
+
+for i in $(seq $start $end); do
+ prefix=$(printf "%04d" $i)
+ files="$files $(ls $prefix-*.patch)"
+done
+
+for f in $files; do
+ prefix=${f:0:4}
+ base=${f#$prefix-}
+
+ rank=$((10#$prefix))# don't interpret the leading 0 as base 8
+ ((n=$rank $op))
+
+ new_prefix=$(printf "%04d" $n)
+ mv $prefix-$base $new_prefix-$base
+done
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/skl: Broaden FBC resolution limit to 4096*4096
On Mon, Jun 16, 2014 at 03:48:18PM -0700, Daisy Sun wrote: > Staring from HSW, the resolution limit of FBC has increased to > 4096*4096 > > Issue: VIZ-2813 > Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac > Signed-off-by: Daisy Sun Reviewed-by: Damien Lespiau -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Broaden FBC resolution limit to 4096x4096
IC. I started working from BDW FBC, did not check all the gens thoroughly:-) Sent out a version 2 just now. - Daisy On 6/16/2014 2:49 PM, Daniel Vetter wrote: On Mon, Jun 16, 2014 at 10:41 PM, Sun, Daisy wrote: Yes, the change starts from HSW. I'll update the patch. what's the "rant" I need to insert? I was not in the list a year ago:), having some trouble find the email as reference. Any archives I can look into? No rant to insert for you ;-) That was a placeholder in my mail, instead of boring people with all the details. Iirc that was to the internal mailing list, and could be older than a year even. Essentially there's a bunch of constraints about pixel depth and pfit usage on recent platforms that we don't quite check correctly. Your patch update to check for gen >= 8 || IS_HASWELL is perfectly fine as-is. -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/skl: Broaden FBC resolution limit to 4096*4096
Staring from HSW, the resolution limit of FBC has increased to
4096*4096
Issue: VIZ-2813
Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
Signed-off-by: Daisy Sun
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2780280..39f7b79 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -530,7 +530,10 @@ void intel_update_fbc(struct drm_device *dev)
goto out_disable;
}
- if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
+ if (INTEL_INFO(dev)->gen >= 8 || IS_HASWELL(dev)) {
+ max_width = 4096;
+ max_height = 4096;
+ } else if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
max_width = 4096;
max_height = 2048;
} else {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Fixed the review issues for pm_rc6_residency IGT case
On Mon, 16 Jun 2014 23:55:24 +0200 Daniel Vetter wrote: > On Mon, Jun 16, 2014 at 10:38 PM, Jesse Barnes > wrote: > > On Mon, 16 Jun 2014 11:43:30 -0700 > > Ben Widawsky wrote: > > > >> Hi Wendy. Daniel has reverted your original commit here: > >> commit 35554a1bcaaea55c1cfa88c0176c58d2fb3b8013 > >> Author: Daniel Vetter > >> Date: Tue Jun 10 11:05:16 2014 +0200 > >> > >> Revert "Add rc6_residency_counter subtest" > >> > >> Note that I absolutely do not agree with the decision to revert your > >> patch as was stated in the commit message. I am not sure how Daniel got > >> the impression that I thought this was "in order." > >> > >> Can you please resubmit the patch based on the latest intel-gpu-tools? > > > > I also made that clear when Daniel and I discussed it. I simply don't > > understand why a revert was necessary, especially given that we had an > > incremental patch to address many of the comments. Was the test > > breaking i-g-t runs (i.e. preventing tests from running)? Was it > > somehow crashing and causing false reports? > > Ok, I've reverted the revert since people are too unhappy with it. Fine, but that doesn't address why we needed the revert in the first place. Until we have some clear explanation of that and some criteria, this will just happen all over again down the road. So, what is revert-worthy in i-g-t? Open review items? Requests for change? False test failures? False test passes? Crashing tests? I'd vote for the latter 3 myself; did this fall into any of those categories? Thanks, -- Jesse Barnes, 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] Fixed the review issues for pm_rc6_residency IGT case
On Mon, Jun 09, 2014 at 04:36:47PM +0800, Wendy Wang wrote:
> Why need add rc6_residency_counter subtest case:
> RC6 feature support residency counter,from power consumption aspect,
> the counter closer to 1,the better.If the counter is < 0.9, the residency
> is not good and will impact power consumption value, if the counter is > 1,
> sysfs file is inaccurate.
>
> Attach the test result message:
> root@x-bdw05:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests#
> ./pm_rc6_residency
> IGT-Version: 1.6-g9a70e29 (x86_64) (Linux:
> 3.15.0-rc7_drm-intel-nightly_0a37b5_20140604+ x86_64)
> Subtest rc6-residency-check: SUCCESS
> This machine doesn't support rc6pp
> This machine doesn't support rc6p
> The residency counter : 0.987000
> This machine entry rc6 state.
> Subtest rc6-residency-counter: SUCCESS
>
> root@x-bdw05:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests#
> ./pm_rc6_residency --run-subtest rc6-residency-counter
> IGT-Version: 1.6-g9a70e29 (x86_64) (Linux:
> 3.15.0-rc7_drm-intel-nightly_0a37b5_20140604+ x86_64)
> This machine doesn't support rc6pp
> This machine doesn't support rc6p
> The residency counter : 0.987000
> This machine entry rc6 state.
> Subtest rc6-residency-counter: SUCCESS
>
> root@x-bdw05:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests#
> ./pm_rc6_residency --run-subtest rc6-residency-check
> IGT-Version: 1.6-g9a70e29 (x86_64) (Linux:
> 3.15.0-rc7_drm-intel-nightly_0a37b5_20140604+ x86_64)
> Subtest rc6-residency-check: SUCCESS
>
> root@x-bdw05:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests#
> ./pm_rc6_residency --list
> rc6-residency-check
> rc6-residency-counter
>
> Run as non-root
> [haha@x-pk home]$ ./pm_rc6_residency
> IGT-Version: 1.6-g18d2130 (x86_64) (Linux:
> 3.13.0-rc3_drm-intel-nightly_639e4d_20131210+ x86_64)
> No intel gpu found
> Subtest rc6-residency-check: SKIP
> Subtest rc6-residency-counter: SKIP
>
> Run on non-intel platform
> [root@x-pk5 home]# ./pm_rc6_residency
> IGT-Version: 1.6-g18d2130 (x86_64) (Linux:
> 3.13.0-rc3_drm-intel-nightly_639e4d_20131210+ x86_64)
> Test requirement not met in function read_rc6_residency, file
> pm_rc6_residency.c:77:
> Last errno: 2, No such file or directory
> Test requirement: (!(file))
> Subtest rc6-residency-check: SKIP
> Subtest rc6-residency-counter: SKIP
>
> Signed-off-by: Wendy Wang
Patch applied, thanks.
-Daniel
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index e4c23b3..214c055 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -72,6 +72,7 @@ TESTS_progs_M = \
> pm_lpsp \
> pm_rpm \
> pm_rps \
> + pm_rc6_residency \
> prime_self_import \
> template \
> $(NULL)
> @@ -138,7 +139,6 @@ TESTS_progs = \
> kms_sink_crc_basic \
> kms_fence_pin_leak \
> pm_psr \
> - pm_rc6_residency \
> prime_udl \
> $(NULL)
>
> diff --git a/tests/pm_rc6_residency.c b/tests/pm_rc6_residency.c
> index 550e3ad..d364369 100644
> --- a/tests/pm_rc6_residency.c
> +++ b/tests/pm_rc6_residency.c
> @@ -38,7 +38,6 @@
> #define SLEEP_DURATION 3000 // in milliseconds
> #define RC6_FUDGE 900 // in milliseconds
>
> -
> static unsigned int readit(const char *path)
> {
> unsigned int ret;
> @@ -60,6 +59,7 @@ static unsigned int readit(const char *path)
>
> static void read_rc6_residency( int value[], const char
> *name_of_rc6_residency[])
> {
> + unsigned int i;
> const int device = drm_get_card();
> char *path ;
> int ret;
> @@ -72,32 +72,33 @@ static void read_rc6_residency( int value[], const char
> *name_of_rc6_residency[]
> ret = asprintf(&path, "/sys/class/drm/card%d/power/rc6_enable", device);
> igt_assert(ret != -1);
>
> - file = fopen(path, "r");//open
> + file = fopen(path, "r");
> igt_require(file);
>
> /* claim success if no rc6 enabled. */
> if (readit(path) == 0)
> igt_success();
>
> - for(unsigned int i = 0; i < 6; i++)
> + for(i = 0; i < 6; i++)
> {
> if(i == 3)
> sleep(SLEEP_DURATION / 1000);
> - ret = asprintf(&path,
> "/sys/class/drm/card%d/power/%s_residency_ms",device,name_of_rc6_residency[i
> % 3] );
> + ret = asprintf(&path,
> "/sys/class/drm/card%d/power/%s_residency_ms",device,name_of_rc6_residency[i
> % 3]);
> igt_assert(ret != -1);
> value[i] = readit(path);
> }
> free(path);
> }
>
> -static void rc6_residency_counter(int value[],const char *
> name_of_rc6_residency[])
> +static void rc6_residency_counter(int value[],const char
> *name_of_rc6_residency[])
> {
> + int flag;
> unsigned int flag_counter,flag_support;
> - double counter_result = 0;
> + double counter_result = 0;
> flag_counter = 0;
> flag_support = 0;
>
> - for(int flag = NUMBER_OF_RC6_RESIDENCY-1; flag >= 0 ; flag --)
> + for(flag = NUMBER_OF_RC6_RESIDENCY-1; flag >= 0; flag
Re: [Intel-gfx] [PATCH] Fixed the review issues for pm_rc6_residency IGT case
On Mon, Jun 16, 2014 at 10:38 PM, Jesse Barnes wrote: > On Mon, 16 Jun 2014 11:43:30 -0700 > Ben Widawsky wrote: > >> Hi Wendy. Daniel has reverted your original commit here: >> commit 35554a1bcaaea55c1cfa88c0176c58d2fb3b8013 >> Author: Daniel Vetter >> Date: Tue Jun 10 11:05:16 2014 +0200 >> >> Revert "Add rc6_residency_counter subtest" >> >> Note that I absolutely do not agree with the decision to revert your >> patch as was stated in the commit message. I am not sure how Daniel got >> the impression that I thought this was "in order." >> >> Can you please resubmit the patch based on the latest intel-gpu-tools? > > I also made that clear when Daniel and I discussed it. I simply don't > understand why a revert was necessary, especially given that we had an > incremental patch to address many of the comments. Was the test > breaking i-g-t runs (i.e. preventing tests from running)? Was it > somehow crashing and causing false reports? Ok, I've reverted the revert since people are too unhappy with it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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/bdw: Broaden FBC resolution limit to 4096x4096
On Mon, Jun 16, 2014 at 10:41 PM, Sun, Daisy wrote: > Yes, the change starts from HSW. I'll update the patch. > what's the "rant" I need to insert? I was not in the list a year ago:), > having some trouble find the email as reference. > Any archives I can look into? No rant to insert for you ;-) That was a placeholder in my mail, instead of boring people with all the details. Iirc that was to the internal mailing list, and could be older than a year even. Essentially there's a bunch of constraints about pixel depth and pfit usage on recent platforms that we don't quite check correctly. Your patch update to check for gen >= 8 || IS_HASWELL is perfectly fine as-is. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.16-rc1: drm:intel_dp_start_link_train *ERROR* too many full retries, give up
On Mon, Jun 16, 2014 at 10:08 PM, Oliver Hartkopp wrote: > Hey all, > > with my Debian unstable the upgrade from 3.15 to 3.16-rc1 failed with this > fancy > [drm:intel_dp_start_link_train *ERROR* too many full retries, give up] > message loop. This message in dmesg and > lightdm/XFCE4 doesn't start anymore (it tries several times but fails always). xfce not starting shouldn't be related. Are you sure xfce isn't starting and that it's not just a black screen, but otherwise working X? Please attach complete dmesg with drm.debug=0xe added to your kernel cmdline and Xorg.log. Thanks, Daniel > Hm - I just found this stuff in my stock Debian Kernel too: > 3.14-1-686-pae #1 SMP Debian 3.14.5-1 (2014-06-05) i686 GNU/Linux > > > [6.461232] [drm:intel_dp_start_link_train] *ERROR* too many full retries, > give up > [6.873772] dell_wmi: Received unknown WMI event (0x11) > [6.884336] Console: switching to colour frame buffer device 240x67 > [6.948511] i915 :00:02.0: fb0: inteldrmfb frame buffer device > [6.948513] i915 :00:02.0: registered panic notifier > > [7.430429] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on > minor 0 > > But at least it starts with the 3.14 (any the latest 3.15). > > I have a Intel(R) Core(TM) i7 CPU M 640 @ 2.80GHz with Intel HD graphics. > > Any idea? > > Regards, > Oliver -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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/bdw: Broaden FBC resolution limit to 4096x4096
Yes, the change starts from HSW. I'll update the patch.
what's the "rant" I need to insert? I was not in the list a year ago:),
having some trouble find the email as reference.
Any archives I can look into?
On 6/16/2014 11:15 AM, Daniel Vetter wrote:
On Mon, Jun 16, 2014 at 06:11:45PM +0100, Damien Lespiau wrote:
On Mon, Jun 16, 2014 at 05:52:12PM +0100, Damien Lespiau wrote:
From: Daisy Sun
Staring from BDW, the resolution limit of FBC has increased to
4096x4096>
Issue: APDEV-2935
Otc-Tracker: VIZ-3826
Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
Signed-off-by: Daisy Sun
Reviewed-by: Damien Lespiau
Iirc 4kx4k is allowed on hsw already, albeit with the lower 2k lines being
uncompressed. Please double-check bspec and update the patch.
Also: Please insert rant here that I've written a mail a year ago about
the piles of little issues in our fbc feature checking.
-Daniel
--
Damien
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0b088fe..8cc60fc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -529,7 +529,10 @@ void intel_update_fbc(struct drm_device *dev)
goto out_disable;
}
- if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
+ if (INTEL_INFO(dev)->gen >= 8) {
+ max_width = 4096;
+ max_height = 4096;
+ } else if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
max_width = 4096;
max_height = 2048;
} else {
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/15] Accurate frontbuffer tracking and psr conversion
On Mon, Jun 16, 2014 at 9:37 PM, Chris Wilson wrote: >> - Try to integrate hw gtt write tracking logic. Note that current psr code >> doesn't rely on this - I've killed the X-tiled checks completely. > > Also probably not worth it. In the normal sporadic use, we can rely on > the GTT being flushed as required. > > Note, that the tracking as proposed will unfortunately get fbcon wrong > after it is touched by X. I think however there is some merit in > improving how we handle fbcon here. Where would that go wrong? After every set_par we do a set_to_gtt_domain, I've hoped that would be good enough to get fbcon into shape and make sure the fbcon fb is in the right domain (i.e. permanently invalidated) again? Or does fbcon not do a set_par when X drops the vt back into text mode? I didn't check that ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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] Fixed the review issues for pm_rc6_residency IGT case
On Mon, 16 Jun 2014 11:43:30 -0700 Ben Widawsky wrote: > Hi Wendy. Daniel has reverted your original commit here: > commit 35554a1bcaaea55c1cfa88c0176c58d2fb3b8013 > Author: Daniel Vetter > Date: Tue Jun 10 11:05:16 2014 +0200 > > Revert "Add rc6_residency_counter subtest" > > Note that I absolutely do not agree with the decision to revert your > patch as was stated in the commit message. I am not sure how Daniel got > the impression that I thought this was "in order." > > Can you please resubmit the patch based on the latest intel-gpu-tools? I also made that clear when Daniel and I discussed it. I simply don't understand why a revert was necessary, especially given that we had an incremental patch to address many of the comments. Was the test breaking i-g-t runs (i.e. preventing tests from running)? Was it somehow crashing and causing false reports? -- Jesse Barnes, 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] drm/i915/bdw: BDW Software Turbo
BDW supports GT C0 residency reporting in constant time unit. Driver calculates
GT utilization based on C0 residency and adjusts RP frequency up/down
accordingly.
Signed-off-by: Daisy Sun
---
drivers/gpu/drm/i915/i915_drv.h | 17
drivers/gpu/drm/i915/i915_irq.c | 10 +++
drivers/gpu/drm/i915/i915_reg.h | 4 +
drivers/gpu/drm/i915/intel_display.c | 2 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 148 +--
6 files changed, 158 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6b0e174..3a52e84 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -880,6 +880,19 @@ struct vlv_s0ix_state {
u32 clock_gate_dis2;
};
+struct intel_rps_bdw_cal {
+ u32 it_threshold_pct; /* interrupt, in percentage */
+ u32 eval_interval; /* evaluation interval, in us */
+ u32 last_ts;
+ u32 last_c0;
+ bool is_up;
+};
+
+struct intel_rps_bdw_turbo {
+ struct intel_rps_bdw_cal up;
+ struct intel_rps_bdw_cal down;
+};
+
struct intel_gen6_power_mgmt {
/* work and pm_iir are protected by dev_priv->irq_lock */
struct work_struct work;
@@ -910,6 +923,9 @@ struct intel_gen6_power_mgmt {
bool enabled;
struct delayed_work delayed_resume_work;
+ bool is_bdw_sw_turbo; /* Switch of BDW software turbo */
+ struct intel_rps_bdw_turbo sw_turbo;/* Calculate RP interrupt
timing */
+
/*
* Protects RPS/RC6 register access and PCU communication.
* Must be taken after struct_mutex if nested.
@@ -2579,6 +2595,7 @@ extern void intel_disable_fbc(struct drm_device *dev);
extern bool ironlake_set_drps(struct drm_device *dev, u8 val);
extern void intel_init_pch_refclk(struct drm_device *dev);
extern void gen6_set_rps(struct drm_device *dev, u8 val);
+extern void bdw_software_turbo(struct drm_device *dev);
extern void valleyview_set_rps(struct drm_device *dev, u8 val);
extern int valleyview_rps_max_freq(struct drm_i915_private *dev_priv);
extern int valleyview_rps_min_freq(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b10fbde..9ad1e93 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1530,6 +1530,16 @@ static void i9xx_pipe_crc_irq_handler(struct drm_device
*dev, enum pipe pipe)
res1, res2);
}
+void gen8_flip_interrupt(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (!dev_priv->rps.is_bdw_sw_turbo)
+ return;
+
+ bdw_software_turbo(dev);
+}
+
/* The RPS events need forcewake, so we add them to a work queue and mask their
* IMR bits until the work is done. Other interrupts can be processed without
* the work queue. */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 122ed3f..d929f3b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5240,6 +5240,10 @@ enum punit_power_well {
#define GEN8_UCGCTL6 0x9430
#define GEN8_SDEUNIT_CLOCK_GATE_DISABLE (1<<14)
+#define TIMESTAMP_CTR 0x44070
+#define FREQ_1_28_US(us) (((us) * 100) >> 7)
+#define MCHBAR_PCU_C0 (MCHBAR_MIRROR_BASE_SNB + 0x5960)
+
#define GEN6_GFXPAUSE 0xA000
#define GEN6_RPNSWREQ 0xA008
#define GEN6_TURBO_DISABLE (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 767ca96..2a45617 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9176,6 +9176,8 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
unsigned long flags;
int ret;
+ gen8_flip_interrupt(dev);
+
/* Can't change pixel format via MI display flips. */
if (fb->pixel_format != crtc->primary->fb->pixel_format)
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index acfc5c8..b8f375e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -948,6 +948,7 @@ void ironlake_teardown_rc6(struct drm_device *dev);
void gen6_update_ring_freq(struct drm_device *dev);
void gen6_rps_idle(struct drm_i915_private *dev_priv);
void gen6_rps_boost(struct drm_i915_private *dev_priv);
+void gen8_flip_interrupt(struct drm_device *dev);
void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
void intel_runtime_pm_get(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7699d7a..880522d 100644
--- a/drivers/gpu/drm/i915/in
Re: [Intel-gfx] [PATCH v4] drm/i915: Added write-enable pte bit support
Hi Akash,
On Mon, 2014-06-09 at 08:36 +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> This adds support for a write-enable bit in the entry of GTT.
> This is handled via a read-only flag in the GEM buffer object which
> is then used to see how to set the bit when writing the GTT entries.
> Currently by default the Batch buffer & Ring buffers are marked as read only.
>
> v2: Moved the pte override code for read-only bit to 'byt_pte_encode'. (Chris)
> Fixed the issue of leaving 'gt_old_ro' as unused. (Chris)
>
> v3: Removed the 'gt_old_ro' field, now setting RO bit only for Ring
> Buffers(Daniel).
>
> v4: Added a new 'flags' parameter to all the pte(gen6) encode &
> insert_entries functions,
> in lieu of overloading the cache_level enum (Daniel).
>
> Signed-off-by: Akash Goel
> ---
> drivers/gpu/drm/i915/i915_drv.h | 6 +
> drivers/gpu/drm/i915/i915_gem_gtt.c | 48
> -
> drivers/gpu/drm/i915/i915_gem_gtt.h | 5 ++--
> drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
> 4 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 506386e..dc18aee 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1658,6 +1658,12 @@ struct drm_i915_gem_object {
> unsigned int pin_display:1;
>
> /*
> + * Is the object to be mapped as read-only to the GPU
> + * Only honoured if hardware has relevant pte bit
> + */
> + unsigned long gt_ro:1;
> +
> + /*
>* Is the GPU currently using a fence to access this buffer,
>*/
> unsigned int pending_fenced_gpu_access:1;
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 8b3cde7..221ea49 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -110,7 +110,7 @@ static inline gen8_ppgtt_pde_t gen8_pde_encode(struct
> drm_device *dev,
>
> static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
>enum i915_cache_level level,
> - bool valid)
> + bool valid, u32 unused)
> {
> gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
> pte |= GEN6_PTE_ADDR_ENCODE(addr);
> @@ -132,7 +132,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
>
> static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
>enum i915_cache_level level,
> - bool valid)
> + bool valid, u32 unused)
> {
> gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
> pte |= GEN6_PTE_ADDR_ENCODE(addr);
> @@ -156,7 +156,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
>
> static gen6_gtt_pte_t byt_pte_encode(dma_addr_t addr,
>enum i915_cache_level level,
> - bool valid)
> + bool valid, u32 flags)
> {
> gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
> pte |= GEN6_PTE_ADDR_ENCODE(addr);
> @@ -164,7 +164,8 @@ static gen6_gtt_pte_t byt_pte_encode(dma_addr_t addr,
> /* Mark the page as writeable. Other platforms don't have a
>* setting for read-only/writable, so this matches that behavior.
>*/
> - pte |= BYT_PTE_WRITEABLE;
> + if (!(flags & PTE_READ_ONLY))
> + pte |= BYT_PTE_WRITEABLE;
>
> if (level != I915_CACHE_NONE)
> pte |= BYT_PTE_SNOOPED_BY_CPU_CACHES;
> @@ -174,7 +175,7 @@ static gen6_gtt_pte_t byt_pte_encode(dma_addr_t addr,
>
> static gen6_gtt_pte_t hsw_pte_encode(dma_addr_t addr,
>enum i915_cache_level level,
> - bool valid)
> + bool valid, u32 unused)
> {
> gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
> pte |= HSW_PTE_ADDR_ENCODE(addr);
> @@ -187,7 +188,7 @@ static gen6_gtt_pte_t hsw_pte_encode(dma_addr_t addr,
>
> static gen6_gtt_pte_t iris_pte_encode(dma_addr_t addr,
> enum i915_cache_level level,
> - bool valid)
> + bool valid, u32 unused)
> {
> gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
> pte |= HSW_PTE_ADDR_ENCODE(addr);
> @@ -301,7 +302,7 @@ static void gen8_ppgtt_clear_range(struct
> i915_address_space *vm,
> static void gen8_ppgtt_insert_entries(struct i915_address_space *vm,
> struct sg_table *pages,
> uint64_t start,
> - enum i915_cache_level cache_level)
> + enum i915_cache_level cache_level, u32
> unused)
> {
> struct i915_hw_ppgtt *ppgtt =
> container
Re: [Intel-gfx] [PATCH 00/15] Accurate frontbuffer tracking and psr conversion
On Mon, Jun 16, 2014 at 07:51:20PM +0200, Daniel Vetter wrote: > Note that currently the gtt tracking has a bit a gap: We never exit it. Bunch > of > fixes are possible: > > - Wire up the core dirty_fb ioctl to flush framebuffers. This is used by > generic > userspace to flush dummy buffers, which in our case means gtt mmaps. So maps > perfectly. > > - Do a delayed gtt pte teardown and force-flush. Probably too ugly to care > really. I don't consider that to be a gap, but accurate reflection of how userspace is using the GTT. The most important usecase in this regard is perhaps how the scanout is permenantly mapped for writing after a terminal GPU hang. Trying to be smart in the kernel is more likely to upset userspace, especially in this last resort effort at keeping everything running. > - Try to integrate hw gtt write tracking logic. Note that current psr code > doesn't rely on this - I've killed the X-tiled checks completely. Also probably not worth it. In the normal sporadic use, we can rely on the GTT being flushed as required. Note, that the tracking as proposed will unfortunately get fbcon wrong after it is touched by X. I think however there is some merit in improving how we handle fbcon here. -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] VGA1 output no longer detected on IBM R31/i830
Am 16.06.2014 19:59, schrieb Daniel Vetter: On Sun, Jun 15, 2014 at 09:38:49PM +0200, Thomas Richter wrote: Thanks for keeping the repository, but that's not a solution, at least not for most of the remaining users of old hardware. Repositories with patches are normal procedures until those patches are properly tested and reviewed. I don't just merge random stuff. Ok then, but what else can I do to get them tested or reviewed, except the testing I can do on the two machines I have? About which time frame are we talking, approximately? The (many possible) approaches to the watermark patch are now over a year somewhere waiting in the testing-and-review pipeline, and that is only one minor problem of the many problems of the 830/845 support. Thanks for your support, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't take fp 0/1 selector into account for pll state
On Mon, Jun 16, 2014 at 09:20:35PM +0300, Ville Syrjälä wrote: > On Mon, Jun 16, 2014 at 08:01:26PM +0200, Daniel Vetter wrote: > > On Mon, Jun 16, 2014 at 11:32:39AM +0300, Ville Syrjälä wrote: > > > On Sun, Jun 15, 2014 at 02:55:42PM +0200, Daniel Vetter wrote: > > > > It changes at runtime and so should be ignored for pipe state checks. > > > > Note that we don't yet read out the full DRRS state, so there's some > > > > gaps. Bu DRRS is also not yet enabled for LVDS by default. > > > > > > > > Cc: Aleks > > > > Reported-by: Aleks > > > > Cc: sta...@vger.kernel.org > > > > Signed-off-by: Daniel Vetter > > > > --- > > > > drivers/gpu/drm/i915/intel_display.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > > b/drivers/gpu/drm/i915/intel_display.c > > > > index ba1d9aac3958..1ccf660e67d9 100644 > > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > > @@ -8549,6 +8549,9 @@ static void i9xx_crtc_clock_get(struct intel_crtc > > > > *crtc, > > > > else > > > > fp = pipe_config->dpll_hw_state.fp1; > > > > > > > > + /* We don't compute the FPA 0/1 selector. */ > > > > + dpll &= ~DISPLAY_RATE_SELECT_FPA1; > > > > + > > > > > > But we still compute port_clock based on the currently active FPA > > > register. Won't that make the clock checks fail as well? > > > > Well yeah, but that should get solved as part of the DRRS stuff I think. > > Imo ignore the frequency selector for the dpll state is the right thing. > > > > DRRS with state readout is still in-flux and unsolved wrt fastbooting. > > > > Should I add a caveat to the commit message that this isn't everything or > > not worth it as-is? > > Well, after a better look I see that this patch does absolutely nothing. > You already picked the FPA register before you cleared the select bit. > So you need to clear it a bit earlier in this function, or even go as > far as clearing it when we read out the dpll state. Maybe the latter > is better in case we want to start checking the entire dpll state? Hm, I guess I hide in shame and will leave this topic to people with clue ;-) Thanks for looking at this anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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] Fixed the review issues for pm_rc6_residency IGT case
Hi Wendy. Daniel has reverted your original commit here: commit 35554a1bcaaea55c1cfa88c0176c58d2fb3b8013 Author: Daniel Vetter Date: Tue Jun 10 11:05:16 2014 +0200 Revert "Add rc6_residency_counter subtest" Note that I absolutely do not agree with the decision to revert your patch as was stated in the commit message. I am not sure how Daniel got the impression that I thought this was "in order." Can you please resubmit the patch based on the latest intel-gpu-tools? -- Ben Widawsky, 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: Don't take fp 0/1 selector into account for pll state
On Mon, Jun 16, 2014 at 08:01:26PM +0200, Daniel Vetter wrote: > On Mon, Jun 16, 2014 at 11:32:39AM +0300, Ville Syrjälä wrote: > > On Sun, Jun 15, 2014 at 02:55:42PM +0200, Daniel Vetter wrote: > > > It changes at runtime and so should be ignored for pipe state checks. > > > Note that we don't yet read out the full DRRS state, so there's some > > > gaps. Bu DRRS is also not yet enabled for LVDS by default. > > > > > > Cc: Aleks > > > Reported-by: Aleks > > > Cc: sta...@vger.kernel.org > > > Signed-off-by: Daniel Vetter > > > --- > > > drivers/gpu/drm/i915/intel_display.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > b/drivers/gpu/drm/i915/intel_display.c > > > index ba1d9aac3958..1ccf660e67d9 100644 > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > @@ -8549,6 +8549,9 @@ static void i9xx_crtc_clock_get(struct intel_crtc > > > *crtc, > > > else > > > fp = pipe_config->dpll_hw_state.fp1; > > > > > > + /* We don't compute the FPA 0/1 selector. */ > > > + dpll &= ~DISPLAY_RATE_SELECT_FPA1; > > > + > > > > But we still compute port_clock based on the currently active FPA > > register. Won't that make the clock checks fail as well? > > Well yeah, but that should get solved as part of the DRRS stuff I think. > Imo ignore the frequency selector for the dpll state is the right thing. > > DRRS with state readout is still in-flux and unsolved wrt fastbooting. > > Should I add a caveat to the commit message that this isn't everything or > not worth it as-is? Well, after a better look I see that this patch does absolutely nothing. You already picked the FPA register before you cleared the select bit. So you need to clear it a bit earlier in this function, or even go as far as clearing it when we read out the dpll state. Maybe the latter is better in case we want to start checking the entire dpll state? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Handle disabled primary plane in debugfs i915_display_info (v2)
On Mon, Jun 16, 2014 at 10:12:55AM -0700, Matt Roper wrote: > Now that the primary plane can be disabled independently of the CRTC, > the debugfs code needs to be updated to recognize when the primary plane > is disabled and not try to return information about the primary plane's > framebuffer. > > This change prevents a NULL dereference when reading i915_display_info > with a disabled primary plane. > > v2: Replace a seq_printf() with seq_puts() (suggested by Damien) > > Signed-off-by: Matt Roper Queued for -next, thanks for the patch. -Daniel > --- > drivers/gpu/drm/i915/i915_debugfs.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index a8b8140..8057fd4 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -2220,9 +2220,12 @@ static void intel_crtc_info(struct seq_file *m, struct > intel_crtc *intel_crtc) > struct drm_crtc *crtc = &intel_crtc->base; > struct intel_encoder *intel_encoder; > > - seq_printf(m, "\tfb: %d, pos: %dx%d, size: %dx%d\n", > -crtc->primary->fb->base.id, crtc->x, crtc->y, > -crtc->primary->fb->width, crtc->primary->fb->height); > + if (crtc->primary->fb) > + seq_printf(m, "\tfb: %d, pos: %dx%d, size: %dx%d\n", > +crtc->primary->fb->base.id, crtc->x, crtc->y, > +crtc->primary->fb->width, crtc->primary->fb->height); > + else > + seq_puts(m, "\tprimary plane disabled\n"); > for_each_encoder_on_crtc(dev, crtc, intel_encoder) > intel_encoder_info(m, intel_crtc, intel_encoder); > } > -- > 1.8.5.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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/bdw: Broaden FBC resolution limit to 4096x4096
On Mon, Jun 16, 2014 at 06:11:45PM +0100, Damien Lespiau wrote:
> On Mon, Jun 16, 2014 at 05:52:12PM +0100, Damien Lespiau wrote:
> > From: Daisy Sun
> >
> > Staring from BDW, the resolution limit of FBC has increased to
> > 4096x4096>
> >
> > Issue: APDEV-2935
> > Otc-Tracker: VIZ-3826
> > Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
> > Signed-off-by: Daisy Sun
>
> Reviewed-by: Damien Lespiau
Iirc 4kx4k is allowed on hsw already, albeit with the lower 2k lines being
uncompressed. Please double-check bspec and update the patch.
Also: Please insert rant here that I've written a mail a year ago about
the piles of little issues in our fbc feature checking.
-Daniel
>
> --
> Damien
>
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 0b088fe..8cc60fc 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -529,7 +529,10 @@ void intel_update_fbc(struct drm_device *dev)
> > goto out_disable;
> > }
> >
> > - if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> > + if (INTEL_INFO(dev)->gen >= 8) {
> > + max_width = 4096;
> > + max_height = 4096;
> > + } else if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> > max_width = 4096;
> > max_height = 2048;
> > } else {
> > --
> > 1.8.3.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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 i-g-t] lib: add missing includes to headers
On Mon, Jun 16, 2014 at 04:21:35PM +0100, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
Both igt patches merged, thanks.
-Daniel
> ---
> lib/debug.h | 3 +++
> lib/gen7_render.h | 2 ++
> lib/igt_aux.h | 1 +
> lib/igt_fb.h | 2 ++
> lib/igt_kms.h | 1 +
> lib/rendercopy.h | 3 +++
> 6 files changed, 12 insertions(+)
>
> diff --git a/lib/debug.h b/lib/debug.h
> index af9cf39..ca4b31e 100644
> --- a/lib/debug.h
> +++ b/lib/debug.h
> @@ -28,6 +28,9 @@
> #ifndef _DEBUG_H_
> #define _DEBUG_H_
>
> +#include
> +#include
> +
> #define DEBUG_PROTOCOL_VERSION 1
> #define COMMUNICATION_OFFSET 0xc00
> #define COMMUNICATION_QWORD 0xc0
> diff --git a/lib/gen7_render.h b/lib/gen7_render.h
> index 992d839..7a6dc05 100644
> --- a/lib/gen7_render.h
> +++ b/lib/gen7_render.h
> @@ -1,6 +1,8 @@
> #ifndef GEN7_RENDER_H
> #define GEN7_RENDER_H
>
> +#include
> +
> #define INTEL_MASK(high, low) (((1 << ((high) - (low) + 1)) - 1) << (low))
>
> #define GEN7_3D(Pipeline,Opcode,Subopcode) ((3 << 29) | \
> diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> index db0dea8..a90d8d9 100644
> --- a/lib/igt_aux.h
> +++ b/lib/igt_aux.h
> @@ -29,6 +29,7 @@
> #define IGT_AUX_H
>
> #include
> +#include
>
> /* auxialiary igt helpers from igt_aux.c */
> /* generally useful helpers */
> diff --git a/lib/igt_fb.h b/lib/igt_fb.h
> index c6558bf..6d030e6 100644
> --- a/lib/igt_fb.h
> +++ b/lib/igt_fb.h
> @@ -36,6 +36,8 @@ typedef struct _cairo_surface cairo_surface_t;
> typedef struct _cairo cairo_t;
> #endif
>
> +#include
> +#include
> #include
> #include
>
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 17bf0a2..7d015b4 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -30,6 +30,7 @@
>
> #include
> #include
> +#include
>
> #include
>
> diff --git a/lib/rendercopy.h b/lib/rendercopy.h
> index bb9051e..20619d6 100644
> --- a/lib/rendercopy.h
> +++ b/lib/rendercopy.h
> @@ -1,3 +1,6 @@
> +#include "intel_batchbuffer.h"
> +
> +
> static inline void emit_vertex_2s(struct intel_batchbuffer *batch,
> int16_t x, int16_t y)
> {
> --
> 1.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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: Ack interrupts before handling them (GEN5 - GEN7)
On Mon, Jun 16, 2014 at 01:07:37PM +0100, Chris Wilson wrote: > On Mon, Jun 16, 2014 at 12:30:26PM +0100, oscar.ma...@intel.com wrote: > > From: Oscar Mateo > > > > Otherwise, we might receive a new interrupt before we have time to ack the > > first > > one, eventually missing it. > > Without a atomic xchg operation with mmio space, we merely reduce the > window. This is even more apparent when you consider how heavyweight > those I915_READ/I915_WRITE are. I think the correct description of the race is: If we handle the irq source before resetting the irq signal bit then there's a race between the handling and the resetting where a new interrupt can get lost. This is important where interrupts can happen quickly and have some status (like seqno or other completion number) attached. If we on the other hand handle the irq (i.e. read the seqno/cookie) after clearing the interrupt we might get a spurious interrupt occasionally (i.e. one for a cookie value we've seen already), but we'll never miss the interrupt for a cookie update. This fix has the potential to explain tons of the missed interrupt fun we've seen in the past years all over the place (render, rps, ...). -Daniel > > > According to BSPec, the right order should be: > > > > 1 - Disable Master Interrupt Control. > > 2 - Find the source(s) of the interrupt and clear the Interrupt Identity > > bits (IIR) > > 4 - Process the interrupt(s) that had bits set in the IIRs. > > 5 - Re-enable Master Interrupt Control. > > > > We maintain the "disable SDE interrupts when handling" hack since > > apparently it works. > > > > Spotted by Bob Beckett . > > > > Signed-off-by: Oscar Mateo > > I'd like the changelog slightly clarified, and the notes here would be > useful in the code as well to describe the theory of operation in > handling IRQ. > -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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/vlv: Ack interrupts before handling them (VLV)
On Mon, Jun 16, 2014 at 04:19:30PM +0300, Imre Deak wrote:
> On Mon, 2014-06-16 at 12:30 +0100, oscar.ma...@intel.com wrote:
> > From: Oscar Mateo
> >
> > Otherwise, we might receive a new interrupt before we have time to
> > ack the first one, eventually missing it.
> >
> > Notice that, before clearing a port-sourced interrupt in the IIR, the
> > corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
> > cleared.
> >
> > Spotted by Bob Beckett .
> >
> > Signed-off-by: Oscar Mateo
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 61
> > +++--
> > 1 file changed, 35 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 4439e2d..9d381cc 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1813,26 +1813,28 @@ static void i9xx_hpd_irq_handler(struct drm_device
> > *dev)
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
> >
> > - if (IS_G4X(dev)) {
> > - u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
> > + if (hotplug_status) {
> > + I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
> > + /*
> > +* Make sure hotplug status is cleared before we clear IIR, or
> > else we
> > +* may miss hotplug events.
> > +*/
> > + POSTING_READ(PORT_HOTPLUG_STAT);
> >
> > - intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_g4x);
> > - } else {
> > - u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
> > + if (IS_G4X(dev)) {
> > + u32 hotplug_trigger = hotplug_status &
> > HOTPLUG_INT_STATUS_G4X;
> >
> > - intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_i915);
> > - }
> > + intel_hpd_irq_handler(dev, hotplug_trigger,
> > hpd_status_g4x);
> > + } else {
> > + u32 hotplug_trigger = hotplug_status &
> > HOTPLUG_INT_STATUS_I915;
> >
> > - if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) &&
> > - hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
> > - dp_aux_irq_handler(dev);
> > + intel_hpd_irq_handler(dev, hotplug_trigger,
> > hpd_status_i915);
> > + }
> >
> > - I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
> > - /*
> > -* Make sure hotplug status is cleared before we clear IIR, or else we
> > -* may miss hotplug events.
> > -*/
> > - POSTING_READ(PORT_HOTPLUG_STAT);
> > + if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) &&
> > + hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
> > + dp_aux_irq_handler(dev);
> > + }
> > }
> >
> > static irqreturn_t valleyview_irq_handler(int irq, void *arg)
> > @@ -1843,29 +1845,36 @@ static irqreturn_t valleyview_irq_handler(int irq,
> > void *arg)
> > irqreturn_t ret = IRQ_NONE;
> >
> > while (true) {
> > - iir = I915_READ(VLV_IIR);
> > gt_iir = I915_READ(GTIIR);
> > pm_iir = I915_READ(GEN6_PMIIR);
> > + iir = I915_READ(VLV_IIR);
> >
> > if (gt_iir == 0 && pm_iir == 0 && iir == 0)
> > goto out;
> >
> > - ret = IRQ_HANDLED;
> > + if (gt_iir)
> > + I915_WRITE(GTIIR, gt_iir);
> >
> > - snb_gt_irq_handler(dev, dev_priv, gt_iir);
> > + if (pm_iir)
> > + I915_WRITE(GEN6_PMIIR, pm_iir);
> >
> > - valleyview_pipestat_irq_handler(dev, iir);
> > + if (iir) {
> > + /* Consume port. Then clear IIR or we'll miss events */
> > + if (iir & I915_DISPLAY_PORT_INTERRUPT)
> > + i9xx_hpd_irq_handler(dev);
> > + I915_WRITE(VLV_IIR, iir);
> > + }
> >
> > - /* Consume port. Then clear IIR or we'll miss events */
> > - if (iir & I915_DISPLAY_PORT_INTERRUPT)
> > - i9xx_hpd_irq_handler(dev);
> > + ret = IRQ_HANDLED;
> > +
> > + if (gt_iir)
> > + snb_gt_irq_handler(dev, dev_priv, gt_iir);
> >
> > if (pm_iir)
> > gen6_rps_irq_handler(dev_priv, pm_iir);
> >
> > - I915_WRITE(GTIIR, gt_iir);
> > - I915_WRITE(GEN6_PMIIR, pm_iir);
> > - I915_WRITE(VLV_IIR, iir);
> > + if (iir)
> > + valleyview_pipestat_irq_handler(dev, iir);
>
> Afaik the pipe underrun flag handled in
> valleyview_pipestat_irq_handler() is not signaled in IIR, although bspec
> is rather unclear about this.
Pipe underrun isn't signalling the top-level interrupt and we also can't
mask it in any way. Hence the funny logic.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH] intel-gpu-tools: remove the --cmd option from gem_seqno_wrap
On Mon, Jun 16, 2014 at 03:32:35PM +0300, Mika Kuoppala wrote:
> tim.g...@intel.com writes:
>
> > From: Tim Gore
> >
> > gem_seqno_wrap was not being built on Android because it uses
> > wordexp which is not in Bionic.
> > After discussion with Mika Kuoppala (the test author) it seems
> > that wordexp was used to implement the --cmd option that was
> > really only intended for use during development of the test and
> > is no longer needed. So I have removed support for this option
> > and enabled this test for Android.
> >
> > Signed-off-by: Tim Gore
>
> Reviewed-by: Mika Kuoppala
Merged, thanks.
-Daniel
>
> > ---
> > tests/Android.mk | 1 -
> > tests/gem_seqno_wrap.c | 77
> > ++
> > 2 files changed, 3 insertions(+), 75 deletions(-)
> >
> > diff --git a/tests/Android.mk b/tests/Android.mk
> > index 9db6625..f085d35 100644
> > --- a/tests/Android.mk
> > +++ b/tests/Android.mk
> > @@ -28,7 +28,6 @@ endef
> >
> > # some tests still do not build under android
> > skip_tests_list :=
> > -skip_tests_list += gem_seqno_wrap
> > skip_tests_list += testdisplay# needs glib.h
> > skip_tests_list += pm_rpm
> >
> > diff --git a/tests/gem_seqno_wrap.c b/tests/gem_seqno_wrap.c
> > index fa38f1f..ad4f839 100644
> > --- a/tests/gem_seqno_wrap.c
> > +++ b/tests/gem_seqno_wrap.c
> > @@ -38,7 +38,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -62,7 +61,6 @@ static struct intel_batchbuffer *batch_3d;
> > struct option_struct {
> > int rounds;
> > int background;
> > - char cmd[1024];
> > int timeout;
> > int dontwrap;
> > int prewrap_space;
> > @@ -281,64 +279,6 @@ static void run_sync_test(int num_buffers, bool verify)
> > close(fd);
> > }
> >
> > -static int run_cmd(char *s)
> > -{
> > - int pid;
> > - int r = -1;
> > - int status = 0;
> > - wordexp_t wexp;
> > - int i;
> > - r = wordexp(s, &wexp, 0);
> > - if (r != 0) {
> > - printf("can't parse %s\n", s);
> > - return r;
> > - }
> > -
> > - for(i = 0; i < wexp.we_wordc; i++)
> > - printf("argv[%d] = %s\n", i, wexp.we_wordv[i]);
> > -
> > - pid = fork();
> > -
> > - if (pid == 0) {
> > - char path[PATH_MAX];
> > - char full_path[PATH_MAX];
> > -
> > - if (getcwd(path, PATH_MAX) == NULL)
> > - perror("getcwd");
> > -
> > - igt_assert(snprintf(full_path, PATH_MAX, "%s/%s", path,
> > wexp.we_wordv[0]) > 0);
> > -
> > - r = execv(full_path, wexp.we_wordv);
> > - if (r == -1)
> > - perror("execv failed");
> > - } else {
> > - int waitcount = options.timeout;
> > -
> > - while(waitcount-- > 0) {
> > - r = waitpid(pid, &status, WNOHANG);
> > - if (r == pid) {
> > - if(WIFEXITED(status)) {
> > - if (WEXITSTATUS(status))
> > - fprintf(stderr,
> > - "child returned with %d\n",
> > - WEXITSTATUS(status));
> > - return WEXITSTATUS(status);
> > - }
> > - } else if (r != 0) {
> > - perror("waitpid");
> > - return -errno;
> > - }
> > -
> > - sleep(3);
> > - }
> > -
> > - kill(pid, SIGKILL);
> > - return -ETIMEDOUT;
> > - }
> > -
> > - return r;
> > -}
> > -
> > static const char *dfs_base = "/sys/kernel/debug/dri";
> > static const char *dfs_entry = "i915_next_seqno";
> >
> > @@ -415,7 +355,7 @@ static int write_seqno(uint32_t seqno)
> > int fh;
> > char buf[32];
> > int r;
> > - uint32_t rb;
> > + uint32_t rb = -1;
> >
> > if (options.dontwrap)
> > return 0;
> > @@ -461,10 +401,7 @@ static uint32_t calc_prewrap_val(void)
> >
> > static void run_test(void)
> > {
> > - if (strnlen(options.cmd, sizeof(options.cmd)) > 0)
> > - igt_assert(run_cmd(options.cmd) == 0);
> > - else
> > - run_sync_test(options.buffers, true);
> > + run_sync_test(options.buffers, true);
> > }
> >
> > static void preset_run_once(void)
> > @@ -521,7 +458,6 @@ static void print_usage(const char *s)
> > printf("%s: [OPTION]...\n", s);
> > printf("where options are:\n");
> > printf("-b --background run in background inducing wraps\n");
> > - printf("-c --cmd=cmdstringuse cmdstring to cross wrap\n");
> > printf("-n --rounds=num run num times across wrap boundary, 0
> > == forever\n");
> > printf("-t --timeout=sec set timeout to wait for testrun to
> > sec seconds\n");
> > printf("-d --dontwrap don't wr
Re: [Intel-gfx] [PATCH] drm/i915: Fix comment about our plane remapping on gen2/3
On Mon, Jun 16, 2014 at 10:55:00AM +0300, Ville Syrjälä wrote: > On Mon, Jun 16, 2014 at 02:08:26AM +0200, Daniel Vetter wrote: > > Spotted while crawling around in the area. > > > > Signed-off-by: Daniel Vetter > > Reviewed-by: Ville Syrjälä Queued for -next, thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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: Don't take fp 0/1 selector into account for pll state
On Mon, Jun 16, 2014 at 11:32:39AM +0300, Ville Syrjälä wrote:
> On Sun, Jun 15, 2014 at 02:55:42PM +0200, Daniel Vetter wrote:
> > It changes at runtime and so should be ignored for pipe state checks.
> > Note that we don't yet read out the full DRRS state, so there's some
> > gaps. Bu DRRS is also not yet enabled for LVDS by default.
> >
> > Cc: Aleks
> > Reported-by: Aleks
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index ba1d9aac3958..1ccf660e67d9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8549,6 +8549,9 @@ static void i9xx_crtc_clock_get(struct intel_crtc
> > *crtc,
> > else
> > fp = pipe_config->dpll_hw_state.fp1;
> >
> > + /* We don't compute the FPA 0/1 selector. */
> > + dpll &= ~DISPLAY_RATE_SELECT_FPA1;
> > +
>
> But we still compute port_clock based on the currently active FPA
> register. Won't that make the clock checks fail as well?
Well yeah, but that should get solved as part of the DRRS stuff I think.
Imo ignore the frequency selector for the dpll state is the right thing.
DRRS with state readout is still in-flux and unsolved wrt fastbooting.
Should I add a caveat to the commit message that this isn't everything or
not worth it as-is?
-Daniel
>
> > clock.m1 = (fp & FP_M1_DIV_MASK) >> FP_M1_DIV_SHIFT;
> > if (IS_PINEVIEW(dev)) {
> > clock.n = ffs((fp & FP_N_PINEVIEW_DIV_MASK) >> FP_N_DIV_SHIFT)
> > - 1;
> > --
> > 2.0.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] VGA1 output no longer detected on IBM R31/i830
On Sun, Jun 15, 2014 at 09:38:49PM +0200, Thomas Richter wrote: > Am 15.06.2014 14:26, schrieb Ville Syrjälä: > > >We all know nightly is rather broken with 830. Nothing new here. I > >suggest just trying my alm_fixes5 branch. > > Excuse my ignorance, but there is something I do not get. There are patches > that are tested and working. Having them in an off-side repository does not > help users at all, so what stops anyone from either applying these patches > to the kernel, or alternatively removing the 830/845 support from the > current i915 driver and create a separate i830 driver from the current > sources with the patches applied? > > The linux i830 kernel support should be working, and not in the broken state > it is right now - the current state of the affair is not very helpful. > > Thanks for keeping the repository, but that's not a solution, at least not > for most of the remaining users of old hardware. Repositories with patches are normal procedures until those patches are properly tested and reviewed. I don't just merge random stuff. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: update BDW DDI buffer translations
On Sat, Jun 14, 2014 at 10:11:51AM +0100, Damien Lespiau wrote:
> On Fri, Jun 13, 2014 at 06:45:40PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Two BSpec updates changed the recommended values for BDW eDP and DP
> > DDI buffer translations. Now the signal levels also match the HSW signal
> > levels, which simplify things a little bit.
> >
> > It seems some DP sinks don't work properly without voltage level 0 and
> > pre-emphasis level 3, so this patch may fix some bugs on
> > panels/monitors that happen on BDW but not on HSW.
> >
> > Signed-off-by: Paulo Zanoni
>
> Reviewed-by: Damien Lespiau
Both merged to dinq. We can always apply this to -fixes once we have
confirmation that it actually fixes something seen in the wild.
-Daniel
>
> --
> Damien
>
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 11
> > drivers/gpu/drm/i915/intel_ddi.c | 4 +--
> > drivers/gpu/drm/i915/intel_dp.c | 55
> > +++-
> > 3 files changed, 5 insertions(+), 65 deletions(-)
> >
> > This doesn't fix the "eDP 5GHz 2 lanes doesn't work" bug I can reproduce on
> > my
> > machine if I revert the upstream hack we currently have.
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 9ce017b..e1fb0f2 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5821,7 +5821,6 @@ enum punit_power_well {
> > #define DDI_BUF_CTL_B 0x64100
> > #define DDI_BUF_CTL(port) _PORT(port, DDI_BUF_CTL_A, DDI_BUF_CTL_B)
> > #define DDI_BUF_CTL_ENABLE(1<<31)
> > -/* Haswell */
> > #define DDI_BUF_EMP_400MV_0DB_HSW (0<<24) /* Sel0 */
> > #define DDI_BUF_EMP_400MV_3_5DB_HSW (1<<24) /* Sel1 */
> > #define DDI_BUF_EMP_400MV_6DB_HSW (2<<24) /* Sel2 */
> > @@ -5831,16 +5830,6 @@ enum punit_power_well {
> > #define DDI_BUF_EMP_600MV_6DB_HSW (6<<24) /* Sel6 */
> > #define DDI_BUF_EMP_800MV_0DB_HSW (7<<24) /* Sel7 */
> > #define DDI_BUF_EMP_800MV_3_5DB_HSW (8<<24) /* Sel8 */
> > -/* Broadwell */
> > -#define DDI_BUF_EMP_400MV_0DB_BDW (0<<24) /* Sel0 */
> > -#define DDI_BUF_EMP_400MV_3_5DB_BDW (1<<24) /* Sel1 */
> > -#define DDI_BUF_EMP_400MV_6DB_BDW (2<<24) /* Sel2 */
> > -#define DDI_BUF_EMP_600MV_0DB_BDW (3<<24) /* Sel3 */
> > -#define DDI_BUF_EMP_600MV_3_5DB_BDW (4<<24) /* Sel4 */
> > -#define DDI_BUF_EMP_600MV_6DB_BDW (5<<24) /* Sel5 */
> > -#define DDI_BUF_EMP_800MV_0DB_BDW (6<<24) /* Sel6 */
> > -#define DDI_BUF_EMP_800MV_3_5DB_BDW (7<<24) /* Sel7 */
> > -#define DDI_BUF_EMP_1200MV_0DB_BDW(8<<24) /* Sel8 */
> > #define DDI_BUF_EMP_MASK (0xf<<24)
> > #define DDI_BUF_PORT_REVERSAL (1<<16)
> > #define DDI_BUF_IS_IDLE (1<<7)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index b17b9c7..ded6013 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -76,12 +76,12 @@ static const u32 bdw_ddi_translations_edp[] = {
> > 0x00FF, 0x0012, /* eDP parameters */
> > 0x00EBAFFF, 0x00020011,
> > 0x00C71FFF, 0x0006000F,
> > + 0x00AAAFFF, 0x000E000A,
> > 0x00FF, 0x00020011,
> > 0x00DB6FFF, 0x0005000F,
> > 0x00BEEFFF, 0x000A000C,
> > 0x00FF, 0x0005000F,
> > 0x00DB6FFF, 0x000A000C,
> > - 0x00FF, 0x000A000C,
> > 0x00FF, 0x00140006 /* HDMI parameters 800mV 0dB*/
> > };
> >
> > @@ -89,12 +89,12 @@ static const u32 bdw_ddi_translations_dp[] = {
> > 0x00FF, 0x0007000E, /* DP parameters */
> > 0x00D75FFF, 0x000E000A,
> > 0x00BE, 0x00140006,
> > + 0x80B2CFFF, 0x001B0002,
> > 0x00FF, 0x000E000A,
> > 0x00D75FFF, 0x00180004,
> > 0x80CB2FFF, 0x001B0002,
> > 0x00F7DFFF, 0x00180004,
> > 0x80D75FFF, 0x001B0002,
> > - 0x80FF, 0x001B0002,
> > 0x00FF, 0x00140006 /* HDMI parameters 800mV 0dB*/
> > };
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index b6b2640..dc58044 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2330,7 +2330,7 @@ intel_dp_voltage_max(struct intel_dp *intel_dp)
> > struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > enum port port = dp_to_dig_port(intel_dp)->port;
> >
> > - if (IS_VALLEYVIEW(dev) || IS_BROADWELL(dev))
> > + if (IS_VALLEYVIEW(dev))
> > return DP_TRAIN_VOLTAGE_SWING_1200;
> > else if (IS_GEN7(dev) && port == PORT_A)
> > return DP_TRAIN_VOLTAGE_SWING_800;
> > @@ -2346,18 +2346,7 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp,
> > uint8_t voltage_swing)
> > struct drm_device *
Re: [Intel-gfx] [PATCH 51/53] drm/i915/bdw: Document Logical Rings, LR contexts and Execlists
On Mon, Jun 16, 2014 at 03:24:26PM +, Mateo Lozano, Oscar wrote: > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Friday, June 13, 2014 5:51 PM > > To: Mateo Lozano, Oscar > > Cc: intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH 51/53] drm/i915/bdw: Document Logical > > Rings, LR contexts and Execlists > > > > On Fri, Jun 13, 2014 at 04:38:09PM +0100, oscar.ma...@intel.com wrote: > > > +/** > > > + * intel_execlists_ctx_id() - get the Execlists Context ID > > > + * @ctx_obj: Logical Ring Context backing object. > > > + * > > > + * Do not confuse with ctx->id! Unfortunately we have a name overload > > > + * here: the old context ID we pass to userspace as a handler so that > > > + * they can refer to a context, and the new context ID we pass to the > > > + * ELSP so that the GPU can inform us of the context status via > > > + * interrupts. > > > + * > > > + * Return: 20-bits globally unique context ID. > > > + */ > > > > Use tag for the ctx id we pass around in hw? > > -Chris > > I also tried other names, like "submission id", but it confuses people > when they search for in the BSpec. Maybe changing ctx->id to ctx->tag, > and leaving id for the hardware? I think Chris' idea was to reuse the id from the idr for the hw tag. But I guess that fails because our idr is global. Or I'm totally confused. I'd vote for hw_ctx_id or something. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - 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: Simplify processing of the golden render context state
On Mon, Jun 16, 2014 at 02:40:45PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Rewrite i915_gem_render_state.c for the purposes of clarity and
> > compactness, in the process we can eliminate some dodgy math that did
> > not handle 64bit addresses correctly.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Ville Syrjälä
> > Cc: Damien Lespiau
> > Cc: Mika Kuoppala
>
> Reviewed-by: Mika Kuoppala
Queued for -next, thanks for the patch.
-Daniel
>
> > ---
> > drivers/gpu/drm/i915/i915_gem_render_state.c | 161
> > +++---
> > drivers/gpu/drm/i915/intel_renderstate.h | 2 -
> > drivers/gpu/drm/i915/intel_renderstate_gen6.c | 1 +
> > drivers/gpu/drm/i915/intel_renderstate_gen7.c | 1 +
> > drivers/gpu/drm/i915/intel_renderstate_gen8.c | 1 +
> > 5 files changed, 69 insertions(+), 97 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
> > b/drivers/gpu/drm/i915/i915_gem_render_state.c
> > index 3521f998a178..e60be3f552a6 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_render_state.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
> > @@ -28,64 +28,13 @@
> > #include "i915_drv.h"
> > #include "intel_renderstate.h"
> >
> > -struct i915_render_state {
> > +struct render_state {
> > + const struct intel_renderstate_rodata *rodata;
> > struct drm_i915_gem_object *obj;
> > - unsigned long ggtt_offset;
> > - void *batch;
> > - u32 size;
> > - u32 len;
> > + u64 ggtt_offset;
> > + int gen;
> > };
> >
> > -static struct i915_render_state *render_state_alloc(struct drm_device *dev)
> > -{
> > - struct i915_render_state *so;
> > - struct page *page;
> > - int ret;
> > -
> > - so = kzalloc(sizeof(*so), GFP_KERNEL);
> > - if (!so)
> > - return ERR_PTR(-ENOMEM);
> > -
> > - so->obj = i915_gem_alloc_object(dev, 4096);
> > - if (so->obj == NULL) {
> > - ret = -ENOMEM;
> > - goto free;
> > - }
> > - so->size = 4096;
> > -
> > - ret = i915_gem_obj_ggtt_pin(so->obj, 4096, 0);
> > - if (ret)
> > - goto free_gem;
> > -
> > - BUG_ON(so->obj->pages->nents != 1);
> > - page = sg_page(so->obj->pages->sgl);
> > -
> > - so->batch = kmap(page);
> > - if (!so->batch) {
> > - ret = -ENOMEM;
> > - goto unpin;
> > - }
> > -
> > - so->ggtt_offset = i915_gem_obj_ggtt_offset(so->obj);
> > -
> > - return so;
> > -unpin:
> > - i915_gem_object_ggtt_unpin(so->obj);
> > -free_gem:
> > - drm_gem_object_unreference(&so->obj->base);
> > -free:
> > - kfree(so);
> > - return ERR_PTR(ret);
> > -}
> > -
> > -static void render_state_free(struct i915_render_state *so)
> > -{
> > - kunmap(so->batch);
> > - i915_gem_object_ggtt_unpin(so->obj);
> > - drm_gem_object_unreference(&so->obj->base);
> > - kfree(so);
> > -}
> > -
> > static const struct intel_renderstate_rodata *
> > render_state_get_rodata(struct drm_device *dev, const int gen)
> > {
> > @@ -101,98 +50,120 @@ render_state_get_rodata(struct drm_device *dev, const
> > int gen)
> > return NULL;
> > }
> >
> > -static int render_state_setup(const int gen,
> > - const struct intel_renderstate_rodata *rodata,
> > - struct i915_render_state *so)
> > +static int render_state_init(struct render_state *so, struct drm_device
> > *dev)
> > {
> > - const u64 goffset = i915_gem_obj_ggtt_offset(so->obj);
> > - u32 reloc_index = 0;
> > - u32 * const d = so->batch;
> > - unsigned int i = 0;
> > int ret;
> >
> > - if (!rodata || rodata->batch_items * 4 > so->size)
> > + so->gen = INTEL_INFO(dev)->gen;
> > + so->rodata = render_state_get_rodata(dev, so->gen);
> > + if (so->rodata == NULL)
> > + return 0;
> > +
> > + if (so->rodata->batch_items * 4 > 4096)
> > return -EINVAL;
> >
> > + so->obj = i915_gem_alloc_object(dev, 4096);
> > + if (so->obj == NULL)
> > + return -ENOMEM;
> > +
> > + ret = i915_gem_obj_ggtt_pin(so->obj, 4096, 0);
> > + if (ret)
> > + goto free_gem;
> > +
> > + so->ggtt_offset = i915_gem_obj_ggtt_offset(so->obj);
> > + return 0;
> > +
> > +free_gem:
> > + drm_gem_object_unreference(&so->obj->base);
> > + return ret;
> > +}
> > +
> > +static int render_state_setup(struct render_state *so)
> > +{
> > + const struct intel_renderstate_rodata *rodata = so->rodata;
> > + unsigned int i = 0, reloc_index = 0;
> > + struct page *page;
> > + u32 *d;
> > + int ret;
> > +
> > ret = i915_gem_object_set_to_cpu_domain(so->obj, true);
> > if (ret)
> > return ret;
> >
> > + page = sg_page(so->obj->pages->sgl);
> > + d = kmap(page);
> > +
> > while (i < rodata->batch_items) {
> > u32 s = rodata->batch[i];
> >
> > - if (reloc_index < rodata->reloc_items &&
> > - i * 4 == rodata->reloc[reloc_index]) {
> > -
> > - s += goffset & 0x;
> > -
> > -
Re: [Intel-gfx] [PATCH] drm/i915: Simplify i915_gem_release_all_mmaps()
On Mon, Jun 16, 2014 at 08:57:44AM +0100, Chris Wilson wrote:
> An object can only have an active gtt mapping if it is currently bound
> into the global gtt. Therefore we can simply walk the list of all bound
> objects and check the flag upon those for an active gtt mapping.
>
> From commit 48018a57a8f5900e7e53ffaa0adeb784095accfb
> Author: Paulo Zanoni
> Date: Fri Dec 13 15:22:31 2013 -0200
>
> drm/i915: release the GTT mmaps when going into D3
>
> Also note that the WARN is inappropriate for this function as GPU
> activity is orthogonal to GTT mmap status. Rather it is the caller that
> relies upon this condition and so it should assert that the GPU is idle
> itself.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=80081
> Signed-off-by: Chris Wilson
> Cc: Paulo Zanoni
> Cc: Rodrigo Vivi
> Cc: Daniel Vetter
> Reviewed-by: Paulo Zanoni
> Tested-by: Paulo Zanoni
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 25 +
> 1 file changed, 9 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 1d7893c982a8..f671216031e7 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1862,22 +1862,6 @@ out:
> return ret;
> }
>
> -void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv)
> -{
> - struct i915_vma *vma;
> -
> - /*
> - * Only the global gtt is relevant for gtt memory mappings, so restrict
> - * list traversal to objects bound into the global address space. Note
> - * that the active list should be empty, but better safe than sorry.
> - */
> - WARN_ON(!list_empty(&dev_priv->gtt.base.active_list));
> - list_for_each_entry(vma, &dev_priv->gtt.base.active_list, mm_list)
> - i915_gem_release_mmap(vma->obj);
> - list_for_each_entry(vma, &dev_priv->gtt.base.inactive_list, mm_list)
> - i915_gem_release_mmap(vma->obj);
> -}
> -
> /**
> * i915_gem_release_mmap - remove physical page mappings
> * @obj: obj in question
> @@ -1903,6 +1887,15 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
> obj->fault_mappable = false;
> }
>
> +void
> +i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv)
> +{
> + struct drm_i915_gem_object *obj;
> +
> + list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list)
> + i915_gem_release_mmap(obj);
> +}
> +
> uint32_t
> i915_gem_get_gtt_size(struct drm_device *dev, uint32_t size, int tiling_mode)
> {
> --
> 2.0.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/15] drm/i915: Fix up PSR frontbuffer tracking
I've tried to split this up, but all the changes are so tightly
related that I didn't find a good way to do this without breaking
bisecting. Essentially this completely changes how psr is glued into
the overall driver, and there's not much you can do to soften such a
paradigm change.
- Use frontbuffer tracking bits stuff to separate disable and
re-enable.
- Don't re-check everything in the psr work. We have now accurate
tracking for everything, so no need to check for sprites or tiling
really. Allows us to ditch tons of locks.
- That in turn allows us to properly cancel the work in the disable
function - no more deadlocks.
- Add a check for HSW sprites and force a flush. Apparently the
hardware doesn't forward the flushing when updating the sprite base
address. We can do the same trick everywhere else we have such
issues, e.g. on baytrail with ... everything.
- Don't re-enable psr with a delay in psr_exit. It really must be
turned off forever if we detect a gtt write. At least with the
current frontbuffer render tracking. Userspace can do a busy ioctl
call or no-op pageflip to re-enable psr.
- Drop redundant checks for crtc and crtc->active - now that they're
only called from enable this is guaranteed.
- Fix up the hsw port check. eDP can also happen on port D, but the
issue is exactly that it doesn't work there. So an || check is
wrong.
- We still schedule the psr work with a delay. The frontbuffer
flushing interface mandates that we upload the next full frame, so
need to wait a bit. Once we have single-shot frame uploads we can do
better here.
v2: Don't enable psr initially, rely upon the fb flush of the initial
plane setup for that. Gives us more unified code flow and makes the
crtc enable sequence less a special case.
v3: s/psr_exit/psr_invalidate/ for consistency
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_dp.c | 103 ---
drivers/gpu/drm/i915/intel_drv.h | 5 +-
4 files changed, 66 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 30c2ae3cbab7..ea69925e0df5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -641,6 +641,7 @@ struct i915_psr {
struct intel_dp *enabled;
bool active;
struct delayed_work work;
+ unsigned busy_frontbuffer_bits;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dfdbf2a02844..9cfc6d003f7a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8898,7 +8898,7 @@ void intel_fb_invalidate(struct drm_i915_gem_object *obj,
intel_mark_fb_busy(dev, obj->frontbuffer_bits, ring);
- intel_edp_psr_exit(dev);
+ intel_edp_psr_invalidate(dev, obj->frontbuffer_bits);
}
/**
@@ -8924,7 +8924,7 @@ void intel_frontbuffer_flush(struct drm_device *dev,
intel_mark_fb_busy(dev, frontbuffer_bits, NULL);
- intel_edp_psr_exit(dev);
+ intel_edp_psr_flush(dev, frontbuffer_bits);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 13c3ec7ec451..50477262b76e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1746,8 +1746,6 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc = dig_port->base.base.crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct drm_i915_gem_object *obj =
to_intel_framebuffer(crtc->primary->fb)->obj;
- struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
lockdep_assert_held(&dev_priv->psr.lock);
lockdep_assert_held(&dev->struct_mutex);
@@ -1761,8 +1759,7 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
return false;
}
- if (IS_HASWELL(dev) && (intel_encoder->type != INTEL_OUTPUT_EDP ||
- dig_port->port != PORT_A)) {
+ if (IS_HASWELL(dev) && dig_port->port != PORT_A) {
DRM_DEBUG_KMS("HSW ties PSR to DDI A (eDP)\n");
return false;
}
@@ -1772,34 +1769,10 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
return false;
}
- crtc = dig_port->base.base.crtc;
- if (crtc == NULL) {
- DRM_DEBUG_KMS("crtc not active for PSR\n");
- return false;
- }
-
- intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc_active(crtc)) {
- DRM_DEBUG_KMS("crtc not active for PSR\n");
- return false;
- }
-
- obj = to_intel_framebuffer(crtc->primary->fb)->obj;
- if (obj->tiling_
[Intel-gfx] [PATCH 08/15] drm/i915: Don't try to disable psr harder from the work item
It's disabled already except when we've raced. Cc: Rodrigo Vivi Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_dp.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 10bcc052df4b..3e0861be9c5d 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1876,9 +1876,7 @@ static void intel_edp_psr_work(struct work_struct *work) container_of(work, typeof(*dev_priv), psr.work.work); struct intel_dp *intel_dp = dev_priv->psr.enabled; - if (!intel_edp_psr_match_conditions(intel_dp)) - intel_edp_psr_disable(intel_dp); - else + if (intel_edp_psr_match_conditions(intel_dp)) intel_edp_psr_do_enable(intel_dp); } -- 2.0.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/15] drm/i915: Lock down psr sw/hw state tracking
Make sure we track the sw side (psr.active) correctly and WARN
everywhere it might get out of sync with the hw.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 43 ++---
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3e0861be9c5d..923a9f6991f7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1817,8 +1817,8 @@ static void intel_edp_psr_do_enable(struct intel_dp
*intel_dp)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- if (intel_edp_is_psr_enabled(dev))
- return;
+ WARN_ON(I915_READ(EDP_PSR_CTL(dev)) & EDP_PSR_ENABLE);
+ WARN_ON(dev_priv->psr.active);
/* Enable PSR on the panel */
intel_edp_psr_enable_sink(intel_dp);
@@ -1859,13 +1859,19 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)
if (!dev_priv->psr.enabled)
return;
- I915_WRITE(EDP_PSR_CTL(dev),
- I915_READ(EDP_PSR_CTL(dev)) & ~EDP_PSR_ENABLE);
+ if (dev_priv->psr.active) {
+ I915_WRITE(EDP_PSR_CTL(dev),
+ I915_READ(EDP_PSR_CTL(dev)) & ~EDP_PSR_ENABLE);
+
+ /* Wait till PSR is idle */
+ if (_wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev)) &
+ EDP_PSR_STATUS_STATE_MASK) == 0, 2000, 10))
+ DRM_ERROR("Timed out waiting for PSR Idle State\n");
- /* Wait till PSR is idle */
- if (_wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev)) &
- EDP_PSR_STATUS_STATE_MASK) == 0, 2000, 10))
- DRM_ERROR("Timed out waiting for PSR Idle State\n");
+ dev_priv->psr.active = false;
+ } else {
+ WARN_ON(I915_READ(EDP_PSR_CTL(dev)) & EDP_PSR_ENABLE);
+ }
dev_priv->psr.enabled = NULL;
}
@@ -1880,16 +1886,6 @@ static void intel_edp_psr_work(struct work_struct *work)
intel_edp_psr_do_enable(intel_dp);
}
-static void intel_edp_psr_inactivate(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
- dev_priv->psr.active = false;
-
- I915_WRITE(EDP_PSR_CTL(dev), I915_READ(EDP_PSR_CTL(dev))
- & ~EDP_PSR_ENABLE);
-}
-
void intel_edp_psr_exit(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1899,8 +1895,15 @@ void intel_edp_psr_exit(struct drm_device *dev)
cancel_delayed_work_sync(&dev_priv->psr.work);
- if (dev_priv->psr.active)
- intel_edp_psr_inactivate(dev);
+ if (dev_priv->psr.active) {
+ u32 val = I915_READ(EDP_PSR_CTL(dev));
+
+ WARN_ON(val & EDP_PSR_ENABLE);
+
+ I915_WRITE(EDP_PSR_CTL(dev), val & ~EDP_PSR_ENABLE);
+
+ dev_priv->psr.active = false;
+ }
schedule_delayed_work(&dev_priv->psr.work,
msecs_to_jiffies(100));
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/15] drm/i915: Add a FIXME about drrs/psr interactions
Can't review this right now due to lack of DRRS code.
Cc: Rodrigo Vivi
Cc: Vandana Kannan
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c7d625040e3d..ac1cef459a7b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4121,6 +4121,11 @@ void intel_dp_set_drrs_state(struct drm_device *dev, int
refresh_rate)
return;
}
+ /*
+* FIXME: This needs proper synchronization with psr state. But really
+* hard to tell without seeing the user of this function of this code.
+* Check locking and ordering once that lands.
+*/
if (INTEL_INFO(dev)->gen < 8 && intel_edp_is_psr_enabled(dev)) {
DRM_DEBUG_KMS("DRRS is disabled as PSR is enabled\n");
return;
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/15] drm/i915: Add locking to psr code
It's not really optional to have locking ...
The ugly part is how much locking the psr work needs since it has to
recheck everything. Which is way too much. But we need to ditch the
psr work in it's current form anyway and implement proper frontbuffer
tracking.
The other nasty bit that had to go was the delayed work cancle in
psr_exit. Which means a bunch of races just became a bit more likely,
but mea culpa.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 33 +
3 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a8b81407338a..0e0e6b6bffd1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1973,7 +1973,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "Sink_Support: %s\n", yesno(dev_priv->psr.sink_support));
seq_printf(m, "Source_OK: %s\n", yesno(dev_priv->psr.source_ok));
- seq_printf(m, "Enabled: %s\n", yesno(dev_priv->psr.enabled));
+ seq_printf(m, "Enabled: %s\n", yesno(!!dev_priv->psr.enabled));
seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
enabled = HAS_PSR(dev) &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 759f7c6d1622..3d3f3b1ef9ae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -635,6 +635,7 @@ struct i915_drrs {
struct intel_dp;
struct i915_psr {
+ struct mutex lock;
bool sink_support;
bool source_ok;
struct intel_dp *enabled;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 503809e4e6f3..13c3ec7ec451 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1749,6 +1749,11 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
struct drm_i915_gem_object *obj =
to_intel_framebuffer(crtc->primary->fb)->obj;
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
+ lockdep_assert_held(&dev_priv->psr.lock);
+ lockdep_assert_held(&dev->struct_mutex);
+ WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+ WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
+
dev_priv->psr.source_ok = false;
if (!HAS_PSR(dev)) {
@@ -1819,6 +1824,7 @@ static void intel_edp_psr_do_enable(struct intel_dp
*intel_dp)
WARN_ON(I915_READ(EDP_PSR_CTL(dev)) & EDP_PSR_ENABLE);
WARN_ON(dev_priv->psr.active);
+ lockdep_assert_held(&dev_priv->psr.lock);
/* Enable PSR on the panel */
intel_edp_psr_enable_sink(intel_dp);
@@ -1833,6 +1839,7 @@ static void intel_edp_psr_do_enable(struct intel_dp
*intel_dp)
void intel_edp_psr_enable(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ struct drm_i915_private *dev_priv = dev->dev_private;
if (!HAS_PSR(dev)) {
DRM_DEBUG_KMS("PSR not supported on this platform\n");
@@ -1844,8 +1851,10 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
return;
}
+ mutex_lock(&dev_priv->psr.lock);
if (dev_priv->psr.enabled) {
DRM_DEBUG_KMS("PSR already in use\n");
+ mutex_unlock(&dev_priv->psr.lock);
return;
}
@@ -1854,6 +1863,7 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
if (intel_edp_psr_match_conditions(intel_dp))
intel_edp_psr_do_enable(intel_dp);
+ mutex_unlock(&dev_priv->psr.lock);
}
void intel_edp_psr_disable(struct intel_dp *intel_dp)
@@ -1861,8 +1871,11 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct drm_i915_private *dev_priv = dev->dev_private;
- if (!dev_priv->psr.enabled)
+ mutex_lock(&dev_priv->psr.lock);
+ if (!dev_priv->psr.enabled) {
+ mutex_unlock(&dev_priv->psr.lock);
return;
+ }
if (dev_priv->psr.active) {
I915_WRITE(EDP_PSR_CTL(dev),
@@ -1879,19 +1892,30 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)
}
dev_priv->psr.enabled = NULL;
+ mutex_unlock(&dev_priv->psr.lock);
}
static void intel_edp_psr_work(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), psr.work.work);
+ struct drm_device *dev = dev_priv->dev;
struct intel_dp *intel_dp = dev_priv->psr.enabled;
+ drm_modeset_lock_all(dev);
+ mutex_lock(&dev->struct_mutex);
+ mutex_lock(&dev_priv->psr.lock);
+ intel_dp = dev_priv->psr.enabled;
+
if (!intel_dp)
- return;
+
[Intel-gfx] [PATCH 01/15] drm/i915: Add missing statics to recent psr functions
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b6b26407f11b..190df701edd5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1888,7 +1888,7 @@ void intel_edp_psr_update(struct drm_device *dev)
intel_edp_psr_exit(dev, true);
}
-void intel_edp_psr_work(struct work_struct *work)
+static void intel_edp_psr_work(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), psr.work.work);
@@ -1907,7 +1907,7 @@ void intel_edp_psr_work(struct work_struct *work)
}
}
-void intel_edp_psr_inactivate(struct drm_device *dev)
+static void intel_edp_psr_inactivate(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_connector *connector;
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/15] drm/i915: Use new frontbuffer bits to increase pll clock
The downclocking checks a few more things, so not that simple to
convert. Also, this should get unified with the drrs handling and also
use the locking of that. Otoh the drrs locking is about as hapzardous
as no locking, at least on first sight.
For easier conversion ditch the upclocking on unload - we'll turn off
everything anyway.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 32 ++--
2 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 870ca04e0888..4c3787699cdf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1609,6 +1609,8 @@ struct drm_i915_gem_object_ops {
(1 << (2 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
#define INTEL_FRONTBUFFER_OVERLAY(pipe) \
(1 << (3 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
+#define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
+ (0xf << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
struct drm_i915_gem_object {
struct drm_gem_object base;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 64145aeefe28..b8359f4a6dc4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -76,7 +76,8 @@ static const uint32_t intel_cursor_formats[] = {
#define DIV_ROUND_CLOSEST_ULL(ll, d) \
({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
-static void intel_increase_pllclock(struct drm_crtc *crtc);
+static void intel_increase_pllclock(struct drm_device *dev,
+ enum pipe pipe);
static void intel_crtc_update_cursor(struct drm_crtc *crtc, bool on);
static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
@@ -2585,7 +2586,7 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
if (dev_priv->display.disable_fbc)
dev_priv->display.disable_fbc(dev);
- intel_increase_pllclock(crtc);
+ intel_increase_pllclock(dev, to_intel_crtc(crtc)->pipe);
dev_priv->display.update_primary_plane(crtc, fb, x, y);
@@ -8723,12 +8724,10 @@ struct drm_display_mode *intel_crtc_mode_get(struct
drm_device *dev,
return mode;
}
-static void intel_increase_pllclock(struct drm_crtc *crtc)
+static void intel_increase_pllclock(struct drm_device *dev,
+ enum pipe pipe)
{
- struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int pipe = intel_crtc->pipe;
int dpll_reg = DPLL(pipe);
int dpll;
@@ -8834,21 +8833,19 @@ void intel_mark_fb_busy(struct drm_i915_gem_object *obj,
struct intel_engine_cs *ring)
{
struct drm_device *dev = obj->base.dev;
- struct drm_crtc *crtc;
+ enum pipe pipe;
intel_edp_psr_exit(dev);
if (!i915.powersave)
return;
- for_each_crtc(dev, crtc) {
- if (!crtc->primary->fb)
- continue;
-
- if (to_intel_framebuffer(crtc->primary->fb)->obj != obj)
+ for_each_pipe(pipe) {
+ if (!(obj->frontbuffer_bits &
+ INTEL_FRONTBUFFER_ALL_MASK(pipe)))
continue;
- intel_increase_pllclock(crtc);
+ intel_increase_pllclock(dev, pipe);
if (ring && intel_fbc_enabled(dev))
ring->fbc_dirty = true;
}
@@ -12658,7 +12655,6 @@ void intel_connector_unregister(struct intel_connector
*intel_connector)
void intel_modeset_cleanup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_crtc *crtc;
struct drm_connector *connector;
/*
@@ -12678,14 +12674,6 @@ void intel_modeset_cleanup(struct drm_device *dev)
intel_unregister_dsm_handler();
- for_each_crtc(dev, crtc) {
- /* Skip inactive CRTCs */
- if (!crtc->primary->fb)
- continue;
-
- intel_increase_pllclock(crtc);
- }
-
intel_disable_fbc(dev);
intel_disable_gt_powersave(dev);
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/15] drm/i915: Introduce accurate frontbuffer tracking
So from just a quick look we seem to have enough information to
accurately figure out whether a given gem bo is used as a frontbuffer
and where exactly: We have obj->pin_count as a first check with no
false negatives and only negligible false positives. And then we can
just walk the modeset objects and figure out where exactly a buffer is
used as scanout.
Except that we can't due to locking order: If we already hold
dev->struct_mutex we can't acquire any modeset locks, so could
potential chase freed pointers and other evil stuff.
So we need something else. For that introduce a new set of bits
obj->frontbuffer_bits to track where a buffer object is used. That we
can then chase without grabbing any modeset locks.
Of course the consumers of this (DRRS, PSR, FBC, ...) still need to be
able to do their magic both when called from modeset and from gem
code. But that can be easily achieved by adding locks for these
specific subsystems which always nest within either kms or gem
locking.
This patch just adds the relevant update code to all places.
Note that if we ever support multi-planar scanout targets then we need
one frontbuffer tracking bit per attachment point that we expose to
userspace.
v2:
- Fix more oopsen. Oops.
- WARN if we leak obj->frontbuffer_bits when freeing a gem buffer. Fix
the bugs this brought to light.
- s/update_frontbuffer_bits/update_fb_bits/. More consistent with the
fb tracking functions (fb for gem object, frontbuffer for raw bits).
And the function name was way too long.
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 24
drivers/gpu/drm/i915/i915_gem.c | 19 ++
drivers/gpu/drm/i915/intel_display.c | 72 +++-
drivers/gpu/drm/i915/intel_overlay.c | 11 ++
drivers/gpu/drm/i915/intel_sprite.c | 7
5 files changed, 116 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d3f3b1ef9ae..870ca04e0888 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1592,6 +1592,24 @@ struct drm_i915_gem_object_ops {
void (*release)(struct drm_i915_gem_object *);
};
+/*
+ * Frontbuffer tracking bits. Set in obj->frontbuffer_bits while a gem bo is
+ * considered to be the frontbuffer for the given plane interface-vise. This
+ * doesn't mean that the hw necessarily already scans it out, but that any
+ * rendering (by the cpu or gpu) will land in the frontbuffer eventually.
+ *
+ * We have one bit per pipe and per scanout plane type.
+ */
+#define INTEL_FRONTBUFFER_BITS_PER_PIPE 4
+#define INTEL_FRONTBUFFER_PRIMARY(pipe) \
+ (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+#define INTEL_FRONTBUFFER_CURSOR(pipe) \
+ (1 << (1 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
+#define INTEL_FRONTBUFFER_SPRITE(pipe) \
+ (1 << (2 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
+#define INTEL_FRONTBUFFER_OVERLAY(pipe) \
+ (1 << (3 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
+
struct drm_i915_gem_object {
struct drm_gem_object base;
@@ -1673,6 +1691,8 @@ struct drm_i915_gem_object {
unsigned int has_global_gtt_mapping:1;
unsigned int has_dma_mapping:1;
+ unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS_PER_PIPE;
+
struct sg_table *pages;
int pages_pin_count;
@@ -1719,6 +1739,10 @@ struct drm_i915_gem_object {
};
#define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
+void i915_gem_update_fb_bits(struct drm_i915_gem_object *old,
+struct drm_i915_gem_object *new,
+unsigned frontbuffer_bits);
+
/**
* Request queue structure.
*
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f22b4aabb945..9722991a0d19 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4456,6 +4456,8 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
if (obj->stolen)
i915_gem_object_unpin_pages(obj);
+ WARN_ON(obj->frontbuffer_bits);
+
if (WARN_ON(obj->pages_pin_count))
obj->pages_pin_count = 0;
if (discard_backing_storage(obj))
@@ -5000,6 +5002,23 @@ int i915_gem_open(struct drm_device *dev, struct
drm_file *file)
return ret;
}
+void i915_gem_update_fb_bits(struct drm_i915_gem_object *old,
+struct drm_i915_gem_object *new,
+unsigned frontbuffer_bits)
+{
+ if (old) {
+ WARN_ON(!mutex_is_locked(&old->base.dev->struct_mutex));
+ WARN_ON(!(old->frontbuffer_bits & frontbuffer_bits));
+ old->frontbuffer_bits &= ~frontbuffer_bits;
+ }
+
+ if (new) {
+ WARN_ON(!mutex_is_locked(&new->base.dev->struct_mutex));
+ WARN_ON(new->frontbuffer_bits & frontbuffer_bits
[Intel-gfx] [PATCH 14/15] drm/i915: Track frontbuffer invalidation/flushing
So these are the guts of the new beast. This tracks when a frontbuffer
gets invalidated (due to frontbuffer rendering) and hence should be
constantly scaned out, and when it's flushed again and can be
compressed/one-shot-upload.
Rules for flushing are simple: The frontbuffer needs one more full
upload starting from the next vblank. Which means that the flushing
can _only_ be called once the frontbuffer update has been latched.
But this poses a problem for pageflips: We can't just delay the
flushing until the pageflip is latched, since that would pose the risk
that we override frontbuffer rendering that has been scheduled
in-between the pageflip ioctl and the actual latching.
To handle this track asynchronous invalidations (and also pageflip)
state per-ring and delay any in-between flushing until the rendering
has completed. And also cancel any delayed flushing if we get a new
invalidation request (whether delayed or not).
Also call intel_mark_fb_busy in both cases in all cases to make sure
that we keep the screen at the highest refresh rate both on flips,
synchronous plane updates and for frontbuffer rendering.
v2: Lots of improvements
Suggestions from Chris:
- Move invalidate/flush in flush_*_domain and set_to_*_domain.
- Drop the flush in busy_ioctl since it's redundant. Was a leftover
from an earlier concept to track flips/delayed flushes.
- Don't forget about the initial modeset enable/final disable.
Suggested by Chris.
Track flips accurately, too. Since flips complete independently of
rendering we need to track pending flips in a separate mask. Again if
an invalidate happens we need to cancel the evenutal flush to avoid
races.
v3:
Provide correct header declarations for flip functions. Currently not
needed outside of intel_display.c, but part of the proper interface.
v4: Add proper domain management to fbcon so that the fbcon buffer is
also tracked correctly.
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h| 14 +++
drivers/gpu/drm/i915/i915_gem.c| 19 ++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 178 +++--
drivers/gpu/drm/i915/intel_drv.h | 10 +-
drivers/gpu/drm/i915/intel_fbdev.c | 18 ++-
drivers/gpu/drm/i915/intel_overlay.c | 3 +
drivers/gpu/drm/i915/intel_sprite.c| 4 +-
8 files changed, 225 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4c3787699cdf..30c2ae3cbab7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1332,6 +1332,17 @@ struct intel_pipe_crc {
wait_queue_head_t wq;
};
+struct i915_frontbuffer_tracking {
+ struct mutex lock;
+
+ /*
+* Tracking bits for delayed frontbuffer flushing du to gpu activity or
+* scheduled flips.
+*/
+ unsigned busy_bits;
+ unsigned flip_bits;
+};
+
struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *slab;
@@ -1475,6 +1486,9 @@ struct drm_i915_private {
bool lvds_downclock_avail;
/* indicates the reduced downclock for LVDS*/
int lvds_downclock;
+
+ struct i915_frontbuffer_tracking fb_tracking;
+
u16 orig_clock;
bool mchbar_need_disable;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9722991a0d19..2ccdd9dcd253 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1395,8 +1395,6 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
goto unlock;
}
- intel_edp_psr_exit(dev);
-
/* Try to flush the object off the GPU without holding the lock.
* We will repeat the flush holding the lock in the normal manner
* to catch cases where we are gazumped.
@@ -1442,8 +1440,6 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void
*data,
if (ret)
return ret;
- intel_edp_psr_exit(dev);
-
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
if (&obj->base == NULL) {
ret = -ENOENT;
@@ -2227,6 +2223,9 @@ i915_gem_object_move_to_inactive(struct
drm_i915_gem_object *obj)
list_move_tail(&vma->mm_list, &vm->inactive_list);
}
+ if (obj->frontbuffer_bits)
+ intel_fb_flush(obj, true);
+
list_del_init(&obj->ring_list);
obj->ring = NULL;
@@ -3556,6 +3555,8 @@ i915_gem_object_flush_gtt_write_domain(struct
drm_i915_gem_object *obj)
old_write_domain = obj->base.write_domain;
obj->base.write_domain = 0;
+ intel_fb_flush(obj, false);
+
trace_i915_gem_object_change_domain(obj,
obj->base.read_domains,
old_write_domain);
@@ -3577,6 +3578
[Intel-gfx] [PATCH 07/15] drm/i915: Track the psr dp connector in dev_priv->psr.enabled
Trying to fish that one out through looping is a bit a locking
nightmare. So just set it and use it in the work struct.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_dp.c | 21 +++--
2 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f5db29428406..759f7c6d1622 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -633,10 +633,11 @@ struct i915_drrs {
struct intel_connector *connector;
};
+struct intel_dp;
struct i915_psr {
bool sink_support;
bool source_ok;
- bool enabled;
+ struct intel_dp *enabled;
bool active;
struct delayed_work work;
};
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ac1cef459a7b..10bcc052df4b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1826,7 +1826,7 @@ static void intel_edp_psr_do_enable(struct intel_dp
*intel_dp)
/* Enable PSR on the host */
intel_edp_psr_enable_source(intel_dp);
- dev_priv->psr.enabled = true;
+ dev_priv->psr.enabled = intel_dp;
dev_priv->psr.active = true;
}
@@ -1867,26 +1867,19 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)
EDP_PSR_STATUS_STATE_MASK) == 0, 2000, 10))
DRM_ERROR("Timed out waiting for PSR Idle State\n");
- dev_priv->psr.enabled = false;
+ dev_priv->psr.enabled = NULL;
}
static void intel_edp_psr_work(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), psr.work.work);
- struct drm_device *dev = dev_priv->dev;
- struct intel_encoder *encoder;
- struct intel_dp *intel_dp = NULL;
-
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.head)
- if (encoder->type == INTEL_OUTPUT_EDP) {
- intel_dp = enc_to_intel_dp(&encoder->base);
+ struct intel_dp *intel_dp = dev_priv->psr.enabled;
- if (!intel_edp_psr_match_conditions(intel_dp))
- intel_edp_psr_disable(intel_dp);
- else
- intel_edp_psr_do_enable(intel_dp);
- }
+ if (!intel_edp_psr_match_conditions(intel_dp))
+ intel_edp_psr_disable(intel_dp);
+ else
+ intel_edp_psr_do_enable(intel_dp);
}
static void intel_edp_psr_inactivate(struct drm_device *dev)
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/15] drm/i915: Drop schedule_back from psr_exit
It doesn't make sense to never again schedule the work, since by the
time we might want to re-enable psr the world might have changed and
we can do it again.
The only exception is when we shut down the pipe, but that's an
entirely different thing and needs to be handled in psr_disable.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 6 +++---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_dp.c | 7 +++
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
5 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1794a041c13c..f22b4aabb945 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1395,7 +1395,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
goto unlock;
}
- intel_edp_psr_exit(dev, true);
+ intel_edp_psr_exit(dev);
/* Try to flush the object off the GPU without holding the lock.
* We will repeat the flush holding the lock in the normal manner
@@ -1442,7 +1442,7 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void
*data,
if (ret)
return ret;
- intel_edp_psr_exit(dev, true);
+ intel_edp_psr_exit(dev);
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
if (&obj->base == NULL) {
@@ -4240,7 +4240,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
if (ret)
return ret;
- intel_edp_psr_exit(dev, true);
+ intel_edp_psr_exit(dev);
obj = to_intel_bo(drm_gem_object_lookup(dev, file, args->handle));
if (&obj->base == NULL) {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c27dadebd0dc..6f2588c95248 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8823,7 +8823,7 @@ void intel_mark_fb_busy(struct drm_i915_gem_object *obj,
struct drm_device *dev = obj->base.dev;
struct drm_crtc *crtc;
- intel_edp_psr_exit(dev, true);
+ intel_edp_psr_exit(dev);
if (!i915.powersave)
return;
@@ -9292,7 +9292,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
return -ENOMEM;
/* Exit PSR early in page flip */
- intel_edp_psr_exit(dev, true);
+ intel_edp_psr_exit(dev);
work->event = event;
work->crtc = crtc;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4ab4757fb53d..c7d625040e3d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1899,7 +1899,7 @@ static void intel_edp_psr_inactivate(struct drm_device
*dev)
& ~EDP_PSR_ENABLE);
}
-void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back)
+void intel_edp_psr_exit(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1911,9 +1911,8 @@ void intel_edp_psr_exit(struct drm_device *dev, bool
schedule_back)
if (dev_priv->psr.active)
intel_edp_psr_inactivate(dev);
- if (schedule_back)
- schedule_delayed_work(&dev_priv->psr.work,
- msecs_to_jiffies(100));
+ schedule_delayed_work(&dev_priv->psr.work,
+ msecs_to_jiffies(100));
}
void intel_edp_psr_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 87e83c315c4b..1d45629a6483 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -829,7 +829,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp);
void intel_edp_psr_enable(struct intel_dp *intel_dp);
void intel_edp_psr_disable(struct intel_dp *intel_dp);
void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate);
-void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back);
+void intel_edp_psr_exit(struct drm_device *dev);
void intel_edp_psr_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 2a211c64ec8d..9038e2ab73c8 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1051,7 +1051,7 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
mutex_unlock(&dev->struct_mutex);
}
- intel_edp_psr_exit(dev, true);
+ intel_edp_psr_exit(dev);
return 0;
}
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/15] drm/i915: More checks for psr.enabled
We need to make sure that no one else is using this in the
enable function and also that the work item hasn't raced
with the disabled function.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 923a9f6991f7..503809e4e6f3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1844,6 +1844,11 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
return;
}
+ if (dev_priv->psr.enabled) {
+ DRM_DEBUG_KMS("PSR already in use\n");
+ return;
+ }
+
/* Setup PSR once */
intel_edp_psr_setup(intel_dp);
@@ -1882,6 +1887,9 @@ static void intel_edp_psr_work(struct work_struct *work)
container_of(work, typeof(*dev_priv), psr.work.work);
struct intel_dp *intel_dp = dev_priv->psr.enabled;
+ if (!intel_dp)
+ return;
+
if (intel_edp_psr_match_conditions(intel_dp))
intel_edp_psr_do_enable(intel_dp);
}
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/15] drm/i915: Drop unecessary complexity from psr_inactivate
It's not needed and further more will get in the way of a sane
locking scheme - psr_exit _can't_ take modeset locks due to lock
inversion, and at least once dp mst hits the connector list
is no longer static.
But since we track all state in dev_priv->psr there is no need
at all.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 190df701edd5..90f6f0a42d15 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1910,29 +1910,11 @@ static void intel_edp_psr_work(struct work_struct *work)
static void intel_edp_psr_inactivate(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_connector *connector;
- struct intel_encoder *encoder;
- struct intel_crtc *intel_crtc;
- struct intel_dp *intel_dp = NULL;
-
- list_for_each_entry(connector, &dev->mode_config.connector_list,
- base.head) {
- if (connector->base.dpms != DRM_MODE_DPMS_ON)
- continue;
-
- encoder = to_intel_encoder(connector->base.encoder);
- if (encoder->type == INTEL_OUTPUT_EDP) {
+ dev_priv->psr.active = false;
- intel_dp = enc_to_intel_dp(&encoder->base);
- intel_crtc = to_intel_crtc(encoder->base.crtc);
-
- dev_priv->psr.active = false;
-
- I915_WRITE(EDP_PSR_CTL(dev), I915_READ(EDP_PSR_CTL(dev))
- & ~EDP_PSR_ENABLE);
- }
- }
+ I915_WRITE(EDP_PSR_CTL(dev), I915_READ(EDP_PSR_CTL(dev))
+ & ~EDP_PSR_ENABLE);
}
void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back)
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/15] drm/i915: Ditch intel_edp_psr_update
We have _enable/_disable interfaces now for the modeset sequence and
intel_edp_psr_exit for workarounds.
The callsites in intel_display.c are all redundant with the modeset
sequence enable/disable calls in intel_ddi.c. The one in
intel_sprite.c is real and needs to be switched to psr_exit.
If this breaks anything then we need to augment the enable/disable
functions accordingly.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 5 -
drivers/gpu/drm/i915/intel_dp.c | 13 -
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
4 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a0f4709f9479..c27dadebd0dc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2763,7 +2763,6 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
- intel_edp_psr_update(dev);
mutex_unlock(&dev->struct_mutex);
return 0;
@@ -3943,7 +3942,6 @@ static void intel_crtc_enable_planes(struct drm_crtc
*crtc)
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
- intel_edp_psr_update(dev);
mutex_unlock(&dev->struct_mutex);
}
@@ -4236,7 +4234,6 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
- intel_edp_psr_update(dev);
mutex_unlock(&dev->struct_mutex);
}
@@ -4284,7 +4281,6 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
- intel_edp_psr_update(dev);
mutex_unlock(&dev->struct_mutex);
}
@@ -4836,7 +4832,6 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
- intel_edp_psr_update(dev);
mutex_unlock(&dev->struct_mutex);
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 90f6f0a42d15..8717d3b9667c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1875,19 +1875,6 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)
dev_priv->psr.enabled = false;
}
-void intel_edp_psr_update(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
- if (!HAS_PSR(dev))
- return;
-
- if (!dev_priv->psr.setup_done)
- return;
-
- intel_edp_psr_exit(dev, true);
-}
-
static void intel_edp_psr_work(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0081f79efad4..87e83c315c4b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -828,7 +828,6 @@ void intel_edp_panel_on(struct intel_dp *intel_dp);
void intel_edp_panel_off(struct intel_dp *intel_dp);
void intel_edp_psr_enable(struct intel_dp *intel_dp);
void intel_edp_psr_disable(struct intel_dp *intel_dp);
-void intel_edp_psr_update(struct drm_device *dev);
void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate);
void intel_edp_psr_exit(struct drm_device *dev, bool schedule_back);
void intel_edp_psr_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 404335d53a89..2a211c64ec8d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1051,7 +1051,7 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
mutex_unlock(&dev->struct_mutex);
}
- intel_edp_psr_update(dev);
+ intel_edp_psr_exit(dev, true);
return 0;
}
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/15] Accurate frontbuffer tracking and psr conversion
Hi all, This patch series adds accurate frontbuffer tracking to i915 and then converts psr over to use. Bunch of things still need to be done. - PSR needs to be re-tested. I lack the hardware for that. The frontbuffer tracking itself is tested. - PSR igt testcase needs to be extended so that we cover all upload methods on all plane types. - DRRS/downclocking needs to be unified and put into this framework properly. Also needs proper locking for all of the DRRS state. - fbc also needs to be fixed up, with state handling properly split between crtc_enable/disable, primary fb updates and the fb tracking for nuking. A bit unclear how we want to integrate gtt cpu write tracking through the hw, since that seems to be the hw tracking piece that actually works. General blueprint for display runtime power saving features: - Have all your state in either intel_crtc or dev_priv, protected by its own lock. - Do state setup in crtc_enable, cleanup in crtc_disable with a pair of enable/disable fuctions. Optionally update everywhere else you want (e.g. primary plane updates for fbc). Not state setup anywhere else allowed, except maybe an _init for setting up work items, locks, ... - Intercept the invalidation/flush signals you need like psr_invalidate/psr_flush. Track internally which frontbuffer bits you're interested in and invalidate/flush accordingly. You can also use these for workarounds (e.g. on hsw we force-flush for sprite changes since the flip signal doesn't result in a hw image upload). Note that currently the gtt tracking has a bit a gap: We never exit it. Bunch of fixes are possible: - Wire up the core dirty_fb ioctl to flush framebuffers. This is used by generic userspace to flush dummy buffers, which in our case means gtt mmaps. So maps perfectly. - Do a delayed gtt pte teardown and force-flush. Probably too ugly to care really. - Try to integrate hw gtt write tracking logic. Note that current psr code doesn't rely on this - I've killed the X-tiled checks completely. Big thanks to Chris for some great ideas for the fb tracking scheme and the precise placement of the invalidate/flush functions. Comments, flames and especially testing on psr hardware highly welcome. Cheers, Daniel Daniel Vetter (15): drm/i915: Add missing statics to recent psr functions drm/i915: Drop unecessary complexity from psr_inactivate drm/i915: Ditch intel_edp_psr_update drm/i915: Run psr_setup unconditionally drm/i915: Drop schedule_back from psr_exit drm/i915: Add a FIXME about drrs/psr interactions drm/i915: Track the psr dp connector in dev_priv->psr.enabled drm/i915: Don't try to disable psr harder from the work item drm/i915: Lock down psr sw/hw state tracking drm/i915: More checks for psr.enabled drm/i915: Add locking to psr code drm/i915: Introduce accurate frontbuffer tracking drm/i915: Use new frontbuffer bits to increase pll clock drm/i915: Track frontbuffer invalidation/flushing drm/i915: Fix up PSR frontbuffer tracking drivers/gpu/drm/i915/i915_debugfs.c| 2 +- drivers/gpu/drm/i915/i915_drv.h| 46 - drivers/gpu/drm/i915/i915_gem.c| 38 +++- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 283 +++-- drivers/gpu/drm/i915/intel_dp.c| 189 +-- drivers/gpu/drm/i915/intel_drv.h | 16 +- drivers/gpu/drm/i915/intel_fbdev.c | 18 +- drivers/gpu/drm/i915/intel_overlay.c | 14 ++ drivers/gpu/drm/i915/intel_sprite.c| 11 +- 10 files changed, 458 insertions(+), 161 deletions(-) -- 2.0.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/15] drm/i915: Run psr_setup unconditionally
Due to runtime pm and system s/r we need to restore hw state every
time we enable a pipe again. Hence trying to avoid that is just
pointless book-keeping which Rodrigo then tried to work around by
manually adding psr_setup calls to our resume code.
Much simpler to just remove code instead.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_dp.c | 8
2 files changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64d520f7e8d9..f5db29428406 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -636,7 +636,6 @@ struct i915_drrs {
struct i915_psr {
bool sink_support;
bool source_ok;
- bool setup_done;
bool enabled;
bool active;
struct delayed_work work;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8717d3b9667c..4ab4757fb53d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1663,9 +1663,6 @@ static void intel_edp_psr_setup(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
struct edp_vsc_psr psr_vsc;
- if (dev_priv->psr.setup_done)
- return;
-
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
memset(&psr_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
@@ -1677,8 +1674,6 @@ static void intel_edp_psr_setup(struct intel_dp *intel_dp)
/* Avoid continuous PSR exit by masking memup and hpd */
I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
-
- dev_priv->psr.setup_done = true;
}
static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
@@ -1911,9 +1906,6 @@ void intel_edp_psr_exit(struct drm_device *dev, bool
schedule_back)
if (!HAS_PSR(dev))
return;
- if (!dev_priv->psr.setup_done)
- return;
-
cancel_delayed_work_sync(&dev_priv->psr.work);
if (dev_priv->psr.active)
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Handle disabled primary plane in debugfs i915_display_info (v2)
Now that the primary plane can be disabled independently of the CRTC, the debugfs code needs to be updated to recognize when the primary plane is disabled and not try to return information about the primary plane's framebuffer. This change prevents a NULL dereference when reading i915_display_info with a disabled primary plane. v2: Replace a seq_printf() with seq_puts() (suggested by Damien) Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_debugfs.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index a8b8140..8057fd4 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2220,9 +2220,12 @@ static void intel_crtc_info(struct seq_file *m, struct intel_crtc *intel_crtc) struct drm_crtc *crtc = &intel_crtc->base; struct intel_encoder *intel_encoder; - seq_printf(m, "\tfb: %d, pos: %dx%d, size: %dx%d\n", - crtc->primary->fb->base.id, crtc->x, crtc->y, - crtc->primary->fb->width, crtc->primary->fb->height); + if (crtc->primary->fb) + seq_printf(m, "\tfb: %d, pos: %dx%d, size: %dx%d\n", + crtc->primary->fb->base.id, crtc->x, crtc->y, + crtc->primary->fb->width, crtc->primary->fb->height); + else + seq_puts(m, "\tprimary plane disabled\n"); for_each_encoder_on_crtc(dev, crtc, intel_encoder) intel_encoder_info(m, intel_crtc, intel_encoder); } -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Broaden FBC resolution limit to 4096x4096
On Mon, Jun 16, 2014 at 05:52:12PM +0100, Damien Lespiau wrote:
> From: Daisy Sun
>
> Staring from BDW, the resolution limit of FBC has increased to
> 4096x4096>
>
> Issue: APDEV-2935
> Otc-Tracker: VIZ-3826
> Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
> Signed-off-by: Daisy Sun
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 0b088fe..8cc60fc 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -529,7 +529,10 @@ void intel_update_fbc(struct drm_device *dev)
> goto out_disable;
> }
>
> - if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> + if (INTEL_INFO(dev)->gen >= 8) {
> + max_width = 4096;
> + max_height = 4096;
> + } else if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
> max_width = 4096;
> max_height = 2048;
> } else {
> --
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Handle disabled primary plane in debugfs i915_display_info
On Mon, Jun 16, 2014 at 10:01:55AM -0700, Matt Roper wrote: > Now that the primary plane can be disabled independently of the CRTC, > the debugfs code needs to be updated to recognize when the primary plane > is disabled and not try to return information about the primary plane's > framebuffer. > > This change prevents a NULL dereference when reading i915_display_info > with a disabled primary plane. > > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/i915_debugfs.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index a8b8140..28aa591 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -2220,9 +2220,12 @@ static void intel_crtc_info(struct seq_file *m, struct > intel_crtc *intel_crtc) > struct drm_crtc *crtc = &intel_crtc->base; > struct intel_encoder *intel_encoder; > > - seq_printf(m, "\tfb: %d, pos: %dx%d, size: %dx%d\n", > -crtc->primary->fb->base.id, crtc->x, crtc->y, > -crtc->primary->fb->width, crtc->primary->fb->height); > + if (crtc->primary->fb) > + seq_printf(m, "\tfb: %d, pos: %dx%d, size: %dx%d\n", > +crtc->primary->fb->base.id, crtc->x, crtc->y, > +crtc->primary->fb->width, crtc->primary->fb->height); > + else > + seq_printf(m, "\tprimary plane disabled\n"); seq_puts() > for_each_encoder_on_crtc(dev, crtc, intel_encoder) > intel_encoder_info(m, intel_crtc, intel_encoder); > } -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Handle disabled primary plane in debugfs i915_display_info
Now that the primary plane can be disabled independently of the CRTC, the debugfs code needs to be updated to recognize when the primary plane is disabled and not try to return information about the primary plane's framebuffer. This change prevents a NULL dereference when reading i915_display_info with a disabled primary plane. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_debugfs.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index a8b8140..28aa591 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2220,9 +2220,12 @@ static void intel_crtc_info(struct seq_file *m, struct intel_crtc *intel_crtc) struct drm_crtc *crtc = &intel_crtc->base; struct intel_encoder *intel_encoder; - seq_printf(m, "\tfb: %d, pos: %dx%d, size: %dx%d\n", - crtc->primary->fb->base.id, crtc->x, crtc->y, - crtc->primary->fb->width, crtc->primary->fb->height); + if (crtc->primary->fb) + seq_printf(m, "\tfb: %d, pos: %dx%d, size: %dx%d\n", + crtc->primary->fb->base.id, crtc->x, crtc->y, + crtc->primary->fb->width, crtc->primary->fb->height); + else + seq_printf(m, "\tprimary plane disabled\n"); for_each_encoder_on_crtc(dev, crtc, intel_encoder) intel_encoder_info(m, intel_crtc, intel_encoder); } -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bdw: Broaden FBC resolution limit to 4096x4096
From: Daisy Sun
Staring from BDW, the resolution limit of FBC has increased to
4096x4096>
Issue: APDEV-2935
Otc-Tracker: VIZ-3826
Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
Signed-off-by: Daisy Sun
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0b088fe..8cc60fc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -529,7 +529,10 @@ void intel_update_fbc(struct drm_device *dev)
goto out_disable;
}
- if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
+ if (INTEL_INFO(dev)->gen >= 8) {
+ max_width = 4096;
+ max_height = 4096;
+ } else if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
max_width = 4096;
max_height = 2048;
} else {
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Clearing buffer objects via blitter engine
On Mon, Jun 16, 2014 at 08:59:04PM +0530, sourab.gu...@intel.com wrote:
> From: Chris Wilson
>
> This patch adds support for clearing buffer objects via blitter
> engines. This is particularly useful for clearing out the memory
> from stolen region.
>
> testcase: igt/gem_create2
>
> Signed-off-by: Sourab Gupta
This doesn't look like it'll work on gen8.
--
Damien
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_gem_exec.c | 120
> +++
> 3 files changed, 124 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/i915_gem_exec.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index cad1683..a18f7e5 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -22,6 +22,7 @@ i915-y += i915_cmd_parser.o \
> i915_gem_debug.o \
> i915_gem_dmabuf.o \
> i915_gem_evict.o \
> + i915_gem_exec.o \
> i915_gem_execbuffer.o \
> i915_gem_gtt.o \
> i915_gem.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 64d520f..0cdd4d7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2425,6 +2425,9 @@ int __must_check i915_gem_evict_something(struct
> drm_device *dev,
> int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
> int i915_gem_evict_everything(struct drm_device *dev);
>
> +/* i915_gem_exec.c */
> +int i915_gem_exec_clear_object(struct drm_i915_gem_object *obj);
> +
> /* belongs in i915_gem_gtt.h */
> static inline void i915_gem_chipset_flush(struct drm_device *dev)
> {
> diff --git a/drivers/gpu/drm/i915/i915_gem_exec.c
> b/drivers/gpu/drm/i915/i915_gem_exec.c
> new file mode 100644
> index 000..374f1e1
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_gem_exec.c
> @@ -0,0 +1,120 @@
> +/*
> + * Copyright © 2013 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:
> + *Chris Wilson
> + *
> + */
> +
> +#include
> +#include
> +#include "i915_drv.h"
> +
> +#define COLOR_BLT_CMD (2<<29 | 0x40<<22)
> +#define BLT_WRITE_ALPHA (1<<21)
> +#define BLT_WRITE_RGB (1<<20)
> +#define BLT_WRITE_RGBA (BLT_WRITE_RGB|BLT_WRITE_ALPHA)
> +
> +#define BPP_8 0
> +#define BPP_16 (1<<24)
> +#define BPP_32 (1<<25 | 1<<24)
> +
> +#define ROP_FILL_COPY (0xf0 << 16)
> +
> +static int i915_gem_exec_flush_object(struct drm_i915_gem_object *obj,
> + struct intel_engine_cs *ring)
> +{
> + int ret;
> +
> + ret = i915_gem_object_sync(obj, ring);
> + if (ret)
> + return ret;
> +
> + if (obj->base.write_domain & I915_GEM_DOMAIN_CPU) {
> + if (i915_gem_clflush_object(obj, false))
> + i915_gem_chipset_flush(obj->base.dev);
> + obj->base.write_domain &= ~I915_GEM_DOMAIN_CPU;
> + }
> + if (obj->base.write_domain & I915_GEM_DOMAIN_GTT) {
> + wmb();
> + obj->base.write_domain &= ~I915_GEM_DOMAIN_GTT;
> + }
> +
> + return intel_ring_invalidate_all_caches(ring);
> +}
> +
> +static void i915_gem_exec_dirty_object(struct drm_i915_gem_object *obj,
> +struct intel_engine_cs *ring)
> +{
> + obj->fenced_gpu_access = false;
> + obj->base.read_domains = I915_GEM_DOMAIN_RENDER;
> + obj->base.write_domain = I915_GEM_DOMAIN_RENDER;
> + i915_vma_move_to_active(i915_gem_obj_to_ggtt(obj), ring);
> + obj->last_write_seqno = intel_ring_get_seqno(ring);
> + obj->dirty = 1;
> +
> + ring->gpu_caches_dirty = true;
> +}
> +
> +int i915_gem_exec_clear_object(struct drm_i915_gem_object *obj)
> +{
> + struct drm_device *dev = obj->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_pr
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Introduce a new create ioctl for user specified placement
On Mon, Jun 16, 2014 at 08:59:05PM +0530, sourab.gu...@intel.com wrote:
> From: Chris Wilson
>
> Despite being a unified memory architecture (UMA) some bits of memory
> are more equal than others. In particular we have the thorny issue of
> stolen memory, memory stolen from the system by the BIOS and reserved
> for igfx use. Stolen memory is required for some functions of the GPU
> and display engine, but in general it goes wasted. Whilst we cannot
> return it back to the system, we need to find some other method for
> utilising it. As we do not support direct access to the physical address
> in the stolen region, it behaves like a different class of memory,
> closer in kin to local GPU memory. This strongly suggests that we need a
> placement model like TTM if we are to fully utilize these discrete
> chunks of differing memory.
>
> This new create ioctl therefore exists to allow the user to create these
> second class buffer objects from stolen memory. At the moment direct
> access by the CPU through mmaps and pread/pwrite are verboten on the
> objects, and so the user must be aware of the limitations of the objects
> created. Yet, those limitations rarely reduce the desired functionality
> in many use cases and so the user should be able to easily fill the
> stolen memory and so help to reduce overall memory pressure.
>
> The most obvious use case for stolen memory is for the creation of objects
> for the display engine which already have very similar restrictions on
> access. However, we want a reasonably general ioctl in order to cater
> for diverse scenarios beyond the author's imagination.
>
> v2: Expand the struct slightly to include cache domains, and ensure that
> all memory allocated by the kernel for userspace is zeroed.
>
> v3: Ben suggested the idea of binding the object at a known offset into
> the target context upon creation.
>
> testcase: igt/gem_create2
>
> Signed-off-by: Chris Wilson
> Signed-off-by: Sourab Gupta
What about those ioctls() losing DRM_AUTH?
--
Damien
> ---
> drivers/gpu/drm/i915/i915_dma.c| 11 +-
> drivers/gpu/drm/i915/i915_drv.h| 15 ++-
> drivers/gpu/drm/i915/i915_gem.c| 208
> ++---
> drivers/gpu/drm/i915/i915_gem_tiling.c | 106 +
> include/uapi/drm/i915_drm.h| 107 +
> 5 files changed, 373 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index aadb0c9..f101d49 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1996,10 +1996,10 @@ const struct drm_ioctl_desc i915_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2,
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl,
> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl,
> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> @@ -2009,8 +2009,8 @@ const struct drm_ioctl_desc i915_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID,
> intel_get_pipe_from_crtc_i
[Intel-gfx] [PATCH 1/2] intel: Adding bufmgr interfaces for exposing create2 ioctl
From: Sourab Gupta
This patch series add the bufmgr interfaces for exposing the
create2 ioctl.
By means of this ioctl, we can specify number of parameters
during object creation time such as placement, cache domains,
caching, madvise, tiling etc.
Signed-off-by: Sourab Gupta
---
include/drm/i915_drm.h| 107
intel/intel_bufmgr.c | 7 +++
intel/intel_bufmgr.h | 20 +++
intel/intel_bufmgr_gem.c | 136 ++
intel/intel_bufmgr_priv.h | 16 ++
5 files changed, 286 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 2f4eb8c..92a3b03 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -223,6 +223,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ 0x31
#define DRM_I915_GET_RESET_STATS 0x32
+#define DRM_I915_GEM_CREATE2 0x34
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -253,6 +254,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_ENTERVT DRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_ENTERVT)
#define DRM_IOCTL_I915_GEM_LEAVEVT DRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_LEAVEVT)
#define DRM_IOCTL_I915_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_CREATE, struct drm_i915_gem_create)
+#define DRM_IOCTL_I915_GEM_CREATE2 DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_CREATE2, struct drm_i915_gem_create2)
#define DRM_IOCTL_I915_GEM_PREAD DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_PREAD, struct drm_i915_gem_pread)
#define DRM_IOCTL_I915_GEM_PWRITE DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_PWRITE, struct drm_i915_gem_pwrite)
#define DRM_IOCTL_I915_GEM_MMAPDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_MMAP, struct drm_i915_gem_mmap)
@@ -434,6 +436,111 @@ struct drm_i915_gem_create {
__u32 pad;
};
+struct drm_i915_gem_create2 {
+ /**
+* Requested size for the object.
+*
+* The (page-aligned) allocated size for the object will be returned.
+*/
+ __u64 size;
+
+ /**
+* Requested offset for the object.
+*
+* Can be used for "soft-pinning" the object into the per-process
+* GTT of the target context upon creation. Only possible if using
+* contexts and per-process GTTs.
+*
+* The address must be page-aligned, and have the valid bit set.
+*/
+ __u64 offset;
+#define I915_CREATE_OFFSET_VALID (1<<0)
+
+ /**
+* Target context of the object.
+*
+* The context of the object can be used for setting the initial offset
+* of the object in the per-process GTT.
+*/
+ __u32 context;
+
+ /**
+* Requested placement (which memory domain)
+*
+* You can request that the object be created from special memory
+* rather than regular system pages. Such irregular objects may
+* have certain restrictions (such as CPU access to a stolen
+* object is verboten).
+*/
+ __u32 placement;
+#define I915_CREATE_PLACEMENT_SYSTEM 0
+#define I915_CREATE_PLACEMENT_STOLEN 1 /* Cannot use CPU mmaps or pread/pwrite
*/
+ /**
+* Requested domain (which cache domain)
+*
+* You can request that the object be created from memory in a
+* certain cache domain (such as RENDER, CPU or GTT). In some cases,
+* this then may allocate from a pool of such pages to avoid any
+* migration overhead, but it is always equivalent to performing
+* an explicit set-domain(read=DOMAIN, write=DOMAIN) on the
+* constructed object.
+*
+* Set to 0, to leave the initial domain unspecified and defaulting
+* to the domain set by the constructor.
+*
+* See DRM_IOCTL_I915_GEM_SET_DOMAIN
+*/
+ __u32 domain;
+
+ /**
+* Requested cache level.
+*
+* See DRM_IOCTL_I915_GEM_SET_CACHING
+*/
+ __u32 caching;
+
+ /**
+* Requested tiling mode.
+*
+* See DRM_IOCTL_I915_GEM_SET_TILING
+*/
+ __u32 tiling_mode;
+ /**
+* Requested stride for tiling.
+*
+* See DRM_IOCTL_I915_GEM_SET_TILING
+*/
+ __u32 stride;
+
+ /**
+* Requested madvise priority.
+*
+* See DRM_IOCTL_I915_GEM_MADVISE
+*/
+ __u32 madvise;
+
+ /**
+* Additional miscellaneous flags
+*
+* Reserved for future use, must be zero.
+*/
+ __u32 flags;
+
+ /**
+* Padding for 64-bit struct alignment.
+*
+* Reserved for future use, must be zero.
+*/
+ __u32 pad;
+
+ /**
+* Returned hand
[Intel-gfx] [PATCH 0/2] Add Bufmgr interfaces for create2 ioctl
From: Sourab Gupta This patch series add the bufmgr interfaces for exposing the create2 ioctl. By means of this ioctl, we can specify number of parameters during object creation time such as placement, cache domains, caching, madvise, tiling etc. Sourab Gupta (2): intel: Adding bufmgr interfaces for exposing create2 ioctl intel: Add the cacheing logic for bo's created using create2 ioctl include/drm/i915_drm.h| 107 intel/intel_bufmgr.c | 7 ++ intel/intel_bufmgr.h | 20 intel/intel_bufmgr_gem.c | 241 ++ intel/intel_bufmgr_priv.h | 16 +++ 5 files changed, 391 insertions(+) -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] intel: Add the cacheing logic for bo's created using create2 ioctl
From: Sourab Gupta
This patch add the cacheing logic for the buffer objects created
using create2 ioctl. This cacheing logic is in principle similar
the cachecing employed in the earlier clear ioctl.
The cacheing is not employed if object is created in stolen region
or if the offset is specified for the object.
Signed-off-by: Sourab Gupta
---
intel/intel_bufmgr_gem.c | 201 ---
1 file changed, 153 insertions(+), 48 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 67430b9..4cefec2 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -781,62 +781,165 @@ drm_intel_gem_bo_alloc_create2(drm_intel_bufmgr *bufmgr,
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bufmgr;
drm_intel_bo_gem *bo_gem;
- struct drm_i915_gem_create2 create;
- int ret;
-
- bo_gem = calloc(1, sizeof(*bo_gem));
- if (!bo_gem)
- return NULL;
-
- bo_gem->bo.size = size;
+ unsigned int page_size = getpagesize();
+ struct drm_intel_gem_bo_bucket *bucket;
+ bool alloc_from_cache;
+ unsigned long bo_size;
+ bool for_render = false;
+ int ret, stride;
- VG_CLEAR(create);
- create.size = size;
- if(params->offset & I915_CREATE_OFFSET_VALID) {
- create.offset = params->offset;
- create.context = params->context;
- }
+ if (params->flags & BO_ALLOC_FOR_RENDER)
+ for_render = true;
if (params->tiling_mode == I915_TILING_NONE)
- create.stride = 0;
+ stride = 0;
else
- create.stride = params->stride;
+ stride = params->stride;
- create.placement = params->placement;
- create.domain = params->cache_domain;
- create.caching = params->caching;
- create.tiling_mode = params->tiling_mode;
- create.madvise = params->madvise;
+ if (params->placement == I915_CREATE_PLACEMENT_STOLEN ||
+ params->offset & I915_CREATE_OFFSET_VALID ||
+ params->madvise == I915_MADV_DONTNEED) {
+ bucket = NULL;
+ bo_size = size;
+ } else {
+ /* Round the allocated size up to a power of two
+* number of pages.
+*/
+ bucket = drm_intel_gem_bo_bucket_for_size(bufmgr_gem, size);
+ /* If we don't have caching at this size, don't actually
+* round the allocation up.
+*/
+ if (bucket == NULL) {
+ bo_size = size;
+ if (bo_size < page_size)
+ bo_size = page_size;
+ } else {
+ bo_size = bucket->size;
+ }
+ }
+ pthread_mutex_lock(&bufmgr_gem->lock);
+ /* Get a buffer out of the cache if available */
+retry:
+ alloc_from_cache = false;
+ if (bucket != NULL && !DRMLISTEMPTY(&bucket->head)) {
+ if (for_render) {
+ /* Allocate new render-target BOs from the tail (MRU)
+* of the list, as it will likely be hot in the GPU
+* cache and in the aperture for us.
+*/
+ bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
+ bucket->head.prev, head);
+ DRMLISTDEL(&bo_gem->head);
+ alloc_from_cache = true;
+ } else {
+ /* For non-render-target BOs (where we're probably
+* going to map it first thing in order to fill it
+* with data), check if the last BO in the cache is
+* unbusy, and only reuse in that case. Otherwise,
+* allocating a new buffer is probably faster than
+* waiting for the GPU to finish.
+*/
+ bo_gem = DRMLISTENTRY(drm_intel_bo_gem,
+ bucket->head.next, head);
+ if (!drm_intel_gem_bo_busy(&bo_gem->bo)) {
+ alloc_from_cache = true;
+ DRMLISTDEL(&bo_gem->head);
+ }
+ }
+ if (alloc_from_cache) {
+ struct drm_i915_gem_caching bo_cache;
+ struct drm_i915_gem_set_domain set_domain;
+ /* We need to call the functions for setcache, domain,
+* tiling, madvise here, as these parameters may be
+* different for the bo present in cache.
+*/
+ if (!drm_intel_gem_bo_madvise_internal
+ (bufmgr_gem, bo_gem,
[Intel-gfx] [PATCH] tests/gem_create2: Verifying the gem_create2 ioctl
From: Sourab Gupta
This patch adds the testcases for verifying the new gem_create2
ioctl. By means of this ioctl, we can specify number of parameters
during object creation time such as placement, cache domains,
caching, madvise, tiling etc.
These testcases include functional tests and interface tests for
testing the create2 ioctl
Signed-off-by: Sourab Gupta
---
tests/Makefile.sources | 1 +
tests/gem_create2.c| 578 +
2 files changed, 579 insertions(+)
create mode 100644 tests/gem_create2.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index b91b2b4..65c5ca4 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -23,6 +23,7 @@ TESTS_progs_M = \
gem_caching \
gem_close_race \
gem_concurrent_blit \
+ gem_create2 \
gem_cs_tlb \
gem_ctx_bad_exec \
gem_ctx_exec \
diff --git a/tests/gem_create2.c b/tests/gem_create2.c
new file mode 100644
index 000..a61d281
--- /dev/null
+++ b/tests/gem_create2.c
@@ -0,0 +1,578 @@
+/*
+ * Copyright ?? 2011 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:
+ *Sourab Gupta
+ *
+ */
+
+/** @file gem_create2.c
+ *
+ * This is a test of create2 ioctl which creates bo according to various
parameters.
+ *
+ *
+ * The goal is to simply ensure the basics work, and invalid input combinations
+ * are rejected.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "ioctl_wrappers.h"
+#include "drmtest.h"
+#include "intel_bufmgr.h"
+#include "intel_batchbuffer.h"
+#include "intel_io.h"
+#include "intel_chipset.h"
+#include "igt_aux.h"
+
+#define WIDTH 512
+#define CPP 4
+#define STRIDE (WIDTH*CPP)
+#define HEIGHT 128
+#define SIZE (HEIGHT*STRIDE)
+#define CLEAR(s) memset(&s, 0, sizeof(s))
+
+static drm_intel_bufmgr *bufmgr;
+static struct intel_batchbuffer *batch;
+static int cfg_count;
+
+void initialize_cfg(void);
+
+enum placement {
+ PLACEMENT_SYSTEM = I915_CREATE_PLACEMENT_SYSTEM,
+ PLACEMENT_STOLEN = I915_CREATE_PLACEMENT_STOLEN,
+};
+
+struct bo_placement {
+ enum placement place;
+ const char *name;
+}placements[] = {
+ { PLACEMENT_SYSTEM, "PLACEMENT_SYSTEM"},
+ { PLACEMENT_STOLEN, "PLACEMENT_STOLEN"},
+};
+
+enum cache_mode {
+ CACHING_NONE = I915_CACHING_NONE,
+ CACHING_CACHED = I915_CACHING_CACHED,
+ CACHING_DISPLAY = I915_CACHING_DISPLAY,
+};
+
+struct bo_cache {
+ enum cache_mode cache;
+ const char *name;
+} caches[] = {
+ { CACHING_NONE, "CACHING_NONE"},
+ { CACHING_CACHED, "CACHING_CACHED"},
+ { CACHING_DISPLAY, "CACHING_DISPLAY"},
+};
+
+enum domain {
+ DOMAIN_CPU = I915_GEM_DOMAIN_CPU,
+ DOMAIN_GTT = I915_GEM_DOMAIN_GTT,
+};
+
+struct bo_domain {
+ enum domain domain;
+ const char *name;
+} domains[] = {
+ { DOMAIN_CPU, "DOMAIN_CPU"},
+ { DOMAIN_GTT, "DOMAIN_GTT"},
+};
+
+enum tiling_mode {
+ TILING_NONE = I915_TILING_NONE,
+ TILING_X = I915_TILING_X,
+ TILING_Y = I915_TILING_Y,
+};
+
+struct bo_tiling {
+ enum tiling_mode tiling;
+ const char *name;
+}tilings[] = {
+ { TILING_NONE, "TILING_NONE"},
+ { TILING_X, "TILING_X"},
+ { TILING_Y, "TILING_Y"},
+};
+
+struct test_config {
+ struct bo_placement cfg_placement;
+ struct bo_cache cfg_cache;
+ struct bo_domain cfg_domain;
+ struct bo_tiling cfg_tiling;
+/* MAX_CONFIGS will change as we add more configs */
+#define MAX_CONFIGS 36
+ char name[128];
+}configs[MAX_CONFIGS];
+
+void initialize_cfg(void)
+{
+ int i, j, k, l;
+
+ cfg_count=0;
+ for (i=0;ivirtual;
+ for (i = 0; i < WIDTH*HEIGHT; i++)
+ virt[i] = i;
+
+ intel_copy_bo(batch, dest, src, SIZE);
+
+
[Intel-gfx] [PATCH 2/3] drm/i915: Introduce a new create ioctl for user specified placement
From: Chris Wilson
Despite being a unified memory architecture (UMA) some bits of memory
are more equal than others. In particular we have the thorny issue of
stolen memory, memory stolen from the system by the BIOS and reserved
for igfx use. Stolen memory is required for some functions of the GPU
and display engine, but in general it goes wasted. Whilst we cannot
return it back to the system, we need to find some other method for
utilising it. As we do not support direct access to the physical address
in the stolen region, it behaves like a different class of memory,
closer in kin to local GPU memory. This strongly suggests that we need a
placement model like TTM if we are to fully utilize these discrete
chunks of differing memory.
This new create ioctl therefore exists to allow the user to create these
second class buffer objects from stolen memory. At the moment direct
access by the CPU through mmaps and pread/pwrite are verboten on the
objects, and so the user must be aware of the limitations of the objects
created. Yet, those limitations rarely reduce the desired functionality
in many use cases and so the user should be able to easily fill the
stolen memory and so help to reduce overall memory pressure.
The most obvious use case for stolen memory is for the creation of objects
for the display engine which already have very similar restrictions on
access. However, we want a reasonably general ioctl in order to cater
for diverse scenarios beyond the author's imagination.
v2: Expand the struct slightly to include cache domains, and ensure that
all memory allocated by the kernel for userspace is zeroed.
v3: Ben suggested the idea of binding the object at a known offset into
the target context upon creation.
testcase: igt/gem_create2
Signed-off-by: Chris Wilson
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_dma.c| 11 +-
drivers/gpu/drm/i915/i915_drv.h| 15 ++-
drivers/gpu/drm/i915/i915_gem.c| 208 ++---
drivers/gpu/drm/i915/i915_gem_tiling.c | 106 +
include/uapi/drm/i915_drm.h| 107 +
5 files changed, 373 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index aadb0c9..f101d49 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1996,10 +1996,10 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl,
DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
@@ -2009,8 +2009,8 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID,
intel_get_pipe_from_crtc_id, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
@@ -2018,12 +2018,13 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs,
DRM_MASTER|DRM_CONTR
[Intel-gfx] [PATCH 3/3] drm/i915: Add support for stealing purgable stolen pages
From: Chris Wilson
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
objects to free up enough contiguous space in the vma when binding
a new object - and you will be forgiven for thinking that the code looks
very similar.
At the moment, we do not allow userspace to allocate objects in stolen,
so there is neither the memory pressure to trigger stolen eviction nor
any purgeable objects inside the stolen arena. However, this will change
in the near future, and so better management and defragmentation of
stolen memory will become a real issue.
v2: Remember to remove the drm_mm_node.
testcase: igt/gem_create2
Signed-off-by: Chris Wilson
Cc: "Gupta, Sourab"
Cc: "Goel, Akash"
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 121 ++---
1 file changed, 110 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 6441178..042ae61 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -340,18 +340,29 @@ cleanup:
return NULL;
}
-struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_device *dev, u32 size)
+static bool mark_free(struct drm_i915_gem_object *obj, struct list_head
*unwind)
+{
+ if (obj->stolen == NULL)
+ return false;
+
+ if (obj->madv != I915_MADV_DONTNEED)
+ return false;
+
+ if (i915_gem_obj_is_pinned(obj))
+ return false;
+
+ list_add(&obj->obj_exec_link, unwind);
+ return drm_mm_scan_add_block(obj->stolen);
+}
+
+static struct drm_mm_node *
+stolen_alloc(struct drm_i915_private *dev_priv, u32 size)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_i915_gem_object *obj;
struct drm_mm_node *stolen;
+ struct drm_i915_gem_object *obj;
+ struct list_head unwind, evict;
int ret;
- if (!drm_mm_initialized(&dev_priv->mm.stolen))
- return NULL;
-
- DRM_DEBUG_KMS("creating stolen object: size=%x\n", size);
if (size == 0)
return NULL;
@@ -361,11 +372,99 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32
size)
ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
4096, DRM_MM_SEARCH_DEFAULT);
- if (ret) {
- kfree(stolen);
- return NULL;
+ if (ret == 0)
+ return stolen;
+
+ /* No more stolen memory available, or too fragmented.
+* Try evicting purgeable objects and search again.
+*/
+
+ drm_mm_init_scan(&dev_priv->mm.stolen, size, 4096, 0);
+ INIT_LIST_HEAD(&unwind);
+
+ list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_list)
+ if (mark_free(obj, &unwind))
+ goto found;
+
+ list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list)
+ if (mark_free(obj, &unwind))
+ goto found;
+
+found:
+ INIT_LIST_HEAD(&evict);
+ while (!list_empty(&unwind)) {
+ obj = list_first_entry(&unwind,
+ struct drm_i915_gem_object,
+ obj_exec_link);
+ list_del_init(&obj->obj_exec_link);
+
+ if (drm_mm_scan_remove_block(obj->stolen)) {
+ list_add(&obj->obj_exec_link, &evict);
+ drm_gem_object_reference(&obj->base);
+ }
}
+ ret = 0;
+ while (!list_empty(&evict)) {
+ obj = list_first_entry(&evict,
+ struct drm_i915_gem_object,
+ obj_exec_link);
+ list_del_init(&obj->obj_exec_link);
+
+ if (ret == 0) {
+ struct i915_vma *vma, *vma_next;
+
+ list_for_each_entry_safe(vma, vma_next,
+&obj->vma_list,
+vma_link)
+ if (i915_vma_unbind(vma))
+ break;
+
+ /* Stolen pins its pages to prevent the
+* normal shrinker from processing stolen
+* objects.
+*/
+ i915_gem_object_unpin_pages(obj);
+
+ ret = i915_gem_object_put_pages(obj);
+ if (ret == 0) {
+ i915_gem_object_release_stolen(obj);
+ obj->madv = __I915_MADV_PURGED;
+ } else
+ i915_gem_object_pin_pages(obj);
+ }
+
+
[Intel-gfx] [PATCH 1/3] drm/i915: Clearing buffer objects via blitter engine
From: Chris Wilson
This patch adds support for clearing buffer objects via blitter
engines. This is particularly useful for clearing out the memory
from stolen region.
testcase: igt/gem_create2
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_gem_exec.c | 120 +++
3 files changed, 124 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_gem_exec.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index cad1683..a18f7e5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -22,6 +22,7 @@ i915-y += i915_cmd_parser.o \
i915_gem_debug.o \
i915_gem_dmabuf.o \
i915_gem_evict.o \
+ i915_gem_exec.o \
i915_gem_execbuffer.o \
i915_gem_gtt.o \
i915_gem.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64d520f..0cdd4d7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2425,6 +2425,9 @@ int __must_check i915_gem_evict_something(struct
drm_device *dev,
int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
int i915_gem_evict_everything(struct drm_device *dev);
+/* i915_gem_exec.c */
+int i915_gem_exec_clear_object(struct drm_i915_gem_object *obj);
+
/* belongs in i915_gem_gtt.h */
static inline void i915_gem_chipset_flush(struct drm_device *dev)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_exec.c
b/drivers/gpu/drm/i915/i915_gem_exec.c
new file mode 100644
index 000..374f1e1
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gem_exec.c
@@ -0,0 +1,120 @@
+/*
+ * Copyright ?? 2013 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:
+ *Chris Wilson
+ *
+ */
+
+#include
+#include
+#include "i915_drv.h"
+
+#define COLOR_BLT_CMD (2<<29 | 0x40<<22)
+#define BLT_WRITE_ALPHA (1<<21)
+#define BLT_WRITE_RGB (1<<20)
+#define BLT_WRITE_RGBA (BLT_WRITE_RGB|BLT_WRITE_ALPHA)
+
+#define BPP_8 0
+#define BPP_16 (1<<24)
+#define BPP_32 (1<<25 | 1<<24)
+
+#define ROP_FILL_COPY (0xf0 << 16)
+
+static int i915_gem_exec_flush_object(struct drm_i915_gem_object *obj,
+ struct intel_engine_cs *ring)
+{
+ int ret;
+
+ ret = i915_gem_object_sync(obj, ring);
+ if (ret)
+ return ret;
+
+ if (obj->base.write_domain & I915_GEM_DOMAIN_CPU) {
+ if (i915_gem_clflush_object(obj, false))
+ i915_gem_chipset_flush(obj->base.dev);
+ obj->base.write_domain &= ~I915_GEM_DOMAIN_CPU;
+ }
+ if (obj->base.write_domain & I915_GEM_DOMAIN_GTT) {
+ wmb();
+ obj->base.write_domain &= ~I915_GEM_DOMAIN_GTT;
+ }
+
+ return intel_ring_invalidate_all_caches(ring);
+}
+
+static void i915_gem_exec_dirty_object(struct drm_i915_gem_object *obj,
+ struct intel_engine_cs *ring)
+{
+ obj->fenced_gpu_access = false;
+ obj->base.read_domains = I915_GEM_DOMAIN_RENDER;
+ obj->base.write_domain = I915_GEM_DOMAIN_RENDER;
+ i915_vma_move_to_active(i915_gem_obj_to_ggtt(obj), ring);
+ obj->last_write_seqno = intel_ring_get_seqno(ring);
+ obj->dirty = 1;
+
+ ring->gpu_caches_dirty = true;
+}
+
+int i915_gem_exec_clear_object(struct drm_i915_gem_object *obj)
+{
+ struct drm_device *dev = obj->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_engine_cs *ring;
+ int ret;
+
+ lockdep_assert_held(&dev->struct_mutex);
+
+ ring = &dev_priv->ring[HAS_BLT(dev) ? BCS : RCS];
+
+ ret = i915_gem_obj_ggtt_pin(obj, 0, 0);
+ if (ret)
+ return ret;
+
+ if (obj->tiling_mode && INTEL_INFO(dev)->gen <= 3) {
+
[Intel-gfx] [PATCH 0/3] Introduce a new create ioctl for user specified
From: Sourab Gupta This patch series introduces a new gem create ioctl for user specified placement. Despite being a unified memory architecture (UMA) some bits of memory are more equal than others. In particular we have the thorny issue of stolen memory, memory stolen from the system by the BIOS and reserved for igfx use. Stolen memory is required for some functions of the GPU and display engine, but in general it goes wasted. Whilst we cannot return it back to the system, we need to find some other method for utilising it. As we do not support direct access to the physical address in the stolen region, it behaves like a different class of memory, closer in kin to local GPU memory. This strongly suggests that we need a placement model like TTM if we are to fully utilize these discrete chunks of differing memory. This new create ioctl therefore exists to allow the user to create these second class buffer objects from stolen memory. At the moment direct access by the CPU through mmaps and pread/pwrite are verboten on the objects, and so the user must be aware of the limitations of the objects created. Yet, those limitations rarely reduce the desired functionality in many use cases and so the user should be able to easily fill the stolen memory and so help to reduce overall memory pressure. The most obvious use case for stolen memory is for the creation of objects for the display engine which already have very similar restrictions on access. However, we want a reasonably general ioctl in order to cater for diverse scenarios beyond the author's imagination. Chris Wilson (3): drm/i915: Clearing buffer objects via blitter engine drm/i915: Introduce a new create ioctl for user specified placement drm/i915: Add support for stealing purgable stolen pages drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_dma.c| 11 +- drivers/gpu/drm/i915/i915_drv.h| 18 ++- drivers/gpu/drm/i915/i915_gem.c| 208 ++--- drivers/gpu/drm/i915/i915_gem_exec.c | 120 +++ drivers/gpu/drm/i915/i915_gem_stolen.c | 121 +-- drivers/gpu/drm/i915/i915_gem_tiling.c | 106 + include/uapi/drm/i915_drm.h| 107 + 8 files changed, 607 insertions(+), 85 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_gem_exec.c -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 51/53] drm/i915/bdw: Document Logical Rings, LR contexts and Execlists
> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Friday, June 13, 2014 5:51 PM > To: Mateo Lozano, Oscar > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 51/53] drm/i915/bdw: Document Logical > Rings, LR contexts and Execlists > > On Fri, Jun 13, 2014 at 04:38:09PM +0100, oscar.ma...@intel.com wrote: > > +/** > > + * intel_execlists_ctx_id() - get the Execlists Context ID > > + * @ctx_obj: Logical Ring Context backing object. > > + * > > + * Do not confuse with ctx->id! Unfortunately we have a name overload > > + * here: the old context ID we pass to userspace as a handler so that > > + * they can refer to a context, and the new context ID we pass to the > > + * ELSP so that the GPU can inform us of the context status via > > + * interrupts. > > + * > > + * Return: 20-bits globally unique context ID. > > + */ > > Use tag for the ctx id we pass around in hw? > -Chris I also tried other names, like "submission id", but it confuses people when they search for in the BSpec. Maybe changing ctx->id to ctx->tag, and leaving id for the hardware? -- Oscar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: add missing includes to headers
Signed-off-by: Thomas Wood
---
lib/debug.h | 3 +++
lib/gen7_render.h | 2 ++
lib/igt_aux.h | 1 +
lib/igt_fb.h | 2 ++
lib/igt_kms.h | 1 +
lib/rendercopy.h | 3 +++
6 files changed, 12 insertions(+)
diff --git a/lib/debug.h b/lib/debug.h
index af9cf39..ca4b31e 100644
--- a/lib/debug.h
+++ b/lib/debug.h
@@ -28,6 +28,9 @@
#ifndef _DEBUG_H_
#define _DEBUG_H_
+#include
+#include
+
#define DEBUG_PROTOCOL_VERSION 1
#define COMMUNICATION_OFFSET 0xc00
#define COMMUNICATION_QWORD 0xc0
diff --git a/lib/gen7_render.h b/lib/gen7_render.h
index 992d839..7a6dc05 100644
--- a/lib/gen7_render.h
+++ b/lib/gen7_render.h
@@ -1,6 +1,8 @@
#ifndef GEN7_RENDER_H
#define GEN7_RENDER_H
+#include
+
#define INTEL_MASK(high, low) (((1 << ((high) - (low) + 1)) - 1) << (low))
#define GEN7_3D(Pipeline,Opcode,Subopcode) ((3 << 29) | \
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index db0dea8..a90d8d9 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -29,6 +29,7 @@
#define IGT_AUX_H
#include
+#include
/* auxialiary igt helpers from igt_aux.c */
/* generally useful helpers */
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index c6558bf..6d030e6 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -36,6 +36,8 @@ typedef struct _cairo_surface cairo_surface_t;
typedef struct _cairo cairo_t;
#endif
+#include
+#include
#include
#include
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 17bf0a2..7d015b4 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -30,6 +30,7 @@
#include
#include
+#include
#include
diff --git a/lib/rendercopy.h b/lib/rendercopy.h
index bb9051e..20619d6 100644
--- a/lib/rendercopy.h
+++ b/lib/rendercopy.h
@@ -1,3 +1,6 @@
+#include "intel_batchbuffer.h"
+
+
static inline void emit_vertex_2s(struct intel_batchbuffer *batch,
int16_t x, int16_t y)
{
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/53] drm/i915: Rename ctx->obj to ctx->render_obj
- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Friday, June 13, 2014 6:01 PM > To: Mateo Lozano, Oscar > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 02/53] drm/i915: Rename ctx->obj to ctx- > >render_obj > > On Fri, Jun 13, 2014 at 04:37:20PM +0100, oscar.ma...@intel.com wrote: > > From: Oscar Mateo > > > > The reason for doing this will be better explained in the following > > patch. For now, suffice it to say that this backing object is only > > used with the render ring, so we're making this fact more explicit. > > > > Done with the following Coccinelle patch (plus manual renaming of the > > struct field): > > > > @@ > > struct intel_context c; > > @@ > > - (c).obj > > + c.render_obj > > > > @@ > > struct intel_context *c; > > @@ > > - (c)->obj > > + c->render_obj > > > > Signed-off-by: Oscar Mateo > > Just screamed at this code reviewing a bugfix from Chris and I really like > this. > Can we have a s/is_initialized/render_is_initialized/ on top pls? > > Or does that interfere too much with the series? I didn't look ahead ... > -Daniel No problem, I can add that on top without any hassle. I´ll send it together with a bunch of other prep-work patches. -- Oscar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/53] drm/i915: Move i915_gem_validate_context() to i915_gem_context.c
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, June 13, 2014 6:11 PM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 05/53] drm/i915: Move
> i915_gem_validate_context() to i915_gem_context.c
>
> On Fri, Jun 13, 2014 at 04:37:23PM +0100, oscar.ma...@intel.com wrote:
> > From: Oscar Mateo
> >
> > ... and namespace appropriately.
> >
> > It looks to me like it belongs logically there.
> >
> > Signed-off-by: Oscar Mateo
> > ---
> > drivers/gpu/drm/i915/i915_drv.h| 3 +++
> > drivers/gpu/drm/i915/i915_gem_context.c| 23
> +++
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 25
> > +
> > 3 files changed, 27 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index ec7e352..a15370c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2409,6 +2409,9 @@ int i915_gem_context_create_ioctl(struct
> drm_device *dev, void *data,
> > struct drm_file *file);
> > int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
> >struct drm_file *file);
> > +struct intel_context *
> > +i915_gem_context_validate(struct drm_device *dev, struct drm_file *file,
> > + struct intel_engine_cs *ring, const u32 ctx_id);
> >
> > /* i915_gem_render_state.c */
> > int i915_gem_render_state_init(struct intel_engine_cs *ring); diff
> > --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index f6c2538..801b891 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -824,3 +824,26 @@ int i915_gem_context_destroy_ioctl(struct
> drm_device *dev, void *data,
> > DRM_DEBUG_DRIVER("HW context %d destroyed\n", args->ctx_id);
> > return 0;
> > }
> > +
> > +struct intel_context *
> > +i915_gem_context_validate(struct drm_device *dev, struct drm_file *file,
> > + struct intel_engine_cs *ring, const u32 ctx_id) {
> > + struct intel_context *ctx = NULL;
> > + struct i915_ctx_hang_stats *hs;
> > +
> > + if (ring->id != RCS && ctx_id != DEFAULT_CONTEXT_ID)
> > + return ERR_PTR(-EINVAL);
> > +
> > + ctx = i915_gem_context_get(file->driver_priv, ctx_id);
> > + if (IS_ERR(ctx))
> > + return ctx;
> > +
> > + hs = &ctx->hang_stats;
> > + if (hs->banned) {
> > + DRM_DEBUG("Context %u tried to submit while banned\n",
> ctx_id);
> > + return ERR_PTR(-EIO);
>
> Ugh. No.
> -Chris
D´oh! Why?
- Oscar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/4] drm/i915/vlv: Ack interrupts before handling them (VLV)
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
Without an atomic XCHG operation with mmio space, this patch merely
reduces the window in which we can miss an interrupt (especially when
you consider how heavyweight the I915_READ/I915_WRITE operations are).
Notice that, before clearing a port-sourced interrupt in the IIR, the
corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
cleared.
Spotted by Bob Beckett .
v2:
- Reorder the IIR clearing to reduce the window even further.
- Add warning to commit message and comments to the code as per Chris
Wilson's request.
- Imre Deak pointed out that the pipe underrun flag might not be signaled
in IIR, so do not make valleyview_pipestat_irq_handler depend on it.
v3: Improve the source code comment.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_irq.c | 67 +++--
1 file changed, 38 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a68f68c..20f7c05 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1813,26 +1813,28 @@ static void i9xx_hpd_irq_handler(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
- if (IS_G4X(dev)) {
- u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
+ if (hotplug_status) {
+ I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
+ /*
+* Make sure hotplug status is cleared before we clear IIR, or
else we
+* may miss hotplug events.
+*/
+ POSTING_READ(PORT_HOTPLUG_STAT);
- intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_g4x);
- } else {
- u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
+ if (IS_G4X(dev)) {
+ u32 hotplug_trigger = hotplug_status &
HOTPLUG_INT_STATUS_G4X;
- intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_i915);
- }
+ intel_hpd_irq_handler(dev, hotplug_trigger,
hpd_status_g4x);
+ } else {
+ u32 hotplug_trigger = hotplug_status &
HOTPLUG_INT_STATUS_I915;
- if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) &&
- hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
- dp_aux_irq_handler(dev);
+ intel_hpd_irq_handler(dev, hotplug_trigger,
hpd_status_i915);
+ }
- I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
- /*
-* Make sure hotplug status is cleared before we clear IIR, or else we
-* may miss hotplug events.
-*/
- POSTING_READ(PORT_HOTPLUG_STAT);
+ if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) &&
+ hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
+ dp_aux_irq_handler(dev);
+ }
}
static irqreturn_t valleyview_irq_handler(int irq, void *arg)
@@ -1843,29 +1845,36 @@ static irqreturn_t valleyview_irq_handler(int irq, void
*arg)
irqreturn_t ret = IRQ_NONE;
while (true) {
- iir = I915_READ(VLV_IIR);
+ /* Find, clear, then process each source of interrupt */
+
gt_iir = I915_READ(GTIIR);
+ if (gt_iir)
+ I915_WRITE(GTIIR, gt_iir);
+
pm_iir = I915_READ(GEN6_PMIIR);
+ if (pm_iir)
+ I915_WRITE(GEN6_PMIIR, pm_iir);
+
+ iir = I915_READ(VLV_IIR);
+ if (iir) {
+ /* Consume port before clearing IIR or we'll miss
events */
+ if (iir & I915_DISPLAY_PORT_INTERRUPT)
+ i9xx_hpd_irq_handler(dev);
+ I915_WRITE(VLV_IIR, iir);
+ }
if (gt_iir == 0 && pm_iir == 0 && iir == 0)
goto out;
ret = IRQ_HANDLED;
- snb_gt_irq_handler(dev, dev_priv, gt_iir);
-
- valleyview_pipestat_irq_handler(dev, iir);
-
- /* Consume port. Then clear IIR or we'll miss events */
- if (iir & I915_DISPLAY_PORT_INTERRUPT)
- i9xx_hpd_irq_handler(dev);
-
+ if (gt_iir)
+ snb_gt_irq_handler(dev, dev_priv, gt_iir);
if (pm_iir)
gen6_rps_irq_handler(dev_priv, pm_iir);
-
- I915_WRITE(GTIIR, gt_iir);
- I915_WRITE(GEN6_PMIIR, pm_iir);
- I915_WRITE(VLV_IIR, iir);
+ /* Call regardless, as some status bits might not be
+* signalled in iir */
+ valleyview_pipestat_irq_handler(dev, iir);
}
out:
--
1.9.0
[Intel-gfx] [PATCH v3 3/4] drm/i915/bdw: Ack interrupts before handling them (GEN8)
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
The right order should be:
1 - Disable Master Interrupt Control.
2 - Find the category of interrupt that is pending.
3 - Find the source(s) of the interrupt and clear the Interrupt Identity bits
(IIR)
4 - Process the interrupt(s) that had bits set in the IIRs.
5 - Re-enable Master Interrupt Control.
Without an atomic XCHG operation with mmio space, the above merely reduces the
window
in which we can miss an interrupt (especially when you consider how heavyweight
the
I915_READ/I915_WRITE operations are).
Spotted by Bob Beckett .
v2: Add warning to commit message and comments to the code as per Chris
Wilson's request.
v3: Improve the source code comment.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_irq.c | 91 -
1 file changed, 45 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 20f7c05..46fe3ad 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1462,6 +1462,7 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device
*dev,
if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
tmp = I915_READ(GEN8_GT_IIR(0));
if (tmp) {
+ I915_WRITE(GEN8_GT_IIR(0), tmp);
ret = IRQ_HANDLED;
rcs = tmp >> GEN8_RCS_IRQ_SHIFT;
bcs = tmp >> GEN8_BCS_IRQ_SHIFT;
@@ -1469,7 +1470,6 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device
*dev,
notify_ring(dev, &dev_priv->ring[RCS]);
if (bcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, &dev_priv->ring[BCS]);
- I915_WRITE(GEN8_GT_IIR(0), tmp);
} else
DRM_ERROR("The master control interrupt lied (GT0)!\n");
}
@@ -1477,6 +1477,7 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device
*dev,
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
tmp = I915_READ(GEN8_GT_IIR(1));
if (tmp) {
+ I915_WRITE(GEN8_GT_IIR(1), tmp);
ret = IRQ_HANDLED;
vcs = tmp >> GEN8_VCS1_IRQ_SHIFT;
if (vcs & GT_RENDER_USER_INTERRUPT)
@@ -1484,7 +1485,6 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device
*dev,
vcs = tmp >> GEN8_VCS2_IRQ_SHIFT;
if (vcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, &dev_priv->ring[VCS2]);
- I915_WRITE(GEN8_GT_IIR(1), tmp);
} else
DRM_ERROR("The master control interrupt lied (GT1)!\n");
}
@@ -1492,10 +1492,10 @@ static irqreturn_t gen8_gt_irq_handler(struct
drm_device *dev,
if (master_ctl & GEN8_GT_PM_IRQ) {
tmp = I915_READ(GEN8_GT_IIR(2));
if (tmp & dev_priv->pm_rps_events) {
- ret = IRQ_HANDLED;
- gen8_rps_irq_handler(dev_priv, tmp);
I915_WRITE(GEN8_GT_IIR(2),
tmp & dev_priv->pm_rps_events);
+ ret = IRQ_HANDLED;
+ gen8_rps_irq_handler(dev_priv, tmp);
} else
DRM_ERROR("The master control interrupt lied (PM)!\n");
}
@@ -1503,11 +1503,11 @@ static irqreturn_t gen8_gt_irq_handler(struct
drm_device *dev,
if (master_ctl & GEN8_GT_VECS_IRQ) {
tmp = I915_READ(GEN8_GT_IIR(3));
if (tmp) {
+ I915_WRITE(GEN8_GT_IIR(3), tmp);
ret = IRQ_HANDLED;
vcs = tmp >> GEN8_VECS_IRQ_SHIFT;
if (vcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, &dev_priv->ring[VECS]);
- I915_WRITE(GEN8_GT_IIR(3), tmp);
} else
DRM_ERROR("The master control interrupt lied (GT3)!\n");
}
@@ -2238,36 +2238,36 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
I915_WRITE(GEN8_MASTER_IRQ, 0);
POSTING_READ(GEN8_MASTER_IRQ);
+ /* Find, clear, then process each source of interrupt */
+
ret = gen8_gt_irq_handler(dev, dev_priv, master_ctl);
if (master_ctl & GEN8_DE_MISC_IRQ) {
tmp = I915_READ(GEN8_DE_MISC_IIR);
- if (tmp & GEN8_DE_MISC_GSE)
- intel_opregion_asle_intr(dev);
- else if (tmp)
- DRM_ERROR("Unexpected DE Misc interrupt\n");
- else
- DRM_ERROR("The master control interrupt lied (DE
MISC)!\n");
-
[Intel-gfx] [PATCH v3 1/4] drm/i915: Ack interrupts before handling them (GEN5 - GEN7)
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to ack the first
one, eventually missing it.
According to BSPec, the right order should be:
1 - Disable Master Interrupt Control.
2 - Find the source(s) of the interrupt.
3 - Clear the Interrupt Identity bits (IIR).
4 - Process the interrupt(s) that had bits set in the IIRs.
5 - Re-enable Master Interrupt Control.
Without an atomic XCHG operation with mmio space, the above merely reduces the
window
in which we can miss an interrupt (especially when you consider how heavyweight
the
I915_READ/I915_WRITE operations are).
We maintain the "disable SDE interrupts when handling" hack since apparently it
works.
Spotted by Bob Beckett .
v2: Add warning to commit message and comments to the code as per Chris
Wilson's request.
v3: Improve the source comments.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_irq.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5522cbf..a68f68c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2136,6 +2136,14 @@ static void ivb_display_irq_handler(struct drm_device
*dev, u32 de_iir)
}
}
+/*
+ * To handle irqs with the minimum potential races with fresh interrupts, we:
+ * 1 - Disable Master Interrupt Control.
+ * 2 - Find the source(s) of the interrupt.
+ * 3 - Clear the Interrupt Identity bits (IIR).
+ * 4 - Process the interrupt(s) that had bits set in the IIRs.
+ * 5 - Re-enable Master Interrupt Control.
+ */
static irqreturn_t ironlake_irq_handler(int irq, void *arg)
{
struct drm_device *dev = arg;
@@ -2163,32 +2171,34 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
POSTING_READ(SDEIER);
}
+ /* Find, clear, then process each source of interrupt */
+
gt_iir = I915_READ(GTIIR);
if (gt_iir) {
+ I915_WRITE(GTIIR, gt_iir);
+ ret = IRQ_HANDLED;
if (INTEL_INFO(dev)->gen >= 6)
snb_gt_irq_handler(dev, dev_priv, gt_iir);
else
ilk_gt_irq_handler(dev, dev_priv, gt_iir);
- I915_WRITE(GTIIR, gt_iir);
- ret = IRQ_HANDLED;
}
de_iir = I915_READ(DEIIR);
if (de_iir) {
+ I915_WRITE(DEIIR, de_iir);
+ ret = IRQ_HANDLED;
if (INTEL_INFO(dev)->gen >= 7)
ivb_display_irq_handler(dev, de_iir);
else
ilk_display_irq_handler(dev, de_iir);
- I915_WRITE(DEIIR, de_iir);
- ret = IRQ_HANDLED;
}
if (INTEL_INFO(dev)->gen >= 6) {
u32 pm_iir = I915_READ(GEN6_PMIIR);
if (pm_iir) {
- gen6_rps_irq_handler(dev_priv, pm_iir);
I915_WRITE(GEN6_PMIIR, pm_iir);
ret = IRQ_HANDLED;
+ gen6_rps_irq_handler(dev_priv, pm_iir);
}
}
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 4/4] drm/i915/chv: Ack interrupts before handling them (CHV)
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
Without an atomic XCHG operation with mmio space, this patch merely
reduces the window in which we can miss an interrupt (especially when
you consider how heavyweight the I915_READ/I915_WRITE operations are).
Notice that, before clearing a port-sourced interrupt in the IIR, the
corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
cleared.
Spotted by Bob Beckett .
v2:
- Add warning to commit message and comments to the code as per Chris
Wilson's request.
- Imre Deak pointed out that the pipe underrun flag might not be signaled
in IIR, so do not make valleyview_pipestat_irq_handler depend on it.
v3: Improve the source code comment.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_irq.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 46fe3ad..aa155b5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1895,21 +1895,27 @@ static irqreturn_t cherryview_irq_handler(int irq, void
*arg)
if (master_ctl == 0 && iir == 0)
break;
+ ret = IRQ_HANDLED;
+
I915_WRITE(GEN8_MASTER_IRQ, 0);
- gen8_gt_irq_handler(dev, dev_priv, master_ctl);
+ /* Find, clear, then process each source of interrupt */
- valleyview_pipestat_irq_handler(dev, iir);
+ if (iir) {
+ /* Consume port before clearing IIR or we'll miss
events */
+ if (iir & I915_DISPLAY_PORT_INTERRUPT)
+ i9xx_hpd_irq_handler(dev);
+ I915_WRITE(VLV_IIR, iir);
+ }
- /* Consume port. Then clear IIR or we'll miss events */
- i9xx_hpd_irq_handler(dev);
+ gen8_gt_irq_handler(dev, dev_priv, master_ctl);
- I915_WRITE(VLV_IIR, iir);
+ /* Call regardless, as some status bits might not be
+* signalled in iir */
+ valleyview_pipestat_irq_handler(dev, iir);
I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
POSTING_READ(GEN8_MASTER_IRQ);
-
- ret = IRQ_HANDLED;
}
return ret;
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: ensure igt_display_init clears the memory for the display struct
Add the call to memset that was accidentally removed in: commit 1e9e1baba389fe498be12390ceeeacb1d141a5cf Author: Daniel Vetter Date: Thu Mar 13 17:20:05 2014 +0100 lib/igt_kms: rip out custom verbose loggin support Instead just piggy-pack on top of igt_log. Signed-off-by: Daniel Vetter Signed-off-by: Thomas Wood --- lib/igt_kms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index ec1ab38..1d9362d 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -544,6 +544,8 @@ void igt_display_init(igt_display_t *display, int drm_fd) drmModePlaneRes *plane_resources; int i; + memset(display, 0, sizeof(igt_display_t)); + LOG_INDENT(display, "init"); display->drm_fd = drm_fd; -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Ack interrupts before handling them (GEN5 - GEN7)
On Mon, Jun 16, 2014 at 03:09:24PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Otherwise, we might receive a new interrupt before we have time to ack the
> first
> one, eventually missing it.
>
> According to BSPec, the right order should be:
>
> 1 - Disable Master Interrupt Control.
> 2 - Find the source(s) of the interrupt.
> 3 - Clear the Interrupt Identity bits (IIR).
> 4 - Process the interrupt(s) that had bits set in the IIRs.
> 5 - Re-enable Master Interrupt Control.
>
> Without an atomic XCHG operation with mmio space, the above merely reduces
> the window
> in which we can miss an interrupt (especially when you consider how
> heavyweight the
> I915_READ/I915_WRITE operations are).
>
> We maintain the "disable SDE interrupts when handling" hack since apparently
> it works.
>
> Spotted by Bob Beckett .
>
> v2: Add warning to commit message and comments to the code as per Chris
> Wilson's request.
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_irq.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 5522cbf..7e9fba0 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2147,7 +2147,7 @@ static irqreturn_t ironlake_irq_handler(int irq, void
> *arg)
>* do any I915_{READ,WRITE}. */
> intel_uncore_check_errors(dev);
>
> - /* disable master interrupt before clearing iir */
> + /* 1 - Disable master interrupt */
Sorry to be a nuisance, but I was thinking of more of theory of
operation block at the start of the function as well.
/* To handle irqs with the minimum of potential races with fresh
* interrupts, we
* 1 - Disable Master Interrupt Control.
* 2 - Find the source(s) of the interrupt.
* 3 - Clear the Interrupt Identity bits (IIR).
* 4 - Process the interrupt(s) that had bits set in the IIRs.
* 5 - Re-enable Master Interrupt Control.
*/
Since we have a number of similar irq handlers this can be in a comment
block in just the first handler. And then we leave condensed reminders
in each function. Actually it may work best with this t.o.p. repeated
each time.
> de_ier = I915_READ(DEIER);
> I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
> POSTING_READ(DEIER);
> @@ -2163,37 +2163,43 @@ static irqreturn_t ironlake_irq_handler(int irq, void
> *arg)
> POSTING_READ(SDEIER);
> }
>
> + /* 2 - Find the source(s) of the interrupt. */
/* Find, clear, then process each source of interrupt */
Then drop 3, 4 since we have the overview block and the ordering reminder
here.
> gt_iir = I915_READ(GTIIR);
> if (gt_iir) {
> + /* 3 - Clear the Interrupt Identity bits (IIR) before trying to
> + * handle the interrupt (we have the IIR safely stored) */
> + I915_WRITE(GTIIR, gt_iir);
> + ret = IRQ_HANDLED;
> + /* 4 - Process the interrupt(s) that had bits set in the IIRs.
> */
> if (INTEL_INFO(dev)->gen >= 6)
> snb_gt_irq_handler(dev, dev_priv, gt_iir);
> else
> ilk_gt_irq_handler(dev, dev_priv, gt_iir);
> - I915_WRITE(GTIIR, gt_iir);
> - ret = IRQ_HANDLED;
> }
>
> de_iir = I915_READ(DEIIR);
> if (de_iir) {
> + I915_WRITE(DEIIR, de_iir);
> + ret = IRQ_HANDLED;
> if (INTEL_INFO(dev)->gen >= 7)
> ivb_display_irq_handler(dev, de_iir);
> else
> ilk_display_irq_handler(dev, de_iir);
> - I915_WRITE(DEIIR, de_iir);
> - ret = IRQ_HANDLED;
> }
>
> if (INTEL_INFO(dev)->gen >= 6) {
> u32 pm_iir = I915_READ(GEN6_PMIIR);
> if (pm_iir) {
> - gen6_rps_irq_handler(dev_priv, pm_iir);
> I915_WRITE(GEN6_PMIIR, pm_iir);
> ret = IRQ_HANDLED;
> + gen6_rps_irq_handler(dev_priv, pm_iir);
> }
> }
>
> + /* 5 - Re-enable Master Interrupt Control */
/* Finally re-enable the master interrupt */
> I915_WRITE(DEIER, de_ier);
> POSTING_READ(DEIER);
> +
> if (!HAS_PCH_NOP(dev)) {
> I915_WRITE(SDEIER, sde_ier);
> POSTING_READ(SDEIER);
--
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: Drop WA to fix Voltage not getting dropped to Vmin when Gfx is power gated.
On Friday 13 June 2014 07:24 PM, Daniel Vetter wrote:
On Fri, Jun 13, 2014 at 05:56:41PM +0530, Deepak S wrote:
On Friday 13 June 2014 05:27 PM, Ville Syrjälä wrote:
On Fri, Jun 13, 2014 at 02:33:44PM +0300, Ville Syrjälä wrote:
On Fri, Jun 13, 2014 at 03:46:14PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S
Workaround fixed in BYT. Forcing Gfx clk up not needed, and Requesting the
min freq should bring bring the voltage Vnn.
Signed-off-by: Deepak S
---
drivers/gpu/drm/i915/intel_pm.c | 40 +---
1 file changed, 1 insertion(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0b088fe..9aee28b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3198,44 +3198,6 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
trace_intel_gpu_freq_change(val * 50);
}
-/* vlv_set_rps_idle: Set the frequency to Rpn if Gfx clocks are down
- *
- * * If Gfx is Idle, then
- * 1. Mask Turbo interrupts
- * 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
- * 4. Clear the Force GFX CLK ON bit so that Gfx can down
- * 5. Unmask Turbo interrupts
-*/
-static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
-{
- /*
-* When we are idle. Drop to min voltage state.
-*/
-
- if (dev_priv->rps.cur_freq <= dev_priv->rps.min_freq_softlimit)
- return;
-
- /* Mask turbo interrupt so that they will not come in between */
- I915_WRITE(GEN6_PMINTRMSK, 0x);
-
- vlv_force_gfx_clock(dev_priv, true);
-
- dev_priv->rps.cur_freq = dev_priv->rps.min_freq_softlimit;
-
- vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ,
- dev_priv->rps.min_freq_softlimit);
-
- if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
- & GENFREQSTATUS) == 0, 5))
- DRM_ERROR("timed out waiting for Punit\n");
-
- vlv_force_gfx_clock(dev_priv, false);
-
- I915_WRITE(GEN6_PMINTRMSK,
- gen6_rps_pm_mask(dev_priv, dev_priv->rps.cur_freq));
-}
-
void gen6_rps_idle(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = dev_priv->dev;
@@ -3243,7 +3205,7 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
mutex_lock(&dev_priv->rps.hw_lock);
if (dev_priv->rps.enabled) {
if (IS_VALLEYVIEW(dev))
- vlv_set_rps_idle(dev_priv);
+ valleyview_set_rps(dev_priv->dev,
dev_priv->rps.min_freq_softlimit);
This should take care of https://bugs.freedesktop.org/show_bug.cgi?id=75244
I don't know when the hardware got fixed so I'm hesitant to r-b it, but
at least my C0 works fine without this stuff, so:
Acked-by: Ville Syrjälä
However to avoid future mishaps I think we should have some kind of a
comment before the valleyview_set_rps() call to let the reader know that
we really need this on VLV to drop the voltage.
hmm, Yes we might need this for other stepping. I will add a comment
Please don't put the stepping info in the comment or commit message
though, that freaks out people ;-) Usually we go with "pre-production" or
"early revisions" or something non-specific.
Ok Sure :)
Thanks for the review
Also it now occurs to me that we might be leaving the GPU frequency (and
thus Vnn) high during a system suspend. I think we need an explicit
rps_idle() call in the suspend path somewhere. Runtime suspend should be
fine already since it depends on intel_mark_idle() getting called before
the last rpm reference is dropped.
Maybe this is all we need?
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3768199..fabd852 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4530,7 +4530,7 @@ i915_gem_suspend(struct drm_device *dev)
del_timer_sync(&dev_priv->gpu_error.hangcheck_timer);
cancel_delayed_work_sync(&dev_priv->mm.retire_work);
- cancel_delayed_work_sync(&dev_priv->mm.idle_work);
+ flush_delayed_work(&dev_priv->mm.idle_work);
return 0;
Yes, while suspending we need move GPU to min_freq. flush_delayed_work
should be fine. Let me create a patch for this.
Since this is gt powersave related can you please also check whether we
shouldn't move this to the intel_suspend_gt_powersave function Jesse
recently added to -nightly?
Thanks, Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915/vlv: Ack interrupts before handling them (VLV)
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
Without an atomic XCHG operation with mmio space, this patch merely
reduces the window in which we can miss an interrupt (especially when
you consider how heavyweight the I915_READ/I915_WRITE operations are).
Notice that, before clearing a port-sourced interrupt in the IIR, the
corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
cleared.
Spotted by Bob Beckett .
v2:
- Reorder the IIR clearing to reduce the window even further.
- Add warning to commit message and comments to the code as per Chris
Wilson's request.
- Imre Deak pointed out that the pipe underrun flag might not be signaled
in IIR, so do not make valleyview_pipestat_irq_handler depend on it.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_irq.c | 67 +++--
1 file changed, 38 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7e9fba0..25044e9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1813,26 +1813,28 @@ static void i9xx_hpd_irq_handler(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
- if (IS_G4X(dev)) {
- u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
+ if (hotplug_status) {
+ I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
+ /*
+* Make sure hotplug status is cleared before we clear IIR, or
else we
+* may miss hotplug events.
+*/
+ POSTING_READ(PORT_HOTPLUG_STAT);
- intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_g4x);
- } else {
- u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
+ if (IS_G4X(dev)) {
+ u32 hotplug_trigger = hotplug_status &
HOTPLUG_INT_STATUS_G4X;
- intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_i915);
- }
+ intel_hpd_irq_handler(dev, hotplug_trigger,
hpd_status_g4x);
+ } else {
+ u32 hotplug_trigger = hotplug_status &
HOTPLUG_INT_STATUS_I915;
- if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) &&
- hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
- dp_aux_irq_handler(dev);
+ intel_hpd_irq_handler(dev, hotplug_trigger,
hpd_status_i915);
+ }
- I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
- /*
-* Make sure hotplug status is cleared before we clear IIR, or else we
-* may miss hotplug events.
-*/
- POSTING_READ(PORT_HOTPLUG_STAT);
+ if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) &&
+ hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
+ dp_aux_irq_handler(dev);
+ }
}
static irqreturn_t valleyview_irq_handler(int irq, void *arg)
@@ -1843,29 +1845,36 @@ static irqreturn_t valleyview_irq_handler(int irq, void
*arg)
irqreturn_t ret = IRQ_NONE;
while (true) {
- iir = I915_READ(VLV_IIR);
+ /* Find the source(s) of the interrupt and clear the IIR
+* before processing (the iir values are safely stored) */
gt_iir = I915_READ(GTIIR);
+ if (gt_iir)
+ I915_WRITE(GTIIR, gt_iir);
+
pm_iir = I915_READ(GEN6_PMIIR);
+ if (pm_iir)
+ I915_WRITE(GEN6_PMIIR, pm_iir);
+
+ iir = I915_READ(VLV_IIR);
+ if (iir) {
+ /* Consume port before clearing IIR or we'll miss
events */
+ if (iir & I915_DISPLAY_PORT_INTERRUPT)
+ i9xx_hpd_irq_handler(dev);
+ I915_WRITE(VLV_IIR, iir);
+ }
if (gt_iir == 0 && pm_iir == 0 && iir == 0)
goto out;
ret = IRQ_HANDLED;
- snb_gt_irq_handler(dev, dev_priv, gt_iir);
-
- valleyview_pipestat_irq_handler(dev, iir);
-
- /* Consume port. Then clear IIR or we'll miss events */
- if (iir & I915_DISPLAY_PORT_INTERRUPT)
- i9xx_hpd_irq_handler(dev);
-
+ if (gt_iir)
+ snb_gt_irq_handler(dev, dev_priv, gt_iir);
if (pm_iir)
gen6_rps_irq_handler(dev_priv, pm_iir);
-
- I915_WRITE(GTIIR, gt_iir);
- I915_WRITE(GEN6_PMIIR, pm_iir);
- I915_WRITE(VLV_IIR, iir);
+ /* Call regardless, as some status bits might not be
+* signalled in iir */
+ valleyview_pipestat_irq_handler(dev,
[Intel-gfx] [PATCH v2 3/4] drm/i915/bdw: Ack interrupts before handling them (GEN8)
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
The right order should be:
1 - Disable Master Interrupt Control.
2 - Find the category of interrupt that is pending.
3 - Find the source(s) of the interrupt and clear the Interrupt Identity bits
(IIR)
4 - Process the interrupt(s) that had bits set in the IIRs.
5 - Re-enable Master Interrupt Control.
Without an atomic XCHG operation with mmio space, the above merely reduces the
window
in which we can miss an interrupt (especially when you consider how heavyweight
the
I915_READ/I915_WRITE operations are).
Spotted by Bob Beckett .
v2: Add warning to commit message and comments to the code as per Chris
Wilson's request.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_irq.c | 100 +---
1 file changed, 52 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 25044e9..69c24b0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1462,6 +1462,7 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device
*dev,
if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
tmp = I915_READ(GEN8_GT_IIR(0));
if (tmp) {
+ I915_WRITE(GEN8_GT_IIR(0), tmp);
ret = IRQ_HANDLED;
rcs = tmp >> GEN8_RCS_IRQ_SHIFT;
bcs = tmp >> GEN8_BCS_IRQ_SHIFT;
@@ -1469,7 +1470,6 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device
*dev,
notify_ring(dev, &dev_priv->ring[RCS]);
if (bcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, &dev_priv->ring[BCS]);
- I915_WRITE(GEN8_GT_IIR(0), tmp);
} else
DRM_ERROR("The master control interrupt lied (GT0)!\n");
}
@@ -1477,6 +1477,7 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device
*dev,
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
tmp = I915_READ(GEN8_GT_IIR(1));
if (tmp) {
+ I915_WRITE(GEN8_GT_IIR(1), tmp);
ret = IRQ_HANDLED;
vcs = tmp >> GEN8_VCS1_IRQ_SHIFT;
if (vcs & GT_RENDER_USER_INTERRUPT)
@@ -1484,7 +1485,6 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device
*dev,
vcs = tmp >> GEN8_VCS2_IRQ_SHIFT;
if (vcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, &dev_priv->ring[VCS2]);
- I915_WRITE(GEN8_GT_IIR(1), tmp);
} else
DRM_ERROR("The master control interrupt lied (GT1)!\n");
}
@@ -1492,10 +1492,10 @@ static irqreturn_t gen8_gt_irq_handler(struct
drm_device *dev,
if (master_ctl & GEN8_GT_PM_IRQ) {
tmp = I915_READ(GEN8_GT_IIR(2));
if (tmp & dev_priv->pm_rps_events) {
- ret = IRQ_HANDLED;
- gen8_rps_irq_handler(dev_priv, tmp);
I915_WRITE(GEN8_GT_IIR(2),
tmp & dev_priv->pm_rps_events);
+ ret = IRQ_HANDLED;
+ gen8_rps_irq_handler(dev_priv, tmp);
} else
DRM_ERROR("The master control interrupt lied (PM)!\n");
}
@@ -1503,11 +1503,11 @@ static irqreturn_t gen8_gt_irq_handler(struct
drm_device *dev,
if (master_ctl & GEN8_GT_VECS_IRQ) {
tmp = I915_READ(GEN8_GT_IIR(3));
if (tmp) {
+ I915_WRITE(GEN8_GT_IIR(3), tmp);
ret = IRQ_HANDLED;
vcs = tmp >> GEN8_VECS_IRQ_SHIFT;
if (vcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, &dev_priv->ring[VECS]);
- I915_WRITE(GEN8_GT_IIR(3), tmp);
} else
DRM_ERROR("The master control interrupt lied (GT3)!\n");
}
@@ -2231,41 +2231,45 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
if (!master_ctl)
return IRQ_NONE;
+ /* 1 - Disable Master Interrupt Control. */
I915_WRITE(GEN8_MASTER_IRQ, 0);
POSTING_READ(GEN8_MASTER_IRQ);
- ret = gen8_gt_irq_handler(dev, dev_priv, master_ctl);
-
+ /* 2 - Find the category of interrupt that is pending. */
if (master_ctl & GEN8_DE_MISC_IRQ) {
+ /* 3 - Find the source(s) of the interrupt and clear the
+* Interrupt Identity bits (IIR) */
tmp = I915_READ(GEN8_DE_MISC_IIR);
- if (tmp & GEN8_DE_MISC_GSE)
- intel_opregion_asle_intr(dev);
- else if (t
[Intel-gfx] [PATCH v2 1/4] drm/i915: Ack interrupts before handling them (GEN5 - GEN7)
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to ack the first
one, eventually missing it.
According to BSPec, the right order should be:
1 - Disable Master Interrupt Control.
2 - Find the source(s) of the interrupt.
3 - Clear the Interrupt Identity bits (IIR).
4 - Process the interrupt(s) that had bits set in the IIRs.
5 - Re-enable Master Interrupt Control.
Without an atomic XCHG operation with mmio space, the above merely reduces the
window
in which we can miss an interrupt (especially when you consider how heavyweight
the
I915_READ/I915_WRITE operations are).
We maintain the "disable SDE interrupts when handling" hack since apparently it
works.
Spotted by Bob Beckett .
v2: Add warning to commit message and comments to the code as per Chris
Wilson's request.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_irq.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5522cbf..7e9fba0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2147,7 +2147,7 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
* do any I915_{READ,WRITE}. */
intel_uncore_check_errors(dev);
- /* disable master interrupt before clearing iir */
+ /* 1 - Disable master interrupt */
de_ier = I915_READ(DEIER);
I915_WRITE(DEIER, de_ier & ~DE_MASTER_IRQ_CONTROL);
POSTING_READ(DEIER);
@@ -2163,37 +2163,43 @@ static irqreturn_t ironlake_irq_handler(int irq, void
*arg)
POSTING_READ(SDEIER);
}
+ /* 2 - Find the source(s) of the interrupt. */
gt_iir = I915_READ(GTIIR);
if (gt_iir) {
+ /* 3 - Clear the Interrupt Identity bits (IIR) before trying to
+* handle the interrupt (we have the IIR safely stored) */
+ I915_WRITE(GTIIR, gt_iir);
+ ret = IRQ_HANDLED;
+ /* 4 - Process the interrupt(s) that had bits set in the IIRs.
*/
if (INTEL_INFO(dev)->gen >= 6)
snb_gt_irq_handler(dev, dev_priv, gt_iir);
else
ilk_gt_irq_handler(dev, dev_priv, gt_iir);
- I915_WRITE(GTIIR, gt_iir);
- ret = IRQ_HANDLED;
}
de_iir = I915_READ(DEIIR);
if (de_iir) {
+ I915_WRITE(DEIIR, de_iir);
+ ret = IRQ_HANDLED;
if (INTEL_INFO(dev)->gen >= 7)
ivb_display_irq_handler(dev, de_iir);
else
ilk_display_irq_handler(dev, de_iir);
- I915_WRITE(DEIIR, de_iir);
- ret = IRQ_HANDLED;
}
if (INTEL_INFO(dev)->gen >= 6) {
u32 pm_iir = I915_READ(GEN6_PMIIR);
if (pm_iir) {
- gen6_rps_irq_handler(dev_priv, pm_iir);
I915_WRITE(GEN6_PMIIR, pm_iir);
ret = IRQ_HANDLED;
+ gen6_rps_irq_handler(dev_priv, pm_iir);
}
}
+ /* 5 - Re-enable Master Interrupt Control */
I915_WRITE(DEIER, de_ier);
POSTING_READ(DEIER);
+
if (!HAS_PCH_NOP(dev)) {
I915_WRITE(SDEIER, sde_ier);
POSTING_READ(SDEIER);
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/4] drm/i915/chv: Ack interrupts before handling them (CHV)
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
Without an atomic XCHG operation with mmio space, this patch merely
reduces the window in which we can miss an interrupt (especially when
you consider how heavyweight the I915_READ/I915_WRITE operations are).
Notice that, before clearing a port-sourced interrupt in the IIR, the
corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
cleared.
Spotted by Bob Beckett .
v2:
- Add warning to commit message and comments to the code as per Chris
Wilson's request.
- Imre Deak pointed out that the pipe underrun flag might not be signaled
in IIR, so do not make valleyview_pipestat_irq_handler depend on it.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_irq.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 69c24b0..630b7fc 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1889,27 +1889,33 @@ static irqreturn_t cherryview_irq_handler(int irq, void
*arg)
irqreturn_t ret = IRQ_NONE;
for (;;) {
+ /* Find the source(s) of the interrupt and clear the IIR
+* before processing */
master_ctl = I915_READ(GEN8_MASTER_IRQ) &
~GEN8_MASTER_IRQ_CONTROL;
iir = I915_READ(VLV_IIR);
if (master_ctl == 0 && iir == 0)
break;
+ ret = IRQ_HANDLED;
+
I915_WRITE(GEN8_MASTER_IRQ, 0);
- gen8_gt_irq_handler(dev, dev_priv, master_ctl);
+ if (iir) {
+ /* Consume port before clearing IIR or we'll miss
events */
+ if (iir & I915_DISPLAY_PORT_INTERRUPT)
+ i9xx_hpd_irq_handler(dev);
+ I915_WRITE(VLV_IIR, iir);
+ }
+ /* Call regardless, as some status bits might not be
+* signalled in iir */
valleyview_pipestat_irq_handler(dev, iir);
- /* Consume port. Then clear IIR or we'll miss events */
- i9xx_hpd_irq_handler(dev);
-
- I915_WRITE(VLV_IIR, iir);
+ gen8_gt_irq_handler(dev, dev_priv, master_ctl);
I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
POSTING_READ(GEN8_MASTER_IRQ);
-
- ret = IRQ_HANDLED;
}
return ret;
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] mm: Report attempts to overwrite PTE from remap_pfn_range()
Chris Wilson wrote:
> When using remap_pfn_range() from a fault handler, we are exposed to
> races between concurrent faults. Rather than hitting a BUG, report the
> error back to the caller, like vm_insert_pfn().
>
> Signed-off-by: Chris Wilson
> Cc: Andrew Morton
> Cc: "Kirill A. Shutemov"
> Cc: Peter Zijlstra
> Cc: Rik van Riel
> Cc: Mel Gorman
> Cc: Cyrill Gorcunov
> Cc: Johannes Weiner
> Cc: linux...@kvack.org
> ---
> mm/memory.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 037b812a9531..6603a9e6a731 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2306,19 +2306,23 @@ static int remap_pte_range(struct mm_struct *mm,
> pmd_t *pmd,
> {
> pte_t *pte;
> spinlock_t *ptl;
> + int ret = 0;
>
> pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
> if (!pte)
> return -ENOMEM;
> arch_enter_lazy_mmu_mode();
> do {
> - BUG_ON(!pte_none(*pte));
> + if (!pte_none(*pte)) {
> + ret = -EBUSY;
> + break;
I think you need at least remove entries you've setup if the check failed not
at first iteration.
And nobody propagate your -EBUSY back to remap_pfn_range(): caller will
see -ENOMEM, which is not what you want, I believe.
--
Kirill A. Shutemov
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/vlv: Ack interrupts before handling them (VLV)
On Mon, 2014-06-16 at 12:30 +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Otherwise, we might receive a new interrupt before we have time to
> ack the first one, eventually missing it.
>
> Notice that, before clearing a port-sourced interrupt in the IIR, the
> corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
> cleared.
>
> Spotted by Bob Beckett .
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_irq.c | 61
> +++--
> 1 file changed, 35 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 4439e2d..9d381cc 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1813,26 +1813,28 @@ static void i9xx_hpd_irq_handler(struct drm_device
> *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
>
> - if (IS_G4X(dev)) {
> - u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
> + if (hotplug_status) {
> + I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
> + /*
> + * Make sure hotplug status is cleared before we clear IIR, or
> else we
> + * may miss hotplug events.
> + */
> + POSTING_READ(PORT_HOTPLUG_STAT);
>
> - intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_g4x);
> - } else {
> - u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
> + if (IS_G4X(dev)) {
> + u32 hotplug_trigger = hotplug_status &
> HOTPLUG_INT_STATUS_G4X;
>
> - intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_i915);
> - }
> + intel_hpd_irq_handler(dev, hotplug_trigger,
> hpd_status_g4x);
> + } else {
> + u32 hotplug_trigger = hotplug_status &
> HOTPLUG_INT_STATUS_I915;
>
> - if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) &&
> - hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
> - dp_aux_irq_handler(dev);
> + intel_hpd_irq_handler(dev, hotplug_trigger,
> hpd_status_i915);
> + }
>
> - I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
> - /*
> - * Make sure hotplug status is cleared before we clear IIR, or else we
> - * may miss hotplug events.
> - */
> - POSTING_READ(PORT_HOTPLUG_STAT);
> + if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) &&
> + hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
> + dp_aux_irq_handler(dev);
> + }
> }
>
> static irqreturn_t valleyview_irq_handler(int irq, void *arg)
> @@ -1843,29 +1845,36 @@ static irqreturn_t valleyview_irq_handler(int irq,
> void *arg)
> irqreturn_t ret = IRQ_NONE;
>
> while (true) {
> - iir = I915_READ(VLV_IIR);
> gt_iir = I915_READ(GTIIR);
> pm_iir = I915_READ(GEN6_PMIIR);
> + iir = I915_READ(VLV_IIR);
>
> if (gt_iir == 0 && pm_iir == 0 && iir == 0)
> goto out;
>
> - ret = IRQ_HANDLED;
> + if (gt_iir)
> + I915_WRITE(GTIIR, gt_iir);
>
> - snb_gt_irq_handler(dev, dev_priv, gt_iir);
> + if (pm_iir)
> + I915_WRITE(GEN6_PMIIR, pm_iir);
>
> - valleyview_pipestat_irq_handler(dev, iir);
> + if (iir) {
> + /* Consume port. Then clear IIR or we'll miss events */
> + if (iir & I915_DISPLAY_PORT_INTERRUPT)
> + i9xx_hpd_irq_handler(dev);
> + I915_WRITE(VLV_IIR, iir);
> + }
>
> - /* Consume port. Then clear IIR or we'll miss events */
> - if (iir & I915_DISPLAY_PORT_INTERRUPT)
> - i9xx_hpd_irq_handler(dev);
> + ret = IRQ_HANDLED;
> +
> + if (gt_iir)
> + snb_gt_irq_handler(dev, dev_priv, gt_iir);
>
> if (pm_iir)
> gen6_rps_irq_handler(dev_priv, pm_iir);
>
> - I915_WRITE(GTIIR, gt_iir);
> - I915_WRITE(GEN6_PMIIR, pm_iir);
> - I915_WRITE(VLV_IIR, iir);
> + if (iir)
> + valleyview_pipestat_irq_handler(dev, iir);
Afaik the pipe underrun flag handled in
valleyview_pipestat_irq_handler() is not signaled in IIR, although bspec
is rather unclear about this.
--Imre
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/vlv: Ack interrupts before handling them (VLV)
On Mon, Jun 16, 2014 at 12:30:27PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Otherwise, we might receive a new interrupt before we have time to
> ack the first one, eventually missing it.
>
> Notice that, before clearing a port-sourced interrupt in the IIR, the
> corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
> cleared.
I believe PIPESTAT (and actually all multi-level interrupts) should be
handled the same way.
The way I would write interrupt handlers is something like this:
{
iir = read(IIR);
if (iir & X) {
iir_x = read(IIR_X);
write(IIR_X, iir_x);
}
if (iir & Y) {
iir_y = read(IIR_Y);
write(IIR_Y, iir_y);
}
...
write(IIR, iir);
process_x(iir_x);
process_y(iir_y);
...
}
And then we hope the hardware is sane enough to keep the IIR bit high as
long as the relevant sub-IIR bits are high, and also that the CPU interrupt
would be re-raised if any IIR bits are high when exiting the interrupt
handler. But I have the impression our hardware isn't quite that sane.
>
> Spotted by Bob Beckett .
>
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/i915_irq.c | 61
> +++--
> 1 file changed, 35 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 4439e2d..9d381cc 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1813,26 +1813,28 @@ static void i9xx_hpd_irq_handler(struct drm_device
> *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
>
> - if (IS_G4X(dev)) {
> - u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
> + if (hotplug_status) {
> + I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
> + /*
> + * Make sure hotplug status is cleared before we clear IIR, or
> else we
> + * may miss hotplug events.
> + */
> + POSTING_READ(PORT_HOTPLUG_STAT);
>
> - intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_g4x);
> - } else {
> - u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
> + if (IS_G4X(dev)) {
> + u32 hotplug_trigger = hotplug_status &
> HOTPLUG_INT_STATUS_G4X;
>
> - intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_i915);
> - }
> + intel_hpd_irq_handler(dev, hotplug_trigger,
> hpd_status_g4x);
> + } else {
> + u32 hotplug_trigger = hotplug_status &
> HOTPLUG_INT_STATUS_I915;
>
> - if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) &&
> - hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
> - dp_aux_irq_handler(dev);
> + intel_hpd_irq_handler(dev, hotplug_trigger,
> hpd_status_i915);
> + }
>
> - I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
> - /*
> - * Make sure hotplug status is cleared before we clear IIR, or else we
> - * may miss hotplug events.
> - */
> - POSTING_READ(PORT_HOTPLUG_STAT);
> + if ((IS_G4X(dev) || IS_VALLEYVIEW(dev)) &&
> + hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
> + dp_aux_irq_handler(dev);
> + }
> }
>
> static irqreturn_t valleyview_irq_handler(int irq, void *arg)
> @@ -1843,29 +1845,36 @@ static irqreturn_t valleyview_irq_handler(int irq,
> void *arg)
> irqreturn_t ret = IRQ_NONE;
>
> while (true) {
> - iir = I915_READ(VLV_IIR);
> gt_iir = I915_READ(GTIIR);
> pm_iir = I915_READ(GEN6_PMIIR);
> + iir = I915_READ(VLV_IIR);
>
> if (gt_iir == 0 && pm_iir == 0 && iir == 0)
> goto out;
>
> - ret = IRQ_HANDLED;
> + if (gt_iir)
> + I915_WRITE(GTIIR, gt_iir);
>
> - snb_gt_irq_handler(dev, dev_priv, gt_iir);
> + if (pm_iir)
> + I915_WRITE(GEN6_PMIIR, pm_iir);
>
> - valleyview_pipestat_irq_handler(dev, iir);
> + if (iir) {
> + /* Consume port. Then clear IIR or we'll miss events */
> + if (iir & I915_DISPLAY_PORT_INTERRUPT)
> + i9xx_hpd_irq_handler(dev);
> + I915_WRITE(VLV_IIR, iir);
> + }
>
> - /* Consume port. Then clear IIR or we'll miss events */
> - if (iir & I915_DISPLAY_PORT_INTERRUPT)
> - i9xx_hpd_irq_handler(dev);
> + ret = IRQ_HANDLED;
> +
> + if (gt_iir)
> + snb_gt_irq_handler(dev, dev_priv, gt_iir);
>
> if (pm_iir)
> gen6_rps_irq_handler(dev_priv, pm_iir);
>
> - I915_WRITE(GTIIR, gt_iir);
> - I
Re: [Intel-gfx] [PATCH] intel-gpu-tools: remove the --cmd option from gem_seqno_wrap
tim.g...@intel.com writes:
> From: Tim Gore
>
> gem_seqno_wrap was not being built on Android because it uses
> wordexp which is not in Bionic.
> After discussion with Mika Kuoppala (the test author) it seems
> that wordexp was used to implement the --cmd option that was
> really only intended for use during development of the test and
> is no longer needed. So I have removed support for this option
> and enabled this test for Android.
>
> Signed-off-by: Tim Gore
Reviewed-by: Mika Kuoppala
> ---
> tests/Android.mk | 1 -
> tests/gem_seqno_wrap.c | 77
> ++
> 2 files changed, 3 insertions(+), 75 deletions(-)
>
> diff --git a/tests/Android.mk b/tests/Android.mk
> index 9db6625..f085d35 100644
> --- a/tests/Android.mk
> +++ b/tests/Android.mk
> @@ -28,7 +28,6 @@ endef
>
> # some tests still do not build under android
> skip_tests_list :=
> -skip_tests_list += gem_seqno_wrap
> skip_tests_list += testdisplay# needs glib.h
> skip_tests_list += pm_rpm
>
> diff --git a/tests/gem_seqno_wrap.c b/tests/gem_seqno_wrap.c
> index fa38f1f..ad4f839 100644
> --- a/tests/gem_seqno_wrap.c
> +++ b/tests/gem_seqno_wrap.c
> @@ -38,7 +38,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -62,7 +61,6 @@ static struct intel_batchbuffer *batch_3d;
> struct option_struct {
> int rounds;
> int background;
> - char cmd[1024];
> int timeout;
> int dontwrap;
> int prewrap_space;
> @@ -281,64 +279,6 @@ static void run_sync_test(int num_buffers, bool verify)
> close(fd);
> }
>
> -static int run_cmd(char *s)
> -{
> - int pid;
> - int r = -1;
> - int status = 0;
> - wordexp_t wexp;
> - int i;
> - r = wordexp(s, &wexp, 0);
> - if (r != 0) {
> - printf("can't parse %s\n", s);
> - return r;
> - }
> -
> - for(i = 0; i < wexp.we_wordc; i++)
> - printf("argv[%d] = %s\n", i, wexp.we_wordv[i]);
> -
> - pid = fork();
> -
> - if (pid == 0) {
> - char path[PATH_MAX];
> - char full_path[PATH_MAX];
> -
> - if (getcwd(path, PATH_MAX) == NULL)
> - perror("getcwd");
> -
> - igt_assert(snprintf(full_path, PATH_MAX, "%s/%s", path,
> wexp.we_wordv[0]) > 0);
> -
> - r = execv(full_path, wexp.we_wordv);
> - if (r == -1)
> - perror("execv failed");
> - } else {
> - int waitcount = options.timeout;
> -
> - while(waitcount-- > 0) {
> - r = waitpid(pid, &status, WNOHANG);
> - if (r == pid) {
> - if(WIFEXITED(status)) {
> - if (WEXITSTATUS(status))
> - fprintf(stderr,
> - "child returned with %d\n",
> - WEXITSTATUS(status));
> - return WEXITSTATUS(status);
> - }
> - } else if (r != 0) {
> - perror("waitpid");
> - return -errno;
> - }
> -
> - sleep(3);
> - }
> -
> - kill(pid, SIGKILL);
> - return -ETIMEDOUT;
> - }
> -
> - return r;
> -}
> -
> static const char *dfs_base = "/sys/kernel/debug/dri";
> static const char *dfs_entry = "i915_next_seqno";
>
> @@ -415,7 +355,7 @@ static int write_seqno(uint32_t seqno)
> int fh;
> char buf[32];
> int r;
> - uint32_t rb;
> + uint32_t rb = -1;
>
> if (options.dontwrap)
> return 0;
> @@ -461,10 +401,7 @@ static uint32_t calc_prewrap_val(void)
>
> static void run_test(void)
> {
> - if (strnlen(options.cmd, sizeof(options.cmd)) > 0)
> - igt_assert(run_cmd(options.cmd) == 0);
> - else
> - run_sync_test(options.buffers, true);
> + run_sync_test(options.buffers, true);
> }
>
> static void preset_run_once(void)
> @@ -521,7 +458,6 @@ static void print_usage(const char *s)
> printf("%s: [OPTION]...\n", s);
> printf("where options are:\n");
> printf("-b --background run in background inducing wraps\n");
> - printf("-c --cmd=cmdstringuse cmdstring to cross wrap\n");
> printf("-n --rounds=num run num times across wrap boundary, 0
> == forever\n");
> printf("-t --timeout=sec set timeout to wait for testrun to
> sec seconds\n");
> printf("-d --dontwrap don't wrap just run the test\n");
> @@ -536,7 +472,6 @@ static void parse_options(int argc, char **argv)
> int c;
> int option_index = 0;
> static struct option long_options[] = {
> - {"cmd", required_argument, 0, 'c'},
>
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Ack interrupts before handling them (GEN5 - GEN7)
On Mon, Jun 16, 2014 at 12:30:26PM +0100, oscar.ma...@intel.com wrote: > From: Oscar Mateo > > Otherwise, we might receive a new interrupt before we have time to ack the > first > one, eventually missing it. Without a atomic xchg operation with mmio space, we merely reduce the window. This is even more apparent when you consider how heavyweight those I915_READ/I915_WRITE are. > According to BSPec, the right order should be: > > 1 - Disable Master Interrupt Control. > 2 - Find the source(s) of the interrupt and clear the Interrupt Identity bits > (IIR) > 4 - Process the interrupt(s) that had bits set in the IIRs. > 5 - Re-enable Master Interrupt Control. > > We maintain the "disable SDE interrupts when handling" hack since apparently > it works. > > Spotted by Bob Beckett . > > Signed-off-by: Oscar Mateo I'd like the changelog slightly clarified, and the notes here would be useful in the code as well to describe the theory of operation in handling IRQ. -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
