[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [1/3] drm/i915: rename macro parameter(ring) to (engine)

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: rename macro parameter(ring) to 
(engine)
URL   : https://patchwork.freedesktop.org/series/10101/
State : success

== Summary ==

Series 10101v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/10101/revisions/1/mbox


fi-hsw-i7-4770k  total:244  pass:216  dwarn:0   dfail:0   fail:8   skip:20 
fi-kbl-qkkr  total:244  pass:179  dwarn:27  dfail:1   fail:9   skip:28 
fi-skl-i5-6260u  total:244  pass:224  dwarn:0   dfail:0   fail:8   skip:12 
fi-skl-i7-6700k  total:244  pass:210  dwarn:0   dfail:0   fail:8   skip:26 
fi-snb-i7-2600   total:244  pass:196  dwarn:0   dfail:0   fail:8   skip:40 
ro-bdw-i5-5250u  total:244  pass:219  dwarn:4   dfail:0   fail:8   skip:13 
ro-bdw-i7-5600u  total:244  pass:204  dwarn:0   dfail:0   fail:8   skip:32 
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:244  pass:197  dwarn:0   dfail:0   fail:9   skip:38 
ro-hsw-i3-4010u  total:244  pass:212  dwarn:0   dfail:0   fail:8   skip:24 
ro-hsw-i7-4770r  total:244  pass:212  dwarn:0   dfail:0   fail:8   skip:24 
ro-ilk1-i5-650   total:239  pass:172  dwarn:0   dfail:0   fail:9   skip:58 
ro-ivb-i7-3770   total:244  pass:203  dwarn:0   dfail:0   fail:8   skip:33 
ro-skl3-i5-6260u total:244  pass:224  dwarn:0   dfail:0   fail:8   skip:12 
ro-snb-i7-2620M  total:244  pass:193  dwarn:0   dfail:0   fail:9   skip:42 
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1549/

621e9dc drm-intel-nightly: 2016y-07m-20d-19h-19m-37s UTC integration manifest
b261a98 drm/i915: rename & update eb_select_ring()
a062554 drm/i915: rename 'ring' where it refers to an engine or engine_id
24e57f2 drm/i915: rename macro parameter(ring) to (engine)

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

Re: [Intel-gfx] [PATCH] drm/vgem: Allow root to inject hanging fences onto dmabufs

[Chris Wilson]

On Wed, Jul 20, 2016 at 04:28:40PM -0700, Kristian Høgsberg wrote:
> Why is this useful if only root can use it?

> > When performing driver testing, one factor we want to test is how we
> > handle a foreign fence that is never signaled. We can wait on that fence
> > indefinitely, in which case the driver appears hung, or we can take some
> > remedial action (with risks regarding the state of any shared content).
> > Whatever the action choosen by the driver, in order to perform the test
> > we want to disable the safety feature of vgem fence (which is then used
> > to test implicit dma-buf fencing). This is regarded as a highly
> > dangerous feature and so hidden behind an expert config option and only
> > available to root when enabled.

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

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Use rt priority kthread to do GuC log buffer sampling

[Chris Wilson]

On Thu, Jul 21, 2016 at 09:11:42AM +0530, Goel, Akash wrote:
> 
> 
> On 7/21/2016 1:04 AM, Chris Wilson wrote:
> >In the end, just the silly locking and placement of complete_all() is
> >dangerous. reinit_completion() lacks the barrier to be used like this
> >really, at any rate, racy with the irq handler, so use sparingly or when
> >you control the irq handler.
> Sorry I forgot to add a comment that
> guc_cancel_log_flush_work_sync() should be invoked only after
> ensuring that there will be no more flush interrupts, which will
> happen either by explicitly disabling the interrupt or disabling the
> logging and that's what is done at the 2 call sites.
> 
> Since had covered reinit_completion() under the irq_lock, thought an
> explicit barrier is not needed.

You hadn't controlled everything via the irq_lock, and nor should you.

> 
>   spin_lock_irq(_priv->irq_lock);
>   if (guc->log.flush_signal) {
>   guc->log.flush_signal = false;
>   reinit_completion(>log.flush_completion);
>   spin_unlock_irq(_priv->irq_lock);
>   i915_guc_capture_logs(_priv->drm);
>   complete_all(>log.flush_completion);
> 
> The placement of complete_all isn't right for the case, where
> a guc_cancel_log_flush_work_sync() is called but there was no prior
> flush interrupt received.

Exactly.
 
> >(Also not sure if log.signal = 0 is sane,
> Did log.signal = 0 for fast cancellation. Will remove that.
> 
> A smp_wmb() after reinit_completion(_completion) would be fine ?

Don't worry, the race can only be controlled by controlling the irq. In
the end, I think something more like

while (signal) ...

complete_all();
schedule();
reinit_completion();

is the simplest.

> >or the current callsites really require the flush.)
> 
> Sync against a ongoing/pending flush is being done for the 2
> forceful flush cases, which will be effective only if the pending
> flush is completed, so forceful flush should be serialized with a
> pending flush.

Or you just signal=true, wakeup task, wait_timeout. Otherwise you
haven't really serialized anything without disabling the interrupt.
-Chris

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

Re: [Intel-gfx] [PATCH v3 0/4] Enable lspcon support for GEN9 devices

[Sharma, Shashank]

> Oh. Do we have some idea of the power cost?
> Curiously when I tried to measure the idle power consumption on my BSW, DP 
> seemed to be a bit less hungry than HDMI. But I guess the PCON stuff itself 
> will use some amount of power which might offset any benefit from using DP on 
> the SoC side.
You are right, the power side would be slightly higher than the LS mode. 
But there were following cases where we were supposed to be on PCON mode, 
regardless of pixel clock of requested mode:
- If monitor is HDCP 2.2 capable
- If monitor is trying YUV 420 playback
- If clock > 297 Mhz

So there were lesses cases left to keep LSPCON in LS mode. 
When we compared the code complexity of maintaining LS and PCON mode both, with 
the use cases, we thought it would be simpler and better to be in PCON mode. 

> The encoder->type swithing is still a problem. Though I suppose it will be 
> fairly well masked if you always have DPCD avaailable.
Not really, now we are always in DP mode. So display controller will be always 
driving as encoder->type = DP. 
The only changes required now is:
- During the bootup, detect presence of a LSPCON based on VBT, and mark it. 
- During EDID read, if this is LSPCON port, use a separate i2c adapter (well 
suggested by you in previous review comments :))
- During AVI IF writes, write into LSPCON registers, instead of / on top of 
display registers. 

Do you think its ok to be going now ? Any further suggestions are welcome. 

Regards
Shashank 
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
Sent: Wednesday, July 20, 2016 10:21 PM
To: Sharma, Shashank 
Cc: intel-gfx@lists.freedesktop.org; rodrigo.v...@gmail.com; Vivi, Rodrigo 
; Zanoni, Paulo R 
Subject: Re: [PATCH v3 0/4] Enable lspcon support for GEN9 devices

On Wed, Jul 20, 2016 at 04:16:30PM +, Sharma, Shashank wrote:
> Hi Ville.
> 
> > This thing seems to be missing a lot of stuff:
> > - where is the EDID etc. handling?
> None required for LSPCON as of now.
> The 4k@60 pixel clock support was already added with SKL, so we can 
> see a HDMI 4k@60 output already on PCON mode, when connected to a 4k@60 
> monitor.
> 
> I have started publishing a separate patch series to support HDMI 2.0, 
> started with the new aspect ratio patches here. I was hoping to proceed with 
> EDID changes, once we get these in, else the patch series gets huge and 
> reviewers find it difficult to review. 
> https://patchwork.freedesktop.org/patch/78308/
>  
> Plan is to publish in this sequence:
> - Add new aspect ratios
> - Add new 4k modes in DRM EDID
> - Add Scrambling support
> - Add SCDC parsing
> - Add YUV 420 CEA-861-F block parsing
> and so on. 
> 
> > - based on my DDI output_types stuff, I was expecting to see an  
> > lspcon .compute_output_type() hook that returns whether we need
>  >  LS or PCON mode. Can't see anything of the sort here.
> As I explained in the commit message/cover letter LSPCON is no more working 
> selectively on LS/PCON mode.

Oh. Do we have some idea of the power cost?

Curiously when I tried to measure the idle power consumption on my BSW, DP 
seemed to be a bit less hungry than HDMI. But I guess the PCON stuff itself 
will use some amount of power which might offset any benefit from using DP on 
the SoC side.


> We are driving it in always PCON mode, and driver always drives a DP.  So we 
> are driving a DP with separate detection sequence. 
> 
> > Also the main patch [1] of my DDI output_types series still didn't get 
> > reviewed...
> Ok, but that should not be a blocker for this series, should it ? 

The encoder->type swithing is still a problem. Though I suppose it will be 
fairly well masked if you always have DPCD avaailable.

> 
> Regards
> Shashank
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Wednesday, July 20, 2016 6:39 PM
> To: Sharma, Shashank 
> Cc: intel-gfx@lists.freedesktop.org; rodrigo.v...@gmail.com; Vivi, 
> Rodrigo ; Zanoni, Paulo R 
> 
> Subject: Re: [PATCH v3 0/4] Enable lspcon support for GEN9 devices
> 
> On Tue, Jul 05, 2016 at 06:35:46PM +0530, Shashank Sharma wrote:
> > LSPCON is essentially a dp++->hdmi adapter with dual mode of operation.
> > 
> > These modes are:
> > - Level Shifter mode: In LS mode, this device works as a type2
> > dp->hdmi passive dongle, which steps up DP++ output to appropriate HDMI 1.4 
> > signal.
> > This mode doesn't do any conversion at the protocol level.
> > 
> > - Protocol Converter mode: In PCON mode, this device acts as an 
> > active
> > DP++->HDMI 2.0 dongle, which converts the DP++ output to compatible
> > HDMI 2.0 output. In PCON mode, lspcon can support 4k@60 outputs, 
> > using DP HBR2 mode.
> > 
> > Many of Intel GEN9 devices come with in-built lspcon card in 
> > motherboartd down mode. This patch series 

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Use rt priority kthread to do GuC log buffer sampling

[Goel, Akash]

On 7/21/2016 1:04 AM, Chris Wilson wrote:

On Sun, Jul 10, 2016 at 07:11:24PM +0530, akash.g...@intel.com wrote:

@@ -1707,8 +1692,8 @@ static void gen9_guc_irq_handler(struct drm_i915_private 
*dev_priv, u32 gt_iir)
I915_READ(SOFT_SCRATCH(15)) & ~msg);

/* Handle flush interrupt event in bottom half 
*/
-   queue_work(dev_priv->guc.log.wq,
-   _priv->guc.events_work);
+   smp_store_mb(dev_priv->guc.log.flush_signal, 1);
+   wake_up_process(dev_priv->guc.log.flush_task);
}



+void guc_cancel_log_flush_work_sync(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(_priv->irq_lock);
+   dev_priv->guc.log.flush_signal = false;
+   spin_unlock_irq(_priv->irq_lock);
+
+   if (dev_priv->guc.log.flush_task)
+   wait_for_completion(_priv->guc.log.flush_completion);
+}
+
+static int guc_log_flush_worker(void *arg)
+{
+   struct drm_i915_private *dev_priv = arg;
+   struct intel_guc *guc = _priv->guc;
+
+   /* Install ourselves with high priority to reduce signalling latency */
+   struct sched_param param = { .sched_priority = 1 };
+   sched_setscheduler_nocheck(current, SCHED_FIFO, );
+
+   do {
+   set_current_state(TASK_INTERRUPTIBLE);
+
+   spin_lock_irq(_priv->irq_lock);
+   if (guc->log.flush_signal) {
+   guc->log.flush_signal = false;
+   reinit_completion(>log.flush_completion);
+   spin_unlock_irq(_priv->irq_lock);
+   i915_guc_capture_logs(_priv->drm);
+   complete_all(>log.flush_completion);
+   } else {
+   spin_unlock_irq(_priv->irq_lock);
+   if (kthread_should_stop())
+   break;
+
+   schedule();
+   }
+   } while (1);
+   __set_current_state(TASK_RUNNING);
+
+   return 0;


This looks decidely fishy.


Sorry for that.


irq handler:
smp_store_mb(log.signal, 1);
wake_up_process(log.tsk);

worker:
do {
set_current_state(TASK_INT);

while (cmpxchg(, 1, 0)) {
reinit_completion(log.complete);
i915_guc_capture_logs();
}

complete_all(log.complete);
if (kthread_should_stop())
break;

schedule();
} while(1);
__set_current_state(TASK_RUNNING);

flush:
smp_store_mb(log.signal, 0);
wait_for_completion(log.complete);


In the end, just the silly locking and placement of complete_all() is
dangerous. reinit_completion() lacks the barrier to be used like this
really, at any rate, racy with the irq handler, so use sparingly or when
you control the irq handler.
Sorry I forgot to add a comment that guc_cancel_log_flush_work_sync() 
should be invoked only after ensuring that there will be no more flush 
interrupts, which will happen either by explicitly disabling the 
interrupt or disabling the logging and that's what is done at the 2 call 
sites.


Since had covered reinit_completion() under the irq_lock, thought an 
explicit barrier is not needed.


spin_lock_irq(_priv->irq_lock);
if (guc->log.flush_signal) {
guc->log.flush_signal = false;
reinit_completion(>log.flush_completion);
spin_unlock_irq(_priv->irq_lock);
i915_guc_capture_logs(_priv->drm);
complete_all(>log.flush_completion);

The placement of complete_all isn't right for the case, where
a guc_cancel_log_flush_work_sync() is called but there was no prior 
flush interrupt received.



(Also not sure if log.signal = 0 is sane,

Did log.signal = 0 for fast cancellation. Will remove that.

A smp_wmb() after reinit_completion(_completion) would be fine ?


or the current callsites really require the flush.)


Sync against a ongoing/pending flush is being done for the 2 forceful 
flush cases, which will be effective only if the pending flush is 
completed, so forceful flush should be serialized with a pending flush.


Best regards
Akash


-Chris


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

Re: [Intel-gfx] [PATCH v2] drm/i915:gen9: restrict WaC6DisallowByGfxPause

[Kamble, Sagar A]

Reviewed-by: Sagar Arun Kamble 

On 7/20/2016 3:30 PM, tim.g...@intel.com wrote:

From: Tim Gore 

WaC6DisallowByGfxPause is currently applied unconditionally
but is not required in all revisions.

v2: extend application of workaround to agree with w/a
database, which differs from the HSD.

References: HSD#2133391
Signed-off-by: Tim Gore 
---
  drivers/gpu/drm/i915/intel_guc_loader.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 605c696..96b0259 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -349,7 +349,9 @@ static int guc_ucode_xfer(struct drm_i915_private *dev_priv)
}
  
  	/* WaC6DisallowByGfxPause*/

-   I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
+   if (IS_SKL_REVID(dev, 0, SKL_REVID_C0) ||
+   IS_BXT_REVID(dev, 0, BXT_REVID_B0))
+   I915_WRITE(GEN6_GFXPAUSE, 0x30FFF);
  
  	if (IS_BROXTON(dev))

I915_WRITE(GEN9LP_GT_PM_CONFIG, GT_DOORBELL_ENABLE);


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

Re: [Intel-gfx] [PATCH 4/6] drm/i915/skl: Always wait for pipes to update after a flush

[Matt Roper]

On Wed, Jul 20, 2016 at 05:00:00PM -0400, Lyude wrote:
> As we've learned, all watermark updates on Skylake have to be strictly
> atomic or things fail. While the bspec doesn't mandate that we need to
> wait for pipes to finish after the third iteration of flushes, not doing
> so gives us the opportunity to break this atomicity later. This example
> assumes that we're lucky enough not to be interrupted by the scheduler
> at any point during this:
> 
>  - Start with pipe A and pipe B enabled
>  - Enable pipe C
>  - Flush pipe A in pass 1, wait until update finishes
>  - Flush pipe B in pass 3, continue without waiting for next vblank
>  - Start another wm update
>  - We enter the next vblank for pipe B before we finish writing all the
>vm values
>  - *Underrun*
> 
> As such, we always need to wait for each pipe we flush to update so as
> to never break this atomicity.

I'm not sure I follow this commit.  If we're enabling a new pipe, the
the allocation for A and B are generally going to shrink, so they'll
usually be flushed in passes 1 and 2, not 3.

My understanding is that the problem that still remains (now that your
first three patches have made progress towards fixing underruns) is that
our DDB updates and flushes (which come from update_watermarks) happen
pre-evasion, whereas the watermarks themselves now happen under evasion.
We really want both the new DDB value and the new watermark value to be
written together and take effect on the same vblank.  I think the
problem is that you might have a shrinking DDB allocation (e.g., because
a new pipe was added or you changed a mode that changed the DDB balance)
which some of the existing WM values exceed.  You can have a sequence
like this:

  - update_wm:
 - write new (smaller) DDB
 - flush DDB
  - vblank happens, old (big) wm + new (small) ddb = underrun
  - vblank evasion:
 - write new plane regs and WM's
 - flush
  - post-evasion vblank happens, underrun is corrected

I think ultimately we want to move the DDB register writes into the
update functions that happen under evasion, just like you did for the WM
registers.  However just doing this the straightforward way won't
satisfy our requirements about pipe update ordering (the three passes
you see today in skl_flush_wm_values).  To make that work, I think the
general approach is that we need to basically replace the
for_each_crtc_in_state() loop in intel_atomic_commit_tail() with some
new CRTC iterator that processes CRTC's in a more intelligent ordering.
We've computed our DDB changes during the atomic check phase, so we
already know which allocations are shrinking, growing, etc. and we
should be able to calculate an appropriate CRTC ordering at the same
time.

With an intelligent CRTC iterator that follows the pre-computed pipe
ordering rules (and adds the necessary vblank waits between each
"phase"), I think we should be able to just write both DDB and WM values
in the skl_update_primary_plane() and similar functions and let the
existing flushes that happen take care of flushing them out at the
appropriate time.  Of course I've kicked that idea around in my head for
a while, but haven't had time to actually write any code for it, so I
may be completely overlooking some stumbling block that makes it much
more complicated than I'm envisioning.


Matt

> 
> Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
> Signed-off-by: Lyude 
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede  
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 788db86..2e31df4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3859,8 +3859,11 @@ static void skl_flush_wm_values(struct 
> drm_i915_private *dev_priv,
>   /*
>* Third pass: flush the pipes that got more space allocated.
>*
> -  * We don't need to actively wait for the update here, next vblank
> -  * will just get more DDB space with the correct WM values.
> +  * While the hardware doesn't require to wait for the next vblank here,
> +  * continuing before the pipe finishes updating could result in us
> +  * trying to update the wm values again before the pipe finishes
> +  * updating, which results in the hardware using intermediate wm values
> +  * and subsequently underrunning pipes.
>*/
>   for_each_intel_crtc(dev, crtc) {
>   if (!crtc->active)
> @@ -3876,6 +3879,16 @@ static void skl_flush_wm_values(struct 
> drm_i915_private *dev_priv,
>   continue;
>  
>   

Re: [Intel-gfx] [PATCH] drm/vgem: Allow root to inject hanging fences onto dmabufs

[Kristian Høgsberg]

Why is this useful if only root can use it?

Kristian

On Wed, Jul 20, 2016 at 12:39 PM, Chris Wilson  wrote:
> When performing driver testing, one factor we want to test is how we
> handle a foreign fence that is never signaled. We can wait on that fence
> indefinitely, in which case the driver appears hung, or we can take some
> remedial action (with risks regarding the state of any shared content).
> Whatever the action choosen by the driver, in order to perform the test
> we want to disable the safety feature of vgem fence (which is then used
> to test implicit dma-buf fencing). This is regarded as a highly
> dangerous feature and so hidden behind an expert config option and only
> available to root when enabled.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/Kconfig   | 13 +
>  drivers/gpu/drm/vgem/vgem_fence.c | 14 --
>  include/uapi/drm/vgem_drm.h   |  1 +
>  3 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index fc357319de35..2b25bc38fad2 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -228,6 +228,19 @@ config DRM_VGEM
>   as used by Mesa's software renderer for enhanced performance.
>   If M is selected the module will be called vgem.
>
> +config DRM_VGEM_FENCE_HANG
> +   bool "Enable fence hang testing (DANGEROUS)"
> +   depends on DRM_VGEM
> +   depends on EXPERT
> +   depends on !COMPILE_TEST
> +   default n
> +   help
> + Enables support for root to use indefinite fences.
> + Do not enable this unless you are testing DRM drivers.
> +
> + Recommended for driver developers only.
> +
> + If in doubt, say "N".
>
>  source "drivers/gpu/drm/exynos/Kconfig"
>
> diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
> b/drivers/gpu/drm/vgem/vgem_fence.c
> index 5c57c1ffa1f9..91d3d75fc9c5 100644
> --- a/drivers/gpu/drm/vgem/vgem_fence.c
> +++ b/drivers/gpu/drm/vgem/vgem_fence.c
> @@ -107,7 +107,8 @@ static struct fence *vgem_fence_create(struct vgem_file 
> *vfile,
> setup_timer(>timer, vgem_fence_timeout, (unsigned long)fence);
>
> /* We force the fence to expire within 10s to prevent driver hangs */
> -   mod_timer(>timer, jiffies + VGEM_FENCE_TIMEOUT);
> +   if ((flags & VGEM_FENCE_NOTIMEOUT) == 0)
> +   mod_timer(>timer, jiffies + VGEM_FENCE_TIMEOUT);
>
> return >base;
>  }
> @@ -160,9 +161,18 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
> struct fence *fence;
> int ret;
>
> -   if (arg->flags & ~VGEM_FENCE_WRITE)
> +   if (arg->flags & ~(VGEM_FENCE_WRITE | VGEM_FENCE_NOTIMEOUT))
> return -EINVAL;
>
> +   if (arg->flags & VGEM_FENCE_NOTIMEOUT) {
> +   if (config_enabled(CONFIG_DRM_VGEM_FENCE_HANG)) {
> +   if (!capable(CAP_SYS_ADMIN))
> +   return -EPERM;
> +   } else {
> +   return -EINVAL;
> +   }
> +   }
> +
> if (arg->pad)
> return -EINVAL;
>
> diff --git a/include/uapi/drm/vgem_drm.h b/include/uapi/drm/vgem_drm.h
> index bf66f5db6da8..55fd08750773 100644
> --- a/include/uapi/drm/vgem_drm.h
> +++ b/include/uapi/drm/vgem_drm.h
> @@ -46,6 +46,7 @@ struct drm_vgem_fence_attach {
> __u32 handle;
> __u32 flags;
>  #define VGEM_FENCE_WRITE   0x1
> +#define VGEM_FENCE_NOTIMEOUT   0x2
> __u32 out_fence;
> __u32 pad;
>  };
> --
> 2.8.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/6] drm/i915/skl: Actually reuse wm values when pipes don't change

[Matt Roper]

On Wed, Jul 20, 2016 at 04:59:59PM -0400, Lyude wrote:
> Up until now we've actually been making the mistake of leaving the
> watermark results for each pipe completely blank in skl_compute_wm()
> when they haven't changed, fix this.

Should this be moved before patch #1?  With the existing code we don't
try to re-write watermark registers if they aren't changing, so leaving
them at zero should be safe.  I think we want to make this change before
we start re-writing non-dirty watermarks.  Alternatively, we could just
add the dirty bit test to the appropriate places in patch #1 and not
worry about copying over the unchanged values.


Matt

> 
> Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 
> 'check' (v2)")
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede  
> Cc: Matt Roper 
> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b7d4af1..788db86 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3987,10 +3987,13 @@ skl_copy_wm_for_pipe(struct skl_wm_values *dst,
>  static int
>  skl_compute_wm(struct drm_atomic_state *state)
>  {
> + struct drm_device *dev = state->dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *cstate;
>   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>   struct skl_wm_values *results = _state->wm_results;
> + struct skl_wm_values *hw_wm = _priv->wm.skl_hw;
>   struct skl_pipe_wm *pipe_wm;
>   bool changed = false;
>   int ret, i;
> @@ -4039,12 +4042,14 @@ skl_compute_wm(struct drm_atomic_state *state)
>   if (changed)
>   results->dirty_pipes |= drm_crtc_mask(crtc);
>  
> - if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
> + if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0) {
>   /* This pipe's WM's did not change */
> + skl_copy_wm_for_pipe(results, hw_wm, intel_crtc->pipe);
>   continue;
> + }
>  
>   intel_cstate->update_wm_pre = true;
> - skl_compute_wm_results(crtc->dev, pipe_wm, results, intel_crtc);
> + skl_compute_wm_results(dev, pipe_wm, results, intel_crtc);
>   }
>  
>   return 0;
> -- 
> 2.7.4
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

[Matt Roper]

On Wed, Jul 20, 2016 at 04:59:58PM -0400, Lyude wrote:
> From: Matt Roper 
> 
> When we write watermark values to the hardware, those values are stored
> in dev_priv->wm.skl_hw.  However with recent watermark changes, the
> results structure we're copying from only contains valid watermark and
> DDB values for the pipes that are actually changing; the values for
> other pipes remain 0.  Thus a blind copy of the entire skl_wm_values
> structure will clobber the values for unchanged pipes...we need to be
> more selective and only copy over the values for the changing pipes.
> 
> This mistake was hidden until recently due to another bug that caused us
> to erroneously re-calculate watermarks for all active pipes rather than
> changing pipes.  Only when that bug was fixed was the impact of this bug
> discovered (e.g., modesets failing with "Requested display configuration
> exceeds system watermark limitations" messages and leaving watermarks
> non-functional, even ones initiated by intel_fbdev_restore_mode).
> 
> Changes since v1:
>  - Add a function for copying a pipe's wm values
>(skl_copy_wm_for_pipe()) so we can reuse this later

Your changes look good to me.

Reviewed-by: Matt Roper 

> 
> Cc: Maarten Lankhorst 
> Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 
> 'check' (v2)")
> Fixes: 9b6130227495 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
> Signed-off-by: Matt Roper 
> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 28 ++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fa86bea..b7d4af1 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3966,6 +3966,24 @@ skl_compute_ddb(struct drm_atomic_state *state)
>   return 0;
>  }
>  
> +static void
> +skl_copy_wm_for_pipe(struct skl_wm_values *dst,
> +  struct skl_wm_values *src,
> +  enum pipe pipe)
> +{
> + dst->wm_linetime[pipe] = src->wm_linetime[pipe];
> + memcpy(dst->plane[pipe], src->plane[pipe],
> +sizeof(dst->plane[pipe]));
> + memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
> +sizeof(dst->plane_trans[pipe]));
> +
> + dst->ddb.pipe[pipe] = src->ddb.pipe[pipe];
> + memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
> +sizeof(dst->ddb.y_plane[pipe]));
> + memcpy(dst->ddb.plane[pipe], src->ddb.plane[pipe],
> +sizeof(dst->ddb.plane[pipe]));
> +}
> +
>  static int
>  skl_compute_wm(struct drm_atomic_state *state)
>  {
> @@ -4038,8 +4056,10 @@ static void skl_update_wm(struct drm_crtc *crtc)
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct skl_wm_values *results = _priv->wm.skl_results;
> + struct skl_wm_values *hw_vals = _priv->wm.skl_hw;
>   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
>   struct skl_pipe_wm *pipe_wm = >wm.skl.optimal;
> + int pipe;
>  
>   if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
>   return;
> @@ -4051,8 +4071,12 @@ static void skl_update_wm(struct drm_crtc *crtc)
>   skl_write_wm_values(dev_priv, results);
>   skl_flush_wm_values(dev_priv, results);
>  
> - /* store the new configuration */
> - dev_priv->wm.skl_hw = *results;
> + /*
> +  * Store the new configuration (but only for the pipes that have
> +  * changed; the other values weren't recomputed).
> +  */
> + for_each_pipe_masked(dev_priv, pipe, results->dirty_pipes)
> + skl_copy_wm_for_pipe(hw_vals, results, pipe);
>  
>   mutex_unlock(_priv->wm.wm_mutex);
>  }
> -- 
> 2.7.4
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] drm/i915/skl: Update plane watermarks atomically during plane updates

[Matt Roper]

On Wed, Jul 20, 2016 at 04:59:57PM -0400, Lyude wrote:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
> 
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them won't take effect until said registers are
> "armed", which is done by writing to the PLANE_SURF (or in the case of
> cursor planes, the CURBASE register) register.
> 
> With this in mind, up until now we've been updating watermarks on skl
> like this:
> 
>   non-modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - intel_pre_plane_update:
> - intel_update_watermarks()
>  - {vblank happens; new watermarks + old plane values => underrun }
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - end vblank evasion
>   }
> 
>   or
> 
>   modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - crtc_enable:
> - intel_update_watermarks()
>  - {vblank happens; new watermarks + old plane values => underrun }
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - end vblank evasion
>   }
> 
> Now we update watermarks atomically like this:
> 
>   non-modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - intel_pre_plane_update:
> - intel_update_watermarks() (wm values aren't written yet)
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
> - write new wm values
> - end vblank evasion
>   }
> 
>   modeset {
>- calculate (during atomic check phase)
>- finish_atomic_commit:
>  - crtc_enable:
> - intel_update_watermarks() (actual wm values aren't written
>   yet)
>  - drm_atomic_helper_commit_planes_on_crtc:
> - start vblank evasion
> - write new plane registers
>   - write new wm values
> - end vblank evasion
>   }
> 
> Which is more of a step in the right direction to fixing all of the
> underrun issues we're currently seeing with skl

So my understanding of this patch is that it moves watermark value
writes to the right place (inside the vblank evasion where we write the
rest of the plane registers), but we aren't tackling the problems with
DDB writes & flushing order yet, so we don't expect everything to be
fixed yet, right?  You might want to clarify that slightly in the commit
message here. 

One other comment inline below.

> 
> Changes since original patch series:
> - Remove mutex_lock/mutex_unlock since they don't do anything and we're
>   not touching global state
> - Move skl_write_cursor_wm/skl_write_plane_wm functions into intel_pm.c, make
>   externally visible
> - Add skl_write_plane_wm calls to skl_update_plane
> - Fix conditional for for loop in skl_write_plane_wm (level < max_level
>   should be level <= max_level)
> - Make diagram in commit more accurate to what's actually happening
> - Add Fixes:
> 
> Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
> Signed-off-by: Lyude 
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede  
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_display.c |  5 
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_pm.c  | 48 
> +---
>  drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
>  4 files changed, 43 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 78beb7e..c0d2074 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3031,6 +3031,8 @@ static void skylake_update_primary_plane(struct 
> drm_plane *plane,
>   intel_crtc->adjusted_x = x_offset;
>   intel_crtc->adjusted_y = y_offset;
>  
> + skl_write_plane_wm(intel_crtc, 0);
> +
>   I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
>   I915_WRITE(PLANE_OFFSET(pipe, 0), plane_offset);
>   I915_WRITE(PLANE_SIZE(pipe, 0), plane_size);
> @@ -10242,6 +10244,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
> u32 base,
>   int pipe = intel_crtc->pipe;
>   uint32_t cntl = 0;
>  
> + if (IS_SKYLAKE(dev_priv))

I believe this should be IS_GEN9 so that it applies to BXT and KBL too.


Matt

> + skl_write_cursor_wm(intel_crtc);
> +
>   if (plane_state && plane_state->visible) {
>   cntl = MCURSOR_GAMMA_ENABLE;
>   switch (plane_state->base.crtc_w) {
> 

Re: [Intel-gfx] [PATCH 23/23] drm/i915: Move HAS_GMCH_DISPLAY definition to platform

[Rodrigo Vivi]

well... this is where one inheriting and extending the previous make
it a bit ugly...
you would need to set it to 0 at GEN5_FEATURES. maybe with a comment
/* support discontinued */


On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 4 ++--
>  drivers/gpu/drm/i915/i915_pci.c | 5 +
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7075f76..b9d0478 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -784,6 +784,7 @@ struct intel_csr {
> func(has_hw_contexts) sep \
> func(has_logical_ring_contexts) sep \
> func(has_l3_dpf) sep \
> +   func(has_gmch_display) sep \
> func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> @@ -2907,8 +2908,7 @@ struct drm_i915_cmd_table {
>  #define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
>  #define HAS_PCH_SPLIT(dev) (INTEL_PCH_TYPE(dev) != PCH_NONE)
>
> -#define HAS_GMCH_DISPLAY(dev) (INTEL_INFO(dev)->gen < 5 || \
> -  IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
> +#define HAS_GMCH_DISPLAY(dev) (INTEL_INFO(dev)->has_gmch_display)
>
>  /* DPF == dynamic parity feature */
>  #define HAS_L3_DPF(dev) (INTEL_INFO(dev)->has_l3_dpf)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index c03cb97..59f3e35 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -57,6 +57,7 @@
>  #define GEN2_FEATURES \
> .gen = 2, .num_pipes = 1, \
> .has_overlay = 1, .overlay_needs_physical = 1, \
> +   .has_gmch_display = 1, \
> .ring_mask = RENDER_RING, \
> GEN_DEFAULT_PIPEOFFSETS, \
> CURSOR_OFFSETS
> @@ -84,6 +85,7 @@ static const struct intel_device_info intel_i865g_info = {
>  #define GEN3_FEATURES \
> .gen = 3, .num_pipes = 2, \
> .has_fw_blc = 1, \
> +   .has_gmch_display = 1, \
> .ring_mask = RENDER_RING, \
> GEN_DEFAULT_PIPEOFFSETS, \
> CURSOR_OFFSETS
> @@ -124,6 +126,7 @@ static const struct intel_device_info intel_i945gm_info = 
> {
> .gen = 4, .num_pipes = 2, \
> .has_hotplug = 1, \
> .has_fw_blc = 1, \
> +   .has_gmch_display = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> CURSOR_OFFSETS
>
> @@ -272,6 +275,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
> .has_gmbus_irq = 1, \
> .has_fw_blc = 1, \
> .has_hw_contexts = 1, \
> +   .has_gmch_display = 1, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -357,6 +361,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .has_fw_blc = 1,
> .has_hw_contexts = 1,
> .has_logical_ring_contexts = 1,
> +   .has_gmch_display = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 22/23] drm/i915: Move HAS_L3_DPF definition to platform definition

[Rodrigo Vivi]

This patch is adding support to l3_dpf to bdw, skl and kbl...

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 6 --
>  2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8f93a93..7075f76 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -783,6 +783,7 @@ struct intel_csr {
> func(has_fw_blc) sep \
> func(has_hw_contexts) sep \
> func(has_logical_ring_contexts) sep \
> +   func(has_l3_dpf) sep \
> func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> @@ -2910,7 +2911,7 @@ struct drm_i915_cmd_table {
>IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
>
>  /* DPF == dynamic parity feature */
> -#define HAS_L3_DPF(dev) (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
> +#define HAS_L3_DPF(dev) (INTEL_INFO(dev)->has_l3_dpf)
>  #define NUM_L3_SLICES(dev) (IS_HSW_GT3(dev) ? 2 : HAS_L3_DPF(dev))
>
>  #define GT_FREQUENCY_MULTIPLIER 50
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index d90cb47..c03cb97 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -240,7 +240,8 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
> IVB_CURSOR_OFFSETS
>
>  #define IVB_FEATURES  \
> -   .has_rc6p = 1
> +   .has_rc6p = 1, \
> +   .has_l3_dpf = 1
>
>  static const struct intel_device_info intel_ivybridge_d_info = {
> GEN7_FEATURES,
> @@ -296,7 +297,8 @@ static const struct intel_device_info 
> intel_valleyview_d_info = {
> .has_psr = 1, \
> .has_runtime_pm = 1, \
> .has_resource_streamer = 1, \
> -   .has_dp_mst = 1
> +   .has_dp_mst = 1, \
> +   .has_l3_dpf = 1
>
>  static const struct intel_device_info intel_haswell_d_info = {
> HSW_FEATURES,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 21/23] drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform definition

[Rodrigo Vivi]

Reviewed-by: Rodrigo Vivi 

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 5 -
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 06d2850..8f93a93 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -782,6 +782,7 @@ struct intel_csr {
> func(has_gmbus_irq) sep \
> func(has_fw_blc) sep \
> func(has_hw_contexts) sep \
> +   func(has_logical_ring_contexts) sep \
> func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> @@ -2816,7 +2817,7 @@ struct drm_i915_cmd_table {
>  #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
>
>  #define HAS_HW_CONTEXTS(dev)   (INTEL_INFO(dev)->has_hw_contexts)
> -#define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 8)
> +#define HAS_LOGICAL_RING_CONTEXTS(dev) 
> (INTEL_INFO(dev)->has_logical_ring_contexts)
>  #define USES_PPGTT(dev)(i915.enable_ppgtt)
>  #define USES_FULL_PPGTT(dev)   (i915.enable_ppgtt >= 2)
>  #define USES_FULL_48BIT_PPGTT(dev) (i915.enable_ppgtt == 3)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 26ff54e..d90cb47 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -311,7 +311,8 @@ static const struct intel_device_info 
> intel_haswell_m_info = {
>
>  #define BDW_FEATURES \
> HSW_FEATURES, \
> -   BDW_COLORS
> +   BDW_COLORS, \
> +   .has_logical_ring_contexts = 1
>
>  static const struct intel_device_info intel_broadwell_d_info = {
> BDW_FEATURES,
> @@ -353,6 +354,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .has_gmbus_irq = 1,
> .has_fw_blc = 1,
> .has_hw_contexts = 1,
> +   .has_logical_ring_contexts = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> @@ -396,6 +398,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
> .has_gmbus_irq = 1,
> .has_fw_blc = 1,
> .has_hw_contexts = 1,
> +   .has_logical_ring_contexts = 1,
> GEN_DEFAULT_PIPEOFFSETS,
> IVB_CURSOR_OFFSETS,
> BDW_COLORS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 20/23] drm/i915: Move HAS_HW_CONTEXTS definition to platform

[Rodrigo Vivi]

this patch could be cleaner if on gen inherit and extend the previous.

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumpig struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8f5b9fd..06d2850 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -781,6 +781,7 @@ struct intel_csr {
> func(has_aux_irq) sep \
> func(has_gmbus_irq) sep \
> func(has_fw_blc) sep \
> +   func(has_hw_contexts) sep \
> func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> @@ -2814,7 +2815,7 @@ struct drm_i915_cmd_table {
>  HAS_EDRAM(dev))
>  #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
>
> -#define HAS_HW_CONTEXTS(dev)   (INTEL_INFO(dev)->gen >= 6)
> +#define HAS_HW_CONTEXTS(dev)   (INTEL_INFO(dev)->has_hw_contexts)
>  #define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 8)
>  #define USES_PPGTT(dev)(i915.enable_ppgtt)
>  #define USES_FULL_PPGTT(dev)   (i915.enable_ppgtt >= 2)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index b44d162..26ff54e 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -209,6 +209,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
> .has_aux_irq = 1, \
> .has_gmbus_irq = 1, \
> .has_fw_blc = 1, \
> +   .has_hw_contexts = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -232,6 +233,7 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
> .has_aux_irq = 1, \
> .has_gmbus_irq = 1, \
> .has_fw_blc = 1, \
> +   .has_hw_contexts = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -268,6 +270,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
> .has_aux_irq = 1, \
> .has_gmbus_irq = 1, \
> .has_fw_blc = 1, \
> +   .has_hw_contexts = 1, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -349,6 +352,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .has_aux_irq = 1,
> .has_gmbus_irq = 1,
> .has_fw_blc = 1,
> +   .has_hw_contexts = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> @@ -391,6 +395,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
> .has_aux_irq = 1,
> .has_gmbus_irq = 1,
> .has_fw_blc = 1,
> +   .has_hw_contexts = 1,
> GEN_DEFAULT_PIPEOFFSETS,
> IVB_CURSOR_OFFSETS,
> BDW_COLORS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 19/23] drm/915: Move HAS_FW_BLC definition to platform

[Rodrigo Vivi]

this patch could be cleaner if on gen inherit and extend the previous.

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform definition allows for
> - standard placae when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 10 +-
>  2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a58765b..8f5b9fd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -780,6 +780,7 @@ struct intel_csr {
> func(has_dp_mst) sep \
> func(has_aux_irq) sep \
> func(has_gmbus_irq) sep \
> +   func(has_fw_blc) sep \
> func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> @@ -2848,7 +2849,7 @@ struct drm_i915_cmd_table {
>  #define SUPPORTS_TV(dev)   (INTEL_INFO(dev)->supports_tv)
>  #define I915_HAS_HOTPLUG(dev)   (INTEL_INFO(dev)->has_hotplug)
>
> -#define HAS_FW_BLC(dev) (INTEL_INFO(dev)->gen > 2)
> +#define HAS_FW_BLC(dev) (INTEL_INFO(dev)->has_fw_blc)
>  #define HAS_PIPE_CXSR(dev) (INTEL_INFO(dev)->has_pipe_cxsr)
>  #define HAS_FBC(dev) (INTEL_INFO(dev)->has_fbc)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 50569c1..b44d162 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -82,7 +82,8 @@ static const struct intel_device_info intel_i865g_info = {
>  };
>
>  #define GEN3_FEATURES \
> -   .gen = 3, .num_pipes = 2,\
> +   .gen = 3, .num_pipes = 2, \
> +   .has_fw_blc = 1, \
> .ring_mask = RENDER_RING, \
> GEN_DEFAULT_PIPEOFFSETS, \
> CURSOR_OFFSETS
> @@ -122,6 +123,7 @@ static const struct intel_device_info intel_i945gm_info = 
> {
>  #define GEN4_FEATURES \
> .gen = 4, .num_pipes = 2, \
> .has_hotplug = 1, \
> +   .has_fw_blc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> CURSOR_OFFSETS
>
> @@ -180,6 +182,7 @@ static const struct intel_device_info intel_pineview_info 
> = {
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .has_aux_irq = 1, \
> .has_gmbus_irq = 1, \
> +   .has_fw_blc = 1, \
> .ring_mask = RENDER_RING | BSD_RING, \
> GEN_DEFAULT_PIPEOFFSETS, \
> CURSOR_OFFSETS
> @@ -205,6 +208,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
> .has_rc6p = 1, \
> .has_aux_irq = 1, \
> .has_gmbus_irq = 1, \
> +   .has_fw_blc = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -227,6 +231,7 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
> .has_rc6 = 1, \
> .has_aux_irq = 1, \
> .has_gmbus_irq = 1, \
> +   .has_fw_blc = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -262,6 +267,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
> .has_rc6 = 1, \
> .has_aux_irq = 1, \
> .has_gmbus_irq = 1, \
> +   .has_fw_blc = 1, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -342,6 +348,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .has_dp_mst = 1,
> .has_aux_irq = 1,
> .has_gmbus_irq = 1,
> +   .has_fw_blc = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> @@ -383,6 +390,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
> .has_rc6 = 1,
> .has_aux_irq = 1,
> .has_gmbus_irq = 1,
> +   .has_fw_blc = 1,
> GEN_DEFAULT_PIPEOFFSETS,
> IVB_CURSOR_OFFSETS,
> BDW_COLORS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 18/23] drm/i915: Introduce GEN2 FEATURES for device info

[Rodrigo Vivi]

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Based on the GEN7_FEATURES changes from Ben W.
>
> Use it for 830, 845g, i85x, i865g.
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 33 +
>  1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 5c490f8..50569c1 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -54,38 +54,31 @@
>  #define CHV_COLORS \
> .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
>
> +#define GEN2_FEATURES \
> +   .gen = 2, .num_pipes = 1, \
> +   .has_overlay = 1, .overlay_needs_physical = 1, \
> +   .ring_mask = RENDER_RING, \
> +   GEN_DEFAULT_PIPEOFFSETS, \
> +   CURSOR_OFFSETS
> +
>  static const struct intel_device_info intel_i830_info = {
> -   .gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
> -   .has_overlay = 1, .overlay_needs_physical = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +   GEN2_FEATURES,
> +   .is_mobile = 1, .cursor_needs_physical = 1,
>  };
>
>  static const struct intel_device_info intel_845g_info = {
> -   .gen = 2, .num_pipes = 1,
> -   .has_overlay = 1, .overlay_needs_physical = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +   GEN2_FEATURES,
>  };
>
>  static const struct intel_device_info intel_i85x_info = {
> -   .gen = 2, .is_i85x = 1, .is_mobile = 1, .num_pipes = 2,
> +   GEN2_FEATURES,

this patch is reducing the number of supported pipes for this platform.

> +   .is_i85x = 1, .is_mobile = 1,
> .cursor_needs_physical = 1,
> -   .has_overlay = 1, .overlay_needs_physical = 1,
> .has_fbc = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
>  };
>
>  static const struct intel_device_info intel_i865g_info = {
> -   .gen = 2, .num_pipes = 1,
> -   .has_overlay = 1, .overlay_needs_physical = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +   GEN2_FEATURES,
>  };
>
>  #define GEN3_FEATURES \
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 17/23] drm/i915: Introduce GEN3_FEATURES for device info

[Rodrigo Vivi]

same as previous patch

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Based on the GEN7_FEATURES changes from Ben W.
>
> Use it for i915g, i915gm, i945g, i945gm, g33 and pineview.
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 58 
> -
>  1 file changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index c4fdb4d..5c490f8 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -88,39 +88,42 @@ static const struct intel_device_info intel_i865g_info = {
> CURSOR_OFFSETS,
>  };
>
> +#define GEN3_FEATURES \
> +   .gen = 3, .num_pipes = 2,\
> +   .ring_mask = RENDER_RING, \
> +   GEN_DEFAULT_PIPEOFFSETS, \
> +   CURSOR_OFFSETS
> +
> +#define GEN3_i9X5_FEATURES \
> +   .cursor_needs_physical = 1, \
> +   .has_overlay = 1, \
> +   .overlay_needs_physical = 1
> +
>  static const struct intel_device_info intel_i915g_info = {
> -   .gen = 3, .is_i915g = 1, .cursor_needs_physical = 1, .num_pipes = 2,
> -   .has_overlay = 1, .overlay_needs_physical = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +   GEN3_FEATURES,
> +   GEN3_i9X5_FEATURES,
> +   .is_i915g = 1,
> +
>  };
>  static const struct intel_device_info intel_i915gm_info = {
> -   .gen = 3, .is_mobile = 1, .num_pipes = 2,
> -   .cursor_needs_physical = 1,
> -   .has_overlay = 1, .overlay_needs_physical = 1,
> +   GEN3_FEATURES,
> +   GEN3_i9X5_FEATURES,
> +   .is_mobile = 1,
> .supports_tv = 1,
> .has_fbc = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
>  };
>  static const struct intel_device_info intel_i945g_info = {
> -   .gen = 3, .has_hotplug = 1, .cursor_needs_physical = 1, .num_pipes = 
> 2,
> -   .has_overlay = 1, .overlay_needs_physical = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +   GEN3_FEATURES,
> +   GEN3_i9X5_FEATURES,
> +   .has_hotplug = 1,
>  };
>  static const struct intel_device_info intel_i945gm_info = {
> -   .gen = 3, .is_i945gm = 1, .is_mobile = 1, .num_pipes = 2,
> -   .has_hotplug = 1, .cursor_needs_physical = 1,
> -   .has_overlay = 1, .overlay_needs_physical = 1,
> +   GEN3_FEATURES,
> +   GEN3_i9X5_FEATURES,
> +   .is_i945gm = 1, .is_mobile = 1,
> +   .has_hotplug = 1,
> .supports_tv = 1,
> .has_fbc = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
>  };
>
>  #define GEN4_FEATURES \
> @@ -154,12 +157,10 @@ static const struct intel_device_info intel_i965gm_info 
> = {
>  };
>
>  static const struct intel_device_info intel_g33_info = {
> -   .gen = 3, .is_g33 = 1, .num_pipes = 2,
> +   GEN3_FEATURES,
> +   .is_g33 = 1,
> .need_gfx_hws = 1, .has_hotplug = 1,
> .has_overlay = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
>  };
>
>  static const struct intel_device_info intel_g45_info = {
> @@ -175,11 +176,10 @@ static const struct intel_device_info intel_gm45_info = 
> {
>  };
>
>  static const struct intel_device_info intel_pineview_info = {
> -   .gen = 3, .is_g33 = 1, .is_pineview = 1, .is_mobile = 1, .num_pipes = 
> 2,
> +   GEN3_FEATURES,
> +   .is_g33 = 1, .is_pineview = 1, .is_mobile = 1,
> .need_gfx_hws = 1, .has_hotplug = 1,
> .has_overlay = 1,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
>  };
>
>  #define GEN5_FEATURES \
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/23] drm/i915: Introduce GEN4_FEATURES for device info

[Rodrigo Vivi]

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Based on the GEN7_FEATURES changes from Ben W.
>
> Use it for i965g, i965gm, g45,and gm45.
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 51 
> ++---
>  1 file changed, 28 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 4652e2d..c4fdb4d 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -123,23 +123,34 @@ static const struct intel_device_info intel_i945gm_info 
> = {
> CURSOR_OFFSETS,
>  };
>
> +#define GEN4_FEATURES \
> +   .gen = 4, .num_pipes = 2, \
> +   .has_hotplug = 1, \
> +   GEN_DEFAULT_PIPEOFFSETS, \
> +   CURSOR_OFFSETS
> +

I like this

> +#define GEN4_G45_FEATURES \
> +   .is_g4x = 1, .need_gfx_hws = 1, \
> +   .has_pipe_cxsr = 1, \
> +   .ring_mask = RENDER_RING | BSD_RING
> +
> +#define GEN4_i965_FEATURES \
> +   .has_overlay = 1, \
> +   .ring_mask = RENDER_RING
> +

but I believe these should be handled separated/individually
unless they inherit GEN4_FEATURES somehow...

>  static const struct intel_device_info intel_i965g_info = {
> -   .gen = 4, .is_broadwater = 1, .num_pipes = 2,
> -   .has_hotplug = 1,
> -   .has_overlay = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +   GEN4_FEATURES,
> +   GEN4_i965_FEATURES,
> +   .is_broadwater = 1,
> +
>  };
>
>  static const struct intel_device_info intel_i965gm_info = {
> -   .gen = 4, .is_crestline = 1, .num_pipes = 2,
> -   .is_mobile = 1, .has_fbc = 1, .has_hotplug = 1,
> -   .has_overlay = 1,
> +   GEN4_FEATURES,
> +   GEN4_i965_FEATURES,

... to avoid these 2 macros here.

> +   .is_crestline = 1,
> +   .is_mobile = 1, .has_fbc = 1,
> .supports_tv = 1,
> -   .ring_mask = RENDER_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
>  };
>
>  static const struct intel_device_info intel_g33_info = {
> @@ -152,21 +163,15 @@ static const struct intel_device_info intel_g33_info = {
>  };
>
>  static const struct intel_device_info intel_g45_info = {
> -   .gen = 4, .is_g4x = 1, .need_gfx_hws = 1, .num_pipes = 2,
> -   .has_pipe_cxsr = 1, .has_hotplug = 1,
> -   .ring_mask = RENDER_RING | BSD_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +   GEN4_FEATURES,
> +   GEN4_G45_FEATURES,
>  };
>
>  static const struct intel_device_info intel_gm45_info = {
> -   .gen = 4, .is_g4x = 1, .num_pipes = 2,
> -   .is_mobile = 1, .need_gfx_hws = 1, .has_fbc = 1,
> -   .has_pipe_cxsr = 1, .has_hotplug = 1,
> +   GEN4_FEATURES,
> +   GEN4_G45_FEATURES,
> +   .is_mobile = 1, .has_fbc = 1,
> .supports_tv = 1,
> -   .ring_mask = RENDER_RING | BSD_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
>  };
>
>  static const struct intel_device_info intel_pineview_info = {
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 15/23] drm/i915: Move HAS_GMBUS_IRQ definition to platform definition

[Rodrigo Vivi]

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 6 ++
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 26283b5..a58765b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -779,6 +779,7 @@ struct intel_csr {
> func(has_rc6p) sep \
> func(has_dp_mst) sep \
> func(has_aux_irq) sep \
> +   func(has_gmbus_irq) sep \
> func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> @@ -2837,7 +2838,7 @@ struct drm_i915_cmd_table {
>   * interrupt source and so prevents the other device from working properly.
>   */
>  #define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->has_aux_irq)
> -#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->has_gmbus_irq)
>
>  /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
>   * rows, which changed the alignment requirements and fence programming.
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 9a5cb33..4652e2d 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -181,6 +181,7 @@ static const struct intel_device_info intel_pineview_info 
> = {
> .gen = 5, .num_pipes = 2, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .has_aux_irq = 1, \
> +   .has_gmbus_irq = 1, \
> .ring_mask = RENDER_RING | BSD_RING, \
> GEN_DEFAULT_PIPEOFFSETS, \
> CURSOR_OFFSETS
> @@ -205,6 +206,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
> .has_rc6 = 1, \
> .has_rc6p = 1, \
> .has_aux_irq = 1, \
> +   .has_gmbus_irq = 1, \

same as aux_irq

> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -226,6 +228,7 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
> .has_core_ring_freq = 1, \
> .has_rc6 = 1, \
> .has_aux_irq = 1, \
> +   .has_gmbus_irq = 1, \

same as aux_irq

> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -260,6 +263,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
> .has_runtime_pm = 1, \
> .has_rc6 = 1, \
> .has_aux_irq = 1, \
> +   .has_gmbus_irq = 1, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -339,6 +343,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .has_rc6 = 1,
> .has_dp_mst = 1,
> .has_aux_irq = 1,
> +   .has_gmbus_irq = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> @@ -379,6 +384,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
> .has_resource_streamer = 1,
> .has_rc6 = 1,
> .has_aux_irq = 1,
> +   .has_gmbus_irq = 1,
> GEN_DEFAULT_PIPEOFFSETS,
> IVB_CURSOR_OFFSETS,
> BDW_COLORS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 14/23] drm/i915: Move HAS_AUX_IRQ definition to platform definition

[Rodrigo Vivi]

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 6 ++
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 27f23cc5..26283b5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -778,6 +778,7 @@ struct intel_csr {
> func(has_rc6) sep \
> func(has_rc6p) sep \
> func(has_dp_mst) sep \
> +   func(has_aux_irq) sep \
> func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> @@ -2835,7 +2836,7 @@ struct drm_i915_cmd_table {
>   * legacy irq no. is shared with another device. The kernel then disables 
> that
>   * interrupt source and so prevents the other device from working properly.
>   */
> -#define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> +#define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->has_aux_irq)
>  #define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
>
>  /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 3844840..9a5cb33 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -180,6 +180,7 @@ static const struct intel_device_info intel_pineview_info 
> = {
>  #define GEN5_FEATURES \
> .gen = 5, .num_pipes = 2, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> +   .has_aux_irq = 1, \
> .ring_mask = RENDER_RING | BSD_RING, \
> GEN_DEFAULT_PIPEOFFSETS, \
> CURSOR_OFFSETS
> @@ -203,6 +204,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
> .has_core_ring_freq = 1, \
> .has_rc6 = 1, \
> .has_rc6p = 1, \
> +   .has_aux_irq = 1, \

GEN6 based on GEN5 should come first

> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -223,6 +225,7 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
> .has_fbc = 1, \
> .has_core_ring_freq = 1, \
> .has_rc6 = 1, \
> +   .has_aux_irq = 1, \

GEN7 based on GEN6 should come first

> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -256,6 +259,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
> .has_psr = 1, \
> .has_runtime_pm = 1, \
> .has_rc6 = 1, \
> +   .has_aux_irq = 1, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -334,6 +338,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .has_resource_streamer = 1,
> .has_rc6 = 1,
> .has_dp_mst = 1,
> +   .has_aux_irq = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> @@ -373,6 +378,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
> .has_pooled_eu = 0,
> .has_resource_streamer = 1,
> .has_rc6 = 1,
> +   .has_aux_irq = 1,
> GEN_DEFAULT_PIPEOFFSETS,
> IVB_CURSOR_OFFSETS,
> BDW_COLORS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 13/23] drm/i915: Introduce GEN5_FEATURES for device info

[Rodrigo Vivi]

ops, actually on this one you could do GEN6_FEATURE inherit and extend this.

On Wed, Jul 20, 2016 at 2:22 PM, Rodrigo Vivi  wrote:
> Reviewed-by: Rodrigo Vivi 
>
> On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
>> Based on the GEN7_FEATURES changes from Ben W.
>>
>> Use it for ilk.
>>
>> Signed-off-by: Carlos Santa 
>> ---
>>  drivers/gpu/drm/i915/i915_pci.c | 21 +++--
>>  1 file changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c 
>> b/drivers/gpu/drm/i915/i915_pci.c
>> index 099f134..3844840 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -177,21 +177,22 @@ static const struct intel_device_info 
>> intel_pineview_info = {
>> CURSOR_OFFSETS,
>>  };
>>
>> +#define GEN5_FEATURES \
>> +   .gen = 5, .num_pipes = 2, \
>> +   .need_gfx_hws = 1, .has_hotplug = 1, \
>> +   .ring_mask = RENDER_RING | BSD_RING, \
>> +   GEN_DEFAULT_PIPEOFFSETS, \
>> +   CURSOR_OFFSETS
>> +
>>  static const struct intel_device_info intel_ironlake_d_info = {
>> -   .gen = 5, .num_pipes = 2,
>> -   .need_gfx_hws = 1, .has_hotplug = 1,
>> -   .ring_mask = RENDER_RING | BSD_RING,
>> -   GEN_DEFAULT_PIPEOFFSETS,
>> -   CURSOR_OFFSETS,
>> +   GEN5_FEATURES
>>  };
>>
>>  static const struct intel_device_info intel_ironlake_m_info = {
>> -   .gen = 5, .is_mobile = 1, .num_pipes = 2,
>> -   .need_gfx_hws = 1, .has_hotplug = 1,
>> +   GEN5_FEATURES,
>> +   .is_mobile = 1,
>> .has_fbc = 1,
>> -   .ring_mask = RENDER_RING | BSD_RING,
>> -   GEN_DEFAULT_PIPEOFFSETS,
>> -   CURSOR_OFFSETS,
>> +
>>  };
>>
>>  #define GEN6_FEATURES \
>> --
>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 13/23] drm/i915: Introduce GEN5_FEATURES for device info

[Rodrigo Vivi]

Reviewed-by: Rodrigo Vivi 

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Based on the GEN7_FEATURES changes from Ben W.
>
> Use it for ilk.
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 099f134..3844840 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -177,21 +177,22 @@ static const struct intel_device_info 
> intel_pineview_info = {
> CURSOR_OFFSETS,
>  };
>
> +#define GEN5_FEATURES \
> +   .gen = 5, .num_pipes = 2, \
> +   .need_gfx_hws = 1, .has_hotplug = 1, \
> +   .ring_mask = RENDER_RING | BSD_RING, \
> +   GEN_DEFAULT_PIPEOFFSETS, \
> +   CURSOR_OFFSETS
> +
>  static const struct intel_device_info intel_ironlake_d_info = {
> -   .gen = 5, .num_pipes = 2,
> -   .need_gfx_hws = 1, .has_hotplug = 1,
> -   .ring_mask = RENDER_RING | BSD_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +   GEN5_FEATURES
>  };
>
>  static const struct intel_device_info intel_ironlake_m_info = {
> -   .gen = 5, .is_mobile = 1, .num_pipes = 2,
> -   .need_gfx_hws = 1, .has_hotplug = 1,
> +   GEN5_FEATURES,
> +   .is_mobile = 1,
> .has_fbc = 1,
> -   .ring_mask = RENDER_RING | BSD_RING,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +
>  };
>
>  #define GEN6_FEATURES \
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 12/23] drm/i915: Move HAS_DP_MST definition to platform definition

[Rodrigo Vivi]

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 5 ++---
>  drivers/gpu/drm/i915/i915_pci.c | 4 +++-
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a6a22b4..27f23cc5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -777,6 +777,7 @@ struct intel_csr {
> func(has_guc_sched) sep \
> func(has_rc6) sep \
> func(has_rc6p) sep \
> +   func(has_dp_mst) sep \
> func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> @@ -2851,9 +2852,7 @@ struct drm_i915_cmd_table {
>
>  #define HAS_IPS(dev)   (IS_HSW_ULT(dev) || IS_BROADWELL(dev))
>
> -#define HAS_DP_MST(dev)(IS_HASWELL(dev) || IS_BROADWELL(dev) 
> || \
> -INTEL_INFO(dev)->gen >= 9)

= hsw, bdw, skl, kbl, bxt.

> -
> +#define HAS_DP_MST(dev)(INTEL_INFO(dev)->has_dp_mst)
>  #define HAS_DDI(dev)   (INTEL_INFO(dev)->has_ddi)
>  #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
>  #define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index c6dae2c..099f134 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -279,7 +279,8 @@ static const struct intel_device_info 
> intel_valleyview_d_info = {
> .has_fpga_dbg = 1, \
> .has_psr = 1, \
> .has_runtime_pm = 1, \
> -   .has_resource_streamer = 1
> +   .has_resource_streamer = 1, \
> +   .has_dp_mst = 1
>
>  static const struct intel_device_info intel_haswell_d_info = {
> HSW_FEATURES,
> @@ -331,6 +332,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .has_runtime_pm = 1,
> .has_resource_streamer = 1,
> .has_rc6 = 1,
> +   .has_dp_mst = 1,

This is in the wrong block.
Cherryview is gen8. This one here should be in broxton.

> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/23] drm/i915: Move HAS_RC6p definition to platform definition

[Rodrigo Vivi]

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 7 +++
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 75131a0..a6a22b4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -776,6 +776,7 @@ struct intel_csr {
> func(has_guc_ucode) sep \
> func(has_guc_sched) sep \
> func(has_rc6) sep \
> +   func(has_rc6p) sep \
> func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> @@ -2858,7 +2859,7 @@ struct drm_i915_cmd_table {
>  #define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
>  #define HAS_RUNTIME_PM(dev)(INTEL_INFO(dev)->has_runtime_pm)
>  #define HAS_RC6(dev)   (INTEL_INFO(dev)->has_rc6)
> -#define HAS_RC6p(dev)  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
> +#define HAS_RC6p(dev)  (INTEL_INFO(dev)->has_rc6p)
>
>  #define HAS_CSR(dev)   (INTEL_INFO(dev)->has_csr)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index e10fb5c..c6dae2c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -201,6 +201,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
> .has_runtime_pm = 1, \
> .has_core_ring_freq = 1, \
> .has_rc6 = 1, \
> +   .has_rc6p = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -226,19 +227,25 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
> GEN_DEFAULT_PIPEOFFSETS, \
> IVB_CURSOR_OFFSETS
>
> +#define IVB_FEATURES  \
> +   .has_rc6p = 1
> +
>  static const struct intel_device_info intel_ivybridge_d_info = {
> GEN7_FEATURES,
> +   IVB_FEATURES,

another case where I don't like 2 macros together...

> .is_ivybridge = 1,
>  };
>
>  static const struct intel_device_info intel_ivybridge_m_info = {
> GEN7_FEATURES,
> +   IVB_FEATURES,
> .is_ivybridge = 1,
> .is_mobile = 1,
>  };
>
>  static const struct intel_device_info intel_ivybridge_q_info = {
> GEN7_FEATURES,
> +   IVB_FEATURES,
> .is_ivybridge = 1,
> .num_pipes = 0, /* legal, last one wins */
>  };
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/23] drm/i915: Move HAS_RC6 definition to platform definition

[Rodrigo Vivi]

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a326a88..75131a0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -775,6 +775,7 @@ struct intel_csr {
> func(has_guc) sep \
> func(has_guc_ucode) sep \
> func(has_guc_sched) sep \
> +   func(has_rc6) sep \
> func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> @@ -2856,7 +2857,7 @@ struct drm_i915_cmd_table {
>  #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
>  #define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
>  #define HAS_RUNTIME_PM(dev)(INTEL_INFO(dev)->has_runtime_pm)
> -#define HAS_RC6(dev)   (INTEL_INFO(dev)->gen >= 6)
> +#define HAS_RC6(dev)   (INTEL_INFO(dev)->has_rc6)
>  #define HAS_RC6p(dev)  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
>
>  #define HAS_CSR(dev)   (INTEL_INFO(dev)->has_csr)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index f59ad4b..e10fb5c 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -200,6 +200,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
> .has_fbc = 1, \
> .has_runtime_pm = 1, \
> .has_core_ring_freq = 1, \
> +   .has_rc6 = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -219,6 +220,7 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .has_fbc = 1, \
> .has_core_ring_freq = 1, \
> +   .has_rc6 = 1, \

another case where the GEN7 features based on GEN6 needs to come first.

> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -245,6 +247,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
> .gen = 7, .num_pipes = 2, \
> .has_psr = 1, \
> .has_runtime_pm = 1, \
> +   .has_rc6 = 1, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -320,6 +323,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .has_psr = 1,
> .has_runtime_pm = 1,
> .has_resource_streamer = 1,
> +   .has_rc6 = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> @@ -358,6 +362,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
> .has_runtime_pm = 1,
> .has_pooled_eu = 0,
> .has_resource_streamer = 1,
> +   .has_rc6 = 1,
> GEN_DEFAULT_PIPEOFFSETS,
> IVB_CURSOR_OFFSETS,
> BDW_COLORS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/23] drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition

[Rodrigo Vivi]

Reviewed-by: Rodrigo Vivi 

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 4 ++--
>  drivers/gpu/drm/i915/i915_pci.c | 5 -
>  2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2ba441e..a326a88 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -775,6 +775,7 @@ struct intel_csr {
> func(has_guc) sep \
> func(has_guc_ucode) sep \
> func(has_guc_sched) sep \
> +   func(has_resource_streamer) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> func(cursor_needs_physical) sep \
> @@ -2869,8 +2870,7 @@ struct drm_i915_cmd_table {
>  #define HAS_GUC_UCODE(dev) (INTEL_INFO(dev)->has_guc_ucode)
>  #define HAS_GUC_SCHED(dev) (INTEL_INFO(dev)->has_guc_sched)
>
> -#define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
> -   INTEL_INFO(dev)->gen >= 8)
> +#define HAS_RESOURCE_STREAMER(dev) (INTEL_INFO(dev)->has_resource_streamer)
>
>  #define HAS_CORE_RING_FREQ(dev)(INTEL_INFO(dev)->has_core_ring_freq)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index f2cb5c3..f59ad4b 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -268,7 +268,8 @@ static const struct intel_device_info 
> intel_valleyview_d_info = {
> .has_ddi = 1, \
> .has_fpga_dbg = 1, \
> .has_psr = 1, \
> -   .has_runtime_pm = 1
> +   .has_runtime_pm = 1, \
> +   .has_resource_streamer = 1
>
>  static const struct intel_device_info intel_haswell_d_info = {
> HSW_FEATURES,
> @@ -318,6 +319,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .is_cherryview = 1,
> .has_psr = 1,
> .has_runtime_pm = 1,
> +   .has_resource_streamer = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> @@ -355,6 +357,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
> .has_fbc = 1,
> .has_runtime_pm = 1,
> .has_pooled_eu = 0,
> +   .has_resource_streamer = 1,
> GEN_DEFAULT_PIPEOFFSETS,
> IVB_CURSOR_OFFSETS,
> BDW_COLORS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/23] drm/i915: Move HAS_GUC_SCHED definition to platform definition

[Rodrigo Vivi]

please kill this _sched variation that is just a alias to guc instead

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7186665..2ba441e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -774,6 +774,7 @@ struct intel_csr {
> func(has_csr) sep \
> func(has_guc) sep \
> func(has_guc_ucode) sep \
> +   func(has_guc_sched) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> func(cursor_needs_physical) sep \
> @@ -2866,7 +2867,7 @@ struct drm_i915_cmd_table {
>   */
>  #define HAS_GUC(dev)   (INTEL_INFO(dev)->has_guc)
>  #define HAS_GUC_UCODE(dev) (INTEL_INFO(dev)->has_guc_ucode)
> -#define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
> +#define HAS_GUC_SCHED(dev) (INTEL_INFO(dev)->has_guc_sched)
>
>  #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
> INTEL_INFO(dev)->gen >= 8)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 8171915..f2cb5c3 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -328,7 +328,8 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .gen = 9, \
> .has_csr = 1, \
> .has_guc = 1, \
> -   .has_guc_ucode = 1
> +   .has_guc_ucode = 1, \
> +   .has_guc_sched = 1
>
>  static const struct intel_device_info intel_skylake_info = {
> BDW_FEATURES,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition

[Rodrigo Vivi]

please kill this _ucode variation that is just a alias to guc instead

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported featurs when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 09c907f..7186665 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -773,6 +773,7 @@ struct intel_csr {
> func(has_core_ring_freq) sep \
> func(has_csr) sep \
> func(has_guc) sep \
> +   func(has_guc_ucode) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> func(cursor_needs_physical) sep \
> @@ -2864,7 +2865,7 @@ struct drm_i915_cmd_table {
>   * properties, so we have separate macros to test them.
>   */
>  #define HAS_GUC(dev)   (INTEL_INFO(dev)->has_guc)
> -#define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
> +#define HAS_GUC_UCODE(dev) (INTEL_INFO(dev)->has_guc_ucode)
>  #define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
>
>  #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index f42bf19..8171915 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -327,7 +327,8 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>  #define GEN9_FEATURES  \
> .gen = 9, \
> .has_csr = 1, \
> -   .has_guc = 1
> +   .has_guc = 1, \
> +   .has_guc_ucode = 1
>
>  static const struct intel_device_info intel_skylake_info = {
> BDW_FEATURES,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/23] drm/i915: Move HAS_CSR definition to platform definition

[Rodrigo Vivi]

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  3 ++-
>  drivers/gpu/drm/i915/i915_pci.c | 14 +-
>  2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 69e3818..db4930c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -771,6 +771,7 @@ struct intel_csr {
> func(has_psr) sep \
> func(has_runtime_pm) sep \
> func(has_core_ring_freq) sep \
> +   func(has_csr) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> func(cursor_needs_physical) sep \
> @@ -2854,7 +2855,7 @@ struct drm_i915_cmd_table {
>  #define HAS_RC6(dev)   (INTEL_INFO(dev)->gen >= 6)
>  #define HAS_RC6p(dev)  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
>
> -#define HAS_CSR(dev)   (IS_GEN9(dev))
> +#define HAS_CSR(dev)   (INTEL_INFO(dev)->has_csr)
>
>  /*
>   * For now, anything with a GuC requires uCode loading, and then supports
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 674b298..d266af5 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -324,22 +324,26 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> CHV_COLORS,
>  };
>
> +#define GEN9_FEATURES  \
> +   .gen = 9, \
> +   .has_csr = 1
> +
>  static const struct intel_device_info intel_skylake_info = {
> BDW_FEATURES,
> +   GEN9_FEATURES,

hmmm.. not sure about this GEN9_FEATURES along with BDW_FEATURES one...
Might be confusing and lead to mistakes.

I believe for now is better to spread the has_csr...

> .is_skylake = 1,
> -   .gen = 9,
>  };
>
>  static const struct intel_device_info intel_skylake_gt3_info = {
> BDW_FEATURES,
> +   GEN9_FEATURES,
> .is_skylake = 1,
> -   .gen = 9,
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | 
> BSD2_RING,
>  };
>
>  static const struct intel_device_info intel_broxton_info = {
> +   GEN9_FEATURES,
> .is_broxton = 1,
> -   .gen = 9,
> .need_gfx_hws = 1, .has_hotplug = 1,
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
> .num_pipes = 3,
> @@ -355,14 +359,14 @@ static const struct intel_device_info 
> intel_broxton_info = {
>
>  static const struct intel_device_info intel_kabylake_info = {
> BDW_FEATURES,
> +   GEN9_FEATURES,
> .is_kabylake = 1,
> -   .gen = 9,
>  };
>
>  static const struct intel_device_info intel_kabylake_gt3_info = {
> BDW_FEATURES,
> +   GEN9_FEATURES,
> .is_kabylake = 1,
> -   .gen = 9,
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | 
> BSD2_RING,
>  };
>
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/6] drm/i915/skl: Actually reuse wm values when pipes don't change

[Lyude]

Up until now we've actually been making the mistake of leaving the
watermark results for each pipe completely blank in skl_compute_wm()
when they haven't changed, fix this.

Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 'check' 
(v2)")
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede  
Cc: Matt Roper 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_pm.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b7d4af1..788db86 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3987,10 +3987,13 @@ skl_copy_wm_for_pipe(struct skl_wm_values *dst,
 static int
 skl_compute_wm(struct drm_atomic_state *state)
 {
+   struct drm_device *dev = state->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_crtc *crtc;
struct drm_crtc_state *cstate;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct skl_wm_values *results = _state->wm_results;
+   struct skl_wm_values *hw_wm = _priv->wm.skl_hw;
struct skl_pipe_wm *pipe_wm;
bool changed = false;
int ret, i;
@@ -4039,12 +4042,14 @@ skl_compute_wm(struct drm_atomic_state *state)
if (changed)
results->dirty_pipes |= drm_crtc_mask(crtc);
 
-   if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
+   if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0) {
/* This pipe's WM's did not change */
+   skl_copy_wm_for_pipe(results, hw_wm, intel_crtc->pipe);
continue;
+   }
 
intel_cstate->update_wm_pre = true;
-   skl_compute_wm_results(crtc->dev, pipe_wm, results, intel_crtc);
+   skl_compute_wm_results(dev, pipe_wm, results, intel_crtc);
}
 
return 0;
-- 
2.7.4

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

[Intel-gfx] [PATCH 5/6] drm/i915/skl: Only flush pipes when we change the ddb allocation

[Lyude]

Manual pipe flushes are only necessary in order to make sure that we prevent
pipes with changed ddb allocations from overlapping from one another at
any point in time. Additionally, forcing us to wait for the next vblank
every time we have to update the watermark values because the cursor was
moving between screens will introduce a rather noticable lag for users.

Signed-off-by: Lyude 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede  
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 31 +--
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c97724d..9e1e045 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1597,6 +1597,7 @@ struct skl_ddb_allocation {
 
 struct skl_wm_values {
unsigned dirty_pipes;
+   bool ddb_changed;
struct skl_ddb_allocation ddb;
uint32_t wm_linetime[I915_MAX_PIPES];
uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2e31df4..4178bdd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3809,6 +3809,12 @@ static void skl_flush_wm_values(struct drm_i915_private 
*dev_priv,
new_ddb = _values->ddb;
cur_ddb = _priv->wm.skl_hw.ddb;
 
+   /* We only ever need to flush when the ddb allocations change */
+   if (!new_values->ddb_changed)
+   return;
+
+   new_values->ddb_changed = false;
+
/*
 * First pass: flush the pipes with the new allocation contained into
 * the old space.
@@ -3926,6 +3932,22 @@ pipes_modified(struct drm_atomic_state *state)
return ret;
 }
 
+static bool
+skl_pipe_ddb_changed(struct skl_ddb_allocation *old,
+struct skl_ddb_allocation *new,
+enum pipe pipe)
+{
+   if (memcmp(>pipe[pipe], >pipe[pipe],
+  sizeof(old->pipe[pipe])) != 0 ||
+   memcmp(>plane[pipe], >plane[pipe],
+  sizeof(old->plane[pipe])) != 0 ||
+   memcmp(>y_plane[pipe], >y_plane[pipe],
+  sizeof(old->y_plane[pipe])) != 0)
+   return true;
+
+   return false;
+}
+
 static int
 skl_compute_ddb(struct drm_atomic_state *state)
 {
@@ -3933,7 +3955,8 @@ skl_compute_ddb(struct drm_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct intel_crtc *intel_crtc;
-   struct skl_ddb_allocation *ddb = _state->wm_results.ddb;
+   struct skl_ddb_allocation *new_ddb = _state->wm_results.ddb;
+   struct skl_ddb_allocation *old_ddb = _priv->wm.skl_hw.ddb;
uint32_t realloc_pipes = pipes_modified(state);
int ret;
 
@@ -3971,9 +3994,13 @@ skl_compute_ddb(struct drm_atomic_state *state)
if (IS_ERR(cstate))
return PTR_ERR(cstate);
 
-   ret = skl_allocate_pipe_ddb(cstate, ddb);
+   ret = skl_allocate_pipe_ddb(cstate, new_ddb);
if (ret)
return ret;
+
+   if (!intel_state->wm_results.ddb_changed &&
+   skl_pipe_ddb_changed(old_ddb, new_ddb, intel_crtc->pipe))
+   intel_state->wm_results.ddb_changed = true;
}
 
return 0;
-- 
2.7.4

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

[Intel-gfx] [PATCH 6/6] drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()

[Lyude]

Similar to how a vehicle will travel faster if you paint flames on it,
cleaning up this extra whitespace is guaranteed to provide additional
stability while updating watermark values.

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_pm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4178bdd..a08a638 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3837,7 +3837,6 @@ static void skl_flush_wm_values(struct drm_i915_private 
*dev_priv,
reallocated[pipe] = true;
}
 
-
/*
 * Second pass: flush the pipes that are having their allocation
 * reduced, but overlapping with a previous allocation.
-- 
2.7.4

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

[Intel-gfx] [PATCH 4/6] drm/i915/skl: Always wait for pipes to update after a flush

[Lyude]

As we've learned, all watermark updates on Skylake have to be strictly
atomic or things fail. While the bspec doesn't mandate that we need to
wait for pipes to finish after the third iteration of flushes, not doing
so gives us the opportunity to break this atomicity later. This example
assumes that we're lucky enough not to be interrupted by the scheduler
at any point during this:

 - Start with pipe A and pipe B enabled
 - Enable pipe C
 - Flush pipe A in pass 1, wait until update finishes
 - Flush pipe B in pass 3, continue without waiting for next vblank
 - Start another wm update
 - We enter the next vblank for pipe B before we finish writing all the
   vm values
 - *Underrun*

As such, we always need to wait for each pipe we flush to update so as
to never break this atomicity.

Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Signed-off-by: Lyude 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede  
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 788db86..2e31df4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3859,8 +3859,11 @@ static void skl_flush_wm_values(struct drm_i915_private 
*dev_priv,
/*
 * Third pass: flush the pipes that got more space allocated.
 *
-* We don't need to actively wait for the update here, next vblank
-* will just get more DDB space with the correct WM values.
+* While the hardware doesn't require to wait for the next vblank here,
+* continuing before the pipe finishes updating could result in us
+* trying to update the wm values again before the pipe finishes
+* updating, which results in the hardware using intermediate wm values
+* and subsequently underrunning pipes.
 */
for_each_intel_crtc(dev, crtc) {
if (!crtc->active)
@@ -3876,6 +3879,16 @@ static void skl_flush_wm_values(struct drm_i915_private 
*dev_priv,
continue;
 
skl_wm_flush_pipe(dev_priv, pipe, 3);
+
+   /*
+* The only time we can get away with not waiting for an update
+* is when we just enabled the pipe, e.g. when it doesn't have
+* vblanks enabled anyway.
+*/
+   if (drm_crtc_vblank_get(>base) == 0) {
+   intel_wait_for_vblank(dev, pipe);
+   drm_crtc_vblank_put(>base);
+   }
}
 }
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/6] drm/i915/skl: Update plane watermarks atomically during plane updates

[Lyude]

Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.

On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.

With this in mind, up until now we've been updating watermarks on skl
like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

  or

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

Now we update watermarks atomically like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks() (wm values aren't written yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks() (actual wm values aren't written
  yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

Which is more of a step in the right direction to fixing all of the
underrun issues we're currently seeing with skl

Changes since original patch series:
- Remove mutex_lock/mutex_unlock since they don't do anything and we're
  not touching global state
- Move skl_write_cursor_wm/skl_write_plane_wm functions into intel_pm.c, make
  externally visible
- Add skl_write_plane_wm calls to skl_update_plane
- Fix conditional for for loop in skl_write_plane_wm (level < max_level
  should be level <= max_level)
- Make diagram in commit more accurate to what's actually happening
- Add Fixes:

Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
Signed-off-by: Lyude 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede  
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c |  5 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c  | 48 +---
 drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
 4 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 78beb7e..c0d2074 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3031,6 +3031,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
intel_crtc->adjusted_x = x_offset;
intel_crtc->adjusted_y = y_offset;
 
+   skl_write_plane_wm(intel_crtc, 0);
+
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, 0), plane_offset);
I915_WRITE(PLANE_SIZE(pipe, 0), plane_size);
@@ -10242,6 +10244,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
int pipe = intel_crtc->pipe;
uint32_t cntl = 0;
 
+   if (IS_SKYLAKE(dev_priv))
+   skl_write_cursor_wm(intel_crtc);
+
if (plane_state && plane_state->visible) {
cntl = MCURSOR_GAMMA_ENABLE;
switch (plane_state->base.crtc_w) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e74d851..f1f54d9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1709,6 +1709,8 @@ void ilk_wm_get_hw_state(struct drm_device *dev);
 void skl_wm_get_hw_state(struct drm_device *dev);
 void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
  struct skl_ddb_allocation *ddb /* out */);
+void skl_write_cursor_wm(struct intel_crtc *intel_crtc);
+void skl_write_plane_wm(struct intel_crtc *intel_crtc, int plane);
 uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
 bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int 

[Intel-gfx] [PATCH 0/6] drm/i915/skl: Finally fix watermarks

[Lyude]

To Sebastian Reichel:
If this e-mail has the bizarre email address formatting issue you
noticed in the last patch series I sent please let me know. I haven't
gotten a chance to properly look at the e-mail you forwarded to me to
see what's causing the problem, but I double checked the Cc: line for
this e-mail manually before sending it out so hopefully I should be
good for now…

Anyway, onto the actual patch series:

Unfortunately as a few of you are aware, Skylake is still very prone to pipe
underruns. Most of this comes from not doing things atomically enough (e.g.
needing to ensure that we update watermarks with other plane attributes, not
forcefully flushing pipes until we need to, etc.). Now that I've finally got a
grasp on how double buffered registers, arming registers, etc. works on skl,
I've written up patches that fix all of the pipe underruns on Skylake I was
able to reproduce.

Of course, one of the prerequisites for this patch series to actually fix all
of the pipe underruns is the patch I previously submitted that added support
for Skylake's SAGV.

Originally this patch series left behind the issue of running into pipe
underruns when we disabled pipes, however I've now managed to fix that behavior
as well. As such I've renamed the patch series appropriately instead of just
incrementing the version.

Signed-off-by: Lyude 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 

Lyude (5):
  drm/i915/skl: Update plane watermarks atomically during plane updates
  drm/i915/skl: Actually reuse wm values when pipes don't change
  drm/i915/skl: Always wait for pipes to update after a flush
  drm/i915/skl: Only flush pipes when we change the ddb allocation
  drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()

Matt Roper (1):
  drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_display.c |   5 ++
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_pm.c  | 133 +--
 drivers/gpu/drm/i915/intel_sprite.c  |   2 +
 5 files changed, 120 insertions(+), 23 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

[Lyude]

From: Matt Roper 

When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw.  However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
other pipes remain 0.  Thus a blind copy of the entire skl_wm_values
structure will clobber the values for unchanged pipes...we need to be
more selective and only copy over the values for the changing pipes.

This mistake was hidden until recently due to another bug that caused us
to erroneously re-calculate watermarks for all active pipes rather than
changing pipes.  Only when that bug was fixed was the impact of this bug
discovered (e.g., modesets failing with "Requested display configuration
exceeds system watermark limitations" messages and leaving watermarks
non-functional, even ones initiated by intel_fbdev_restore_mode).

Changes since v1:
 - Add a function for copying a pipe's wm values
   (skl_copy_wm_for_pipe()) so we can reuse this later

Cc: Maarten Lankhorst 
Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 'check' 
(v2)")
Fixes: 9b6130227495 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
Signed-off-by: Matt Roper 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_pm.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fa86bea..b7d4af1 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3966,6 +3966,24 @@ skl_compute_ddb(struct drm_atomic_state *state)
return 0;
 }
 
+static void
+skl_copy_wm_for_pipe(struct skl_wm_values *dst,
+struct skl_wm_values *src,
+enum pipe pipe)
+{
+   dst->wm_linetime[pipe] = src->wm_linetime[pipe];
+   memcpy(dst->plane[pipe], src->plane[pipe],
+  sizeof(dst->plane[pipe]));
+   memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
+  sizeof(dst->plane_trans[pipe]));
+
+   dst->ddb.pipe[pipe] = src->ddb.pipe[pipe];
+   memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
+  sizeof(dst->ddb.y_plane[pipe]));
+   memcpy(dst->ddb.plane[pipe], src->ddb.plane[pipe],
+  sizeof(dst->ddb.plane[pipe]));
+}
+
 static int
 skl_compute_wm(struct drm_atomic_state *state)
 {
@@ -4038,8 +4056,10 @@ static void skl_update_wm(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct skl_wm_values *results = _priv->wm.skl_results;
+   struct skl_wm_values *hw_vals = _priv->wm.skl_hw;
struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
struct skl_pipe_wm *pipe_wm = >wm.skl.optimal;
+   int pipe;
 
if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
return;
@@ -4051,8 +4071,12 @@ static void skl_update_wm(struct drm_crtc *crtc)
skl_write_wm_values(dev_priv, results);
skl_flush_wm_values(dev_priv, results);
 
-   /* store the new configuration */
-   dev_priv->wm.skl_hw = *results;
+   /*
+* Store the new configuration (but only for the pipes that have
+* changed; the other values weren't recomputed).
+*/
+   for_each_pipe_masked(dev_priv, pipe, results->dirty_pipes)
+   skl_copy_wm_for_pipe(hw_vals, results, pipe);
 
mutex_unlock(_priv->wm.wm_mutex);
 }
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 04/23] drm/i915: Move HAS_CORE_RING_FREQ definition to platform definition

[Rodrigo Vivi]

another reason to have GEN7_FEATURES based on GEN6_FEATURES.

Please add that before patches like this so we avoid duplication since
the beginning. And do that has_runtime_pm=0 and put a comment or a
FIXME there...

Thanks,
Rodrigo.

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 5 ++---
>  drivers/gpu/drm/i915/i915_pci.c | 2 ++
>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7443b9a..69e3818 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -770,6 +770,7 @@ struct intel_csr {
> func(has_fbc) sep \
> func(has_psr) sep \
> func(has_runtime_pm) sep \
> +   func(has_core_ring_freq) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> func(cursor_needs_physical) sep \
> @@ -2867,9 +2868,7 @@ struct drm_i915_cmd_table {
>  #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
> INTEL_INFO(dev)->gen >= 8)
>
> -#define HAS_CORE_RING_FREQ(dev)(INTEL_INFO(dev)->gen >= 6 && \
> -!IS_VALLEYVIEW(dev) && !IS_CHERRYVIEW(dev) 
> && \
> -!IS_BROXTON(dev))
> +#define HAS_CORE_RING_FREQ(dev)(INTEL_INFO(dev)->has_core_ring_freq)
>
>  #define HAS_POOLED_EU(dev) (INTEL_INFO(dev)->has_pooled_eu)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 92ab3c2..674b298 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -199,6 +199,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .has_fbc = 1, \
> .has_runtime_pm = 1, \
> +   .has_core_ring_freq = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -217,6 +218,7 @@ static const struct intel_device_info 
> intel_sandybridge_m_info = {
> .gen = 7, .num_pipes = 3, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .has_fbc = 1, \
> +   .has_core_ring_freq = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/23] drm/i915: Move HAS_RUNTIME_PM definition to platform

[Rodrigo Vivi]

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Moving all GPU features to the platform struct definition allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct
>   definitions
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 6 ++
>  drivers/gpu/drm/i915/i915_pci.c | 7 ++-
>  2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6569eb7..7443b9a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -769,6 +769,7 @@ struct intel_csr {
> func(is_preliminary) sep \
> func(has_fbc) sep \
> func(has_psr) sep \
> +   func(has_runtime_pm) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> func(cursor_needs_physical) sep \
> @@ -2848,10 +2849,7 @@ struct drm_i915_cmd_table {
>  #define HAS_DDI(dev)   (INTEL_INFO(dev)->has_ddi)
>  #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
>  #define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
> -#define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
> -IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
> -IS_CHERRYVIEW(dev) || IS_SKYLAKE(dev) || \
> -IS_KABYLAKE(dev) || IS_BROXTON(dev))

Why don't we have runtime_pm on Ivybridge since we have on
sandybdrige? Imre, any idea?

> +#define HAS_RUNTIME_PM(dev)(INTEL_INFO(dev)->has_runtime_pm)
>  #define HAS_RC6(dev)   (INTEL_INFO(dev)->gen >= 6)
>  #define HAS_RC6p(dev)  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 8b1311d..92ab3c2 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -198,6 +198,7 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
> .gen = 6, .num_pipes = 2, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .has_fbc = 1, \
> +   .has_runtime_pm = 1, \

This patch made me notice that we should define the

GEN7_FEATURE on GEN6_FEATURES + new changes as a followup of patch
02/32 or in that same patch.
However for this case we should redefine .has_runtime_pm=0 on gen7,
what is really strange.

Anyway, this patch itself has nothing wrong and just follows what it
was set there already.
any change related to my comments should be addressed in separated patches.
So fell free to also use
Reviewed-by: Rodrigo Vivi 

> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .has_llc = 1, \
> GEN_DEFAULT_PIPEOFFSETS, \
> @@ -241,6 +242,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
>  #define VLV_FEATURES  \
> .gen = 7, .num_pipes = 2, \
> .has_psr = 1, \
> +   .has_runtime_pm = 1, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -263,7 +265,8 @@ static const struct intel_device_info 
> intel_valleyview_d_info = {
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
> .has_ddi = 1, \
> .has_fpga_dbg = 1, \
> -   .has_psr = 1
> +   .has_psr = 1, \
> +   .has_runtime_pm = 1
>
>  static const struct intel_device_info intel_haswell_d_info = {
> HSW_FEATURES,
> @@ -312,6 +315,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
> .is_cherryview = 1,
> .has_psr = 1,
> +   .has_runtime_pm = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> @@ -340,6 +344,7 @@ static const struct intel_device_info intel_broxton_info 
> = {
> .has_ddi = 1,
> .has_fpga_dbg = 1,
> .has_fbc = 1,
> +   .has_runtime_pm = 1,
> .has_pooled_eu = 0,
> GEN_DEFAULT_PIPEOFFSETS,
> IVB_CURSOR_OFFSETS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/23] drm/i915: Introduce GEN6_FEATURES for device info

[Rodrigo Vivi]

Reviewed-by: Rodrigo Vivi 


On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> Based on the GEN7_FEATURES changes from Ben W.
>
> Use it for snb.
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 26 --
>  1 file changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 08cdeb3..8b1311d 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -194,24 +194,22 @@ static const struct intel_device_info 
> intel_ironlake_m_info = {
> CURSOR_OFFSETS,
>  };
>
> +#define GEN6_FEATURES \
> +   .gen = 6, .num_pipes = 2, \
> +   .need_gfx_hws = 1, .has_hotplug = 1, \
> +   .has_fbc = 1, \
> +   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> +   .has_llc = 1, \
> +   GEN_DEFAULT_PIPEOFFSETS, \
> +   CURSOR_OFFSETS
> +
>  static const struct intel_device_info intel_sandybridge_d_info = {
> -   .gen = 6, .num_pipes = 2,
> -   .need_gfx_hws = 1, .has_hotplug = 1,
> -   .has_fbc = 1,
> -   .ring_mask = RENDER_RING | BSD_RING | BLT_RING,
> -   .has_llc = 1,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +   GEN6_FEATURES
>  };
>
>  static const struct intel_device_info intel_sandybridge_m_info = {
> -   .gen = 6, .is_mobile = 1, .num_pipes = 2,
> -   .need_gfx_hws = 1, .has_hotplug = 1,
> -   .has_fbc = 1,
> -   .ring_mask = RENDER_RING | BSD_RING | BLT_RING,
> -   .has_llc = 1,
> -   GEN_DEFAULT_PIPEOFFSETS,
> -   CURSOR_OFFSETS,
> +   GEN6_FEATURES,
> +   .is_mobile = 1
>  };
>
>  #define GEN7_FEATURES  \
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/23] drm/i915: Move HAS_PSR definition to platform struct definition

[Rodrigo Vivi]

Reviewed-by: Rodrigo Vivi 

On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> [patch series] Moving all GPU features to the platform struct definition
> allows for
> - standard place when adding new features from new platforms
> - possible to see supported features when dumping struct definition
>
> Signed-off-by: Carlos Santa 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 5 ++---
>  drivers/gpu/drm/i915/i915_pci.c | 5 -
>  2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e76cfe2..6569eb7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -768,6 +768,7 @@ struct intel_csr {
> func(is_kabylake) sep \
> func(is_preliminary) sep \
> func(has_fbc) sep \
> +   func(has_psr) sep \
> func(has_pipe_cxsr) sep \
> func(has_hotplug) sep \
> func(cursor_needs_physical) sep \
> @@ -2846,9 +2847,7 @@ struct drm_i915_cmd_table {
>
>  #define HAS_DDI(dev)   (INTEL_INFO(dev)->has_ddi)
>  #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
> -#define HAS_PSR(dev)   (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
> -IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
> -IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
> +#define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
>  #define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
>  IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
>  IS_CHERRYVIEW(dev) || IS_SKYLAKE(dev) || \
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 949c016..08cdeb3 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -242,6 +242,7 @@ static const struct intel_device_info 
> intel_ivybridge_q_info = {
>
>  #define VLV_FEATURES  \
> .gen = 7, .num_pipes = 2, \
> +   .has_psr = 1, \
> .need_gfx_hws = 1, .has_hotplug = 1, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> .display_mmio_offset = VLV_DISPLAY_BASE, \
> @@ -263,7 +264,8 @@ static const struct intel_device_info 
> intel_valleyview_d_info = {
> GEN7_FEATURES, \
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
> .has_ddi = 1, \
> -   .has_fpga_dbg = 1
> +   .has_fpga_dbg = 1, \
> +   .has_psr = 1
>
>  static const struct intel_device_info intel_haswell_d_info = {
> HSW_FEATURES,
> @@ -311,6 +313,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
> .need_gfx_hws = 1, .has_hotplug = 1,
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
> .is_cherryview = 1,
> +   .has_psr = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/vgem: Allow root to inject hanging fences onto dmabufs

[Chris Wilson]

When performing driver testing, one factor we want to test is how we
handle a foreign fence that is never signaled. We can wait on that fence
indefinitely, in which case the driver appears hung, or we can take some
remedial action (with risks regarding the state of any shared content).
Whatever the action choosen by the driver, in order to perform the test
we want to disable the safety feature of vgem fence (which is then used
to test implicit dma-buf fencing). This is regarded as a highly
dangerous feature and so hidden behind an expert config option and only
available to root when enabled.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/Kconfig   | 13 +
 drivers/gpu/drm/vgem/vgem_fence.c | 14 --
 include/uapi/drm/vgem_drm.h   |  1 +
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index fc357319de35..2b25bc38fad2 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -228,6 +228,19 @@ config DRM_VGEM
  as used by Mesa's software renderer for enhanced performance.
  If M is selected the module will be called vgem.
 
+config DRM_VGEM_FENCE_HANG
+   bool "Enable fence hang testing (DANGEROUS)"
+   depends on DRM_VGEM
+   depends on EXPERT
+   depends on !COMPILE_TEST
+   default n
+   help
+ Enables support for root to use indefinite fences.
+ Do not enable this unless you are testing DRM drivers.
+
+ Recommended for driver developers only.
+
+ If in doubt, say "N".
 
 source "drivers/gpu/drm/exynos/Kconfig"
 
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
index 5c57c1ffa1f9..91d3d75fc9c5 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -107,7 +107,8 @@ static struct fence *vgem_fence_create(struct vgem_file 
*vfile,
setup_timer(>timer, vgem_fence_timeout, (unsigned long)fence);
 
/* We force the fence to expire within 10s to prevent driver hangs */
-   mod_timer(>timer, jiffies + VGEM_FENCE_TIMEOUT);
+   if ((flags & VGEM_FENCE_NOTIMEOUT) == 0)
+   mod_timer(>timer, jiffies + VGEM_FENCE_TIMEOUT);
 
return >base;
 }
@@ -160,9 +161,18 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
struct fence *fence;
int ret;
 
-   if (arg->flags & ~VGEM_FENCE_WRITE)
+   if (arg->flags & ~(VGEM_FENCE_WRITE | VGEM_FENCE_NOTIMEOUT))
return -EINVAL;
 
+   if (arg->flags & VGEM_FENCE_NOTIMEOUT) {
+   if (config_enabled(CONFIG_DRM_VGEM_FENCE_HANG)) {
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+   } else {
+   return -EINVAL;
+   }
+   }
+
if (arg->pad)
return -EINVAL;
 
diff --git a/include/uapi/drm/vgem_drm.h b/include/uapi/drm/vgem_drm.h
index bf66f5db6da8..55fd08750773 100644
--- a/include/uapi/drm/vgem_drm.h
+++ b/include/uapi/drm/vgem_drm.h
@@ -46,6 +46,7 @@ struct drm_vgem_fence_attach {
__u32 handle;
__u32 flags;
 #define VGEM_FENCE_WRITE   0x1
+#define VGEM_FENCE_NOTIMEOUT   0x2
__u32 out_fence;
__u32 pad;
 };
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Use rt priority kthread to do GuC log buffer sampling

[Chris Wilson]

On Sun, Jul 10, 2016 at 07:11:24PM +0530, akash.g...@intel.com wrote:
> @@ -1707,8 +1692,8 @@ static void gen9_guc_irq_handler(struct 
> drm_i915_private *dev_priv, u32 gt_iir)
>   I915_READ(SOFT_SCRATCH(15)) & ~msg);
>  
>   /* Handle flush interrupt event in bottom half 
> */
> - queue_work(dev_priv->guc.log.wq,
> - _priv->guc.events_work);
> + smp_store_mb(dev_priv->guc.log.flush_signal, 1);
> + wake_up_process(dev_priv->guc.log.flush_task);
>   }

> +void guc_cancel_log_flush_work_sync(struct drm_i915_private *dev_priv)
> +{
> + spin_lock_irq(_priv->irq_lock);
> + dev_priv->guc.log.flush_signal = false;
> + spin_unlock_irq(_priv->irq_lock);
> +
> + if (dev_priv->guc.log.flush_task)
> + wait_for_completion(_priv->guc.log.flush_completion);
> +}
> +
> +static int guc_log_flush_worker(void *arg)
> +{
> + struct drm_i915_private *dev_priv = arg;
> + struct intel_guc *guc = _priv->guc;
> +
> + /* Install ourselves with high priority to reduce signalling latency */
> + struct sched_param param = { .sched_priority = 1 };
> + sched_setscheduler_nocheck(current, SCHED_FIFO, );
> +
> + do {
> + set_current_state(TASK_INTERRUPTIBLE);
> +
> + spin_lock_irq(_priv->irq_lock);
> + if (guc->log.flush_signal) {
> + guc->log.flush_signal = false;
> + reinit_completion(>log.flush_completion);
> + spin_unlock_irq(_priv->irq_lock);
> + i915_guc_capture_logs(_priv->drm);
> + complete_all(>log.flush_completion);
> + } else {
> + spin_unlock_irq(_priv->irq_lock);
> + if (kthread_should_stop())
> + break;
> +
> + schedule();
> + }
> + } while (1);
> + __set_current_state(TASK_RUNNING);
> +
> + return 0;

This looks decidely fishy.

irq handler:
smp_store_mb(log.signal, 1);
wake_up_process(log.tsk);

worker:
do {
set_current_state(TASK_INT);

while (cmpxchg(, 1, 0)) {
reinit_completion(log.complete);
i915_guc_capture_logs();
}

complete_all(log.complete);
if (kthread_should_stop())
break;

schedule();
} while(1);
__set_current_state(TASK_RUNNING);

flush:
smp_store_mb(log.signal, 0);
wait_for_completion(log.complete);


In the end, just the silly locking and placement of complete_all() is
dangerous. reinit_completion() lacks the barrier to be used like this
really, at any rate, racy with the irq handler, so use sparingly or when
you control the irq handler. (Also not sure if log.signal = 0 is sane,
or the current callsites really require the flush.)
-Chris

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

[Intel-gfx] [PATCH 1/2] drm/i915: Drop racy markup of missed-irqs from idle-worker

[Chris Wilson]

During the idle-worker we disable the hangcheck and so kick any waiters
that should have been completed (since the GPU is now idle). Unlike the
hangcheck, we do not take any care to avoid the race between the irq
handler and ourselves, and so it is possible for us to declare a missed
interrupt even as the bottom-half is being scheduled to run. Let's
ignore this race to stop a potential false-positive error.

References: https://bugs.freedesktop.org/show_bug.cgi?id=96974
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 40047eb48826..9e826585edb2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2706,10 +2706,9 @@ i915_gem_idle_work_handler(struct work_struct *work)
rearm_hangcheck = false;
 
stuck_engines = intel_kick_waiters(dev_priv);
-   if (unlikely(stuck_engines)) {
-   DRM_DEBUG_DRIVER("kicked stuck waiters...missed irq\n");
-   dev_priv->gpu_error.missed_irq_rings |= stuck_engines;
-   }
+   if (unlikely(stuck_engines))
+   DRM_DEBUG_DRIVER("kicked stuck waiters (%x)...missed irq?\n",
+stuck_engines);
 
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_idle(dev_priv);
-- 
2.8.1

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

[Intel-gfx] [PATCH 2/2] drm/i915: Update the breadcrumb interrupt counter before enabling

[Chris Wilson]

In order to close a race with a long running hangcheck comparing a stale
interrupt counter with a just started waiter, we need to first bump the
counter as we start the fresh wait.

References: https://bugs.freedesktop.org/show_bug.cgi?id=96974
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index f0b56e3f4abe..d893ccdd62ac 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -51,6 +51,13 @@ static void irq_enable(struct intel_engine_cs *engine)
 */
engine->breadcrumbs.irq_posted = true;
 
+   /* Make sure the current hangcheck doesn't falsely accuse a just
+* started irq handler from missing an interrupt (because the
+* interrupt count still matches the stale value from when
+* the irq handler was disabled, many hangchecks ago).
+*/
+   engine->breadcrumbs.irq_wakeups++;
+
spin_lock_irq(>i915->irq_lock);
engine->irq_enable(engine);
spin_unlock_irq(>i915->irq_lock);
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH 1/2] meh

[Chris Wilson]

On Wed, Jul 20, 2016 at 07:57:08PM +0100, Chris Wilson wrote:

Bleh, send-email from wrong branch.
-Chris

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

[Intel-gfx] [PATCH 2/2] drm/vgem: Allow root to inject hanging fences onto dmabufs

[Chris Wilson]

When performing driver testing, one factor we want to test is how we
handle a foreign fence that is never signaled. We can wait on that fence
indefinitely, in which case the driver appears hung, or we can take some
remedial action (with risks regarding the state of any shared content).
Whatever the action choosen by the driver, in order to perform the test
we want to disable the safety feature of vgem fence (which is then used
to test implicit dma-buf fencing). This is regarded as a highly
dangerous feature and so hidden behind an expert config option and only
available to root when enabled.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/Kconfig   | 13 +
 drivers/gpu/drm/vgem/vgem_fence.c | 14 --
 include/uapi/drm/vgem_drm.h   |  1 +
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index fc357319de35..2b25bc38fad2 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -228,6 +228,19 @@ config DRM_VGEM
  as used by Mesa's software renderer for enhanced performance.
  If M is selected the module will be called vgem.
 
+config DRM_VGEM_FENCE_HANG
+   bool "Enable fence hang testing (DANGEROUS)"
+   depends on DRM_VGEM
+   depends on EXPERT
+   depends on !COMPILE_TEST
+   default n
+   help
+ Enables support for root to use indefinite fences.
+ Do not enable this unless you are testing DRM drivers.
+
+ Recommended for driver developers only.
+
+ If in doubt, say "N".
 
 source "drivers/gpu/drm/exynos/Kconfig"
 
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
index 5c57c1ffa1f9..91d3d75fc9c5 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -107,7 +107,8 @@ static struct fence *vgem_fence_create(struct vgem_file 
*vfile,
setup_timer(>timer, vgem_fence_timeout, (unsigned long)fence);
 
/* We force the fence to expire within 10s to prevent driver hangs */
-   mod_timer(>timer, jiffies + VGEM_FENCE_TIMEOUT);
+   if ((flags & VGEM_FENCE_NOTIMEOUT) == 0)
+   mod_timer(>timer, jiffies + VGEM_FENCE_TIMEOUT);
 
return >base;
 }
@@ -160,9 +161,18 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
struct fence *fence;
int ret;
 
-   if (arg->flags & ~VGEM_FENCE_WRITE)
+   if (arg->flags & ~(VGEM_FENCE_WRITE | VGEM_FENCE_NOTIMEOUT))
return -EINVAL;
 
+   if (arg->flags & VGEM_FENCE_NOTIMEOUT) {
+   if (config_enabled(CONFIG_DRM_VGEM_FENCE_HANG)) {
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+   } else {
+   return -EINVAL;
+   }
+   }
+
if (arg->pad)
return -EINVAL;
 
diff --git a/include/uapi/drm/vgem_drm.h b/include/uapi/drm/vgem_drm.h
index bf66f5db6da8..55fd08750773 100644
--- a/include/uapi/drm/vgem_drm.h
+++ b/include/uapi/drm/vgem_drm.h
@@ -46,6 +46,7 @@ struct drm_vgem_fence_attach {
__u32 handle;
__u32 flags;
 #define VGEM_FENCE_WRITE   0x1
+#define VGEM_FENCE_NOTIMEOUT   0x2
__u32 out_fence;
__u32 pad;
 };
-- 
2.8.1

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

[Intel-gfx] [PATCH 1/2] meh

[Chris Wilson]

---
 drivers/gpu/drm/i915/i915_debugfs.c| 162 +---
 drivers/gpu/drm/i915/i915_drv.h|  84 ++---
 drivers/gpu/drm/i915/i915_gem.c| 150 ---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   3 +-
 drivers/gpu/drm/i915/i915_gem_request.c| 286 +++--
 drivers/gpu/drm/i915/i915_gem_request.h|   5 +
 drivers/gpu/drm/i915/i915_gpu_error.c  |  60 +-
 drivers/gpu/drm/i915/intel_engine_cs.c |   3 +-
 drivers/gpu/drm/i915/intel_lrc.c   |   2 +-
 drivers/gpu/drm/i915/intel_pm.c|   3 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c|   1 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|  14 +-
 12 files changed, 251 insertions(+), 522 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0c8aeed4ca8f..6cf921ebfb60 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -366,28 +366,6 @@ static int per_file_stats(int id, void *ptr, void *data)
   stats.unbound); \
 } while (0)
 
-static void print_batch_pool_stats(struct seq_file *m,
-  struct drm_i915_private *dev_priv)
-{
-   struct drm_i915_gem_object *obj;
-   struct file_stats stats;
-   struct intel_engine_cs *engine;
-   int j;
-
-   memset(, 0, sizeof(stats));
-
-   for_each_engine(engine, dev_priv) {
-   for (j = 0; j < ARRAY_SIZE(engine->batch_pool.cache_list); j++) 
{
-   list_for_each_entry(obj,
-   >batch_pool.cache_list[j],
-   batch_pool_link)
-   per_file_stats(0, obj, );
-   }
-   }
-
-   print_file_stats(m, "[k]batch pool", stats);
-}
-
 static int per_file_ctx_stats(int id, void *ptr, void *data)
 {
struct i915_gem_context *ctx = ptr;
@@ -545,7 +523,6 @@ static int i915_gem_object_info(struct seq_file *m, void* 
data)
   ggtt->base.total, ggtt->mappable_end - ggtt->base.start);
 
seq_putc(m, '\n');
-   print_batch_pool_stats(m, dev_priv);
mutex_unlock(>struct_mutex);
 
mutex_lock(>filelist_mutex);
@@ -655,10 +632,9 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
if (work->flip_queued_req) {
struct intel_engine_cs *engine = 
i915_gem_request_get_engine(work->flip_queued_req);
 
-   seq_printf(m, "Flip queued on %s at seqno %x, 
next seqno %x [current breadcrumb %x], completed? %d\n",
+   seq_printf(m, "Flip queued on %s at seqno %x, 
current breadcrumb %x, completed? %d\n",
   engine->name,
   
i915_gem_request_get_seqno(work->flip_queued_req),
-  dev_priv->next_seqno,
   intel_engine_get_seqno(engine),
   
i915_gem_request_completed(work->flip_queued_req));
} else
@@ -688,99 +664,6 @@ static int i915_gem_pageflip_info(struct seq_file *m, void 
*data)
return 0;
 }
 
-static int i915_gem_batch_pool_info(struct seq_file *m, void *data)
-{
-   struct drm_info_node *node = m->private;
-   struct drm_device *dev = node->minor->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct drm_i915_gem_object *obj;
-   struct intel_engine_cs *engine;
-   int total = 0;
-   int ret, j;
-
-   ret = mutex_lock_interruptible(>struct_mutex);
-   if (ret)
-   return ret;
-
-   for_each_engine(engine, dev_priv) {
-   for (j = 0; j < ARRAY_SIZE(engine->batch_pool.cache_list); j++) 
{
-   int count;
-
-   count = 0;
-   list_for_each_entry(obj,
-   >batch_pool.cache_list[j],
-   batch_pool_link)
-   count++;
-   seq_printf(m, "%s cache[%d]: %d objects\n",
-  engine->name, j, count);
-
-   list_for_each_entry(obj,
-   >batch_pool.cache_list[j],
-   batch_pool_link) {
-   seq_puts(m, "   ");
-   describe_obj(m, obj);
-   seq_putc(m, '\n');
-   }
-
-   total += count;
-   }
-   }
-
-   seq_printf(m, "total: %d\n", total);
-
-   mutex_unlock(>struct_mutex);
-
-   return 0;
-}
-
-static int i915_gem_request_info(struct seq_file *m, void *data)
-{
-   struct drm_info_node *node = 

[Intel-gfx] [PATCH 06/23] drm/i915: Move HAS_GUC definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platform
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index db4930c..09c907f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -772,6 +772,7 @@ struct intel_csr {
func(has_runtime_pm) sep \
func(has_core_ring_freq) sep \
func(has_csr) sep \
+   func(has_guc) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
func(cursor_needs_physical) sep \
@@ -2862,7 +2863,7 @@ struct drm_i915_cmd_table {
  * command submission once loaded. But these are logically independent
  * properties, so we have separate macros to test them.
  */
-#define HAS_GUC(dev)   (IS_GEN9(dev))
+#define HAS_GUC(dev)   (INTEL_INFO(dev)->has_guc)
 #define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
 #define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d266af5..f42bf19 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -326,7 +326,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
 
 #define GEN9_FEATURES  \
.gen = 9, \
-   .has_csr = 1
+   .has_csr = 1, \
+   .has_guc = 1
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
-- 
1.9.1

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

[Intel-gfx] [PATCH 09/23] drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 4 ++--
 drivers/gpu/drm/i915/i915_pci.c | 5 -
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2ba441e..a326a88 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -775,6 +775,7 @@ struct intel_csr {
func(has_guc) sep \
func(has_guc_ucode) sep \
func(has_guc_sched) sep \
+   func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
func(cursor_needs_physical) sep \
@@ -2869,8 +2870,7 @@ struct drm_i915_cmd_table {
 #define HAS_GUC_UCODE(dev) (INTEL_INFO(dev)->has_guc_ucode)
 #define HAS_GUC_SCHED(dev) (INTEL_INFO(dev)->has_guc_sched)
 
-#define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
-   INTEL_INFO(dev)->gen >= 8)
+#define HAS_RESOURCE_STREAMER(dev) (INTEL_INFO(dev)->has_resource_streamer)
 
 #define HAS_CORE_RING_FREQ(dev)(INTEL_INFO(dev)->has_core_ring_freq)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f2cb5c3..f59ad4b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -268,7 +268,8 @@ static const struct intel_device_info 
intel_valleyview_d_info = {
.has_ddi = 1, \
.has_fpga_dbg = 1, \
.has_psr = 1, \
-   .has_runtime_pm = 1
+   .has_runtime_pm = 1, \
+   .has_resource_streamer = 1
 
 static const struct intel_device_info intel_haswell_d_info = {
HSW_FEATURES,
@@ -318,6 +319,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.is_cherryview = 1,
.has_psr = 1,
.has_runtime_pm = 1,
+   .has_resource_streamer = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
@@ -355,6 +357,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_fbc = 1,
.has_runtime_pm = 1,
.has_pooled_eu = 0,
+   .has_resource_streamer = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
BDW_COLORS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 10/23] drm/i915: Move HAS_RC6 definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a326a88..75131a0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -775,6 +775,7 @@ struct intel_csr {
func(has_guc) sep \
func(has_guc_ucode) sep \
func(has_guc_sched) sep \
+   func(has_rc6) sep \
func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
@@ -2856,7 +2857,7 @@ struct drm_i915_cmd_table {
 #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
 #define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
 #define HAS_RUNTIME_PM(dev)(INTEL_INFO(dev)->has_runtime_pm)
-#define HAS_RC6(dev)   (INTEL_INFO(dev)->gen >= 6)
+#define HAS_RC6(dev)   (INTEL_INFO(dev)->has_rc6)
 #define HAS_RC6p(dev)  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
 
 #define HAS_CSR(dev)   (INTEL_INFO(dev)->has_csr)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f59ad4b..e10fb5c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -200,6 +200,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.has_fbc = 1, \
.has_runtime_pm = 1, \
.has_core_ring_freq = 1, \
+   .has_rc6 = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -219,6 +220,7 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
.need_gfx_hws = 1, .has_hotplug = 1, \
.has_fbc = 1, \
.has_core_ring_freq = 1, \
+   .has_rc6 = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -245,6 +247,7 @@ static const struct intel_device_info 
intel_ivybridge_q_info = {
.gen = 7, .num_pipes = 2, \
.has_psr = 1, \
.has_runtime_pm = 1, \
+   .has_rc6 = 1, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.display_mmio_offset = VLV_DISPLAY_BASE, \
@@ -320,6 +323,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_psr = 1,
.has_runtime_pm = 1,
.has_resource_streamer = 1,
+   .has_rc6 = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
@@ -358,6 +362,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_runtime_pm = 1,
.has_pooled_eu = 0,
.has_resource_streamer = 1,
+   .has_rc6 = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
BDW_COLORS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 15/23] drm/i915: Move HAS_GMBUS_IRQ definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 6 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 26283b5..a58765b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -779,6 +779,7 @@ struct intel_csr {
func(has_rc6p) sep \
func(has_dp_mst) sep \
func(has_aux_irq) sep \
+   func(has_gmbus_irq) sep \
func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
@@ -2837,7 +2838,7 @@ struct drm_i915_cmd_table {
  * interrupt source and so prevents the other device from working properly.
  */
 #define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->has_aux_irq)
-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->has_gmbus_irq)
 
 /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
  * rows, which changed the alignment requirements and fence programming.
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 9a5cb33..4652e2d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -181,6 +181,7 @@ static const struct intel_device_info intel_pineview_info = 
{
.gen = 5, .num_pipes = 2, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.has_aux_irq = 1, \
+   .has_gmbus_irq = 1, \
.ring_mask = RENDER_RING | BSD_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
@@ -205,6 +206,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.has_rc6 = 1, \
.has_rc6p = 1, \
.has_aux_irq = 1, \
+   .has_gmbus_irq = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -226,6 +228,7 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
.has_core_ring_freq = 1, \
.has_rc6 = 1, \
.has_aux_irq = 1, \
+   .has_gmbus_irq = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -260,6 +263,7 @@ static const struct intel_device_info 
intel_ivybridge_q_info = {
.has_runtime_pm = 1, \
.has_rc6 = 1, \
.has_aux_irq = 1, \
+   .has_gmbus_irq = 1, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.display_mmio_offset = VLV_DISPLAY_BASE, \
@@ -339,6 +343,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_rc6 = 1,
.has_dp_mst = 1,
.has_aux_irq = 1,
+   .has_gmbus_irq = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
@@ -379,6 +384,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_resource_streamer = 1,
.has_rc6 = 1,
.has_aux_irq = 1,
+   .has_gmbus_irq = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
BDW_COLORS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 19/23] drm/915: Move HAS_FW_BLC definition to platform

[Carlos Santa]

Moving all GPU features to the platform definition allows for
- standard placae when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h |  3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 10 +-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a58765b..8f5b9fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -780,6 +780,7 @@ struct intel_csr {
func(has_dp_mst) sep \
func(has_aux_irq) sep \
func(has_gmbus_irq) sep \
+   func(has_fw_blc) sep \
func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
@@ -2848,7 +2849,7 @@ struct drm_i915_cmd_table {
 #define SUPPORTS_TV(dev)   (INTEL_INFO(dev)->supports_tv)
 #define I915_HAS_HOTPLUG(dev)   (INTEL_INFO(dev)->has_hotplug)
 
-#define HAS_FW_BLC(dev) (INTEL_INFO(dev)->gen > 2)
+#define HAS_FW_BLC(dev) (INTEL_INFO(dev)->has_fw_blc)
 #define HAS_PIPE_CXSR(dev) (INTEL_INFO(dev)->has_pipe_cxsr)
 #define HAS_FBC(dev) (INTEL_INFO(dev)->has_fbc)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 50569c1..b44d162 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -82,7 +82,8 @@ static const struct intel_device_info intel_i865g_info = {
 };
 
 #define GEN3_FEATURES \
-   .gen = 3, .num_pipes = 2,\
+   .gen = 3, .num_pipes = 2, \
+   .has_fw_blc = 1, \
.ring_mask = RENDER_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
@@ -122,6 +123,7 @@ static const struct intel_device_info intel_i945gm_info = {
 #define GEN4_FEATURES \
.gen = 4, .num_pipes = 2, \
.has_hotplug = 1, \
+   .has_fw_blc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
 
@@ -180,6 +182,7 @@ static const struct intel_device_info intel_pineview_info = 
{
.need_gfx_hws = 1, .has_hotplug = 1, \
.has_aux_irq = 1, \
.has_gmbus_irq = 1, \
+   .has_fw_blc = 1, \
.ring_mask = RENDER_RING | BSD_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
@@ -205,6 +208,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.has_rc6p = 1, \
.has_aux_irq = 1, \
.has_gmbus_irq = 1, \
+   .has_fw_blc = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -227,6 +231,7 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
.has_rc6 = 1, \
.has_aux_irq = 1, \
.has_gmbus_irq = 1, \
+   .has_fw_blc = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -262,6 +267,7 @@ static const struct intel_device_info 
intel_ivybridge_q_info = {
.has_rc6 = 1, \
.has_aux_irq = 1, \
.has_gmbus_irq = 1, \
+   .has_fw_blc = 1, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.display_mmio_offset = VLV_DISPLAY_BASE, \
@@ -342,6 +348,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_dp_mst = 1,
.has_aux_irq = 1,
.has_gmbus_irq = 1,
+   .has_fw_blc = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
@@ -383,6 +390,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_rc6 = 1,
.has_aux_irq = 1,
.has_gmbus_irq = 1,
+   .has_fw_blc = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
BDW_COLORS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 02/23] drm/i915: Introduce GEN6_FEATURES for device info

[Carlos Santa]

Based on the GEN7_FEATURES changes from Ben W.

Use it for snb.

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_pci.c | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 08cdeb3..8b1311d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -194,24 +194,22 @@ static const struct intel_device_info 
intel_ironlake_m_info = {
CURSOR_OFFSETS,
 };
 
+#define GEN6_FEATURES \
+   .gen = 6, .num_pipes = 2, \
+   .need_gfx_hws = 1, .has_hotplug = 1, \
+   .has_fbc = 1, \
+   .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
+   .has_llc = 1, \
+   GEN_DEFAULT_PIPEOFFSETS, \
+   CURSOR_OFFSETS
+
 static const struct intel_device_info intel_sandybridge_d_info = {
-   .gen = 6, .num_pipes = 2,
-   .need_gfx_hws = 1, .has_hotplug = 1,
-   .has_fbc = 1,
-   .ring_mask = RENDER_RING | BSD_RING | BLT_RING,
-   .has_llc = 1,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+   GEN6_FEATURES
 };
 
 static const struct intel_device_info intel_sandybridge_m_info = {
-   .gen = 6, .is_mobile = 1, .num_pipes = 2,
-   .need_gfx_hws = 1, .has_hotplug = 1,
-   .has_fbc = 1,
-   .ring_mask = RENDER_RING | BSD_RING | BLT_RING,
-   .has_llc = 1,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+   GEN6_FEATURES,
+   .is_mobile = 1
 };
 
 #define GEN7_FEATURES  \
-- 
1.9.1

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

[Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported featurs when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 09c907f..7186665 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -773,6 +773,7 @@ struct intel_csr {
func(has_core_ring_freq) sep \
func(has_csr) sep \
func(has_guc) sep \
+   func(has_guc_ucode) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
func(cursor_needs_physical) sep \
@@ -2864,7 +2865,7 @@ struct drm_i915_cmd_table {
  * properties, so we have separate macros to test them.
  */
 #define HAS_GUC(dev)   (INTEL_INFO(dev)->has_guc)
-#define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
+#define HAS_GUC_UCODE(dev) (INTEL_INFO(dev)->has_guc_ucode)
 #define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
 
 #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f42bf19..8171915 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -327,7 +327,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
 #define GEN9_FEATURES  \
.gen = 9, \
.has_csr = 1, \
-   .has_guc = 1
+   .has_guc = 1, \
+   .has_guc_ucode = 1
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
-- 
1.9.1

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

[Intel-gfx] [PATCH 21/23] drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 5 -
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 06d2850..8f93a93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -782,6 +782,7 @@ struct intel_csr {
func(has_gmbus_irq) sep \
func(has_fw_blc) sep \
func(has_hw_contexts) sep \
+   func(has_logical_ring_contexts) sep \
func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
@@ -2816,7 +2817,7 @@ struct drm_i915_cmd_table {
 #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
 
 #define HAS_HW_CONTEXTS(dev)   (INTEL_INFO(dev)->has_hw_contexts)
-#define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 8)
+#define HAS_LOGICAL_RING_CONTEXTS(dev) 
(INTEL_INFO(dev)->has_logical_ring_contexts)
 #define USES_PPGTT(dev)(i915.enable_ppgtt)
 #define USES_FULL_PPGTT(dev)   (i915.enable_ppgtt >= 2)
 #define USES_FULL_48BIT_PPGTT(dev) (i915.enable_ppgtt == 3)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 26ff54e..d90cb47 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -311,7 +311,8 @@ static const struct intel_device_info intel_haswell_m_info 
= {
 
 #define BDW_FEATURES \
HSW_FEATURES, \
-   BDW_COLORS
+   BDW_COLORS, \
+   .has_logical_ring_contexts = 1
 
 static const struct intel_device_info intel_broadwell_d_info = {
BDW_FEATURES,
@@ -353,6 +354,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_gmbus_irq = 1,
.has_fw_blc = 1,
.has_hw_contexts = 1,
+   .has_logical_ring_contexts = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
@@ -396,6 +398,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_gmbus_irq = 1,
.has_fw_blc = 1,
.has_hw_contexts = 1,
+   .has_logical_ring_contexts = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
BDW_COLORS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 00/23] drm/i915: Organize most GPU features by platform

[Carlos Santa]

This patchset includes the following changes:

 - organize most GPU features so that they are easy to group by platforms.
   It seems some of the ground work was already done for Gen7 features.
   Reuse some of that work for the rest of the Gen platforms (GEN6, GEN5, GEN4, 
GEN3
   and GEN2).

 - make most of these GPU features now a device_info flag also based on
   previous work done by others. The idea is here is to have a central place 
where
   to add new features and also now it should be possible to see what the 
supported 
   features are for a given platform by dumping of the struct definitions.
   The list of the features that were converted to a device_info flag include: 
PSR,
   RUNTIME_PM, CORE_RING_FREQ, CSR, GUC, GUC_UCODE, GUC_SCHED, 
RESOURCE_STREAMER, RC6,
   RC6p, DP_MST, GMBUS_IRQ, FW_BLC, HW_CONTEXTS, LOGICAL_RING_CONTEXTS, L3_DPF, 
and
   GMCH_DISPLAY.

Carlos Santa (23):
  drm/i915: Move HAS_PSR definition to platform struct definition
  drm/i915: Introduce GEN6_FEATURES for device info
  drm/i915: Move HAS_RUNTIME_PM definition to platform
  drm/i915: Move HAS_CORE_RING_FREQ definition to platform definition
  drm/i915: Move HAS_CSR definition to platform definition
  drm/i915: Move HAS_GUC definition to platform definition
  drm/i915: Move HAS_GUC_UCODE definition to platform definition
  drm/i915: Move HAS_GUC_SCHED definition to platform definition
  drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition
  drm/i915: Move HAS_RC6 definition to platform definition
  drm/i915: Move HAS_RC6p definition to platform definition
  drm/i915: Move HAS_DP_MST definition to platform definition
  drm/i915: Introduce GEN5_FEATURES for device info
  drm/i915: Move HAS_AUX_IRQ definition to platform definition
  drm/i915: Move HAS_GMBUS_IRQ definition to platform definition
  drm/i915: Introduce GEN4_FEATURES for device info
  drm/i915: Introduce GEN3_FEATURES for device info
  drm/i915: Introduce GEN2 FEATURES for device info
  drm/915: Move HAS_FW_BLC definition to platform
  drm/i915: Move HAS_HW_CONTEXTS definition to platform
  drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform
definition
  drm/i915: Move HAS_L3_DPF definition to platform definition
  drm/i915: Move HAS_GMCH_DISPLAY definition to platform

 drivers/gpu/drm/i915/i915_drv.h |  67 +-
 drivers/gpu/drm/i915/i915_pci.c | 272 +---
 2 files changed, 206 insertions(+), 133 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 18/23] drm/i915: Introduce GEN2 FEATURES for device info

[Carlos Santa]

Based on the GEN7_FEATURES changes from Ben W.

Use it for 830, 845g, i85x, i865g.

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_pci.c | 33 +
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 5c490f8..50569c1 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -54,38 +54,31 @@
 #define CHV_COLORS \
.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
 
+#define GEN2_FEATURES \
+   .gen = 2, .num_pipes = 1, \
+   .has_overlay = 1, .overlay_needs_physical = 1, \
+   .ring_mask = RENDER_RING, \
+   GEN_DEFAULT_PIPEOFFSETS, \
+   CURSOR_OFFSETS
+
 static const struct intel_device_info intel_i830_info = {
-   .gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
-   .has_overlay = 1, .overlay_needs_physical = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+   GEN2_FEATURES,
+   .is_mobile = 1, .cursor_needs_physical = 1,
 };
 
 static const struct intel_device_info intel_845g_info = {
-   .gen = 2, .num_pipes = 1,
-   .has_overlay = 1, .overlay_needs_physical = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+   GEN2_FEATURES,
 };
 
 static const struct intel_device_info intel_i85x_info = {
-   .gen = 2, .is_i85x = 1, .is_mobile = 1, .num_pipes = 2,
+   GEN2_FEATURES,
+   .is_i85x = 1, .is_mobile = 1,
.cursor_needs_physical = 1,
-   .has_overlay = 1, .overlay_needs_physical = 1,
.has_fbc = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
 };
 
 static const struct intel_device_info intel_i865g_info = {
-   .gen = 2, .num_pipes = 1,
-   .has_overlay = 1, .overlay_needs_physical = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+   GEN2_FEATURES,
 };
 
 #define GEN3_FEATURES \
-- 
1.9.1

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

[Intel-gfx] [PATCH 04/23] drm/i915: Move HAS_CORE_RING_FREQ definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 ++---
 drivers/gpu/drm/i915/i915_pci.c | 2 ++
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7443b9a..69e3818 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -770,6 +770,7 @@ struct intel_csr {
func(has_fbc) sep \
func(has_psr) sep \
func(has_runtime_pm) sep \
+   func(has_core_ring_freq) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
func(cursor_needs_physical) sep \
@@ -2867,9 +2868,7 @@ struct drm_i915_cmd_table {
 #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
 
-#define HAS_CORE_RING_FREQ(dev)(INTEL_INFO(dev)->gen >= 6 && \
-!IS_VALLEYVIEW(dev) && !IS_CHERRYVIEW(dev) && \
-!IS_BROXTON(dev))
+#define HAS_CORE_RING_FREQ(dev)(INTEL_INFO(dev)->has_core_ring_freq)
 
 #define HAS_POOLED_EU(dev) (INTEL_INFO(dev)->has_pooled_eu)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 92ab3c2..674b298 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -199,6 +199,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.need_gfx_hws = 1, .has_hotplug = 1, \
.has_fbc = 1, \
.has_runtime_pm = 1, \
+   .has_core_ring_freq = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -217,6 +218,7 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
.gen = 7, .num_pipes = 3, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.has_fbc = 1, \
+   .has_core_ring_freq = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
-- 
1.9.1

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

[Intel-gfx] [PATCH 01/23] drm/i915: Move HAS_PSR definition to platform struct definition

[Carlos Santa]

[patch series] Moving all GPU features to the platform struct definition
allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct definition

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 ++---
 drivers/gpu/drm/i915/i915_pci.c | 5 -
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e76cfe2..6569eb7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -768,6 +768,7 @@ struct intel_csr {
func(is_kabylake) sep \
func(is_preliminary) sep \
func(has_fbc) sep \
+   func(has_psr) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
func(cursor_needs_physical) sep \
@@ -2846,9 +2847,7 @@ struct drm_i915_cmd_table {
 
 #define HAS_DDI(dev)   (INTEL_INFO(dev)->has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
-#define HAS_PSR(dev)   (IS_HASWELL(dev) || IS_BROADWELL(dev) || \
-IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev) || \
-IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
+#define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
 #define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
 IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
 IS_CHERRYVIEW(dev) || IS_SKYLAKE(dev) || \
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 949c016..08cdeb3 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -242,6 +242,7 @@ static const struct intel_device_info 
intel_ivybridge_q_info = {
 
 #define VLV_FEATURES  \
.gen = 7, .num_pipes = 2, \
+   .has_psr = 1, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.display_mmio_offset = VLV_DISPLAY_BASE, \
@@ -263,7 +264,8 @@ static const struct intel_device_info 
intel_valleyview_d_info = {
GEN7_FEATURES, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
.has_ddi = 1, \
-   .has_fpga_dbg = 1
+   .has_fpga_dbg = 1, \
+   .has_psr = 1
 
 static const struct intel_device_info intel_haswell_d_info = {
HSW_FEATURES,
@@ -311,6 +313,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.is_cherryview = 1,
+   .has_psr = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 14/23] drm/i915: Move HAS_AUX_IRQ definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 6 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 27f23cc5..26283b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -778,6 +778,7 @@ struct intel_csr {
func(has_rc6) sep \
func(has_rc6p) sep \
func(has_dp_mst) sep \
+   func(has_aux_irq) sep \
func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
@@ -2835,7 +2836,7 @@ struct drm_i915_cmd_table {
  * legacy irq no. is shared with another device. The kernel then disables that
  * interrupt source and so prevents the other device from working properly.
  */
-#define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
+#define HAS_AUX_IRQ(dev) (INTEL_INFO(dev)->has_aux_irq)
 #define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
 
 /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 3844840..9a5cb33 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -180,6 +180,7 @@ static const struct intel_device_info intel_pineview_info = 
{
 #define GEN5_FEATURES \
.gen = 5, .num_pipes = 2, \
.need_gfx_hws = 1, .has_hotplug = 1, \
+   .has_aux_irq = 1, \
.ring_mask = RENDER_RING | BSD_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
@@ -203,6 +204,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.has_core_ring_freq = 1, \
.has_rc6 = 1, \
.has_rc6p = 1, \
+   .has_aux_irq = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -223,6 +225,7 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
.has_fbc = 1, \
.has_core_ring_freq = 1, \
.has_rc6 = 1, \
+   .has_aux_irq = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -256,6 +259,7 @@ static const struct intel_device_info 
intel_ivybridge_q_info = {
.has_psr = 1, \
.has_runtime_pm = 1, \
.has_rc6 = 1, \
+   .has_aux_irq = 1, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.display_mmio_offset = VLV_DISPLAY_BASE, \
@@ -334,6 +338,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_resource_streamer = 1,
.has_rc6 = 1,
.has_dp_mst = 1,
+   .has_aux_irq = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
@@ -373,6 +378,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_pooled_eu = 0,
.has_resource_streamer = 1,
.has_rc6 = 1,
+   .has_aux_irq = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
BDW_COLORS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 12/23] drm/i915: Move HAS_DP_MST definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 5 ++---
 drivers/gpu/drm/i915/i915_pci.c | 4 +++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a6a22b4..27f23cc5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -777,6 +777,7 @@ struct intel_csr {
func(has_guc_sched) sep \
func(has_rc6) sep \
func(has_rc6p) sep \
+   func(has_dp_mst) sep \
func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
@@ -2851,9 +2852,7 @@ struct drm_i915_cmd_table {
 
 #define HAS_IPS(dev)   (IS_HSW_ULT(dev) || IS_BROADWELL(dev))
 
-#define HAS_DP_MST(dev)(IS_HASWELL(dev) || IS_BROADWELL(dev) 
|| \
-INTEL_INFO(dev)->gen >= 9)
-
+#define HAS_DP_MST(dev)(INTEL_INFO(dev)->has_dp_mst)
 #define HAS_DDI(dev)   (INTEL_INFO(dev)->has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
 #define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index c6dae2c..099f134 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -279,7 +279,8 @@ static const struct intel_device_info 
intel_valleyview_d_info = {
.has_fpga_dbg = 1, \
.has_psr = 1, \
.has_runtime_pm = 1, \
-   .has_resource_streamer = 1
+   .has_resource_streamer = 1, \
+   .has_dp_mst = 1
 
 static const struct intel_device_info intel_haswell_d_info = {
HSW_FEATURES,
@@ -331,6 +332,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_runtime_pm = 1,
.has_resource_streamer = 1,
.has_rc6 = 1,
+   .has_dp_mst = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 05/23] drm/i915: Move HAS_CSR definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h |  3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 14 +-
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 69e3818..db4930c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -771,6 +771,7 @@ struct intel_csr {
func(has_psr) sep \
func(has_runtime_pm) sep \
func(has_core_ring_freq) sep \
+   func(has_csr) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
func(cursor_needs_physical) sep \
@@ -2854,7 +2855,7 @@ struct drm_i915_cmd_table {
 #define HAS_RC6(dev)   (INTEL_INFO(dev)->gen >= 6)
 #define HAS_RC6p(dev)  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
 
-#define HAS_CSR(dev)   (IS_GEN9(dev))
+#define HAS_CSR(dev)   (INTEL_INFO(dev)->has_csr)
 
 /*
  * For now, anything with a GuC requires uCode loading, and then supports
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 674b298..d266af5 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -324,22 +324,26 @@ static const struct intel_device_info 
intel_cherryview_info = {
CHV_COLORS,
 };
 
+#define GEN9_FEATURES  \
+   .gen = 9, \
+   .has_csr = 1
+
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
+   GEN9_FEATURES,
.is_skylake = 1,
-   .gen = 9,
 };
 
 static const struct intel_device_info intel_skylake_gt3_info = {
BDW_FEATURES,
+   GEN9_FEATURES,
.is_skylake = 1,
-   .gen = 9,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
 static const struct intel_device_info intel_broxton_info = {
+   GEN9_FEATURES,
.is_broxton = 1,
-   .gen = 9,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_pipes = 3,
@@ -355,14 +359,14 @@ static const struct intel_device_info intel_broxton_info 
= {
 
 static const struct intel_device_info intel_kabylake_info = {
BDW_FEATURES,
+   GEN9_FEATURES,
.is_kabylake = 1,
-   .gen = 9,
 };
 
 static const struct intel_device_info intel_kabylake_gt3_info = {
BDW_FEATURES,
+   GEN9_FEATURES,
.is_kabylake = 1,
-   .gen = 9,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 23/23] drm/i915: Move HAS_GMCH_DISPLAY definition to platform

[Carlos Santa]

Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 4 ++--
 drivers/gpu/drm/i915/i915_pci.c | 5 +
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7075f76..b9d0478 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -784,6 +784,7 @@ struct intel_csr {
func(has_hw_contexts) sep \
func(has_logical_ring_contexts) sep \
func(has_l3_dpf) sep \
+   func(has_gmch_display) sep \
func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
@@ -2907,8 +2908,7 @@ struct drm_i915_cmd_table {
 #define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
 #define HAS_PCH_SPLIT(dev) (INTEL_PCH_TYPE(dev) != PCH_NONE)
 
-#define HAS_GMCH_DISPLAY(dev) (INTEL_INFO(dev)->gen < 5 || \
-  IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
+#define HAS_GMCH_DISPLAY(dev) (INTEL_INFO(dev)->has_gmch_display)
 
 /* DPF == dynamic parity feature */
 #define HAS_L3_DPF(dev) (INTEL_INFO(dev)->has_l3_dpf)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index c03cb97..59f3e35 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -57,6 +57,7 @@
 #define GEN2_FEATURES \
.gen = 2, .num_pipes = 1, \
.has_overlay = 1, .overlay_needs_physical = 1, \
+   .has_gmch_display = 1, \
.ring_mask = RENDER_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
@@ -84,6 +85,7 @@ static const struct intel_device_info intel_i865g_info = {
 #define GEN3_FEATURES \
.gen = 3, .num_pipes = 2, \
.has_fw_blc = 1, \
+   .has_gmch_display = 1, \
.ring_mask = RENDER_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
@@ -124,6 +126,7 @@ static const struct intel_device_info intel_i945gm_info = {
.gen = 4, .num_pipes = 2, \
.has_hotplug = 1, \
.has_fw_blc = 1, \
+   .has_gmch_display = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
CURSOR_OFFSETS
 
@@ -272,6 +275,7 @@ static const struct intel_device_info 
intel_ivybridge_q_info = {
.has_gmbus_irq = 1, \
.has_fw_blc = 1, \
.has_hw_contexts = 1, \
+   .has_gmch_display = 1, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.display_mmio_offset = VLV_DISPLAY_BASE, \
@@ -357,6 +361,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_fw_blc = 1,
.has_hw_contexts = 1,
.has_logical_ring_contexts = 1,
+   .has_gmch_display = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 03/23] drm/i915: Move HAS_RUNTIME_PM definition to platform

[Carlos Santa]

Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 6 ++
 drivers/gpu/drm/i915/i915_pci.c | 7 ++-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6569eb7..7443b9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -769,6 +769,7 @@ struct intel_csr {
func(is_preliminary) sep \
func(has_fbc) sep \
func(has_psr) sep \
+   func(has_runtime_pm) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
func(cursor_needs_physical) sep \
@@ -2848,10 +2849,7 @@ struct drm_i915_cmd_table {
 #define HAS_DDI(dev)   (INTEL_INFO(dev)->has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
 #define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
-#define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
-IS_BROADWELL(dev) || IS_VALLEYVIEW(dev) || \
-IS_CHERRYVIEW(dev) || IS_SKYLAKE(dev) || \
-IS_KABYLAKE(dev) || IS_BROXTON(dev))
+#define HAS_RUNTIME_PM(dev)(INTEL_INFO(dev)->has_runtime_pm)
 #define HAS_RC6(dev)   (INTEL_INFO(dev)->gen >= 6)
 #define HAS_RC6p(dev)  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 8b1311d..92ab3c2 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -198,6 +198,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.gen = 6, .num_pipes = 2, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.has_fbc = 1, \
+   .has_runtime_pm = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -241,6 +242,7 @@ static const struct intel_device_info 
intel_ivybridge_q_info = {
 #define VLV_FEATURES  \
.gen = 7, .num_pipes = 2, \
.has_psr = 1, \
+   .has_runtime_pm = 1, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.display_mmio_offset = VLV_DISPLAY_BASE, \
@@ -263,7 +265,8 @@ static const struct intel_device_info 
intel_valleyview_d_info = {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
.has_ddi = 1, \
.has_fpga_dbg = 1, \
-   .has_psr = 1
+   .has_psr = 1, \
+   .has_runtime_pm = 1
 
 static const struct intel_device_info intel_haswell_d_info = {
HSW_FEATURES,
@@ -312,6 +315,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.is_cherryview = 1,
.has_psr = 1,
+   .has_runtime_pm = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
@@ -340,6 +344,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_ddi = 1,
.has_fpga_dbg = 1,
.has_fbc = 1,
+   .has_runtime_pm = 1,
.has_pooled_eu = 0,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 22/23] drm/i915: Move HAS_L3_DPF definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 6 --
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8f93a93..7075f76 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -783,6 +783,7 @@ struct intel_csr {
func(has_fw_blc) sep \
func(has_hw_contexts) sep \
func(has_logical_ring_contexts) sep \
+   func(has_l3_dpf) sep \
func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
@@ -2910,7 +2911,7 @@ struct drm_i915_cmd_table {
   IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
 
 /* DPF == dynamic parity feature */
-#define HAS_L3_DPF(dev) (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
+#define HAS_L3_DPF(dev) (INTEL_INFO(dev)->has_l3_dpf)
 #define NUM_L3_SLICES(dev) (IS_HSW_GT3(dev) ? 2 : HAS_L3_DPF(dev))
 
 #define GT_FREQUENCY_MULTIPLIER 50
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d90cb47..c03cb97 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -240,7 +240,8 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
IVB_CURSOR_OFFSETS
 
 #define IVB_FEATURES  \
-   .has_rc6p = 1
+   .has_rc6p = 1, \
+   .has_l3_dpf = 1
 
 static const struct intel_device_info intel_ivybridge_d_info = {
GEN7_FEATURES,
@@ -296,7 +297,8 @@ static const struct intel_device_info 
intel_valleyview_d_info = {
.has_psr = 1, \
.has_runtime_pm = 1, \
.has_resource_streamer = 1, \
-   .has_dp_mst = 1
+   .has_dp_mst = 1, \
+   .has_l3_dpf = 1
 
 static const struct intel_device_info intel_haswell_d_info = {
HSW_FEATURES,
-- 
1.9.1

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

[Intel-gfx] [PATCH 20/23] drm/i915: Move HAS_HW_CONTEXTS definition to platform

[Carlos Santa]

Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumpig struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8f5b9fd..06d2850 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -781,6 +781,7 @@ struct intel_csr {
func(has_aux_irq) sep \
func(has_gmbus_irq) sep \
func(has_fw_blc) sep \
+   func(has_hw_contexts) sep \
func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
@@ -2814,7 +2815,7 @@ struct drm_i915_cmd_table {
 HAS_EDRAM(dev))
 #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
 
-#define HAS_HW_CONTEXTS(dev)   (INTEL_INFO(dev)->gen >= 6)
+#define HAS_HW_CONTEXTS(dev)   (INTEL_INFO(dev)->has_hw_contexts)
 #define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 8)
 #define USES_PPGTT(dev)(i915.enable_ppgtt)
 #define USES_FULL_PPGTT(dev)   (i915.enable_ppgtt >= 2)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index b44d162..26ff54e 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -209,6 +209,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.has_aux_irq = 1, \
.has_gmbus_irq = 1, \
.has_fw_blc = 1, \
+   .has_hw_contexts = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -232,6 +233,7 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
.has_aux_irq = 1, \
.has_gmbus_irq = 1, \
.has_fw_blc = 1, \
+   .has_hw_contexts = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -268,6 +270,7 @@ static const struct intel_device_info 
intel_ivybridge_q_info = {
.has_aux_irq = 1, \
.has_gmbus_irq = 1, \
.has_fw_blc = 1, \
+   .has_hw_contexts = 1, \
.need_gfx_hws = 1, .has_hotplug = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.display_mmio_offset = VLV_DISPLAY_BASE, \
@@ -349,6 +352,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_aux_irq = 1,
.has_gmbus_irq = 1,
.has_fw_blc = 1,
+   .has_hw_contexts = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
@@ -391,6 +395,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_aux_irq = 1,
.has_gmbus_irq = 1,
.has_fw_blc = 1,
+   .has_hw_contexts = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
BDW_COLORS,
-- 
1.9.1

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

[Intel-gfx] [PATCH 16/23] drm/i915: Introduce GEN4_FEATURES for device info

[Carlos Santa]

Based on the GEN7_FEATURES changes from Ben W.

Use it for i965g, i965gm, g45,and gm45.

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_pci.c | 51 ++---
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 4652e2d..c4fdb4d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -123,23 +123,34 @@ static const struct intel_device_info intel_i945gm_info = 
{
CURSOR_OFFSETS,
 };
 
+#define GEN4_FEATURES \
+   .gen = 4, .num_pipes = 2, \
+   .has_hotplug = 1, \
+   GEN_DEFAULT_PIPEOFFSETS, \
+   CURSOR_OFFSETS
+
+#define GEN4_G45_FEATURES \
+   .is_g4x = 1, .need_gfx_hws = 1, \
+   .has_pipe_cxsr = 1, \
+   .ring_mask = RENDER_RING | BSD_RING
+
+#define GEN4_i965_FEATURES \
+   .has_overlay = 1, \
+   .ring_mask = RENDER_RING
+
 static const struct intel_device_info intel_i965g_info = {
-   .gen = 4, .is_broadwater = 1, .num_pipes = 2,
-   .has_hotplug = 1,
-   .has_overlay = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+   GEN4_FEATURES,
+   GEN4_i965_FEATURES,
+   .is_broadwater = 1,
+
 };
 
 static const struct intel_device_info intel_i965gm_info = {
-   .gen = 4, .is_crestline = 1, .num_pipes = 2,
-   .is_mobile = 1, .has_fbc = 1, .has_hotplug = 1,
-   .has_overlay = 1,
+   GEN4_FEATURES,
+   GEN4_i965_FEATURES,
+   .is_crestline = 1,
+   .is_mobile = 1, .has_fbc = 1,
.supports_tv = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
 };
 
 static const struct intel_device_info intel_g33_info = {
@@ -152,21 +163,15 @@ static const struct intel_device_info intel_g33_info = {
 };
 
 static const struct intel_device_info intel_g45_info = {
-   .gen = 4, .is_g4x = 1, .need_gfx_hws = 1, .num_pipes = 2,
-   .has_pipe_cxsr = 1, .has_hotplug = 1,
-   .ring_mask = RENDER_RING | BSD_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+   GEN4_FEATURES,
+   GEN4_G45_FEATURES,
 };
 
 static const struct intel_device_info intel_gm45_info = {
-   .gen = 4, .is_g4x = 1, .num_pipes = 2,
-   .is_mobile = 1, .need_gfx_hws = 1, .has_fbc = 1,
-   .has_pipe_cxsr = 1, .has_hotplug = 1,
+   GEN4_FEATURES,
+   GEN4_G45_FEATURES,
+   .is_mobile = 1, .has_fbc = 1,
.supports_tv = 1,
-   .ring_mask = RENDER_RING | BSD_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
 };
 
 static const struct intel_device_info intel_pineview_info = {
-- 
1.9.1

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

[Intel-gfx] [PATCH 08/23] drm/i915: Move HAS_GUC_SCHED definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7186665..2ba441e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -774,6 +774,7 @@ struct intel_csr {
func(has_csr) sep \
func(has_guc) sep \
func(has_guc_ucode) sep \
+   func(has_guc_sched) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
func(cursor_needs_physical) sep \
@@ -2866,7 +2867,7 @@ struct drm_i915_cmd_table {
  */
 #define HAS_GUC(dev)   (INTEL_INFO(dev)->has_guc)
 #define HAS_GUC_UCODE(dev) (INTEL_INFO(dev)->has_guc_ucode)
-#define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
+#define HAS_GUC_SCHED(dev) (INTEL_INFO(dev)->has_guc_sched)
 
 #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 8171915..f2cb5c3 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -328,7 +328,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
.gen = 9, \
.has_csr = 1, \
.has_guc = 1, \
-   .has_guc_ucode = 1
+   .has_guc_ucode = 1, \
+   .has_guc_sched = 1
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
-- 
1.9.1

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

[Intel-gfx] [PATCH 13/23] drm/i915: Introduce GEN5_FEATURES for device info

[Carlos Santa]

Based on the GEN7_FEATURES changes from Ben W.

Use it for ilk.

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_pci.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 099f134..3844840 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -177,21 +177,22 @@ static const struct intel_device_info intel_pineview_info 
= {
CURSOR_OFFSETS,
 };
 
+#define GEN5_FEATURES \
+   .gen = 5, .num_pipes = 2, \
+   .need_gfx_hws = 1, .has_hotplug = 1, \
+   .ring_mask = RENDER_RING | BSD_RING, \
+   GEN_DEFAULT_PIPEOFFSETS, \
+   CURSOR_OFFSETS
+
 static const struct intel_device_info intel_ironlake_d_info = {
-   .gen = 5, .num_pipes = 2,
-   .need_gfx_hws = 1, .has_hotplug = 1,
-   .ring_mask = RENDER_RING | BSD_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+   GEN5_FEATURES
 };
 
 static const struct intel_device_info intel_ironlake_m_info = {
-   .gen = 5, .is_mobile = 1, .num_pipes = 2,
-   .need_gfx_hws = 1, .has_hotplug = 1,
+   GEN5_FEATURES,
+   .is_mobile = 1,
.has_fbc = 1,
-   .ring_mask = RENDER_RING | BSD_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+
 };
 
 #define GEN6_FEATURES \
-- 
1.9.1

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

[Intel-gfx] [PATCH 11/23] drm/i915: Move HAS_RC6p definition to platform definition

[Carlos Santa]

Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
  definitions

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 drivers/gpu/drm/i915/i915_pci.c | 7 +++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 75131a0..a6a22b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -776,6 +776,7 @@ struct intel_csr {
func(has_guc_ucode) sep \
func(has_guc_sched) sep \
func(has_rc6) sep \
+   func(has_rc6p) sep \
func(has_resource_streamer) sep \
func(has_pipe_cxsr) sep \
func(has_hotplug) sep \
@@ -2858,7 +2859,7 @@ struct drm_i915_cmd_table {
 #define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
 #define HAS_RUNTIME_PM(dev)(INTEL_INFO(dev)->has_runtime_pm)
 #define HAS_RC6(dev)   (INTEL_INFO(dev)->has_rc6)
-#define HAS_RC6p(dev)  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
+#define HAS_RC6p(dev)  (INTEL_INFO(dev)->has_rc6p)
 
 #define HAS_CSR(dev)   (INTEL_INFO(dev)->has_csr)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index e10fb5c..c6dae2c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -201,6 +201,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.has_runtime_pm = 1, \
.has_core_ring_freq = 1, \
.has_rc6 = 1, \
+   .has_rc6p = 1, \
.ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
.has_llc = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
@@ -226,19 +227,25 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
GEN_DEFAULT_PIPEOFFSETS, \
IVB_CURSOR_OFFSETS
 
+#define IVB_FEATURES  \
+   .has_rc6p = 1
+
 static const struct intel_device_info intel_ivybridge_d_info = {
GEN7_FEATURES,
+   IVB_FEATURES,
.is_ivybridge = 1,
 };
 
 static const struct intel_device_info intel_ivybridge_m_info = {
GEN7_FEATURES,
+   IVB_FEATURES,
.is_ivybridge = 1,
.is_mobile = 1,
 };
 
 static const struct intel_device_info intel_ivybridge_q_info = {
GEN7_FEATURES,
+   IVB_FEATURES,
.is_ivybridge = 1,
.num_pipes = 0, /* legal, last one wins */
 };
-- 
1.9.1

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

[Intel-gfx] [PATCH 17/23] drm/i915: Introduce GEN3_FEATURES for device info

[Carlos Santa]

Based on the GEN7_FEATURES changes from Ben W.

Use it for i915g, i915gm, i945g, i945gm, g33 and pineview.

Signed-off-by: Carlos Santa 
---
 drivers/gpu/drm/i915/i915_pci.c | 58 -
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index c4fdb4d..5c490f8 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -88,39 +88,42 @@ static const struct intel_device_info intel_i865g_info = {
CURSOR_OFFSETS,
 };
 
+#define GEN3_FEATURES \
+   .gen = 3, .num_pipes = 2,\
+   .ring_mask = RENDER_RING, \
+   GEN_DEFAULT_PIPEOFFSETS, \
+   CURSOR_OFFSETS
+
+#define GEN3_i9X5_FEATURES \
+   .cursor_needs_physical = 1, \
+   .has_overlay = 1, \
+   .overlay_needs_physical = 1
+
 static const struct intel_device_info intel_i915g_info = {
-   .gen = 3, .is_i915g = 1, .cursor_needs_physical = 1, .num_pipes = 2,
-   .has_overlay = 1, .overlay_needs_physical = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+   GEN3_FEATURES,
+   GEN3_i9X5_FEATURES,
+   .is_i915g = 1,
+
 };
 static const struct intel_device_info intel_i915gm_info = {
-   .gen = 3, .is_mobile = 1, .num_pipes = 2,
-   .cursor_needs_physical = 1,
-   .has_overlay = 1, .overlay_needs_physical = 1,
+   GEN3_FEATURES,
+   GEN3_i9X5_FEATURES,
+   .is_mobile = 1,
.supports_tv = 1,
.has_fbc = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
 };
 static const struct intel_device_info intel_i945g_info = {
-   .gen = 3, .has_hotplug = 1, .cursor_needs_physical = 1, .num_pipes = 2,
-   .has_overlay = 1, .overlay_needs_physical = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
+   GEN3_FEATURES,
+   GEN3_i9X5_FEATURES,
+   .has_hotplug = 1,
 };
 static const struct intel_device_info intel_i945gm_info = {
-   .gen = 3, .is_i945gm = 1, .is_mobile = 1, .num_pipes = 2,
-   .has_hotplug = 1, .cursor_needs_physical = 1,
-   .has_overlay = 1, .overlay_needs_physical = 1,
+   GEN3_FEATURES,
+   GEN3_i9X5_FEATURES,
+   .is_i945gm = 1, .is_mobile = 1,
+   .has_hotplug = 1,
.supports_tv = 1,
.has_fbc = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
 };
 
 #define GEN4_FEATURES \
@@ -154,12 +157,10 @@ static const struct intel_device_info intel_i965gm_info = 
{
 };
 
 static const struct intel_device_info intel_g33_info = {
-   .gen = 3, .is_g33 = 1, .num_pipes = 2,
+   GEN3_FEATURES,
+   .is_g33 = 1,
.need_gfx_hws = 1, .has_hotplug = 1,
.has_overlay = 1,
-   .ring_mask = RENDER_RING,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
 };
 
 static const struct intel_device_info intel_g45_info = {
@@ -175,11 +176,10 @@ static const struct intel_device_info intel_gm45_info = {
 };
 
 static const struct intel_device_info intel_pineview_info = {
-   .gen = 3, .is_g33 = 1, .is_pineview = 1, .is_mobile = 1, .num_pipes = 2,
+   GEN3_FEATURES,
+   .is_g33 = 1, .is_pineview = 1, .is_mobile = 1,
.need_gfx_hws = 1, .has_hotplug = 1,
.has_overlay = 1,
-   GEN_DEFAULT_PIPEOFFSETS,
-   CURSOR_OFFSETS,
 };
 
 #define GEN5_FEATURES \
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: rename & update eb_select_ring()

[Chris Wilson]

On Wed, Jul 20, 2016 at 06:16:07PM +0100, Dave Gordon wrote:
> 'ring' is an old deprecated term for a GPU engine, so we're trying to
> phase out all such terminology. eb_select_ring() not only has 'ring'
> (meaning engine) in its name, but it has an ugly calling convention
> whereby it returns an errno and stores a pointer-to-engine indirectly
> through an output parameter. As there is only one error it ever returns
> (-EINVAL), we can make it return the pointer directly, and have the
> caller pass back the error code -EINVAL if the pointer result is NULL.
> 
> Thus we can replace
> - ret = eb_select_ring(dev_priv, file, args, );
> - if (ret)
> - return ret;
> with
> + engine = eb_select_engine(dev_priv, file, args);
> + if (!engine)
> + return -EINVAL;
> for increased clarity and maybe save a few cycles too.
> 
> Signed-off-by: Dave Gordon 

Thanks. I feel foolish for missing that easy transform before.
Reviewed-by: Chris Wilson 

There's a bsd_ring buried beneath here as well...
-Chris

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: rename 'ring' where it refers to an engine or engine_id

[Chris Wilson]

On Wed, Jul 20, 2016 at 06:16:06PM +0100, Dave Gordon wrote:
> 'ring' is an old deprecated term for a GPU engine. Chris Wilson wants to
> use the name for what is currently known as an intel_ringbuffer, but it
> will be dreadfully confusing if some rings are ringbuffers but other
> rings are still engines. So this patch changes the names of a bunch of
> parameters called 'ring' to either 'engine' or 'engine_id' according to
> what they actually are.
> 
> Signed-off-by: Dave Gordon 
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: rename macro parameter(ring) to (engine)

[Chris Wilson]

On Wed, Jul 20, 2016 at 06:16:05PM +0100, Dave Gordon wrote:
> 'ring' is an old deprecated term for a GPU engine. Here we make the
> terminology more consistent by renaming the 'ring' parameter of lots of
> macros that calculate addresses within the MMIO space of an engine.
> 
> Signed-off-by: Dave Gordon 
Reviewed-by: Chris Wilson 

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 14 +++---
>  drivers/gpu/drm/i915/intel_lrc.h| 16 
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 24 
>  3 files changed, 27 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8bfde75..559c9d7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -186,13 +186,13 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define  GEN9_GRDOM_GUC  (1 << 5)
>  #define  GEN8_GRDOM_MEDIA2   (1 << 7)
>  
> -#define RING_PP_DIR_BASE(ring)   _MMIO((ring)->mmio_base+0x228)
> -#define RING_PP_DIR_BASE_READ(ring)  _MMIO((ring)->mmio_base+0x518)
> -#define RING_PP_DIR_DCLV(ring)   _MMIO((ring)->mmio_base+0x220)
> +#define RING_PP_DIR_BASE(engine) _MMIO((engine)->mmio_base+0x228)
> +#define RING_PP_DIR_BASE_READ(engine)_MMIO((engine)->mmio_base+0x518)
> +#define RING_PP_DIR_DCLV(engine) _MMIO((engine)->mmio_base+0x220)
>  #define   PP_DIR_DCLV_2G 0x

Since these registers don't refer to the actual ring buffer, but the
state of the engine itself, I was thinking about updating the RING_
prefix as well. I didn't think it is worth it atm.
-Chris

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

Re: [Intel-gfx] Reduce usage of the name 'ring' for engines et al

[Chris Wilson]

On Wed, Jul 20, 2016 at 06:16:04PM +0100, Dave Gordon wrote:
> Chris Wilson is trying to convert 'ringbuffer' to 'ring', but at present
> there's rather too much legacy code using 'ring' for various other things,
> usually engines or engine-ids. This patchset converts some of them (but
> not as yet the gpu_error or trace code).

For trace, I think we want to be a little more relaxed, just so we avoid
user visible changes without a strong justification.
 
> Chris: what is your prefered name for a local holding an engine id?
> 'engine_id' is obvious, but seems overly long and clunky. Anything better?

I was going along the lines of int idx = req->engine->id. Of course,
that is only clear in simple cases. In more complex stacks, engine_id
wins - but those are fortunately rare.
-chris

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

[Intel-gfx] [PATCH 2/3] drm/i915: rename 'ring' where it refers to an engine or engine_id

[Dave Gordon]

'ring' is an old deprecated term for a GPU engine. Chris Wilson wants to
use the name for what is currently known as an intel_ringbuffer, but it
will be dreadfully confusing if some rings are ringbuffers but other
rings are still engines. So this patch changes the names of a bunch of
parameters called 'ring' to either 'engine' or 'engine_id' according to
what they actually are.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_mocs.c   |  6 +++---
 drivers/gpu/drm/i915/intel_mocs.h   |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h | 12 ++--
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
b/drivers/gpu/drm/i915/intel_mocs.c
index 2280c32..bd46968 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -204,9 +204,9 @@ static bool get_mocs_settings(struct drm_i915_private 
*dev_priv,
return result;
 }
 
-static i915_reg_t mocs_register(enum intel_engine_id ring, int index)
+static i915_reg_t mocs_register(enum intel_engine_id engine_id, int index)
 {
-   switch (ring) {
+   switch (engine_id) {
case RCS:
return GEN9_GFX_MOCS(index);
case VCS:
@@ -218,7 +218,7 @@ static i915_reg_t mocs_register(enum intel_engine_id ring, 
int index)
case VCS2:
return GEN9_MFX1_MOCS(index);
default:
-   MISSING_CASE(ring);
+   MISSING_CASE(engine_id);
return INVALID_MMIO_REG;
}
 }
diff --git a/drivers/gpu/drm/i915/intel_mocs.h 
b/drivers/gpu/drm/i915/intel_mocs.h
index 4640299..a8bd9f7 100644
--- a/drivers/gpu/drm/i915/intel_mocs.h
+++ b/drivers/gpu/drm/i915/intel_mocs.h
@@ -54,6 +54,6 @@
 
 int intel_rcs_context_init_mocs(struct drm_i915_gem_request *req);
 void intel_mocs_init_l3cc_table(struct drm_device *dev);
-int intel_mocs_init_engine(struct intel_engine_cs *ring);
+int intel_mocs_init_engine(struct intel_engine_cs *engine);
 
 #endif
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b844e69..a6f7db2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1581,7 +1581,7 @@ static inline bool i915_gem_has_seqno_wrapped(struct 
drm_i915_private *dev_priv,
 }
 
 static void
-gen5_seqno_barrier(struct intel_engine_cs *ring)
+gen5_seqno_barrier(struct intel_engine_cs *engine)
 {
/* MI_STORE are internally buffered by the GPU and not flushed
 * either by MI_FLUSH or SyncFlush or any other combination of
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 4671fb8..0f80194 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -197,14 +197,14 @@ struct intel_engine_cs {
 
u32 irq_keep_mask; /* always keep these interrupts */
u32 irq_enable_mask; /* bitmask to enable ring interrupt */
-   void(*irq_enable)(struct intel_engine_cs *ring);
-   void(*irq_disable)(struct intel_engine_cs *ring);
+   void(*irq_enable)(struct intel_engine_cs *engine);
+   void(*irq_disable)(struct intel_engine_cs *engine);
 
-   int (*init_hw)(struct intel_engine_cs *ring);
+   int (*init_hw)(struct intel_engine_cs *engine);
 
int (*init_context)(struct drm_i915_gem_request *req);
 
-   void(*write_tail)(struct intel_engine_cs *ring,
+   void(*write_tail)(struct intel_engine_cs *engine,
  u32 value);
int __must_check (*flush)(struct drm_i915_gem_request *req,
  u32   invalidate_domains,
@@ -216,14 +216,14 @@ struct intel_engine_cs {
 * seen value is good enough. Note that the seqno will always be
 * monotonic, even if not coherent.
 */
-   void(*irq_seqno_barrier)(struct intel_engine_cs *ring);
+   void(*irq_seqno_barrier)(struct intel_engine_cs *engine);
int (*dispatch_execbuffer)(struct drm_i915_gem_request *req,
   u64 offset, u32 length,
   unsigned dispatch_flags);
 #define I915_DISPATCH_SECURE 0x1
 #define I915_DISPATCH_PINNED 0x2
 #define I915_DISPATCH_RS 0x4
-   void(*cleanup)(struct intel_engine_cs *ring);
+   void(*cleanup)(struct intel_engine_cs *engine);
 
/* GEN8 signal/wait table - never trust comments!
 *signal to signal tosignal to   signal to  signal 
to
-- 
1.9.1

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

[Intel-gfx] Reduce usage of the name 'ring' for engines et al

[Dave Gordon]

Chris Wilson is trying to convert 'ringbuffer' to 'ring', but at present
there's rather too much legacy code using 'ring' for various other things,
usually engines or engine-ids. This patchset converts some of them (but
not as yet the gpu_error or trace code).

Chris: what is your prefered name for a local holding an engine id?
'engine_id' is obvious, but seems overly long and clunky. Anything better?

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

[Intel-gfx] [PATCH 1/3] drm/i915: rename macro parameter(ring) to (engine)

[Dave Gordon]

'ring' is an old deprecated term for a GPU engine. Here we make the
terminology more consistent by renaming the 'ring' parameter of lots of
macros that calculate addresses within the MMIO space of an engine.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_reg.h | 14 +++---
 drivers/gpu/drm/i915/intel_lrc.h| 16 
 drivers/gpu/drm/i915/intel_ringbuffer.h | 24 
 3 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8bfde75..559c9d7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -186,13 +186,13 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define  GEN9_GRDOM_GUC(1 << 5)
 #define  GEN8_GRDOM_MEDIA2 (1 << 7)
 
-#define RING_PP_DIR_BASE(ring) _MMIO((ring)->mmio_base+0x228)
-#define RING_PP_DIR_BASE_READ(ring)_MMIO((ring)->mmio_base+0x518)
-#define RING_PP_DIR_DCLV(ring) _MMIO((ring)->mmio_base+0x220)
+#define RING_PP_DIR_BASE(engine)   _MMIO((engine)->mmio_base+0x228)
+#define RING_PP_DIR_BASE_READ(engine)  _MMIO((engine)->mmio_base+0x518)
+#define RING_PP_DIR_DCLV(engine)   _MMIO((engine)->mmio_base+0x220)
 #define   PP_DIR_DCLV_2G   0x
 
-#define GEN8_RING_PDP_UDW(ring, n) _MMIO((ring)->mmio_base+0x270 + (n) * 8 
+ 4)
-#define GEN8_RING_PDP_LDW(ring, n) _MMIO((ring)->mmio_base+0x270 + (n) * 8)
+#define GEN8_RING_PDP_UDW(engine, n)   _MMIO((engine)->mmio_base+0x270 + (n) * 
8 + 4)
+#define GEN8_RING_PDP_LDW(engine, n)   _MMIO((engine)->mmio_base+0x270 + (n) * 
8)
 
 #define GEN8_R_PWR_CLK_STATE   _MMIO(0x20C8)
 #define   GEN8_RPCS_ENABLE (1 << 31)
@@ -1647,7 +1647,7 @@ enum skl_disp_power_wells {
 #define   ARB_MODE_BWGTLB_DISABLE (1<<9)
 #define   ARB_MODE_SWIZZLE_BDW (1<<1)
 #define RENDER_HWS_PGA_GEN7_MMIO(0x04080)
-#define RING_FAULT_REG(ring)   _MMIO(0x4094 + 0x100*(ring)->id)
+#define RING_FAULT_REG(engine) _MMIO(0x4094 + 0x100*(engine)->id)
 #define   RING_FAULT_GTTSEL_MASK (1<<11)
 #define   RING_FAULT_SRCID(x)  (((x) >> 3) & 0xff)
 #define   RING_FAULT_FAULT_TYPE(x) (((x) >> 1) & 0x3)
@@ -1842,7 +1842,7 @@ enum skl_disp_power_wells {
 
 #define GFX_MODE   _MMIO(0x2520)
 #define GFX_MODE_GEN7  _MMIO(0x229c)
-#define RING_MODE_GEN7(ring)   _MMIO((ring)->mmio_base+0x29c)
+#define RING_MODE_GEN7(engine) _MMIO((engine)->mmio_base+0x29c)
 #define   GFX_RUN_LIST_ENABLE  (1<<15)
 #define   GFX_INTERRUPT_STEERING   (1<<14)
 #define   GFX_TLB_INVALIDATE_EXPLICIT  (1<<13)
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index aa3ac02..3828730 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -29,17 +29,17 @@
 #define GEN8_LR_CONTEXT_ALIGN 4096
 
 /* Execlists regs */
-#define RING_ELSP(ring)_MMIO((ring)->mmio_base 
+ 0x230)
-#define RING_EXECLIST_STATUS_LO(ring)  _MMIO((ring)->mmio_base + 0x234)
-#define RING_EXECLIST_STATUS_HI(ring)  _MMIO((ring)->mmio_base + 0x234 
+ 4)
-#define RING_CONTEXT_CONTROL(ring) _MMIO((ring)->mmio_base + 0x244)
+#define RING_ELSP(engine)  _MMIO((engine)->mmio_base + 
0x230)
+#define RING_EXECLIST_STATUS_LO(engine)
_MMIO((engine)->mmio_base + 0x234)
+#define RING_EXECLIST_STATUS_HI(engine)
_MMIO((engine)->mmio_base + 0x234 + 4)
+#define RING_CONTEXT_CONTROL(engine)   _MMIO((engine)->mmio_base + 
0x244)
 #define  CTX_CTRL_INHIBIT_SYN_CTX_SWITCH   (1 << 3)
 #define  CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT   (1 << 0)
 #define   CTX_CTRL_RS_CTX_ENABLE(1 << 1)
-#define RING_CONTEXT_STATUS_BUF_BASE(ring) _MMIO((ring)->mmio_base + 0x370)
-#define RING_CONTEXT_STATUS_BUF_LO(ring, i)_MMIO((ring)->mmio_base + 0x370 
+ (i) * 8)
-#define RING_CONTEXT_STATUS_BUF_HI(ring, i)_MMIO((ring)->mmio_base + 0x370 
+ (i) * 8 + 4)
-#define RING_CONTEXT_STATUS_PTR(ring)  _MMIO((ring)->mmio_base + 0x3a0)
+#define RING_CONTEXT_STATUS_BUF_BASE(engine)   _MMIO((engine)->mmio_base + 
0x370)
+#define RING_CONTEXT_STATUS_BUF_LO(engine, i)  _MMIO((engine)->mmio_base + 
0x370 + (i) * 8)
+#define RING_CONTEXT_STATUS_BUF_HI(engine, i)  _MMIO((engine)->mmio_base + 
0x370 + (i) * 8 + 4)
+#define RING_CONTEXT_STATUS_PTR(engine)
_MMIO((engine)->mmio_base + 0x3a0)
 
 /* The docs specify that the write pointer wraps around after 5h, "After status
  * is written out to the last available status QW at offset 5h, this pointer
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 05bab8b..4671fb8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -31,23 +31,23 @@ struct  intel_hw_status_page {
struct  

[Intel-gfx] [PATCH 3/3] drm/i915: rename & update eb_select_ring()

[Dave Gordon]

'ring' is an old deprecated term for a GPU engine, so we're trying to
phase out all such terminology. eb_select_ring() not only has 'ring'
(meaning engine) in its name, but it has an ugly calling convention
whereby it returns an errno and stores a pointer-to-engine indirectly
through an output parameter. As there is only one error it ever returns
(-EINVAL), we can make it return the pointer directly, and have the
caller pass back the error code -EINVAL if the pointer result is NULL.

Thus we can replace
-   ret = eb_select_ring(dev_priv, file, args, );
-   if (ret)
-   return ret;
with
+   engine = eb_select_engine(dev_priv, file, args);
+   if (!engine)
+   return -EINVAL;
for increased clarity and maybe save a few cycles too.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 32 +++---
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6482ec2..f8d8ae3 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1380,24 +1380,24 @@ static bool only_mappable_for_reloc(unsigned int flags)
[I915_EXEC_VEBOX]   = VECS
 };
 
-static int
-eb_select_ring(struct drm_i915_private *dev_priv,
-  struct drm_file *file,
-  struct drm_i915_gem_execbuffer2 *args,
-  struct intel_engine_cs **ring)
+static struct intel_engine_cs *
+eb_select_engine(struct drm_i915_private *dev_priv,
+struct drm_file *file,
+struct drm_i915_gem_execbuffer2 *args)
 {
unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
+   struct intel_engine_cs *engine;
 
if (user_ring_id > I915_USER_RINGS) {
DRM_DEBUG("execbuf with unknown ring: %u\n", user_ring_id);
-   return -EINVAL;
+   return NULL;
}
 
if ((user_ring_id != I915_EXEC_BSD) &&
((args->flags & I915_EXEC_BSD_MASK) != 0)) {
DRM_DEBUG("execbuf with non bsd ring but with invalid "
  "bsd dispatch flags: %d\n", (int)(args->flags));
-   return -EINVAL;
+   return NULL;
}
 
if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
@@ -1412,20 +1412,20 @@ static bool only_mappable_for_reloc(unsigned int flags)
} else {
DRM_DEBUG("execbuf with unknown bsd ring: %u\n",
  bsd_idx);
-   return -EINVAL;
+   return NULL;
}
 
-   *ring = _priv->engine[_VCS(bsd_idx)];
+   engine = _priv->engine[_VCS(bsd_idx)];
} else {
-   *ring = _priv->engine[user_ring_map[user_ring_id]];
+   engine = _priv->engine[user_ring_map[user_ring_id]];
}
 
-   if (!intel_engine_initialized(*ring)) {
+   if (!intel_engine_initialized(engine)) {
DRM_DEBUG("execbuf with invalid ring: %u\n", user_ring_id);
-   return -EINVAL;
+   return NULL;
}
 
-   return 0;
+   return engine;
 }
 
 static int
@@ -1467,9 +1467,9 @@ static bool only_mappable_for_reloc(unsigned int flags)
if (args->flags & I915_EXEC_IS_PINNED)
dispatch_flags |= I915_DISPATCH_PINNED;
 
-   ret = eb_select_ring(dev_priv, file, args, );
-   if (ret)
-   return ret;
+   engine = eb_select_engine(dev_priv, file, args);
+   if (!engine)
+   return -EINVAL;
 
if (args->buffer_count < 1) {
DRM_DEBUG("execbuf with %d buffers\n", args->buffer_count);
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 12/13] drm/i915: Consolidate legacy semaphore initialization

[Dave Gordon]

On 20/07/16 17:07, Tvrtko Ursulin wrote:


On 20/07/16 13:50, Dave Gordon wrote:

On 20/07/16 10:54, Tvrtko Ursulin wrote:


On 19/07/16 19:38, Dave Gordon wrote:

On 15/07/16 14:13, Tvrtko Ursulin wrote:


On 29/06/16 17:00, Chris Wilson wrote:

On Wed, Jun 29, 2016 at 04:41:58PM +0100, Tvrtko Ursulin wrote:


On 29/06/16 16:34, Chris Wilson wrote:

On Wed, Jun 29, 2016 at 04:09:31PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Replace per-engine initialization with a common half-programatic,
half-data driven code for ease of maintenance and compactness.

Signed-off-by: Tvrtko Ursulin 


This is the biggest pill to swallow (since our 5x5 table is only
sparsely populated), but it looks correct, and more importantly
easier to
read.


Yeah I was out of ideas on how to improve it. Fresh mind needed to
try and spot a pattern in how MI_SEMAPHORE_SYNC_* and GEN6_*SYNC map
to bits and registers respectively, and write it as a function.


It's actually a very simple cyclic function based on register
offset = base + (signaler hw_id - waiter hw_id - 1) % num_rings.

(The only real challenge is picking the direction.)

commit c8c99b0f0dea1ced5d0e10cdb9143356cc16b484
Author: Ben Widawsky 
Date:   Wed Sep 14 20:32:47 2011 -0700

 drm/i915: Dumb down the semaphore logic

 While I think the previous code is correct, it was hard to
follow
and
 hard to debug. Since we already have a ring abstraction,
might as
well
 use it to handle the semaphore updates and compares.


Doesn't seem to fit, or I just can't figure it out. Needs two
functions
to get rid of the table:

f1(0, 1) = 2
f1(0, 2) = 0
f1(0, 3) = 2
f1(1, 0) = 0
f1(1, 2) = 2
f1(1, 3) = 1
f1(2, 0) = 2
f1(2, 1) = 0
f1(2, 3) = 0
f1(3, 0) = 1
f1(3, 1) = 1
f1(3, 2) = 1

and:

f2(0, 1) = 1
f2(0, 2) = 0
f2(0, 3) = 1
f2(1, 0) = 0
f2(1, 2) = 1
f2(1, 3) = 2
f2(2, 0) = 1
f2(2, 1) = 0
f2(2, 3) = 0
f2(3, 0) = 2
f2(3, 1) = 2
f2(3, 2) = 2

A weekend math puzzle for someone? :)

Regards,
Tvrtko


Here's the APL expression for (the transpose of) f2, with -1's
filled in
along the leading diagonal (you need ⎕io←0 so the ⍳-vectors are in
origin 0)

   {¯1+(⍵≠⍳4)⍀(2|⍵)⌽(⌽⍣(1=⍵))1+⍳3}¨⍳4

┌┬┬┬┐
│¯1 0 1 2│1 ¯1 0 2│0 1 ¯1 2│1 2 0 ¯1│
└┴┴┴┘

or transposed back so that the first argument is the row index and the
second is the column index:

   ⍉↑{¯1+(⍵≠⍳4)⍀(2|⍵)⌽(⌽⍣(1=⍵))1+⍳3}¨⍳4

 ¯1  1  0  1
  0 ¯1  1  2
  1  0 ¯1  0
  2  2  2 ¯1

http://tryapl.org/?a=%u2349%u2191%7B%AF1+%28%u2375%u2260%u23734%29%u2340%282%7C%u2375%29%u233D%28%u233D%u2363%281%3D%u2375%29%291+%u23733%7D%A8%u23734





  :-C ! How to convert that to C ? :)


f1 is trivially derived from this by the observation that f1 is just f2
with the 1's and 2's interchanged.


Ah yes, nicely spotted.

Regards,
Tvrtko


Assuming you don't care about the leading diagonal (x == y), then

  (⍵≠⍳4)⍀(2|⍵)⌽(⌽⍣(1=⍵))

translates into:

int f2(unsigned int x, unsigned int y)
{
 x -= x >= y;
 if (y == 1)
 x = 3 - x;
 x += y & 1;
 return x % 3;
}

y:x 0 1 2 3
0:  0 0 1 2
1:  1 1 0 2
2:  0 1 1 2
3:  1 2 0 0

Each line of C corresponds quite closely to one operation in the APL :)
Although, in APL we tend to leave the data unchanged while shuffling it
around into new shapes, whereas the C below does the equivalent things
by changing the data (noting that it's all modulo-3 arithmetic).

  (⍵≠⍳4)⍀  inserts the leading diagonal, corresponding to the subtraction
   of x >= y (which removes the leading diagonal).

  ⌽⍣(1=⍵)  reverses the sequence if y==1; in C, that's the 3-x

  (2|⍵)⌽   rotates the sequence by 1 if y is odd; that's the +=

and the final % ensures that the result is 0-2.


I was hoping for a solution which does not include conditionals, someone
led me to believe it is possible! :)

But thanks, your transformation really works. I've sent a patch
implementing it to trybot for now.

Regards,
Tvrtko


You can write it like this if you don't want any visible conditionals :)

unsigned int f2(unsigned int x, unsigned int y)
{
x -= x >= y;
x += y & 1;
x ^= y & x >> y;  /* WTF? */
return x % 3;
}

But I think that's even more obscure.

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

Re: [Intel-gfx] [PATCH v3 0/4] Enable lspcon support for GEN9 devices

[Ville Syrjälä]

On Wed, Jul 20, 2016 at 04:16:30PM +, Sharma, Shashank wrote:
> Hi Ville.
> 
> > This thing seems to be missing a lot of stuff:
> > - where is the EDID etc. handling?
> None required for LSPCON as of now.
> The 4k@60 pixel clock support was already added with SKL, so we can see
> a HDMI 4k@60 output already on PCON mode, when connected to a 4k@60 monitor.
> 
> I have started publishing a separate patch series to support HDMI 2.0, 
> started with the new aspect ratio patches here. I was hoping to proceed with 
> EDID changes, once we get these in, else the patch series gets huge and 
> reviewers find it difficult to review. 
> https://patchwork.freedesktop.org/patch/78308/ 
>  
> Plan is to publish in this sequence:
> - Add new aspect ratios
> - Add new 4k modes in DRM EDID
> - Add Scrambling support
> - Add SCDC parsing
> - Add YUV 420 CEA-861-F block parsing
> and so on. 
> 
> > - based on my DDI output_types stuff, I was expecting to see an
> >  lspcon .compute_output_type() hook that returns whether we need
>  >  LS or PCON mode. Can't see anything of the sort here.
> As I explained in the commit message/cover letter LSPCON is no more working 
> selectively on LS/PCON mode.

Oh. Do we have some idea of the power cost?

Curiously when I tried to measure the idle power consumption on my BSW,
DP seemed to be a bit less hungry than HDMI. But I guess the PCON
stuff itself will use some amount of power which might offset any
benefit from using DP on the SoC side.


> We are driving it in always PCON mode, and driver always drives a DP.  So we 
> are driving a DP with separate detection sequence. 
> 
> > Also the main patch [1] of my DDI output_types series still didn't get 
> > reviewed...
> Ok, but that should not be a blocker for this series, should it ? 

The encoder->type swithing is still a problem. Though I suppose it will
be fairly well masked if you always have DPCD avaailable.

> 
> Regards
> Shashank
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
> Sent: Wednesday, July 20, 2016 6:39 PM
> To: Sharma, Shashank 
> Cc: intel-gfx@lists.freedesktop.org; rodrigo.v...@gmail.com; Vivi, Rodrigo 
> ; Zanoni, Paulo R 
> Subject: Re: [PATCH v3 0/4] Enable lspcon support for GEN9 devices
> 
> On Tue, Jul 05, 2016 at 06:35:46PM +0530, Shashank Sharma wrote:
> > LSPCON is essentially a dp++->hdmi adapter with dual mode of operation.
> > 
> > These modes are:
> > - Level Shifter mode: In LS mode, this device works as a type2 
> > dp->hdmi passive dongle, which steps up DP++ output to appropriate HDMI 1.4 
> > signal.
> > This mode doesn't do any conversion at the protocol level.
> > 
> > - Protocol Converter mode: In PCON mode, this device acts as an active 
> > DP++->HDMI 2.0 dongle, which converts the DP++ output to compatible 
> > HDMI 2.0 output. In PCON mode, lspcon can support 4k@60 outputs, using 
> > DP HBR2 mode.
> > 
> > Many of Intel GEN9 devices come with in-built lspcon card in 
> > motherboartd down mode. This patch series adds support for lspcon 
> > devices in I915 driver.
> > 
> > While unit-testing this code, I was able to see a 4k@60 modeset with:
> > - BXT-T board
> > - Single HDMI 4k@60 display (ACER S)
> > - Ubuntu 14.04 desktop
> > 
> > V2: Worked on review comments from Ville
> > - In general, Ville suggested not to use the dual personality of
> >   DDI to drive lspcon, so this patch set drives it just as DP++ display.
> >   There is no separate detection for lspcon (hpd_pulse is good enough), and
> >   its being driven as a DP display with special initialization and EDID
> >   read sequence. To be able to do this, we driving lspcon in PCON mode only,
> >   where it can serve both HDMI1.3/HDMI1.4 sinks as well as 4k@60 capable
> >   HDMI 2.0 sinks. So compared to previous series, there is one patch less,
> >   as we have dropped lspcon detection patch.
> > 
> > 
> > V3: Addressed review comments from Rodrigo
> > Details available in respective patch.
> > 
> > Shashank Sharma (4):
> >   drm: Helper for lspcon in drm_dp_dual_mode
> >   drm/i915: Add lspcon support for I915 driver
> >   drm/i915: Parse VBT data for lspcon
> >   drm/i915: Enable lspcon initialization
> 
> This thing seems to be missing a lot of stuff:
> - where is the EDID etc. handling?
> None required for LSPCON as of now. The 4k@60 pixel clock support was already 
> added with SKL
> - based on my DDI output_types stuff, I was expecting to see an
>   lspcon .compute_output_type() hook that returns whether we need
>   LS or PCON mode. Can't see anything of the sort here.
> 
> Also the main patch [1] of my DDI output_types series still didn't get 
> reviewed...
> 
> [1] https://patchwork.freedesktop.org/patch/94581/
> 
> > 
> >  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 103 +
> >  drivers/gpu/drm/i915/Makefile |   1 +
> >  drivers/gpu/drm/i915/i915_drv.h   |   

Re: [Intel-gfx] [PATCH v3 0/4] Enable lspcon support for GEN9 devices

[Sharma, Shashank]

Hi Ville.

> This thing seems to be missing a lot of stuff:
> - where is the EDID etc. handling?
None required for LSPCON as of now. The 4k@60 pixel clock support was already 
added with SKL, so we can see
a HDMI 4k@60 output already on PCON mode, when connected to a 4k@60 monitor.

I have started publishing a separate patch series to support HDMI 2.0, started 
with the new aspect ratio patches here. I was hoping to proceed with EDID 
changes, once we get these in, else the patch series gets huge and reviewers 
find it difficult to review. 
https://patchwork.freedesktop.org/patch/78308/ 
 
Plan is to publish in this sequence:
- Add new aspect ratios
- Add new 4k modes in DRM EDID
- Add Scrambling support
- Add SCDC parsing
- Add YUV 420 CEA-861-F block parsing
and so on. 

> - based on my DDI output_types stuff, I was expecting to see an
>  lspcon .compute_output_type() hook that returns whether we need
 >  LS or PCON mode. Can't see anything of the sort here.
As I explained in the commit message/cover letter LSPCON is no more working 
selectively on LS/PCON mode.
We are driving it in always PCON mode, and driver always drives a DP.  So we 
are driving a DP with separate detection sequence. 

> Also the main patch [1] of my DDI output_types series still didn't get 
> reviewed...
Ok, but that should not be a blocker for this series, should it ? 

Regards
Shashank
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
Sent: Wednesday, July 20, 2016 6:39 PM
To: Sharma, Shashank 
Cc: intel-gfx@lists.freedesktop.org; rodrigo.v...@gmail.com; Vivi, Rodrigo 
; Zanoni, Paulo R 
Subject: Re: [PATCH v3 0/4] Enable lspcon support for GEN9 devices

On Tue, Jul 05, 2016 at 06:35:46PM +0530, Shashank Sharma wrote:
> LSPCON is essentially a dp++->hdmi adapter with dual mode of operation.
> 
> These modes are:
> - Level Shifter mode: In LS mode, this device works as a type2 
> dp->hdmi passive dongle, which steps up DP++ output to appropriate HDMI 1.4 
> signal.
> This mode doesn't do any conversion at the protocol level.
> 
> - Protocol Converter mode: In PCON mode, this device acts as an active 
> DP++->HDMI 2.0 dongle, which converts the DP++ output to compatible 
> HDMI 2.0 output. In PCON mode, lspcon can support 4k@60 outputs, using 
> DP HBR2 mode.
> 
> Many of Intel GEN9 devices come with in-built lspcon card in 
> motherboartd down mode. This patch series adds support for lspcon 
> devices in I915 driver.
> 
> While unit-testing this code, I was able to see a 4k@60 modeset with:
> - BXT-T board
> - Single HDMI 4k@60 display (ACER S)
> - Ubuntu 14.04 desktop
> 
> V2: Worked on review comments from Ville
> - In general, Ville suggested not to use the dual personality of
>   DDI to drive lspcon, so this patch set drives it just as DP++ display.
>   There is no separate detection for lspcon (hpd_pulse is good enough), and
>   its being driven as a DP display with special initialization and EDID
>   read sequence. To be able to do this, we driving lspcon in PCON mode only,
>   where it can serve both HDMI1.3/HDMI1.4 sinks as well as 4k@60 capable
>   HDMI 2.0 sinks. So compared to previous series, there is one patch less,
>   as we have dropped lspcon detection patch.
> 
> 
> V3: Addressed review comments from Rodrigo
> Details available in respective patch.
> 
> Shashank Sharma (4):
>   drm: Helper for lspcon in drm_dp_dual_mode
>   drm/i915: Add lspcon support for I915 driver
>   drm/i915: Parse VBT data for lspcon
>   drm/i915: Enable lspcon initialization

This thing seems to be missing a lot of stuff:
- where is the EDID etc. handling?
None required for LSPCON as of now. The 4k@60 pixel clock support was already 
added with SKL
- based on my DDI output_types stuff, I was expecting to see an
  lspcon .compute_output_type() hook that returns whether we need
  LS or PCON mode. Can't see anything of the sort here.

Also the main patch [1] of my DDI output_types series still didn't get 
reviewed...

[1] https://patchwork.freedesktop.org/patch/94581/

> 
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 103 +
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/i915_drv.h   |   5 ++
>  drivers/gpu/drm/i915/intel_bios.c |  49 ++
>  drivers/gpu/drm/i915/intel_ddi.c  |  29 +-
>  drivers/gpu/drm/i915/intel_drv.h  |  13 ++-
>  drivers/gpu/drm/i915/intel_lspcon.c   | 145 
> ++
>  include/drm/drm_dp_dual_mode_helper.h |  26 ++
>  8 files changed, 369 insertions(+), 2 deletions(-)  create mode 
> 100644 drivers/gpu/drm/i915/intel_lspcon.c
> 
> --
> 1.9.1

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/9] drm/i915: Rename request reference/unreference to get/put

[Chris Wilson]

On Wed, Jul 20, 2016 at 05:03:10PM +0100, Tvrtko Ursulin wrote:
> 
> On 20/07/16 16:51, Dave Gordon wrote:
> >On 20/07/16 14:02, Patchwork wrote:
> >>== Series Details ==
> >>
> >>Series: series starting with [CI,1/9] drm/i915: Rename request
> >>reference/unreference to get/put
> >>URL   : https://patchwork.freedesktop.org/series/10089/
> >>State : failure
> >>
> >>== Summary ==
> >>
> >>Series 10089v1 Series without cover letter
> >>http://patchwork.freedesktop.org/api/1.0/series/10089/revisions/1/mbox
> >>
> >>Test gem_sync:
> >> Subgroup basic-store-each:
> >> pass   -> FAIL   (ro-bdw-i7-5600u)
> >
> >That's
> >Bug 96974 - [BAT BDW] gem_sync / basic-store-each fails sporadically
> >
> >It claims that some interrupts were missed during the test but it
> >doesn't happen on any other BDW (or any other machine at all).
> >Perhaps we need another one "exactly the same" to see whether it's at
> >all reproducible anywhere but that one system?
> 
> Looks like Chris has already merged this series, just forgot to do
> the commiter's reply. :)

This here is potentially a race in idle_worker vs the interrupt, the
other variant of the fail on this machine looks like a race in hangcheck
vs enabling the interrupt. Or at least those are two races I can see
that match the different fails. On the other hand, the detection may be
genuine from the two different paths that do the check.
-Chris

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

Re: [Intel-gfx] [PATCH v4 2/5] drm: Add private data field to trace control block

[Patrik Jakobsson]

On Jul 20, 2016 4:50 PM, "Dmitry V. Levin"  wrote:
>
> On Mon, Sep 07, 2015 at 08:23:57PM +0200, Patrik Jakobsson wrote:
> > On Mon, Sep 7, 2015 at 6:51 PM, Dmitry V. Levin wrote:
> > > On Mon, Aug 31, 2015 at 02:37:07PM +0200, Patrik Jakobsson wrote:
> > > [...]
> > >> Here's my take on it (I assume it needs some discussion):
> > >>
> > >> int
> > >> set_tcb_priv_data(struct tcb *tcp, void *priv_data)
> > >> {
> > >>   /* A free callback is required before setting private data and
private
> > >>* data must be set back to NULL before being set again.
> > >>*/
> > >
> > > I think a single function initializing both _priv_data and
_free_priv_data
> > > would suffice:
> > >
> > > int
> > > set_tcb_priv_data(struct tcb *tcp, void *priv_data,
> > >   void (*free_priv_data)(void *))
> > > {
> > > if (tcp->_priv_data)
> > > return -1;
> > >
> > > tcp->_free_priv_data = free_priv_data;
> > > tcp->_priv_data = priv_data;
> > >
> > > return 0;
> > > }
> >
> > Sure, and since they always come in a pairs it might be even better. If
it turns
> > out we need it split up it is easily done later.
>
> JFYI, I've finalized and merged this set_tcb_priv_data interface.

Thanks Dmitry

-Patrik

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

Re: [Intel-gfx] [PATCH 12/13] drm/i915: Consolidate legacy semaphore initialization

[Tvrtko Ursulin]

On 20/07/16 13:50, Dave Gordon wrote:

On 20/07/16 10:54, Tvrtko Ursulin wrote:


On 19/07/16 19:38, Dave Gordon wrote:

On 15/07/16 14:13, Tvrtko Ursulin wrote:


On 29/06/16 17:00, Chris Wilson wrote:

On Wed, Jun 29, 2016 at 04:41:58PM +0100, Tvrtko Ursulin wrote:


On 29/06/16 16:34, Chris Wilson wrote:

On Wed, Jun 29, 2016 at 04:09:31PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Replace per-engine initialization with a common half-programatic,
half-data driven code for ease of maintenance and compactness.

Signed-off-by: Tvrtko Ursulin 


This is the biggest pill to swallow (since our 5x5 table is only
sparsely populated), but it looks correct, and more importantly
easier to
read.


Yeah I was out of ideas on how to improve it. Fresh mind needed to
try and spot a pattern in how MI_SEMAPHORE_SYNC_* and GEN6_*SYNC map
to bits and registers respectively, and write it as a function.


It's actually a very simple cyclic function based on register
offset = base + (signaler hw_id - waiter hw_id - 1) % num_rings.

(The only real challenge is picking the direction.)

commit c8c99b0f0dea1ced5d0e10cdb9143356cc16b484
Author: Ben Widawsky 
Date:   Wed Sep 14 20:32:47 2011 -0700

 drm/i915: Dumb down the semaphore logic

 While I think the previous code is correct, it was hard to follow
and
 hard to debug. Since we already have a ring abstraction, might as
well
 use it to handle the semaphore updates and compares.


Doesn't seem to fit, or I just can't figure it out. Needs two functions
to get rid of the table:

f1(0, 1) = 2
f1(0, 2) = 0
f1(0, 3) = 2
f1(1, 0) = 0
f1(1, 2) = 2
f1(1, 3) = 1
f1(2, 0) = 2
f1(2, 1) = 0
f1(2, 3) = 0
f1(3, 0) = 1
f1(3, 1) = 1
f1(3, 2) = 1

and:

f2(0, 1) = 1
f2(0, 2) = 0
f2(0, 3) = 1
f2(1, 0) = 0
f2(1, 2) = 1
f2(1, 3) = 2
f2(2, 0) = 1
f2(2, 1) = 0
f2(2, 3) = 0
f2(3, 0) = 2
f2(3, 1) = 2
f2(3, 2) = 2

A weekend math puzzle for someone? :)

Regards,
Tvrtko


Here's the APL expression for (the transpose of) f2, with -1's filled in
along the leading diagonal (you need ⎕io←0 so the ⍳-vectors are in
origin 0)

   {¯1+(⍵≠⍳4)⍀(2|⍵)⌽(⌽⍣(1=⍵))1+⍳3}¨⍳4

┌┬┬┬┐
│¯1 0 1 2│1 ¯1 0 2│0 1 ¯1 2│1 2 0 ¯1│
└┴┴┴┘

or transposed back so that the first argument is the row index and the
second is the column index:

   ⍉↑{¯1+(⍵≠⍳4)⍀(2|⍵)⌽(⌽⍣(1=⍵))1+⍳3}¨⍳4

 ¯1  1  0  1
  0 ¯1  1  2
  1  0 ¯1  0
  2  2  2 ¯1

http://tryapl.org/?a=%u2349%u2191%7B%AF1+%28%u2375%u2260%u23734%29%u2340%282%7C%u2375%29%u233D%28%u233D%u2363%281%3D%u2375%29%291+%u23733%7D%A8%u23734




  :-C ! How to convert that to C ? :)


f1 is trivially derived from this by the observation that f1 is just f2
with the 1's and 2's interchanged.


Ah yes, nicely spotted.

Regards,
Tvrtko


Assuming you don't care about the leading diagonal (x == y), then

  (⍵≠⍳4)⍀(2|⍵)⌽(⌽⍣(1=⍵))

translates into:

int f2(unsigned int x, unsigned int y)
{
 x -= x >= y;
 if (y == 1)
 x = 3 - x;
 x += y & 1;
 return x % 3;
}

y:x 0 1 2 3
0:  0 0 1 2
1:  1 1 0 2
2:  0 1 1 2
3:  1 2 0 0

Each line of C corresponds quite closely to one operation in the APL :)
Although, in APL we tend to leave the data unchanged while shuffling it
around into new shapes, whereas the C below does the equivalent things
by changing the data (noting that it's all modulo-3 arithmetic).

  (⍵≠⍳4)⍀  inserts the leading diagonal, corresponding to the subtraction
   of x >= y (which removes the leading diagonal).

  ⌽⍣(1=⍵)  reverses the sequence if y==1; in C, that's the 3-x

  (2|⍵)⌽   rotates the sequence by 1 if y is odd; that's the +=

and the final % ensures that the result is 0-2.


I was hoping for a solution which does not include conditionals, someone 
led me to believe it is possible! :)


But thanks, your transformation really works. I've sent a patch 
implementing it to trybot for now.


Regards,

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/9] drm/i915: Rename request reference/unreference to get/put

[Tvrtko Ursulin]

On 20/07/16 16:51, Dave Gordon wrote:

On 20/07/16 14:02, Patchwork wrote:

== Series Details ==

Series: series starting with [CI,1/9] drm/i915: Rename request
reference/unreference to get/put
URL   : https://patchwork.freedesktop.org/series/10089/
State : failure

== Summary ==

Series 10089v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/10089/revisions/1/mbox

Test gem_sync:
 Subgroup basic-store-each:
 pass   -> FAIL   (ro-bdw-i7-5600u)


That's
Bug 96974 - [BAT BDW] gem_sync / basic-store-each fails sporadically

It claims that some interrupts were missed during the test but it
doesn't happen on any other BDW (or any other machine at all).
Perhaps we need another one "exactly the same" to see whether it's at
all reproducible anywhere but that one system?


Looks like Chris has already merged this series, just forgot to do the 
commiter's reply. :)


Regards,

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/9] drm/i915: Rename request reference/unreference to get/put

[Dave Gordon]

On 20/07/16 14:02, Patchwork wrote:

== Series Details ==

Series: series starting with [CI,1/9] drm/i915: Rename request 
reference/unreference to get/put
URL   : https://patchwork.freedesktop.org/series/10089/
State : failure

== Summary ==

Series 10089v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/10089/revisions/1/mbox

Test gem_sync:
 Subgroup basic-store-each:
 pass   -> FAIL   (ro-bdw-i7-5600u)


That's
Bug 96974 - [BAT BDW] gem_sync / basic-store-each fails sporadically

It claims that some interrupts were missed during the test but it 
doesn't happen on any other BDW (or any other machine at all).
Perhaps we need another one "exactly the same" to see whether it's at 
all reproducible anywhere but that one system?


.Dave.


fi-hsw-i7-4770k  total:244  pass:216  dwarn:0   dfail:0   fail:8   skip:20
fi-kbl-qkkr  total:244  pass:180  dwarn:28  dfail:1   fail:8   skip:27
fi-skl-i5-6260u  total:244  pass:224  dwarn:0   dfail:0   fail:8   skip:12
fi-skl-i7-6700k  total:244  pass:210  dwarn:0   dfail:0   fail:8   skip:26
fi-snb-i7-2600   total:244  pass:196  dwarn:0   dfail:0   fail:8   skip:40
ro-bdw-i5-5250u  total:244  pass:219  dwarn:4   dfail:0   fail:8   skip:13
ro-bdw-i7-5600u  total:244  pass:203  dwarn:0   dfail:0   fail:9   skip:32
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42
ro-byt-n2820 total:244  pass:197  dwarn:0   dfail:0   fail:9   skip:38
ro-hsw-i3-4010u  total:244  pass:212  dwarn:0   dfail:0   fail:8   skip:24
ro-hsw-i7-4770r  total:244  pass:212  dwarn:0   dfail:0   fail:8   skip:24
ro-ilk-i7-620lm  total:244  pass:172  dwarn:0   dfail:0   fail:9   skip:63
ro-ilk1-i5-650   total:239  pass:172  dwarn:0   dfail:0   fail:9   skip:58
ro-ivb-i7-3770   total:244  pass:203  dwarn:0   dfail:0   fail:8   skip:33
ro-skl3-i5-6260u total:244  pass:224  dwarn:0   dfail:0   fail:8   skip:12
ro-snb-i7-2620M  total:244  pass:193  dwarn:0   dfail:0   fail:9   skip:42
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1543/

cafe8a2 drm-intel-nightly: 2016y-07m-20d-08h-45m-03s UTC integration manifest
1f14a4a drm/i915: Convert i915_semaphores_is_enabled over to early sanitize
b2c39d7 drm/i915: Rename ring->virtual_start as ring->vaddr
170ddd1 drm/i915: Treat ringbuffer writes as write to normal memory
5118b49 drm/i915: Rename drm_gem_object_unreference_unlocked in preparation for 
lockless free
9e842dc drm/i915: Rename drm_gem_object_unreference in preparation for lockless 
free
cc3c3c5 drm/i915: Wrap drm_gem_object_reference in i915_gem_object_get
dd5b89e drm/i915: Wrap drm_gem_object_lookup in i915_gem_object_lookup
9794f2d drm/i915: Rename i915_gem_context_reference/unreference()
e08379e drm/i915: Rename request reference/unreference to get/put

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



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

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/18] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [01/18] drm/i915: Unify intel_logical_ring_emit 
and intel_ring_emit (rev2)
URL   : https://patchwork.freedesktop.org/series/10090/
State : failure

== Summary ==

Applying: drm/i915: Unify intel_logical_ring_emit and intel_ring_emit
Applying: drm/i915: Convert stray struct intel_engine_cs *ring
Applying: drm/i915: Rename backpointer from intel_ringbuffer to intel_engine_cs
Applying: drm/i915: Rename intel_context[engine].ringbuf
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_drv.h
M   drivers/gpu/drm/i915/i915_gem_context.c
M   drivers/gpu/drm/i915/intel_lrc.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_lrc.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c
Auto-merging drivers/gpu/drm/i915/i915_gem_context.c
Auto-merging drivers/gpu/drm/i915/i915_drv.h
error: Failed to merge in the changes.
Patch failed at 0004 drm/i915: Rename intel_context[engine].ringbuf
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] [PATCH] drm/i915: Convert stray struct intel_engine_cs *ring

[Chris Wilson]

We still have a few uses of the identifier "ring" used when referring to
the struct intel_engine_cs (a remanent from when there was only one dual
purpose engine/ringbuffer). Rename all of this to use the familiar
engine so that the separation between the hardware engine and the
ringbuffer containing the commands is clear.

This patch was formed by searching for instances of '\' and
changing those found to be referring to an engine. There are quite a few
instances in comments remaining where it is less clear what is
appropriate for the context, the registers still refer to ring (there we
need to check against bspec for any counter-recommendations, but quite a
few registers, like PDP should be engine based, whereas RING_HEAD
probably wants to remain as ring based) and the biggest compromise was
in error capture where we already have a local engine variable and so
finding a good name was trickier.

Signed-off-by: Chris Wilson 
Cc: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c |   4 +-
 drivers/gpu/drm/i915/i915_drv.h|  15 +-
 drivers/gpu/drm/i915/i915_gem.c|  26 +--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  23 +--
 drivers/gpu/drm/i915/i915_gpu_error.c  | 255 +++--
 drivers/gpu/drm/i915/i915_irq.c|   6 +-
 drivers/gpu/drm/i915/intel_mocs.h  |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c|   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h|  24 +--
 9 files changed, 183 insertions(+), 174 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index b0fd6a7b0603..b5b520176c59 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -636,7 +636,7 @@ static bool validate_cmds_sorted(struct intel_engine_cs 
*engine,
return ret;
 }
 
-static bool check_sorted(int ring_id,
+static bool check_sorted(int engine_id,
 const struct drm_i915_reg_descriptor *reg_table,
 int reg_count)
 {
@@ -649,7 +649,7 @@ static bool check_sorted(int ring_id,
 
if (curr < previous) {
DRM_ERROR("CMD: table not sorted ring=%d entry=%d 
reg=0x%08X prev=0x%08X\n",
- ring_id, i, curr, previous);
+ engine_id, i, curr, previous);
ret = false;
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0f408ada1c65..808333a1d42d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -402,7 +402,7 @@ struct drm_i915_file_private {
unsigned boosts;
} rps;
 
-   unsigned int bsd_ring;
+   unsigned int bsd_engine;
 };
 
 /* Used by dp and fdi links */
@@ -512,7 +512,7 @@ struct drm_i915_error_state {
struct intel_display_error_state *display;
struct drm_i915_error_object *semaphore_obj;
 
-   struct drm_i915_error_ring {
+   struct drm_i915_error_engine {
bool valid;
/* Software tracked state */
bool waiting;
@@ -578,7 +578,7 @@ struct drm_i915_error_state {
 
pid_t pid;
char comm[TASK_COMM_LEN];
-   } ring[I915_NUM_ENGINES];
+   } engine[I915_NUM_ENGINES];
 
struct drm_i915_error_buffer {
u32 size;
@@ -593,7 +593,7 @@ struct drm_i915_error_state {
u32 dirty:1;
u32 purgeable:1;
u32 userptr:1;
-   s32 ring:4;
+   s32 engine:4;
u32 cache_level:3;
} **active_bo, **pinned_bo;
 
@@ -1331,7 +1331,7 @@ struct i915_gem_mm {
bool interruptible;
 
/* the indicator for dispatch video commands on two BSD rings */
-   unsigned int bsd_ring_dispatch_index;
+   unsigned int bsd_engine_dispatch_index;
 
/** Bit 6 swizzling required for X tiling */
uint32_t bit_6_swizzle_x;
@@ -2500,8 +2500,9 @@ struct drm_i915_cmd_descriptor {
 /*
  * A table of commands requiring special handling by the command parser.
  *
- * Each ring has an array of tables. Each table consists of an array of command
- * descriptors, which must be sorted with command opcodes in ascending order.
+ * Each engine has an array of tables. Each table consists of an array of
+ * command descriptors, which must be sorted with command opcodes in
+ * ascending order.
  */
 struct drm_i915_cmd_table {
const struct drm_i915_cmd_descriptor *table;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 40047eb48826..d004664c0847 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -46,7 +46,7 @@ static void i915_gem_object_flush_cpu_write_domain(struct 
drm_i915_gem_object *o
 static void
 i915_gem_object_retire__write(struct 

Re: [Intel-gfx] [PATCH v4 2/5] drm: Add private data field to trace control block

[Dmitry V. Levin]

On Mon, Sep 07, 2015 at 08:23:57PM +0200, Patrik Jakobsson wrote:
> On Mon, Sep 7, 2015 at 6:51 PM, Dmitry V. Levin wrote:
> > On Mon, Aug 31, 2015 at 02:37:07PM +0200, Patrik Jakobsson wrote:
> > [...]
> >> Here's my take on it (I assume it needs some discussion):
> >>
> >> int
> >> set_tcb_priv_data(struct tcb *tcp, void *priv_data)
> >> {
> >>   /* A free callback is required before setting private data and 
> >> private
> >>* data must be set back to NULL before being set again.
> >>*/
> >
> > I think a single function initializing both _priv_data and _free_priv_data
> > would suffice:
> >
> > int
> > set_tcb_priv_data(struct tcb *tcp, void *priv_data,
> >   void (*free_priv_data)(void *))
> > {
> > if (tcp->_priv_data)
> > return -1;
> >
> > tcp->_free_priv_data = free_priv_data;
> > tcp->_priv_data = priv_data;
> >
> > return 0;
> > }
> 
> Sure, and since they always come in a pairs it might be even better. If it 
> turns
> out we need it split up it is easily done later.

JFYI, I've finalized and merged this set_tcb_priv_data interface.


-- 
ldv


pgp4iyIZxJS8j.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/18] drm/i915: Rename request->ringbuf to request->ring

[Dave Gordon]

On 20/07/16 15:12, Dave Gordon wrote:

On 20/07/16 14:11, Chris Wilson wrote:

Now that we have disambuigated ring and engine, we can use the clearer
and more consistent name for the intel_ringbuffer pointer in the
request.

Signed-off-by: Chris Wilson 


You missed a few instances of 'ring' meaning engine:

i915_gem_execbuffer.c:   struct intel_engine_cs **ring)
intel_mocs.h:int intel_mocs_init_engine(struct intel_engine_cs *ring);
intel_ringbuffer.c:gen5_seqno_barrier(struct intel_engine_cs *ring)
intel_ringbuffer.h:void(*irq_enable)(struct intel_engine_cs
*ring);
intel_ringbuffer.h:void(*irq_disable)(struct intel_engine_cs
*ring);
intel_ringbuffer.h:int(*init_hw)(struct intel_engine_cs *ring);
intel_ringbuffer.h:void(*irq_seqno_barrier)(struct
intel_engine_cs *ring);
intel_ringbuffer.h:void(*cleanup)(struct intel_engine_cs
*ring);

I think we have to purge every last trace of this usage before using
'ring' as shorthand for 'ringbuf[fer]'.

.Dave.


Oh yes, also there are lots of other things called 'ring' which aren't 
ringbuffers, such as an engine:


#define RING_ELSP(ring) _MMIO((ring)->mmio_base + 0x230)

or an engine id:

static i915_reg_t mocs_register(enum intel_engine_id ring, int index)
i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring)
int ring = req->engine->id;

or a different structure entirely:

struct drm_i915_error_ring *ring = >ring[ring_idx];

I could probably write some Cocci to find-and-rename all the things 
called 'ring' that weren't ringbuffers, but it would be easier not to 
overload the identifier with a host of different meanings in the first 
place. So I think adding any more instances of things called 'ring' 
should wait until the name has no other meanings, if ringbuffers are the 
thing you want it to unambiguously identify.


.Dave.

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

Re: [Intel-gfx] [PATCH 03/18] drm/i915: Rename backpointer from intel_ringbuffer to intel_engine_cs

[Dave Gordon]

On 20/07/16 14:11, Chris Wilson wrote:

Having ringbuf->ring point to an engine is confusing, so rename it once
again to ring->engine.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/intel_ringbuffer.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)


Doesn't do what it says in the commit message (which sounded like a good 
idea). This patch actually just renames the function 
intel_init_ring_buffer() to intel_init_engine(). However /most/ of the 
code in that function is to do with initialising a ringbuffer!


.Dave.


diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ac51e4885046..3cfbfe40f6e8 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2171,7 +2171,7 @@ static void intel_ring_context_unpin(struct 
i915_gem_context *ctx,
i915_gem_context_put(ctx);
  }

-static int intel_init_ring_buffer(struct intel_engine_cs *engine)
+static int intel_init_engine(struct intel_engine_cs *engine)
  {
struct drm_i915_private *dev_priv = engine->i915;
struct intel_ringbuffer *ringbuf;
@@ -2868,7 +2868,7 @@ int intel_init_render_ring_buffer(struct intel_engine_cs 
*engine)
engine->init_hw = init_render_ring;
engine->cleanup = render_ring_cleanup;

-   ret = intel_init_ring_buffer(engine);
+   ret = intel_init_engine(engine);
if (ret)
return ret;

@@ -2907,7 +2907,7 @@ int intel_init_bsd_ring_buffer(struct intel_engine_cs 
*engine)
engine->irq_enable_mask = I915_BSD_USER_INTERRUPT;
}

-   return intel_init_ring_buffer(engine);
+   return intel_init_engine(engine);
  }

  /**
@@ -2921,7 +2921,7 @@ int intel_init_bsd2_ring_buffer(struct intel_engine_cs 
*engine)

engine->flush = gen6_bsd_ring_flush;

-   return intel_init_ring_buffer(engine);
+   return intel_init_engine(engine);
  }

  int intel_init_blt_ring_buffer(struct intel_engine_cs *engine)
@@ -2934,7 +2934,7 @@ int intel_init_blt_ring_buffer(struct intel_engine_cs 
*engine)
if (INTEL_GEN(dev_priv) < 8)
engine->irq_enable_mask = GT_BLT_USER_INTERRUPT;

-   return intel_init_ring_buffer(engine);
+   return intel_init_engine(engine);
  }

  int intel_init_vebox_ring_buffer(struct intel_engine_cs *engine)
@@ -2951,7 +2951,7 @@ int intel_init_vebox_ring_buffer(struct intel_engine_cs 
*engine)
engine->irq_disable = hsw_vebox_irq_disable;
}

-   return intel_init_ring_buffer(engine);
+   return intel_init_engine(engine);
  }

  int



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

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Per-plane rotation, fixes, and mirroring for CHV

[Patchwork]

== Series Details ==

Series: drm/i915: Per-plane rotation, fixes, and mirroring for CHV
URL   : https://patchwork.freedesktop.org/series/10093/
State : success

== Summary ==

Series 10093v1 drm/i915: Per-plane rotation, fixes, and mirroring for CHV
http://patchwork.freedesktop.org/api/1.0/series/10093/revisions/1/mbox

Test gem_sync:
Subgroup basic-store-each:
dmesg-fail -> PASS   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (fi-hsw-i7-4770k)

fi-hsw-i7-4770k  total:208  pass:189  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-qkkr  total:244  pass:179  dwarn:27  dfail:0   fail:11  skip:27 
fi-skl-i5-6260u  total:244  pass:224  dwarn:0   dfail:0   fail:8   skip:12 
fi-skl-i7-6700k  total:244  pass:210  dwarn:0   dfail:0   fail:8   skip:26 
fi-snb-i7-2600   total:244  pass:196  dwarn:0   dfail:0   fail:8   skip:40 
ro-bdw-i5-5250u  total:244  pass:219  dwarn:4   dfail:0   fail:8   skip:13 
ro-bdw-i7-5600u  total:244  pass:204  dwarn:0   dfail:0   fail:8   skip:32 
ro-bsw-n3050 total:218  pass:173  dwarn:0   dfail:0   fail:2   skip:42 
ro-byt-n2820 total:244  pass:197  dwarn:0   dfail:0   fail:9   skip:38 
ro-hsw-i3-4010u  total:244  pass:212  dwarn:0   dfail:0   fail:8   skip:24 
ro-hsw-i7-4770r  total:244  pass:212  dwarn:0   dfail:0   fail:8   skip:24 
ro-ilk-i7-620lm  total:244  pass:172  dwarn:0   dfail:0   fail:9   skip:63 
ro-ilk1-i5-650   total:239  pass:172  dwarn:0   dfail:0   fail:9   skip:58 
ro-ivb-i7-3770   total:244  pass:203  dwarn:0   dfail:0   fail:8   skip:33 
ro-skl3-i5-6260u total:244  pass:224  dwarn:0   dfail:0   fail:8   skip:12 
ro-snb-i7-2620M  total:244  pass:193  dwarn:0   dfail:0   fail:9   skip:42 
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1545/

30920eb drm-intel-nightly: 2016y-07m-20d-13h-08m-56s UTC integration manifest
26bd7f8 drm/i915: Add horizontal mirroring support for CHV pipe B planes
d6486b7 drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup
3d4af5f drm/i915: Use & instead if == to check for rotations
8db883e drm/i915: Use the per-plane rotation property
e2e77bc drm: Add support for optional per-plane rotation property
82703dc drm/atomic: Reject attempts to use multiple rotation angles at once
f11ba82 drm: Add drm_rotation_90_or_270()

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

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Use the per-plane rotation property

[Ville Syrjälä]

On Wed, Jul 20, 2016 at 04:57:32PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > On certain platforms not all planes support the same set of
> > rotations/reflections, so let's use the per-plane property
> > for this.
> > 
> > This is already a problem on SKL when we use the legay cursor plane
> > as it only supports 0|180 whereas the universal planes support
> > 0|90|180|270, and it will be a problem on CHV soon.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 51 
> > +++-
> >  drivers/gpu/drm/i915/intel_drv.h |  4 +--
> >  drivers/gpu/drm/i915/intel_sprite.c  | 12 -
> >  3 files changed, 40 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 08b9f9a19df0..93ecb259c5ce 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14217,6 +14217,7 @@ static struct drm_plane 
> > *intel_primary_plane_create(struct drm_device *dev,
> >     struct intel_plane *primary = NULL;
> >     struct intel_plane_state *state = NULL;
> >     const uint32_t *intel_primary_formats;
> > +   unsigned int supported_rotations;
> >     unsigned int num_formats;
> >     int ret;
> >  
> > @@ -14289,8 +14290,19 @@ static struct drm_plane 
> > *intel_primary_plane_create(struct drm_device *dev,
> >     if (ret)
> >     goto fail;
> >  
> > +   if (INTEL_INFO(dev)->gen >= 9) {
> > +   supported_rotations =
> > +   BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
> > +   BIT(DRM_ROTATE_180) | BIT(DRM_ROTATE_270);
> > +   } else if (INTEL_INFO(dev)->gen >= 4) {
> > +   supported_rotations =
> > +   BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_180);
> > +   } else {
> > +   supported_rotations = BIT(DRM_ROTATE_0);
> > +   }
> > +
> 
> Might this be more informative if it was;
> 
> supported_rotations = BIT(DRM_ROTATE_0);
> 
> if (gen >= 4)
>   supported_rotations |= BIT(DRM_ROTATE_180);
> 
> Then you could exclude too, for special platforms.

I think I prefer to have explicit "these platforms support exactly these 
things".
Less thinking required.

> 
> Also, use INTEL_GEN()
> 
> >     if (INTEL_INFO(dev)->gen >= 4)
> > -   intel_create_rotation_property(dev, primary);
> > +   intel_create_rotation_property(primary, supported_rotations);
> >  
> >     drm_plane_helper_add(>base, _plane_helper_funcs);
> >  
> > @@ -14303,22 +14315,20 @@ fail:
> >     return NULL;
> >  }
> >  
> > -void intel_create_rotation_property(struct drm_device *dev, struct 
> > intel_plane *plane)
> > +void intel_create_rotation_property(struct intel_plane *plane,
> > +   unsigned int supported_rotations)
> >  {
> > -   if (!dev->mode_config.rotation_property) {
> > -   unsigned long flags = BIT(DRM_ROTATE_0) |
> > -   BIT(DRM_ROTATE_180);
> > +   struct drm_device *dev = plane->base.dev;
> >  
> > -   if (INTEL_INFO(dev)->gen >= 9)
> > -   flags |= BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270);
> > +   if (!plane->base.rotation_property)
> > +   plane->base.rotation_property =
> > +   drm_mode_create_rotation_property(dev,
> > +     supported_rotations);
> >  
> > -   dev->mode_config.rotation_property =
> > -   drm_mode_create_rotation_property(dev, flags);
> > -   }
> > -   if (dev->mode_config.rotation_property)
> > +   if (plane->base.rotation_property)
> >     drm_object_attach_property(>base.base,
> > -   dev->mode_config.rotation_property,
> > -   plane->base.state->rotation);
> > +      plane->base.rotation_property,
> > +      plane->base.state->rotation);
> >  }
> >  
> >  static int
> > @@ -14449,17 +14459,10 @@ static struct drm_plane 
> > *intel_cursor_plane_create(struct drm_device *dev,
> >     if (ret)
> >     goto fail;
> >  
> > -   if (INTEL_INFO(dev)->gen >= 4) {
> > -   if (!dev->mode_config.rotation_property)
> > -   dev->mode_config.rotation_property =
> > -   drm_mode_create_rotation_property(dev,
> > -   BIT(DRM_ROTATE_0) |
> > -   BIT(DRM_ROTATE_180));
> > -   if (dev->mode_config.rotation_property)
> > -   drm_object_attach_property(>base.base,
> > -   dev->mode_config.rotation_property,
> > -   state->base.rotation);
> > -   }
> > +   if (INTEL_INFO(dev)->gen >= 4)
> 
> 

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Use & instead if == to check for rotations

[Ville Syrjälä]

On Wed, Jul 20, 2016 at 05:01:00PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Using == to check for 180 degree rotation only works as long as the
> > reflection bits aren't set. That will change soon enough for CHV, so
> > let's stop doing things the wrong way.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Joonas Lahtinen 
> 
> Reading through the patch makes me wanna do the change;
> 
> #define DRM_ROTATE_180 BIT(x)
> 
> even more. Maybe with coccinelle.

Yeah, that one is annoying. One problem is the way the bits are
specified for bitmask properties (as shifts), so we still need the
names for the shifts too :(

> 
> Regards, Joonas
> 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 9 +
> >  drivers/gpu/drm/i915/intel_sprite.c  | 6 +++---
> >  2 files changed, 8 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 93ecb259c5ce..79c1a8b89d1d 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2688,7 +2688,7 @@ static void i9xx_update_primary_plane(struct 
> > drm_plane *primary,
> >     intel_crtc->dspaddr_offset = linear_offset;
> >     }
> >  
> > -   if (rotation == BIT(DRM_ROTATE_180)) {
> > +   if (rotation & BIT(DRM_ROTATE_180)) {
> >     dspcntr |= DISPPLANE_ROTATE_180;
> >  
> >     x += (crtc_state->pipe_src_w - 1);
> > @@ -2791,7 +2791,8 @@ static void ironlake_update_primary_plane(struct 
> > drm_plane *primary,
> >     intel_compute_tile_offset(, , fb, 0,
> >       fb->pitches[0], rotation);
> >     linear_offset -= intel_crtc->dspaddr_offset;
> > -   if (rotation == BIT(DRM_ROTATE_180)) {
> > +
> > +   if (rotation & BIT(DRM_ROTATE_180)) {
> >     dspcntr |= DISPPLANE_ROTATE_180;
> >  
> >     if (!IS_HASWELL(dev) && !IS_BROADWELL(dev)) {
> > @@ -10263,7 +10264,7 @@ static void i9xx_update_cursor(struct drm_crtc 
> > *crtc, u32 base,
> >     if (HAS_DDI(dev))
> >     cntl |= CURSOR_PIPE_CSC_ENABLE;
> >  
> > -   if (plane_state->base.rotation == BIT(DRM_ROTATE_180))
> > +   if (plane_state->base.rotation & BIT(DRM_ROTATE_180))
> >     cntl |= CURSOR_ROTATE_180;
> >     }
> >  
> > @@ -10309,7 +10310,7 @@ static void intel_crtc_update_cursor(struct 
> > drm_crtc *crtc,
> >  
> >     /* ILK+ do this automagically */
> >     if (HAS_GMCH_DISPLAY(dev) &&
> > -   plane_state->base.rotation == BIT(DRM_ROTATE_180)) {
> > +   plane_state->base.rotation & BIT(DRM_ROTATE_180)) {
> >     base += (plane_state->base.crtc_h *
> >      plane_state->base.crtc_w - 1) * 4;
> >     }
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index bc41c1bba04c..6b815d57d75a 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -444,7 +444,7 @@ vlv_update_plane(struct drm_plane *dplane,
> >        fb->pitches[0], rotation);
> >     linear_offset -= sprsurf_offset;
> >  
> > -   if (rotation == BIT(DRM_ROTATE_180)) {
> > +   if (rotation & BIT(DRM_ROTATE_180)) {
> >     sprctl |= SP_ROTATE_180;
> >  
> >     x += src_w;
> > @@ -577,7 +577,7 @@ ivb_update_plane(struct drm_plane *plane,
> >        fb->pitches[0], rotation);
> >     linear_offset -= sprsurf_offset;
> >  
> > -   if (rotation == BIT(DRM_ROTATE_180)) {
> > +   if (rotation & BIT(DRM_ROTATE_180)) {
> >     sprctl |= SPRITE_ROTATE_180;
> >  
> >     /* HSW and BDW does this automagically in hardware */
> > @@ -714,7 +714,7 @@ ilk_update_plane(struct drm_plane *plane,
> >        fb->pitches[0], rotation);
> >     linear_offset -= dvssurf_offset;
> >  
> > -   if (rotation == BIT(DRM_ROTATE_180)) {
> > +   if (rotation & BIT(DRM_ROTATE_180)) {
> >     dvscntr |= DVS_ROTATE_180;
> >  
> >     x += src_w;
> -- 
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation

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

Re: [Intel-gfx] [PATCH 02/18] drm/i915: Rename request->ringbuf to request->ring

[Dave Gordon]

On 20/07/16 14:11, Chris Wilson wrote:

Now that we have disambuigated ring and engine, we can use the clearer
and more consistent name for the intel_ringbuffer pointer in the
request.

Signed-off-by: Chris Wilson 


You missed a few instances of 'ring' meaning engine:

i915_gem_execbuffer.c: struct intel_engine_cs **ring)
intel_mocs.h:int intel_mocs_init_engine(struct intel_engine_cs *ring);
intel_ringbuffer.c:gen5_seqno_barrier(struct intel_engine_cs *ring)
intel_ringbuffer.h: void(*irq_enable)(struct intel_engine_cs 
*ring);
intel_ringbuffer.h: void(*irq_disable)(struct intel_engine_cs 
*ring);
intel_ringbuffer.h: int (*init_hw)(struct intel_engine_cs 
*ring);
intel_ringbuffer.h:	void		(*irq_seqno_barrier)(struct intel_engine_cs 
*ring);

intel_ringbuffer.h: void(*cleanup)(struct intel_engine_cs 
*ring);

I think we have to purge every last trace of this usage before using 
'ring' as shorthand for 'ringbuf[fer]'.


.Dave.


---
  drivers/gpu/drm/i915/i915_gem_context.c|  4 +-
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  4 +-
  drivers/gpu/drm/i915/i915_gem_gtt.c|  6 +-
  drivers/gpu/drm/i915/i915_gem_request.c| 16 +++---
  drivers/gpu/drm/i915/i915_gem_request.h|  2 +-
  drivers/gpu/drm/i915/i915_gpu_error.c  | 20 +++
  drivers/gpu/drm/i915/intel_display.c   | 10 ++--
  drivers/gpu/drm/i915/intel_lrc.c   | 57 +-
  drivers/gpu/drm/i915/intel_mocs.c  | 36 ++--
  drivers/gpu/drm/i915/intel_overlay.c   |  8 +--
  drivers/gpu/drm/i915/intel_ringbuffer.c| 92 +++---
  11 files changed, 126 insertions(+), 129 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index b6d10bd763a0..16138c4ff7db 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -552,7 +552,7 @@ static inline int
  mi_set_context(struct drm_i915_gem_request *req, u32 hw_flags)
  {
struct drm_i915_private *dev_priv = req->i915;
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
u32 flags = hw_flags | MI_MM_SPACE_GTT;
const int num_rings =
/* Use an extended w/a on ivb+ if signalling from other rings */
@@ -654,7 +654,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
  static int remap_l3(struct drm_i915_gem_request *req, int slice)
  {
u32 *remap_info = req->i915->l3_parity.remap_info[slice];
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
int i, ret;

if (!remap_info)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index e2c4d99a1e7f..501a1751d432 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1173,7 +1173,7 @@ i915_gem_execbuffer_retire_commands(struct 
i915_execbuffer_params *params)
  static int
  i915_reset_gen7_sol_offsets(struct drm_i915_gem_request *req)
  {
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
int ret, i;

if (!IS_GEN7(req->i915) || req->engine->id != RCS) {
@@ -1303,7 +1303,7 @@ i915_gem_ringbuffer_submission(struct 
i915_execbuffer_params *params,

if (params->engine->id == RCS &&
instp_mode != dev_priv->relative_constants_mode) {
-   struct intel_ringbuffer *ring = params->request->ringbuf;
+   struct intel_ringbuffer *ring = params->request->ring;

ret = intel_ring_begin(params->request, 4);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index abc439be2049..a48329baf432 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -669,7 +669,7 @@ static int gen8_write_pdp(struct drm_i915_gem_request *req,
  unsigned entry,
  dma_addr_t addr)
  {
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
int ret;

BUG_ON(entry >= 4);
@@ -1660,7 +1660,7 @@ static uint32_t get_pd_offset(struct i915_hw_ppgtt *ppgtt)
  static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
 struct drm_i915_gem_request *req)
  {
-   struct intel_ringbuffer *ring = req->ringbuf;
+   struct intel_ringbuffer *ring = req->ring;
int ret;

/* NB: TLBs must be flushed and invalidated before a switch */
@@ -1688,7 +1688,7 @@ static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
  static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
  struct drm_i915_gem_request *req)
  {
-   struct intel_ringbuffer *ring = req->ringbuf;
+   

Re: [Intel-gfx] [PATCH 3/7] drm: Add support for optional per-plane rotation property

[Joonas Lahtinen]

On ke, 2016-07-20 at 17:08 +0300, Ville Syrjälä wrote:
> On Wed, Jul 20, 2016 at 04:51:57PM +0300, Joonas Lahtinen wrote:
> > 
> > On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote:
> > > 
> > > From: Ville Syrjälä 
> > > 
> > > Not all planes on the ssytem may support the same rotations/reflections,
> > s/ssytem/system/
> > 
> > > 
> > > so make it possible to create a separate property for each plane.
> > > This way userspace gets told exactly which rotations/reflections are
> > > possible for each plane.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c| 6 --
> > >  drivers/gpu/drm/drm_fb_helper.c | 6 +-
> > >  include/drm/drm_crtc.h  | 2 ++
> > >  3 files changed, 11 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 5f0002897862..38b023da6f09 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -710,7 +710,8 @@ int drm_atomic_plane_set_property(struct drm_plane 
> > > *plane,
> > >   state->src_w = val;
> > >   } else if (property == config->prop_src_h) {
> > >   state->src_h = val;
> > > - } else if (property == config->rotation_property) {
> > > + } else if (property == config->rotation_property ||
> > > +    property == plane->rotation_property) {
> > >   if (!is_power_of_2(val & DRM_ROTATE_MASK))
> > >   return -EINVAL;
> > >   state->rotation = val;
> > > @@ -768,7 +769,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > >   *val = state->src_w;
> > >   } else if (property == config->prop_src_h) {
> > >   *val = state->src_h;
> > > - } else if (property == config->rotation_property) {
> > > + } else if (property == config->rotation_property ||
> > > +    property == plane->rotation_property) {
> > >   *val = state->rotation;
> > >   } else if (plane->funcs->atomic_get_property) {
> > >   return plane->funcs->atomic_get_property(plane, state, 
> > > property, val);
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index ce54e985d91b..ce536c0553e5 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -392,7 +392,11 @@ static int restore_fbdev_mode(struct drm_fb_helper 
> > > *fb_helper)
> > >   if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> > >   drm_plane_force_disable(plane);
> > >  
> > > - if (dev->mode_config.rotation_property) {
> > > + if (plane->rotation_property) {
> > > + drm_mode_plane_set_obj_prop(plane,
> > > + plane->rotation_property,
> > > + BIT(DRM_ROTATE_0));
> > > + } else if (dev->mode_config.rotation_property) {
> > Why not clear the mode_config.rotation_property too, still?
> I would be cleared if any plane uses it. Though I'm not sure mixing
> per-plane and global rotation props in one device makes any real sense.
> 
> Or maybe I should just nuke the global property?

Maybe a vote for nuking, co-existence will unnecessarily complicate the
code. Only scenario I can see it working when planes with the property
are not used, and planes without are used solely. So the legacy
behaviour might not be very useful.

Regards, Joonas

-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm: Add support for optional per-plane rotation property

[Ville Syrjälä]

On Wed, Jul 20, 2016 at 04:51:57PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Not all planes on the ssytem may support the same rotations/reflections,
> 
> s/ssytem/system/
> 
> > so make it possible to create a separate property for each plane.
> > This way userspace gets told exactly which rotations/reflections are
> > possible for each plane.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_atomic.c| 6 --
> >  drivers/gpu/drm/drm_fb_helper.c | 6 +-
> >  include/drm/drm_crtc.h  | 2 ++
> >  3 files changed, 11 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 5f0002897862..38b023da6f09 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -710,7 +710,8 @@ int drm_atomic_plane_set_property(struct drm_plane 
> > *plane,
> >     state->src_w = val;
> >     } else if (property == config->prop_src_h) {
> >     state->src_h = val;
> > -   } else if (property == config->rotation_property) {
> > +   } else if (property == config->rotation_property ||
> > +      property == plane->rotation_property) {
> >     if (!is_power_of_2(val & DRM_ROTATE_MASK))
> >     return -EINVAL;
> >     state->rotation = val;
> > @@ -768,7 +769,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> >     *val = state->src_w;
> >     } else if (property == config->prop_src_h) {
> >     *val = state->src_h;
> > -   } else if (property == config->rotation_property) {
> > +   } else if (property == config->rotation_property ||
> > +      property == plane->rotation_property) {
> >     *val = state->rotation;
> >     } else if (plane->funcs->atomic_get_property) {
> >     return plane->funcs->atomic_get_property(plane, state, 
> > property, val);
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index ce54e985d91b..ce536c0553e5 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -392,7 +392,11 @@ static int restore_fbdev_mode(struct drm_fb_helper 
> > *fb_helper)
> >     if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> >     drm_plane_force_disable(plane);
> >  
> > -   if (dev->mode_config.rotation_property) {
> > +   if (plane->rotation_property) {
> > +   drm_mode_plane_set_obj_prop(plane,
> > +   plane->rotation_property,
> > +   BIT(DRM_ROTATE_0));
> > +   } else if (dev->mode_config.rotation_property) {
> 
> Why not clear the mode_config.rotation_property too, still?

I would be cleared if any plane uses it. Though I'm not sure mixing
per-plane and global rotation props in one device makes any real sense.

Or maybe I should just nuke the global property?

> 
> Regards, Joonas
> 
> >     drm_mode_plane_set_obj_prop(plane,
> >     
> > dev->mode_config.rotation_property,
> >     BIT(DRM_ROTATE_0));
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index b7ac7dcf52db..8d65e85d6d91 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -1737,6 +1737,8 @@ struct drm_plane {
> >     const struct drm_plane_helper_funcs *helper_private;
> >  
> >     struct drm_plane_state *state;
> > +
> > +   struct drm_property *rotation_property;
> >  };
> >  
> >  /**
> -- 
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation

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

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup

[Joonas Lahtinen]

On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Move the plane control register rotation setup away from the
> coordinate munging code. This will result in neater looking
> code once we add reflection support for CHV.
> 
> Signed-off-by: Ville Syrjälä 

Looks cleaner,

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 28 ++--
>  drivers/gpu/drm/i915/intel_sprite.c  | 28 +++-
>  2 files changed, 29 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 79c1a8b89d1d..88a7c4173715 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2674,6 +2674,9 @@ static void i9xx_update_primary_plane(struct drm_plane 
> *primary,
>   obj->tiling_mode != I915_TILING_NONE)
>   dspcntr |= DISPPLANE_TILED;
>  
> + if (rotation & BIT(DRM_ROTATE_180))
> + dspcntr |= DISPPLANE_ROTATE_180;
> +
>   if (IS_G4X(dev))
>   dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
>  
> @@ -2689,8 +2692,6 @@ static void i9xx_update_primary_plane(struct drm_plane 
> *primary,
>   }
>  
>   if (rotation & BIT(DRM_ROTATE_180)) {
> - dspcntr |= DISPPLANE_ROTATE_180;
> -
>   x += (crtc_state->pipe_src_w - 1);
>   y += (crtc_state->pipe_src_h - 1);
>  
> @@ -2783,6 +2784,9 @@ static void ironlake_update_primary_plane(struct 
> drm_plane *primary,
>   if (obj->tiling_mode != I915_TILING_NONE)
>   dspcntr |= DISPPLANE_TILED;
>  
> + if (rotation & BIT(DRM_ROTATE_180))
> + dspcntr |= DISPPLANE_ROTATE_180;
> +
>   if (!IS_HASWELL(dev) && !IS_BROADWELL(dev))
>   dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
>  
> @@ -2792,19 +2796,15 @@ static void ironlake_update_primary_plane(struct 
> drm_plane *primary,
>     fb->pitches[0], rotation);
>   linear_offset -= intel_crtc->dspaddr_offset;
>  
> - if (rotation & BIT(DRM_ROTATE_180)) {
> - dspcntr |= DISPPLANE_ROTATE_180;
> -
> - if (!IS_HASWELL(dev) && !IS_BROADWELL(dev)) {
> - x += (crtc_state->pipe_src_w - 1);
> - y += (crtc_state->pipe_src_h - 1);
> + /* HSW and BDW does this automagically in hardware */
> + if (!IS_HASWELL(dev) && !IS_BROADWELL(dev) &&
> + rotation & BIT(DRM_ROTATE_180)) {
> + x += (crtc_state->pipe_src_w - 1);
> + y += (crtc_state->pipe_src_h - 1);
>  
> - /* Finding the last pixel of the last line of the 
> display
> - data and adding to linear_offset*/
> - linear_offset +=
> - (crtc_state->pipe_src_h - 1) * fb->pitches[0] +
> - (crtc_state->pipe_src_w - 1) * cpp;
> - }
> + linear_offset +=
> + (crtc_state->pipe_src_h - 1) * fb->pitches[0] +
> + (crtc_state->pipe_src_w - 1) * cpp;
>   }
>  
>   intel_crtc->adjusted_x = x;
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 6b815d57d75a..14173f53f520 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -433,6 +433,9 @@ vlv_update_plane(struct drm_plane *dplane,
>   if (obj->tiling_mode != I915_TILING_NONE)
>   sprctl |= SP_TILED;
>  
> + if (rotation & BIT(DRM_ROTATE_180))
> + sprctl |= SP_ROTATE_180;
> +
>   /* Sizes are 0 based */
>   src_w--;
>   src_h--;
> @@ -445,8 +448,6 @@ vlv_update_plane(struct drm_plane *dplane,
>   linear_offset -= sprsurf_offset;
>  
>   if (rotation & BIT(DRM_ROTATE_180)) {
> - sprctl |= SP_ROTATE_180;
> -
>   x += src_w;
>   y += src_h;
>   linear_offset += src_h * fb->pitches[0] + src_w * cpp;
> @@ -555,6 +556,9 @@ ivb_update_plane(struct drm_plane *plane,
>   if (obj->tiling_mode != I915_TILING_NONE)
>   sprctl |= SPRITE_TILED;
>  
> + if (rotation & BIT(DRM_ROTATE_180))
> + sprctl |= SPRITE_ROTATE_180;
> +
>   if (IS_HASWELL(dev) || IS_BROADWELL(dev))
>   sprctl &= ~SPRITE_TRICKLE_FEED_DISABLE;
>   else
> @@ -577,15 +581,12 @@ ivb_update_plane(struct drm_plane *plane,
>      fb->pitches[0], rotation);
>   linear_offset -= sprsurf_offset;
>  
> - if (rotation & BIT(DRM_ROTATE_180)) {
> - sprctl |= SPRITE_ROTATE_180;
> -
> - /* HSW and BDW does this automagically in hardware */
> - if (!IS_HASWELL(dev) && !IS_BROADWELL(dev)) {
> - x += src_w;
> -