Re: [Intel-gfx] [PATCH] drm/i915: save/restore GMBUS freq across suspend/resume on gen4

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1 364/366  365/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(6, M26)PASS(21, M26M37)   
   PASS(1, M37)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Add drrs_interval module parameter

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1-3  364/366  362/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt_kms_render_direct-render  PASS(7, M26)  DMESG_WARN(1, M26)
 ILK  igt_kms_flip_blocking-absolute-wf_vblank-interruptible  DMESG_WARN(1, 
M26)PASS(7, M26)  DMESG_WARN(1, M26)
 ILK  igt_kms_flip_vblank-vs-hang  DMESG_WARN(2, M26)PASS(2, M26)  
DMESG_WARN(1, M26)
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(6, M26)PASS(20, M26M37)   
   PASS(1, M26)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Specify bsd rings through exec flag

[Zhao, Yakui]

On Wed, 2014-12-10 at 08:55 -0700, Dave Gordon wrote:
> On 10/12/14 09:11, Daniel Vetter wrote:
> > On Wed, Dec 10, 2014 at 02:18:15AM +, Gong, Zhipeng wrote:
> >> On Tue, 2014-12-09 at 10:46 +0100, Daniel Vetter wrote:
> >>> On Mon, Dec 08, 2014 at 01:55:56PM -0800, Rodrigo Vivi wrote:
> 
> [snip]
> 
>  diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
>  b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>  index e1ed85a..d9081ec 100644
>  --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>  +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
>  @@ -1273,8 +1273,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, 
>  void *data,
>    else if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
>    if (HAS_BSD2(dev)) {
>    int ring_id;
>  - ring_id = gen8_dispatch_bsd_ring(dev, file);
>  - ring = &dev_priv->ring[ring_id];
>  +
>  + switch (args->flags & I915_EXEC_BSD_MASK) {
>  + case I915_EXEC_BSD_DEFAULT:
>  + ring_id = gen8_dispatch_bsd_ring(dev, 
>  file);
>  + ring = &dev_priv->ring[ring_id];
>  + break;
>  + case I915_EXEC_BSD_RING1:
>  + ring = &dev_priv->ring[VCS];
> >>>
> >>> Do we have any use-case for selecting ring1 specifically? I've thought
> >>> it's only ring2 that is special?
> >> The HEVC GPU commands should be dispatched to BSD RING 1 instead of BSD
> >> RING2 as the two rings are asymmetrical. 
> >> For the H264 decoding/encoding either ring is OK.
> > 
> > Well then same arguments applies with ring2 since only ring1 is special?
> > It's just to minimize abi and reduce the amount of rope we hand to
> > userspace.
> 
> Anyone who knows to use any of these flags is taking responsibility for
> doing explicit engine allocation, so why not give them all the options
> -- if for no other reason, more symmetry is good.

Agree with Dave's point. The override flag is initiated by the SKL GT3
platform, which requires that the HEVC GPU command can only be
dispatched to the BSD ring1 explicitly as the two BSD rings are not
symmetric. And the override flag can also provide the user-space
app/driver with more flexibility to explicitly determine which BSD ring
should be used to dispatch video GPU command instead of kernel ping-pong
mode. And it benefits the platform with two BSD rings.

> 
> As an examle, there could be a case where userspace knows better than
> the kernel how long each batch will take, and can predict an optimal
> allocation pattern rather than just flip-flopping. So even when a batch
> *can* run on either engine, there might be a reason to pick a specific one.
> 
> e.g.  short-1 -> ring 1
>   short-2 -> ring 1
>   long-1  -> ring 2
>   short-3 -> ring 1
>   long-2  -> ring 1
> 
> because the program knows that the three short batches together will
> take less time than the one first long one.
> 
> .Dave.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx


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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Documentation for multiple GGTT views

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1-2  364/366  363/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt_kms_setmode_invalid-clone-exclusive-crtc  PASS(5, M26)  
DMESG_WARN(1, M26)
*ILK  igt_kms_flip_rcs-flip-vs-modeset  NSPT(1, M26)PASS(4, M26)  
DMESG_WARN(1, M26)
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(5, M26)PASS(20, M26M37)   
   PASS(1, M26)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Call the lrc irq handler correctly

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1 364/366  365/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(4, M26)PASS(20, M26M37)   
   PASS(1, M37)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Paolo Bonzini]

On 11/12/2014 01:33, Tian, Kevin wrote:
> My point is that KVMGT doesn't introduce new requirements as what's
> required in IGD passthrough case, because all the hacks you see now
> is to satisfy guest graphics driver's expectation. I haven't follow up the
> KVM IGD passthrough progress, but if it doesn't require ISA bridge hacking
> the same trick can be adopted by KVMGT too.

Right now it did require ISA bridge hacking.

> You may know Allen is
> working on driver changes to avoid causing those hacks in Qemu side.
> That effort will benefit us too.

That's good to know, thanks!

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

Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1-4  364/366  361/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt_kms_flip_nonexisting-fb  DMESG_WARN(1, M26)PASS(5, M26)  
NSPT(1, M26)
*ILK  igt_kms_flip_rcs-flip-vs-panning-interruptible  PASS(4, M26)  
DMESG_WARN(1, M26)
 ILK  igt_kms_flip_blocking-absolute-wf_vblank-interruptible  DMESG_WARN(1, 
M26)PASS(6, M26)  DMESG_WARN(1, M26)
 ILK  igt_kms_flip_plain-flip-ts-check-interruptible  DMESG_WARN(1, 
M26)PASS(3, M26)  DMESG_WARN(1, M26)
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(4, M26)PASS(19, M26M37)   
   PASS(1, M26)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Tian, Kevin]

> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Thursday, December 11, 2014 12:59 AM
> 
> On 09/12/2014 03:49, Tian, Kevin wrote:
> > - Now we have XenGT/KVMGT separately maintained, and KVMGT lags
> > behind XenGT regarding to features and qualities. Likely you'll continue
> > see stale code (like Xen inst decoder) for some time. In the future we
> > plan to maintain a single kernel repo for both, so KVMGT can share
> > same quality as XenGT once KVM in-kernel dm framework is stable.
> >
> > - Regarding to Qemu hacks, KVMGT really doesn't have any different
> > requirements as what have been discussed for GPU pass-through, e.g.
> > about ISA bridge. Our implementation is based on an old Qemu repo,
> > and honestly speaking not cleanly developed, because we know we
> > can leverage from GPU pass-through support once it's in Qemu. At
> > that time we'll leverage the same logic with minimal changes to
> > hook KVMGT mgmt. APIs (e.g. create/destroy a vGPU instance). So
> > we can ignore this area for now. :-)
> 
> Could the virtual device model introduce new registers in order to avoid
> poking at the ISA bridge?  I'm not sure that you "can leverage from GPU
> pass-through support once it's in Qemu", since the Xen IGD passthrough
> support is being added to a separate machine that is specific to Xen IGD
> passthrough; no ISA bridge hacking will probably be allowed on the "-M
> pc" and "-M q35" machine types.
> 

My point is that KVMGT doesn't introduce new requirements as what's
required in IGD passthrough case, because all the hacks you see now
is to satisfy guest graphics driver's expectation. I haven't follow up the
KVM IGD passthrough progress, but if it doesn't require ISA bridge hacking
the same trick can be adopted by KVMGT too. You may know Allen is
working on driver changes to avoid causing those hacks in Qemu side.
That effort will benefit us too. So I don't think this is a KVMGT specific
issue, and we need a common solution to close this gap instead of 
hacking vGPU device model alone.

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Track nested calls to intel(_logical)_ring_{begin, advance}

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV -2  364/364  362/364
ILK  +1-9  364/366  356/366
SNB -12  448/450  436/450
IVB -9  497/498  488/498
BYT -5  289/289  284/289
HSW -11  563/564  552/564
BDW -5  417/417  412/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*PNV  igt_gem_ringfill_blitter  PASS(3, M23M25)  DMESG_WARN(1, M23)
*PNV  igt_gem_ringfill_blitter-interruptible  PASS(3, M23M25)  
DMESG_WARN(1, M23)
*ILK  igt_gem_concurrent_blit_gpu-bcs-gpu-read-after-write-interruptible  
PASS(3, M26M37)  DMESG_WARN(1, M37)
*ILK  igt_gem_concurrent_blit_gpu-bcs-overwrite-source  PASS(2, M26M37) 
 DMESG_WARN(1, M37)
*ILK  igt_gem_concurrent_blit_gpu-bcs-overwrite-source-interruptible  
PASS(3, M26M37)  DMESG_WARN(1, M37)
*ILK  igt_gem_concurrent_blit_gpuX-bcs-gpu-read-after-write-interruptible  
PASS(3, M26M37)  DMESG_WARN(1, M37)
*ILK  igt_gem_concurrent_blit_gpuX-bcs-overwrite-source-interruptible  
PASS(3, M26M37)  DMESG_WARN(1, M37)
*ILK  igt_gem_concurrent_blit_gtt-bcs-gpu-read-after-write-interruptible  
PASS(3, M26M37)  DMESG_WARN(1, M37)
*ILK  igt_gem_concurrent_blit_gttX-bcs-gpu-read-after-write-interruptible  
PASS(3, M26M37)  DMESG_WARN(1, M37)
*ILK  igt_gem_ringfill_blitter  PASS(3, M26M37)  DMESG_WARN(1, M37)
*ILK  igt_gem_ringfill_blitter-interruptible  PASS(3, M26M37)  
DMESG_WARN(1, M37)
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(3, M26)PASS(19, M26M37)   
   PASS(1, M37)
*SNB  igt_gem_concurrent_blit_cpu-rcs-gpu-read-after-write-interruptible  
PASS(3, M35M22)  DMESG_WARN(1, M35)
*SNB  igt_gem_concurrent_blit_gpu-rcs-gpu-read-after-write-forked  PASS(3, 
M35M22)  DMESG_WARN(1, M35)
*SNB  igt_gem_concurrent_blit_gpu-rcs-gpu-read-after-write-interruptible  
PASS(3, M35M22)  DMESG_WARN(1, M35)
*SNB  igt_gem_concurrent_blit_gpuX-rcs-gpu-read-after-write-interruptible  
PASS(3, M35M22)  DMESG_WARN(1, M35)
*SNB  igt_gem_concurrent_blit_prw-rcs-gpu-read-after-write-forked  PASS(3, 
M35M22)  DMESG_WARN(1, M35)
*SNB  igt_gem_concurrent_blit_prw-rcs-gpu-read-after-write-interruptible  
PASS(3, M35M22)  DMESG_WARN(1, M35)
*SNB  igt_gem_ring_sync_copy_sync-render-blitter-read-write  PASS(3, 
M35M22)  DMESG_WARN(1, M35)
*SNB  igt_gem_ring_sync_copy_sync-render-blitter-write-read  PASS(3, 
M35M22)  DMESG_WARN(1, M35)
*SNB  igt_gem_ring_sync_copy_sync-render-blitter-write-write  PASS(3, 
M35M22)  DMESG_WARN(1, M35)
*SNB  igt_gem_userptr_blits_coherency-sync  PASS(3, M35M22)  
DMESG_WARN(1, M35)
*SNB  igt_pm_rps_min-max-config-loaded  PASS(3, M35M22)  DMESG_WARN(1, 
M35)
*SNB  igt_gem_concurrent_blit_gtt-rcs-gpu-read-after-write-interruptible  
PASS(3, M35M22)  DMESG_WARN(1, M35)
*IVB  igt_gem_linear_blits_interruptible  PASS(3, M4M34)  DMESG_WARN(1, 
M4)
*IVB  igt_gem_linear_blits_normal  PASS(3, M4M34)  DMESG_WARN(1, M4)
*IVB  igt_gem_render_linear_blits  PASS(3, M4M34)  DMESG_WARN(1, M4)
*IVB  igt_gem_render_tiled_blits  PASS(3, M4M34)  DMESG_WARN(1, M4)
*IVB  igt_gem_tiled_blits_interruptible  PASS(3, M4M34)  DMESG_WARN(1, 
M4)
*IVB  igt_gem_tiled_blits_normal  PASS(3, M4M34)  DMESG_WARN(1, M4)
*IVB  igt_gem_tiled_fence_blits  PASS(3, M4M34)  DMESG_WARN(1, M4)
*IVB  igt_gem_ringfill_blitter  PASS(3, M4M34)  DMESG_WARN(1, M4)
*IVB  igt_gem_ringfill_blitter-interruptible  PASS(3, M4M34)  
DMESG_WARN(1, M4)
*BYT  igt_gem_gtt_hog  PASS(3, M48M51)  DMESG_WARN(1, M48)
*BYT  igt_gem_ringfill_blitter  PASS(3, M48M51)  DMESG_WARN(1, M48)
*BYT  igt_gem_ringfill_blitter-interruptible  PASS(3, M48M51)  
DMESG_WARN(1, M48)
*BYT  igt_gem_ringfill_render  PASS(3, M48M51)  DMESG_WARN(1, M48)
*BYT  igt_gem_ringfill_render-interruptible  PASS(3, M48M51)  
DMESG_WARN(1, M48)
*HSW  igt_gem_linear_blits_interruptible  PASS(3, M40M20)  
DMESG_WARN(1, M20)
*HSW  igt_gem_linear_blits_normal  PASS(3, M40M20)  DMESG_WARN(1, M20)
*HSW  igt_gem_render_linear_blits  PASS(3, M40M20)  DMESG_WARN(1, M20)
*HSW  igt_gem_render_tiled_blits  PASS(3, M40M20)  DMESG_WARN(1, M20)
*HSW  igt_gem_tiled_blits_interruptible  PASS(3, M40M20)  DMESG_WARN(1, 
M20)
*HSW  igt_gem_tiled_blits_normal  PASS(3, M40M20)  

[Intel-gfx] [PATCH 14/17] drm/i915: Add debugfs function to check connector status for compliance testing

[Todd Previte]

Adds a function to check the status of a Displayport connector. This function
simplifies the Displayport compliance testing interface in debugfs by providing
a single method for determining the status of a connector during Displayport
compliance testing. This function checks whether or not the connector is a
Displayport connector and whether or not that connector is active.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5eb6c24..978ddd1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3920,6 +3920,35 @@ static int displayport_parse_config(char *input_buffer,
return status;
 }
 
+static bool dp_connector_is_valid(struct drm_connector *connector,
+ bool check_active)
+{
+   struct intel_encoder *intel_encoder;
+   struct intel_connector *intel_connector;
+
+   intel_connector = to_intel_connector(connector);
+   intel_encoder = intel_connector->encoder;
+
+   if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort)
+   goto no;
+
+   if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT &&
+   intel_encoder->type != INTEL_OUTPUT_UNKNOWN)
+   goto no;
+
+   if (check_active) {
+   if (connector->status == connector_status_connected)
+   goto yes;
+   else
+   goto no;
+   }
+
+yes:
+   return true;
+no:
+   return false;
+}
+
 static int displayport_config_ctl_show(struct seq_file *m, void *data)
 {
struct drm_device *dev = m->private;
-- 
1.9.1

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

[Intel-gfx] [PATCH 12/17] drm/i915: Update intel_dp_compute_config() to handle compliance test requests

[Todd Previte]

Adds provisions in intel_dp_compute_config() to accommodate compliance
testing. Mostly this invovles circumventing the automatic link configuration
parameters and allowing the compliance code to set those parameters as
required by the tests.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2a13124..4a55ca6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1189,6 +1189,21 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_drrs = false;
pipe_config->has_audio = intel_dp->has_audio;
 
+   /* Compliance testing should skip most of this function */
+   if (!is_edp(intel_dp) && intel_dp->compliance_testing_active) {
+   bpp = intel_dp->compliance_config.bits_per_pixel;
+   lane_count = intel_dp->compliance_config.lane_count;
+   clock = intel_dp->compliance_config.link_rate >> 3;
+   /* Assign here and skip at the end - ensures correct values */
+   intel_dp->link_bw = bws[clock];
+   intel_dp->lane_count = lane_count;
+   pipe_config->pipe_bpp = bpp;
+   pipe_config->port_clock =
+   drm_dp_bw_code_to_link_rate(intel_dp->link_bw);
+
+   goto compliance_exit;
+   }
+
if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
   adjusted_mode);
@@ -1275,6 +1290,7 @@ found:
DRM_DEBUG_KMS("DP link bw required %i available %i\n",
  mode_rate, link_avail);
 
+compliance_exit:
intel_link_compute_m_n(bpp, lane_count,
   adjusted_mode->crtc_clock,
   pipe_config->port_clock,
-- 
1.9.1

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

[Intel-gfx] [PATCH 17/17] drm/i915: Add debugfs write and test param parsing function for DP test control

[Todd Previte]

Adds and implements the 'write' function for the debugfs i915_dp_test_ctrl file.
Also adds in the required parsing function to read in the data from the file
once the user app has written its data to it.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 103 
 1 file changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d2cd684..091d62b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4063,6 +4063,46 @@ static const struct file_operations 
i915_displayport_config_ctl_fops = {
.write = displayport_config_ctl_write
 };
 
+static int displayport_parse_test_ctl(char *input_buffer,
+ ssize_t buffer_size,
+ struct intel_dp *intel_dp)
+{
+   char *ctrl_lines[DP_TEST_CTRL_LINE_COUNT];
+   int line_count;
+   int test_data;
+   int active;
+   int response;
+   char *conn_name; /* Connector name in the file */
+   char *dp_name;   /* Connector name in the intel_dp struct */
+
+   if (!input_buffer)
+   return -EIO;
+
+   line_count = tokenize_dp_config(input_buffer, ctrl_lines);
+   if (line_count != DP_TEST_CTRL_LINE_COUNT)
+   return -EIO;
+
+   conn_name = ctrl_lines[DP_CTRL_PARAM_CONNECTOR];
+   dp_name = intel_dp->attached_connector->base.name;
+
+   if (strncmp(conn_name, dp_name, strlen(dp_name)) == 0) {
+   kstrtol(ctrl_lines[DP_CTRL_PARAM_TEST_DATA],
+   16,
+   (long *)&test_data);
+   kstrtol(ctrl_lines[DP_CTRL_PARAM_TEST_ACTIVE],
+   16,
+   (long *)&active);
+   kstrtol(ctrl_lines[DP_CTRL_PARAM_TEST_RESPONSE],
+   16,
+   (long *)&response);
+   } else {
+   DRM_DEBUG_DRIVER("Connector names don't match\n");
+   return -EIO;
+   }
+
+   return 0;
+}
+
 static int displayport_test_ctl_show(struct seq_file *m, void *data)
 {
struct drm_device *dev = m->private;
@@ -4109,9 +4149,72 @@ static int displayport_test_ctl_open(struct inode *inode,
return single_open(file, displayport_test_ctl_show, dev);
 }
 
+static ssize_t displayport_test_ctl_write(struct file *file,
+   const char __user *ubuf,
+   size_t len, loff_t *offp)
+{
+   char *input_buffer;
+   int status = 0;
+   struct seq_file *m;
+   struct drm_device *dev;
+   struct drm_connector *connector;
+   struct intel_encoder *intel_encoder;
+   struct intel_connector *intel_connector;
+   struct intel_dp *intel_dp;
+
+   m = file->private_data;
+   if (!m) {
+   status = -ENODEV;
+   return status;
+   }
+   dev = m->private;
+
+   if (!dev) {
+   status = -ENODEV;
+   return status;
+   }
+
+   if (len == 0)
+   return 0;
+
+   input_buffer = kmalloc(len + 1, GFP_KERNEL);
+   if (!input_buffer)
+   return -ENOMEM;
+
+   if (copy_from_user(input_buffer, ubuf, len)) {
+   status = -EFAULT;
+   goto out;
+   }
+
+   input_buffer[len] = '\0';
+   DRM_DEBUG_DRIVER("Copied %d bytes from user\n", (unsigned int)len);
+
+   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+   intel_connector = to_intel_connector(connector);
+   intel_encoder = intel_connector->encoder;
+   if (dp_connector_is_valid(connector, 0)) {
+   intel_dp = enc_to_intel_dp(&intel_encoder->base);
+   status = displayport_parse_test_ctl(input_buffer,
+   len,
+   intel_dp);
+   if (status < 0)
+   goto out;
+   }
+   }
+out:
+   kfree(input_buffer);
+   if (status < 0)
+   return status;
+
+   *offp += len;
+   return len;
+
+}
+
 static const struct file_operations i915_dp_test_ctl_fops = {
.owner = THIS_MODULE,
.open = displayport_test_ctl_open,
+   .write = displayport_test_ctl_write,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
-- 
1.9.1

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

[Intel-gfx] [PATCH 13/17] drm/i915: Update intel_dp_hpd_pulse() to check link status for non-MST operation

[Todd Previte]

Moves the non-MST case out of the if-statement and places it at the beginning
of the function to handle HPD events for SST mode. The reasoning behind this
is to accommodate link status checks for compliance testing. Some test devices
use long pulses to perform test requests so link status must be checked
regardless of the pulse width for the SST operational mode.

This patch replaces [PATCH 10/10] drm/i915: Fix intel_dp_hot_plug() in the
previous compliance testing patch sequence. Review feedback on that patch
indicated that updating intel_dp_hot_plug() was not the correct place for
the test handler.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4a55ca6..73014d8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4613,6 +4613,18 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
 
+   if (!intel_dp->is_mst) {
+   /*
+*  Pulse width doesn't matter for SST mode
+*  Handle the HPD event now
+   */
+   drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+   intel_dp_check_link_status(intel_dp);
+   drm_modeset_unlock(&dev->mode_config.connection_mutex);
+   ret = false;
+   goto put_power;
+   }
+
if (long_hpd) {
 
if (HAS_PCH_SPLIT(dev)) {
@@ -4637,16 +4649,6 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
goto mst_fail;
}
-
-   if (!intel_dp->is_mst) {
-   /*
-* we'll check the link status via the normal hot plug 
path later -
-* but for short hpds we should check it now
-*/
-   drm_modeset_lock(&dev->mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
-   drm_modeset_unlock(&dev->mode_config.connection_mutex);
-   }
}
ret = false;
goto put_power;
-- 
1.9.1

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

[Intel-gfx] [PATCH 15/17] drm/i915: Update debugfs functions for Displayport compliance testing

[Todd Previte]

Updates displayport_config_ctl_write and displayport_config_ctl_show to
use the dp_connector_is_valid() function. This saves on code and improves
maintainability by unifying the code in a single, common path.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 42 +
 1 file changed, 14 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 978ddd1..846b2fb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3955,6 +3955,7 @@ static int displayport_config_ctl_show(struct seq_file 
*m, void *data)
struct drm_connector *drm_connector;
struct intel_encoder *encoder;
struct intel_connector *connector;
+   char *conn_name;
 
if (!dev)
return -ENODEV;
@@ -3964,23 +3965,14 @@ static int displayport_config_ctl_show(struct seq_file 
*m, void *data)
head) {
connector = to_intel_connector(drm_connector);
encoder = connector->encoder;
-   if (drm_connector->connector_type ==
-   DRM_MODE_CONNECTOR_DisplayPort) {
-   if (encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
-   encoder->type == INTEL_OUTPUT_UNKNOWN) {
-   if (drm_connector->status ==
-   connector_status_connected) {
-   displayport_show_config_info(m,
-connector);
-   } else {
-   seq_printf(m, DP_CONF_STR_CONNECTOR,
-  encoder->base.name);
-   seq_puts(m, "disconnected\n");
-   }
-   }
+   conn_name = connector->base.name;
+   if (dp_connector_is_valid(drm_connector, 1)) {
+   displayport_show_config_info(m, connector);
+   } else {
+   seq_printf(m, DP_CONF_STR_CONNECTOR, conn_name);
+   seq_puts(m, "disconnected\n");
}
}
-
return 0;
 }
 
@@ -4001,7 +3993,6 @@ static ssize_t displayport_config_ctl_write(struct file 
*file,
struct seq_file *m;
struct drm_device *dev;
struct drm_connector *connector;
-   struct drm_encoder *drm_enc;
struct intel_encoder *intel_encoder;
struct intel_connector *intel_connector;
struct intel_dp *intel_dp;
@@ -4036,18 +4027,13 @@ static ssize_t displayport_config_ctl_write(struct file 
*file,
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
intel_connector = to_intel_connector(connector);
intel_encoder = intel_connector->encoder;
-   drm_enc = &intel_encoder->base;
-   if (connector->connector_type ==
-   DRM_MODE_CONNECTOR_DisplayPort) {
-   if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
-   intel_encoder->type == INTEL_OUTPUT_UNKNOWN) {
-   intel_dp = enc_to_intel_dp(drm_enc);
-   status = displayport_parse_config(input_buffer,
- len,
- intel_dp);
-   if (status < 0)
-   goto out;
-   }
+   if (dp_connector_is_valid(connector, 0)) {
+   intel_dp = enc_to_intel_dp(&intel_encoder->base);
+   status = displayport_parse_config(input_buffer,
+ len,
+ intel_dp);
+   if (status < 0)
+   goto out;
}
}
 out:
-- 
1.9.1

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

[Intel-gfx] [PATCH 16/17] drm/i915: Add new debugfs file for Displaypor compliance test control

[Todd Previte]

Adds a new file for controlling Displayport compliance testing via the debugfs
interface. Adds two functions, 'open' and 'show', as well as the file operations
structure to support reading the file from userspace. The new file is called
'i915_dp_test_ctl' and contains 4 fields:
  - Connector name
  - Test data
  - Test active flag
  - Test response
These four fields are used to control communication and operation between the
userspace application and the kernel during compliance testing. A new variable
is also added to the intel_dp struct to hold the response code from the user
application. This response code is then sent to the sink device upon completion
of the test.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 66 -
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 2 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 846b2fb..d2cd684 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -54,6 +54,7 @@ static const char *yesno(int v)
 
 #define DP_PARAMETER_COUNT 8
 #define MAX_DP_CONFIG_LINE_COUNT   64
+#define DP_TEST_CTRL_LINE_COUNT4
 
 enum dp_config_param {
DP_CONFIG_PARAM_INVALID = -1,
@@ -67,6 +68,14 @@ enum dp_config_param {
DP_CONFIG_PARAM_BPP
 };
 
+enum dp_ctrl_param {
+   DP_CTRL_PARAM_INVALID = -1,
+   DP_CTRL_PARAM_CONNECTOR = 0,
+   DP_CTRL_PARAM_TEST_DATA = 1,
+   DP_CTRL_PARAM_TEST_ACTIVE = 2,
+   DP_CTRL_PARAM_TEST_RESPONSE = 3
+};
+
 struct dp_config {
enum dp_config_param type;
unsigned long value;
@@ -4054,6 +4063,60 @@ static const struct file_operations 
i915_displayport_config_ctl_fops = {
.write = displayport_config_ctl_write
 };
 
+static int displayport_test_ctl_show(struct seq_file *m, void *data)
+{
+   struct drm_device *dev = m->private;
+   struct drm_connector *connector;
+   struct intel_encoder *intel_encoder;
+   struct intel_connector *intel_connector;
+   struct intel_dp *intel_dp;
+
+   if (!dev)
+   return -ENODEV;
+
+   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+   intel_connector = to_intel_connector(connector);
+   intel_encoder = intel_connector->encoder;
+
+   seq_printf(m, DP_CONF_STR_CONNECTOR,
+  intel_connector->base.name);
+
+   if (dp_connector_is_valid(connector, 1)) {
+   intel_encoder = intel_connector->encoder;
+   intel_dp = enc_to_intel_dp(&intel_encoder->base);
+   /* Compliance test data informs userspace about current
+  request
+   */
+   seq_printf(m, "Test Data  : %08lx\n",
+  intel_dp->compliance_test_data);
+   seq_printf(m, "Test Active: %02x\n",
+  intel_dp->compliance_testing_active);
+   seq_printf(m, "Test Response: %02lx\n",
+  intel_dp->compliance_test_response);
+   } else {
+   seq_puts(m, "disconnected\n");
+   }
+   }
+
+   return 0;
+}
+
+static int displayport_test_ctl_open(struct inode *inode,
+ struct file *file)
+{
+   struct drm_device *dev = inode->i_private;
+
+   return single_open(file, displayport_test_ctl_show, dev);
+}
+
+static const struct file_operations i915_dp_test_ctl_fops = {
+   .owner = THIS_MODULE,
+   .open = displayport_test_ctl_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+};
+
 static void wm_latency_show(struct seq_file *m, const uint16_t wm[8])
 {
struct drm_device *dev = m->private;
@@ -4806,7 +4869,8 @@ static const struct i915_debugfs_files {
{"i915_spr_wm_latency", &i915_spr_wm_latency_fops},
{"i915_cur_wm_latency", &i915_cur_wm_latency_fops},
{"i915_fbc_false_color", &i915_fbc_fc_fops},
-   {"i915_displayport_config_ctl", &i915_displayport_config_ctl_fops}
+   {"i915_displayport_config_ctl", &i915_displayport_config_ctl_fops},
+   {"i915_dp_test_ctl", &i915_dp_test_ctl_fops}
 };
 
 void intel_display_crc_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5a8b1d6..eff3a14 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -653,6 +653,7 @@ struct intel_dp {
/* Displayport compliance testing */
unsigned long compliance_test_data;
bool compliance_testing_active;
+   unsigned long compliance_test_response;
struct intel_dp_link_config compliance_config;
struct intel_dp_link_config saved_config;
 

[Intel-gfx] [PATCH 11/17] drm/i915: Update the EDID automated compliance test function

[Todd Previte]

Updates the EDID compliance test function to perform the EDID read as
required by the tests. This read needs to take place in the kernel for
reasons of speed and efficiency. The results of the EDID read are handed
off to userspace so that the remainder of the test can be conducted there.

V2:
- Addressed mailing list feedback
- Removed excess debug messages
- Removed extraneous comments
- Fixed formatting issues (line length > 80)
- Updated the debug message in compute_edid_checksum to output hex values
  instead of decimal

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 72 -
 1 file changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b6f5a72..2a13124 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -40,6 +40,13 @@
 
 #define DP_LINK_CHECK_TIMEOUT  (10 * 1000)
 
+/* Compliance test status bits  */
+#define  INTEL_DP_EDID_OK  (0<<0)
+#define  INTEL_DP_EDID_CORRUPT (1<<0)
+#define  INTEL_DP_RESOLUTION_PREFERRED (1<<2)
+#define  INTEL_DP_RESOLUTION_STANDARD  (1<<3)
+#define  INTEL_DP_RESOLUTION_FAILSAFE  (1<<4)
+
 struct dp_link_dpll {
int link_bw;
struct dpll dpll;
@@ -3761,9 +3768,72 @@ static uint8_t intel_dp_autotest_video_pattern(struct 
intel_dp *intel_dp)
return test_result;
 }
 
+static bool intel_dp_compute_edid_checksum(uint8_t *edid_data,
+  uint8_t *edid_checksum)
+{
+   uint32_t byte_total = 0;
+   uint8_t i = 0;
+   bool edid_ok = true;
+
+   /* Don't include last byte (the checksum) in the computation */
+   for (i = 0; i < EDID_LENGTH - 2; i++)
+   byte_total += edid_data[i];
+
+   *edid_checksum = 256 - (byte_total % 256);
+
+   if (*edid_checksum != edid_data[EDID_LENGTH - 1]) {
+   DRM_DEBUG_KMS("Invalid EDID checksum %02x, should be %02x\n",
+ edid_data[EDID_LENGTH - 40 - 1], *edid_checksum);
+   edid_ok = false;
+   }
+
+   return edid_ok;
+}
+
 static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
 {
-   uint8_t test_result = DP_TEST_NAK;
+   struct drm_connector *connector = &intel_dp->attached_connector->base;
+   struct i2c_adapter *adapter = &intel_dp->aux.ddc;
+   struct edid *edid_read = NULL;
+   uint8_t *edid_data = NULL;
+   uint8_t test_result = DP_TEST_NAK, checksum = 0;
+   uint32_t ret = 0;
+
+   intel_dp->aux.i2c_nack_count = 0;
+   intel_dp->aux.i2c_defer_count = 0;
+
+   edid_read = drm_get_edid(connector, adapter);
+
+   if (edid_read == NULL) {
+   /* Check for NACKs/DEFERs, use failsafe if detected
+  (DP CTS 1.2 Core Rev 1.1, 4.2.2.4, 4.2.2.5) */
+   if (intel_dp->aux.i2c_nack_count > 0 ||
+   intel_dp->aux.i2c_defer_count > 0)
+   DRM_DEBUG_KMS("EDID read had %d NACKs, %d DEFERs\n",
+ intel_dp->aux.i2c_nack_count,
+ intel_dp->aux.i2c_defer_count);
+   intel_dp->compliance_test_data = INTEL_DP_EDID_CORRUPT |
+INTEL_DP_RESOLUTION_FAILSAFE;
+   } else {
+   edid_data = (uint8_t *) edid_read;
+
+   if (intel_dp_compute_edid_checksum(edid_data, &checksum)) {
+   ret = drm_dp_dpcd_write(&intel_dp->aux,
+   DP_TEST_EDID_CHECKSUM,
+   &edid_read->checksum, 1);
+   test_result = DP_TEST_ACK |
+ DP_TEST_EDID_CHECKSUM_WRITE;
+   intel_dp->compliance_test_data =
+   INTEL_DP_EDID_OK |
+   INTEL_DP_RESOLUTION_PREFERRED;
+   } else {
+   /* Invalid checksum - EDID corruption detection */
+   intel_dp->compliance_test_data =
+   INTEL_DP_EDID_CORRUPT |
+   INTEL_DP_RESOLUTION_FAILSAFE;
+   }
+   }
+
return test_result;
 }
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 03/17] drm/i915: Add a delay in Displayport AUX transactions for compliance testing

[Todd Previte]

The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that repeated AUX transactions after a failure (no response /
invalid response) must have a minimum delay of 400us before the resend can
occur. Tests 4.2.1.1 and 4.2.1.2 are two tests that require this specifically.

V2:
- Changed udelay() to usleep_range()

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1b452cc..b6f5a72 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -876,9 +876,14 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
   DP_AUX_CH_CTL_TIME_OUT_ERROR |
   DP_AUX_CH_CTL_RECEIVE_ERROR);
 
+   /* DP compliance requires 400us delay for errors
+  and timeouts (DP CTS 1.2 Core Rev 1.1, 4.2.1.1
+  & 4.2.1.2) */
if (status & (DP_AUX_CH_CTL_TIME_OUT_ERROR |
- DP_AUX_CH_CTL_RECEIVE_ERROR))
+ DP_AUX_CH_CTL_RECEIVE_ERROR)) {
+   usleep_range(400, 500);
continue;
+   }
if (status & DP_AUX_CH_CTL_DONE)
break;
}
-- 
1.9.1

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

[Intel-gfx] [PATCH 08/17] drm/i915: Add Displayport link configuration structure

[Todd Previte]

This patch was previously part of "[PATCH 07/10] drm/i915: Add structures for
Displayport compliance testing parameters". Adds a struct to maintain link
configuration data for Displayport compliance testing. The members added to
the intel_dp struct are for compliance testing purposes only and should not
be used during normal operations.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_drv.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d1a807a..5a8b1d6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -577,6 +577,18 @@ enum edp_drrs_refresh_rate_type {
DRRS_MAX_RR, /* RR count */
 };
 
+struct intel_dp_link_config {
+   uint8_t lane_count;
+   uint8_t link_rate;
+   uint8_t vswing_level;
+   uint8_t preemp_level;
+   uint32_t hres;
+   uint32_t vres;
+   uint8_t bits_per_pixel;
+   struct drm_display_mode *compliance_mode;
+   char connector_name[12];
+};
+
 struct intel_dp {
uint32_t output_reg;
uint32_t aux_ch_ctl_reg;
@@ -641,6 +653,8 @@ struct intel_dp {
/* Displayport compliance testing */
unsigned long compliance_test_data;
bool compliance_testing_active;
+   struct intel_dp_link_config compliance_config;
+   struct intel_dp_link_config saved_config;
 
 };
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 04/17] drm/i915: Add debugfs information for Displayport compliance testing

[Todd Previte]

This patch was part of "[PATCH 05/10] drm/i915: Add debugfs interface for
Displayport debug and compliance testing". That patch has been split into
smaller patches for ease of review and integration.

This patch contains the definitions/declarations for some of the constants
and data structures added to support debugfs output for Displayport compliance
testing.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 479e0c1..65b4f5e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "intel_drv.h"
@@ -51,6 +52,46 @@ static const char *yesno(int v)
return v ? "yes" : "no";
 }
 
+#define DP_PARAMETER_COUNT 8
+#define MAX_DP_CONFIG_LINE_COUNT   64
+
+enum dp_config_param {
+   DP_CONFIG_PARAM_INVALID = -1,
+   DP_CONFIG_PARAM_CONNECTOR = 0,
+   DP_CONFIG_PARAM_LINK_RATE,
+   DP_CONFIG_PARAM_LANE_COUNT,
+   DP_CONFIG_PARAM_VOLTAGE_SWING,
+   DP_CONFIG_PARAM_PREEMPHASIS,
+   DP_CONFIG_PARAM_HRES,
+   DP_CONFIG_PARAM_VRES,
+   DP_CONFIG_PARAM_BPP
+};
+
+struct dp_config {
+   enum dp_config_param type;
+   unsigned long value;
+};
+
+const char *dp_conf_tokens[DP_PARAMETER_COUNT] = {
+"Connector",
+"Link Rate",
+"Lane Count",
+"Voltage Swing Level",
+"Preemphasis Level",
+"Horizontal Resolution",
+"Vertical Resolution",
+"Bits Per Pixel"
+};
+/* Strings for writing out dp_configs */
+#define DP_CONF_STR_CONNECTOR  "Connector: %s\n"
+#define DP_CONF_STR_LINKRATE   "Link Rate: %02x\n"
+#define DP_CONF_STR_LANES  "Lane Count:%u\n"
+#define DP_CONF_STR_VSWING "Voltage Swing Level:   %u\n"
+#define DP_CONF_STR_PREEMP "Preemphasis Level: %u\n"
+#define DP_CONF_STR_HRES   "Horizontal Resolution: %d\n"
+#define DP_CONF_STR_VRES   "Vertical Resolution:   %d\n"
+#define DP_CONF_STR_BPP"Bits Per Pixel:%u\n"
+
 /* As the drm_debugfs_init() routines are called before dev->dev_private is
  * allocated we need to hook into the minor for release. */
 static int
-- 
1.9.1

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

[Intel-gfx] [PATCH 10/17] drm/i915: Implement the 'open' and 'write' debugfs functions for Displayport compliance

[Todd Previte]

This patch is a combination of sections out of the following two previous
patches:
[PATCH 05/10] drm/i915: Add debugfs interface for Displayport debug and
compliance testing
[PATCH 07/10] drm/i915: Add structures for Displayport compliance testing
parameters

This patch implements the debugfs functions for 'open' and 'write' as they
are specified in the file ops structure. The 'open' function outputs
Displayport data to the appropriate debugfs file while the 'write' function
handles parsing of user data written to that same file.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 66 +++--
 1 file changed, 64 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 55b6da5..5eb6c24 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3958,14 +3958,76 @@ static int displayport_config_ctl_show(struct seq_file 
*m, void *data)
 static int displayport_config_ctl_open(struct inode *inode,
   struct file *file)
 {
-   return 0;
+   struct drm_device *dev = inode->i_private;
+
+   return single_open(file, displayport_config_ctl_show, dev);
 }
 
 static ssize_t displayport_config_ctl_write(struct file *file,
const char __user *ubuf,
size_t len, loff_t *offp)
 {
-   return 0;
+   char *input_buffer;
+   int status = 0;
+   struct seq_file *m;
+   struct drm_device *dev;
+   struct drm_connector *connector;
+   struct drm_encoder *drm_enc;
+   struct intel_encoder *intel_encoder;
+   struct intel_connector *intel_connector;
+   struct intel_dp *intel_dp;
+
+   m = file->private_data;
+   if (!m) {
+   status = -ENODEV;
+   return status;
+   }
+   dev = m->private;
+
+   if (!dev) {
+   status = -ENODEV;
+   return status;
+   }
+
+   if (len == 0)
+   return 0;
+
+   input_buffer = kmalloc(len + 1, GFP_KERNEL);
+   if (!input_buffer)
+   return -ENOMEM;
+
+   if (copy_from_user(input_buffer, ubuf, len)) {
+   status = -EFAULT;
+   goto out;
+   }
+
+   input_buffer[len] = '\0';
+   DRM_DEBUG_DRIVER("Copied %d bytes from user\n", (unsigned int)len);
+
+   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+   intel_connector = to_intel_connector(connector);
+   intel_encoder = intel_connector->encoder;
+   drm_enc = &intel_encoder->base;
+   if (connector->connector_type ==
+   DRM_MODE_CONNECTOR_DisplayPort) {
+   if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
+   intel_encoder->type == INTEL_OUTPUT_UNKNOWN) {
+   intel_dp = enc_to_intel_dp(drm_enc);
+   status = displayport_parse_config(input_buffer,
+ len,
+ intel_dp);
+   if (status < 0)
+   goto out;
+   }
+   }
+   }
+out:
+   kfree(input_buffer);
+   if (status < 0)
+   return status;
+
+   *offp += len;
+   return len;
 }
 
 static const struct file_operations i915_displayport_config_ctl_fops = {
-- 
1.9.1

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

[Intel-gfx] [PATCH 06/17] drm/i915: Add support functions in debugfs for handling Displayport compliance configuration

[Todd Previte]

This patch was previously part of "[PATCH 05/10] drm/i915: Add debugfs interface
for Displayport debug  and compliance testing". Adds two support functions for
handling Displayport configuration parameters that are used for compliance
testing.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 48 +
 1 file changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index feae100..ce091c1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3694,6 +3694,54 @@ static const struct file_operations 
i915_display_crc_ctl_fops = {
.write = display_crc_ctl_write
 };
 
+enum dp_config_param displayport_get_config_param_type(char *input_string)
+{
+   enum dp_config_param param_type = DP_CONFIG_PARAM_INVALID;
+   int i = 0;
+
+   for (i = 0; i < DP_PARAMETER_COUNT; i++) {
+   if (strncmp(input_string, dp_conf_tokens[i],
+   strlen(dp_conf_tokens[i])) == 0) {
+   param_type = (enum dp_config_param) i;
+   break;
+   }
+   }
+   return param_type;
+}
+
+int value_for_config_param(enum dp_config_param param,
+  char *input_string,
+  void *output_value)
+{
+   int status = 0;
+   unsigned int *out_ptr = (unsigned int *)output_value;
+   char *index = input_string;
+
+   switch (param) {
+   case DP_CONFIG_PARAM_CONNECTOR:
+   output_value = (char *)index;
+   break;
+   case DP_CONFIG_PARAM_LINK_RATE:
+   case DP_CONFIG_PARAM_LANE_COUNT:
+   case DP_CONFIG_PARAM_VOLTAGE_SWING:
+   case DP_CONFIG_PARAM_PREEMPHASIS:
+   status = kstrtol(index, 16, (long *)out_ptr);
+   break;
+   case DP_CONFIG_PARAM_HRES:
+   case DP_CONFIG_PARAM_VRES:
+   case DP_CONFIG_PARAM_BPP:
+   status = kstrtol(index, 10, (long *)out_ptr);
+   break;
+   default:
+   /* Unhandled case */
+   status = -EINVAL;
+   *out_ptr = 0;
+   break;
+   }
+
+   return status;
+}
+
 static int displayport_config_ctl_open(struct inode *inode,
   struct file *file)
 {
-- 
1.9.1

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

[Intel-gfx] [PATCH 05/17] drm/i915: Add file ops for Displayport configuration in debugfs

[Todd Previte]

This patch was also part of "[PATCH 05/10] drm/i915: Add debugfs interface
for Displayport debug and compliance testing". Adds file operations structures
for Displayport configuration in debugfs for compliance testing. Also adds
the declarations for the open() and write() functions listed in the file ops
structure.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 65b4f5e..feae100 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3694,6 +3694,28 @@ static const struct file_operations 
i915_display_crc_ctl_fops = {
.write = display_crc_ctl_write
 };
 
+static int displayport_config_ctl_open(struct inode *inode,
+  struct file *file)
+{
+   return 0;
+}
+
+static ssize_t displayport_config_ctl_write(struct file *file,
+   const char __user *ubuf,
+   size_t len, loff_t *offp)
+{
+   return 0;
+}
+
+static const struct file_operations i915_displayport_config_ctl_fops = {
+   .owner = THIS_MODULE,
+   .open = displayport_config_ctl_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+   .write = displayport_config_ctl_write
+};
+
 static void wm_latency_show(struct seq_file *m, const uint16_t wm[8])
 {
struct drm_device *dev = m->private;
@@ -4446,6 +4468,7 @@ static const struct i915_debugfs_files {
{"i915_spr_wm_latency", &i915_spr_wm_latency_fops},
{"i915_cur_wm_latency", &i915_cur_wm_latency_fops},
{"i915_fbc_false_color", &i915_fbc_fc_fops},
+   {"i915_displayport_config_ctl", &i915_displayport_config_ctl_fops}
 };
 
 void intel_display_crc_init(struct drm_device *dev)
-- 
1.9.1

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

[Intel-gfx] [PATCH 07/17] drm/i915: Add and implement the debugfs 'show' functions for Displayport compliance

[Todd Previte]

This patch was previously part of "[PATCH 05/10] drm/i915: Add debugfs
interface for Displayport debug and compliance testing". This patch implements
the 'show' functions for the debugfs interface for Displayport compliance
testing.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 85 +
 1 file changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ce091c1..184797d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3694,6 +3694,56 @@ static const struct file_operations 
i915_display_crc_ctl_fops = {
.write = display_crc_ctl_write
 };
 
+static void displayport_show_config_info(struct seq_file *m,
+ struct intel_connector *intel_connector)
+{
+   struct intel_encoder *intel_encoder = intel_connector->encoder;
+   struct intel_dp *intel_dp;
+   struct intel_crtc *icrtc;
+   struct intel_crtc_config *crtc_config;
+   char *conn_name = intel_connector->base.name;
+   int pipe_bpp, hres, vres;
+   uint8_t vs[4], pe[4];
+   struct drm_display_mode *mode;
+   int i = 0;
+
+   if (intel_encoder) {
+   intel_dp = enc_to_intel_dp(&intel_encoder->base);
+   for (i = 0; i < intel_dp->lane_count; i++) {
+   vs[i] = intel_dp->train_set[i]
+   & DP_TRAIN_VOLTAGE_SWING_MASK;
+   pe[i] = (intel_dp->train_set[i]
+ & DP_TRAIN_PRE_EMPHASIS_MASK) >> 3;
+   }
+   if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT) {
+   if (intel_encoder->new_crtc) {
+   crtc_config = &intel_encoder->new_crtc->config;
+   pipe_bpp = crtc_config->pipe_bpp;
+   mode = &crtc_config->adjusted_mode;
+   hres = mode->hdisplay;
+   vres = mode->vdisplay;
+   } else if (intel_encoder->base.crtc) {
+   icrtc = to_intel_crtc(intel_encoder->base.crtc);
+   pipe_bpp = icrtc->config.pipe_bpp;
+   mode = &icrtc->config.adjusted_mode;
+   hres = mode->hdisplay;
+   vres = mode->vdisplay;
+   } else {
+   pipe_bpp = 0;
+   hres = vres = 0;
+   }
+   seq_printf(m, DP_CONF_STR_CONNECTOR, conn_name);
+   seq_printf(m, DP_CONF_STR_LINKRATE, intel_dp->link_bw);
+   seq_printf(m, DP_CONF_STR_LANES, intel_dp->lane_count);
+   seq_printf(m, DP_CONF_STR_VSWING, vs[0]);
+   seq_printf(m, DP_CONF_STR_PREEMP, pe[0]);
+   seq_printf(m, DP_CONF_STR_HRES, hres);
+   seq_printf(m, DP_CONF_STR_VRES, vres);
+   seq_printf(m, DP_CONF_STR_BPP, pipe_bpp);
+   }
+   }
+}
+
 enum dp_config_param displayport_get_config_param_type(char *input_string)
 {
enum dp_config_param param_type = DP_CONFIG_PARAM_INVALID;
@@ -3742,6 +3792,41 @@ int value_for_config_param(enum dp_config_param param,
return status;
 }
 
+static int displayport_config_ctl_show(struct seq_file *m, void *data)
+{
+   struct drm_device *dev = m->private;
+   struct drm_connector *drm_connector;
+   struct intel_encoder *encoder;
+   struct intel_connector *connector;
+
+   if (!dev)
+   return -ENODEV;
+
+   list_for_each_entry(drm_connector,
+   &dev->mode_config.connector_list,
+   head) {
+   connector = to_intel_connector(drm_connector);
+   encoder = connector->encoder;
+   if (drm_connector->connector_type ==
+   DRM_MODE_CONNECTOR_DisplayPort) {
+   if (encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
+   encoder->type == INTEL_OUTPUT_UNKNOWN) {
+   if (drm_connector->status ==
+   connector_status_connected) {
+   displayport_show_config_info(m,
+connector);
+   } else {
+   seq_printf(m, DP_CONF_STR_CONNECTOR,
+  encoder->base.name);
+   seq_puts(m, "disconnected\n");
+   }
+   }
+   }
+   }
+
+   return 0;
+}
+
 static int displayport_config_ctl_open(struct inode *inode,
 

[Intel-gfx] [PATCH 02/17] drm/i915: Update intel_dp_check_link_status() for Displayport compliance testing

[Todd Previte]

Move the DPCD read to the top and check for an interrupt from the sink to catch
Displayport automated testing requests necessary to support Displayport 
compliance
testing. The checks for active connectors and link status are moved below the
check for the interrupt.

Adds a check at the top to verify that the device is connected. This is 
necessary
for DP compliance testing to ensure that test requests are captured and 
acknowledged.
If a test request is present during a connected->disconnected transition,
the test code will attempt to execute even though the connection has been 
disabled,
resulting in a faied test.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3dc92a3..1b452cc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3890,21 +3890,14 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
 
-   if (!intel_encoder->connectors_active)
-   return;
-
-   if (WARN_ON(!intel_encoder->base.crtc))
-   return;
-
-   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
-   return;
-
-   /* Try to read receiver status if the link appears to be up */
-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+   /* Bail if not connected */
+   if (intel_dp->attached_connector->base.status !=
+   connector_status_connected) {
+   DRM_DEBUG_KMS("Not connected\n");
return;
}
 
-   /* Now read the DPCD to see if it's actually running */
+   /* Attempt to read the DPCD */
if (!intel_dp_get_dpcd(intel_dp)) {
return;
}
@@ -3916,13 +3909,26 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
drm_dp_dpcd_writeb(&intel_dp->aux,
   DP_DEVICE_SERVICE_IRQ_VECTOR,
   sink_irq_vector);
-
if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
intel_dp_handle_test_request(intel_dp);
if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
 
+   if (!intel_encoder->connectors_active)
+   return;
+
+   if (WARN_ON(!intel_encoder->base.crtc))
+   return;
+
+   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+   return;
+
+   /* Try to read receiver status if the link appears to be up */
+   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+   return;
+   }
+
if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
  intel_encoder->base.name);
-- 
1.9.1

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

[Intel-gfx] [PATCH 09/17] drm/i915: Add config parsing utilities in debugfs for Displayport compliance

[Todd Previte]

This patch was previously part of "[PATCH 05/10] drm/i915: Add debugfs
interface for Displayport debug and compliance testing". This patch adds two
functions to handle parsing of Displayport configuration information as it
formatted in the debugfs file. It is used to process incoming configuration
changes from the userspace compliance application during testing.

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 128 
 1 file changed, 128 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 184797d..55b6da5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3792,6 +3792,134 @@ int value_for_config_param(enum dp_config_param param,
return status;
 }
 
+int tokenize_dp_config(char *input_buffer, char *output[])
+{
+   char *base = input_buffer, *index, *end;
+   int line_count = 0;
+   int i = 0, len = 0;
+   int done = 0;
+
+   if (!input_buffer)
+   return 0;
+
+   while (!done) {
+   index = strpbrk(base, ":");
+   if (index) {
+   len = index - base;
+   *index = '\0';
+   index++;
+   /* Save the type string */
+   output[i] = base;
+   i++;
+   line_count++;
+   end = strpbrk(index, "\n\0");
+   if (end) {
+   *end = '\0';
+   /* Eat up whitespace */
+   while (*index <= 0x20)
+   index++;
+   output[i] = index;
+   i++;
+   line_count++;
+   } else
+   done = 1;
+   /* Move to the next section of the string */
+   base = end + 1;
+   } else
+   done = 1;
+   }
+   return line_count;
+}
+
+static int displayport_parse_config(char *input_buffer,
+   ssize_t buffer_size,
+   struct intel_dp *intel_dp)
+{
+   int status = 0;
+   char *lines[MAX_DP_CONFIG_LINE_COUNT];
+   int i = 0;
+   struct dp_config parms[DP_PARAMETER_COUNT];
+   int line_count = 0;
+   char *buffer = input_buffer;
+   enum dp_config_param parm_type;
+   unsigned long parm_value;
+
+   line_count = tokenize_dp_config(buffer, lines);
+
+   if (line_count == 0) {
+   DRM_DEBUG_DRIVER("No lines to process\n");
+   return 0;
+   }
+
+   for (i = 0; i < line_count; i += 2) {
+   parm_type = displayport_get_config_param_type(lines[i]);
+   if (parm_type != DP_CONFIG_PARAM_INVALID) {
+   status = value_for_config_param(parm_type,
+   lines[i+1],
+   &parm_value);
+   if (status == 0) {
+   parms[parm_type].type = parm_type;
+   parms[parm_type].value = parm_value;
+   }
+   }
+   }
+
+   if (parms[DP_CONFIG_PARAM_LINK_RATE].value == 0x06 ||
+   parms[DP_CONFIG_PARAM_LINK_RATE].value == 0x0a ||
+   parms[DP_CONFIG_PARAM_LINK_RATE].value == 0x14) {
+   intel_dp->compliance_config.link_rate =
+   parms[DP_CONFIG_PARAM_LINK_RATE].value;
+   } else
+   return -EINVAL;
+
+   if (parms[DP_CONFIG_PARAM_LANE_COUNT].value == 0x01 ||
+   parms[DP_CONFIG_PARAM_LANE_COUNT].value == 0x02 ||
+   parms[DP_CONFIG_PARAM_LANE_COUNT].value == 0x04) {
+   intel_dp->compliance_config.lane_count =
+   parms[DP_CONFIG_PARAM_LANE_COUNT].value;
+   } else
+   return -EINVAL;
+
+   if (parms[DP_CONFIG_PARAM_VOLTAGE_SWING].value <= 0x03 &&
+   parms[DP_CONFIG_PARAM_VOLTAGE_SWING].value >= 0x00) {
+   intel_dp->compliance_config.vswing_level =
+   parms[DP_CONFIG_PARAM_VOLTAGE_SWING].value;
+   } else
+   return -EINVAL;
+
+   if (parms[DP_CONFIG_PARAM_PREEMPHASIS].value <= 0x03 &&
+   parms[DP_CONFIG_PARAM_PREEMPHASIS].value >= 0x00) {
+   intel_dp->compliance_config.preemp_level =
+   parms[DP_CONFIG_PARAM_PREEMPHASIS].value;
+   } else
+   return -EINVAL;
+
+   if (parms[DP_CONFIG_PARAM_BPP].value == 18 ||
+   parms[DP_CONFIG_PARAM_BPP].value == 24 ||
+   parms[DP_CONFIG_PARAM_BPP].value == 30 ||
+   parms[DP_CONFIG_PARAM_BPP].value == 36) {
+   intel_dp->compliance_

[Intel-gfx] [PATCH 01/17] drm/i915: Add automated testing support for Displayport compliance testing

[Todd Previte]

Add the skeleton framework for supporting automation for Displayport compliance
testing. This patch adds the necessary framework for the source device to
appropriately respond to test automation requests from a sink device.

V2:
- Addressed previous mailing list feedback
- Fixed compilation issue (struct members declared in a later patch)
- Updated debug messages to be more accurate
- Added status checks for the DPCD read/write calls
- Removed excess comments and debug messages
- Fixed debug message compilation warnings
- Fixed compilation issue with missing variables
- Updated link training autotest to ACK

Signed-off-by: Todd Previte 
---
 drivers/gpu/drm/i915/intel_dp.c  | 72 +---
 drivers/gpu/drm/i915/intel_drv.h |  4 +++
 2 files changed, 72 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3fc3296..3dc92a3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3744,11 +3744,75 @@ intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 
*sink_irq_vector)
return true;
 }
 
-static void
-intel_dp_handle_test_request(struct intel_dp *intel_dp)
+static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
+{
+   uint8_t test_result = DP_TEST_ACK;
+   return test_result;
+}
+
+static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
+{
+   uint8_t test_result = DP_TEST_NAK;
+   return test_result;
+}
+
+static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
+{
+   uint8_t test_result = DP_TEST_NAK;
+   return test_result;
+}
+
+static uint8_t intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
+{
+   uint8_t test_result = DP_TEST_NAK;
+   return test_result;
+}
+
+static void intel_dp_handle_test_request(struct intel_dp *intel_dp)
 {
-   /* NAK by default */
-   drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_RESPONSE, DP_TEST_NAK);
+   uint8_t response = DP_TEST_NAK;
+   uint8_t rxdata = 0;
+   int status = 0;
+
+   status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_REQUEST, &rxdata, 1);
+   if (status != 0) {
+   response = DP_TEST_NAK;
+   DRM_DEBUG_KMS("Could not read test request from sink\n");
+   return;
+   }
+
+   switch (rxdata) {
+   case DP_TEST_LINK_TRAINING:
+   DRM_DEBUG_KMS("LINK_TRAINING test requested\n");
+   response = intel_dp_autotest_link_training(intel_dp);
+   break;
+   case DP_TEST_LINK_VIDEO_PATTERN:
+   DRM_DEBUG_KMS("TEST_PATTERN test requested\n");
+   response = intel_dp_autotest_video_pattern(intel_dp);
+   break;
+   case DP_TEST_LINK_EDID_READ:
+   DRM_DEBUG_KMS("EDID test requested\n");
+   response = intel_dp_autotest_edid(intel_dp);
+   break;
+   case DP_TEST_LINK_PHY_TEST_PATTERN:
+   DRM_DEBUG_KMS("PHY_PATTERN test requested\n");
+   response = intel_dp_autotest_phy_pattern(intel_dp);
+   break;
+   /* FAUX is optional in DP 1.2*/
+   case DP_TEST_LINK_FAUX_PATTERN:
+   DRM_DEBUG_KMS("FAUX_PATTERN testing not supported\n");
+   break;
+   default:
+   DRM_DEBUG_KMS("Invalid test request '%02x'\n", rxdata);
+   break;
+   }
+   status = drm_dp_dpcd_write(&intel_dp->aux,
+  DP_TEST_RESPONSE,
+  &response, 1);
+   if (status != 0)
+   DRM_DEBUG_KMS("Could not write test response to sink\n");
+
+   intel_dp->compliance_testing_active = 0;
 }
 
 static int
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 588b618..d1a807a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -638,6 +638,10 @@ struct intel_dp {
struct mutex mutex;
} drrs_state;
 
+   /* Displayport compliance testing */
+   unsigned long compliance_test_data;
+   bool compliance_testing_active;
+
 };
 
 struct intel_digital_port {
-- 
1.9.1

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

[Intel-gfx] [intel-gfx] Displayport Compliance Testing V2

[Todd Previte]

This is version 2 of the patch set for Displayport compliance testing support 
in the i915 driver. This implementation of compliance testing conforms to the 
VESA specification Displayport Link Compliance Testing Specification (Link CTS)
1.2 Core Rev1.1. The code has been partitioned into two segments - the kernel 
side comprised of this patch set and a userspace application that handles the 
heavy lifting for necessary mode sets. It can also handle link configuration
changes if necessary.

Overview Changes for V2:
- Removed the kernel<->userpsace signal mechanism for communication during 
testing. The
  original code used signals for communication between the kernel and userspace 
which met
  with significant resistance during review. That mechanism has been removed in 
favor of
  a file polling mechanism that contains the necessary data for the user app to 
properly
  communicate with the kernel during compliance testing.
- Review feedback from as far back as July has been rolled up and integrated 
into this
  patch set where necessary/applicable. For those cases, the feedback has been 
directly
  noted in the commit message
- Some patches have been either moved or deleted from the set as they have gone 
through
  the review cycle. Where this has occurred, it has been noted in the commit 
message.


drm/i915: Add debugfs write and test param parsing function for DP test control
drm/i915: Add new debugfs file for Displaypor compliance test control
drm/i915: Update debugfs functions for Displayport compliance testing
drm/i915: Add debugfs function to check connector status for compliance testing
drm/i915: Update intel_dp_hpd_pulse() to check link status for non-MST operation
drm/i915: Update intel_dp_compute_config() to handle compliance test requests
drm/i915: Update the EDID automated compliance test function
drm/i915: Implement the 'open' and 'write' debugfs functions for Displayport 
compliance
drm/i915: Add config parsing utilities in debugfs for Displayport compliance
drm/i915: Add Displayport link configuration structure
drm/i915: Add and implement the debugfs 'show' functions for Displayport 
compliance
drm/i915: Add support functions in debugfs for handling Displayport compliance 
configuration
drm/i915: Add file ops for Displayport configuration in debugfs
drm/i915: Add debugfs information for Displayport compliance testing
drm/i915: Add a delay in Displayport AUX transactions for compliance testing
drm/i915: Update intel_dp_check_link_status() for Displayport compliance testing
drm/i915: Add automated testing support for Displayport compliance testing

 drivers/gpu/drm/i915/i915_debugfs.c | 569 +++
 drivers/gpu/drm/i915/intel_dp.c | 219 ++--
 drivers/gpu/drm/i915/intel_drv.h|  19 ++
 3 files changed, 779 insertions(+), 28 deletions(-)

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Track nested calls to intel(_logical)_ring_{begin, advance}

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV -2  364/364  362/364
ILK -11  364/366  353/366
SNB -13  448/450  435/450
IVB -11  497/498  486/498
BYT -5  289/289  284/289
HSW -10  563/564  553/564
BDW -7  417/417  410/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*PNV  igt_gem_ringfill_blitter  PASS(3, M23M25)  DMESG_WARN(1, M25)
*PNV  igt_gem_ringfill_blitter-interruptible  PASS(3, M23M25)  
DMESG_WARN(1, M25)
*ILK  igt_gem_concurrent_blit_gpu-bcs-gpu-read-after-write-interruptible  
PASS(2, M26)  DMESG_WARN(1, M26)
*ILK  igt_gem_concurrent_blit_gpu-bcs-overwrite-source-interruptible  
PASS(2, M26)  DMESG_WARN(1, M26)
*ILK  igt_gem_concurrent_blit_gpuX-bcs-gpu-read-after-write-interruptible  
PASS(2, M26)  DMESG_WARN(1, M26)
*ILK  igt_gem_concurrent_blit_gpuX-bcs-overwrite-source-interruptible  
PASS(2, M26)  DMESG_WARN(1, M26)
*ILK  igt_gem_concurrent_blit_prw-bcs-gpu-read-after-write-interruptible  
PASS(2, M26)  DMESG_WARN(1, M26)
*ILK  igt_kms_flip_nonexisting-fb  DMESG_WARN(1, M26)PASS(4, M26)  
NSPT(1, M26)
*ILK  igt_gem_concurrent_blit_gtt-bcs-gpu-read-after-write-interruptible  
PASS(2, M26)  DMESG_WARN(1, M26)
*ILK  igt_gem_concurrent_blit_gttX-bcs-gpu-read-after-write-interruptible  
PASS(2, M26)  DMESG_WARN(1, M26)
*ILK  igt_gem_ringfill_blitter  PASS(2, M26)  DMESG_WARN(1, M26)
*ILK  igt_gem_ringfill_blitter-interruptible  PASS(2, M26)  
DMESG_WARN(1, M26)
*ILK  igt_kms_flip_bcs-flip-vs-modeset-interruptible  PASS(5, M26)  
DMESG_WARN(1, M26)
*SNB  igt_gem_concurrent_blit_cpu-rcs-gpu-read-after-write-interruptible  
PASS(3, M35M22)  DMESG_WARN(1, M22)
*SNB  igt_gem_concurrent_blit_gpu-rcs-gpu-read-after-write-forked  PASS(3, 
M35M22)  DMESG_WARN(1, M22)
*SNB  igt_gem_concurrent_blit_gpu-rcs-gpu-read-after-write-interruptible  
PASS(3, M35M22)  DMESG_WARN(1, M22)
*SNB  igt_gem_concurrent_blit_gpuX-rcs-gpu-read-after-write-forked  PASS(2, 
M35M22)  DMESG_WARN(1, M22)
*SNB  igt_gem_concurrent_blit_gpuX-rcs-gpu-read-after-write-interruptible  
PASS(3, M35M22)  DMESG_WARN(1, M22)
*SNB  igt_gem_concurrent_blit_prw-rcs-gpu-read-after-write-forked  PASS(3, 
M35M22)  DMESG_WARN(1, M22)
*SNB  igt_gem_concurrent_blit_prw-rcs-gpu-read-after-write-interruptible  
PASS(3, M35M22)  DMESG_WARN(1, M22)
*SNB  igt_gem_ring_sync_copy_sync-render-blitter-read-write  PASS(3, 
M35M22)  DMESG_WARN(1, M22)
*SNB  igt_gem_ring_sync_copy_sync-render-blitter-write-read  PASS(3, 
M35M22)  DMESG_WARN(1, M22)
*SNB  igt_gem_ring_sync_copy_sync-render-blitter-write-write  PASS(3, 
M35M22)  DMESG_WARN(1, M22)
*SNB  igt_gem_userptr_blits_coherency-sync  PASS(3, M35M22)  
DMESG_WARN(1, M22)
*SNB  igt_pm_rps_min-max-config-loaded  PASS(3, M35M22)  DMESG_WARN(1, 
M22)
*SNB  igt_gem_concurrent_blit_gtt-rcs-gpu-read-after-write-interruptible  
PASS(3, M35M22)  DMESG_WARN(1, M22)
*IVB  igt_gem_linear_blits_interruptible  PASS(3, M4M34)  DMESG_WARN(1, 
M34)
*IVB  igt_gem_linear_blits_normal  PASS(3, M4M34)  DMESG_WARN(1, M34)
*IVB  igt_gem_render_linear_blits  PASS(3, M4M34)  DMESG_WARN(1, M34)
*IVB  igt_gem_render_tiled_blits  PASS(3, M4M34)  DMESG_WARN(1, M34)
*IVB  igt_gem_tiled_blits_interruptible  PASS(3, M4M34)  DMESG_WARN(1, 
M34)
*IVB  igt_gem_tiled_blits_normal  PASS(3, M4M34)  DMESG_WARN(1, M34)
*IVB  igt_gem_tiled_fence_blits  PASS(3, M4M34)  DMESG_WARN(1, M34)
*IVB  igt_gem_userptr_blits_coherency-sync  PASS(2, M4M34)  
DMESG_WARN(1, M34)
*IVB  igt_gem_userptr_blits_coherency-unsync  PASS(2, M4M34)  
DMESG_WARN(1, M34)
*IVB  igt_gem_ringfill_blitter  PASS(3, M4M34)  DMESG_WARN(1, M34)
*IVB  igt_gem_ringfill_blitter-interruptible  PASS(3, M4M34)  
DMESG_WARN(1, M34)
*BYT  igt_gem_gtt_hog  PASS(3, M48M51)  DMESG_WARN(1, M51)
*BYT  igt_gem_ringfill_blitter  PASS(3, M48M51)  DMESG_WARN(1, M51)
*BYT  igt_gem_ringfill_blitter-interruptible  PASS(3, M48M51)  
DMESG_WARN(1, M51)
*BYT  igt_gem_ringfill_render  PASS(3, M48M51)  DMESG_WARN(1, M51)
*BYT  igt_gem_ringfill_render-interruptible  PASS(3, M48M51)  
DMESG_WARN(1, M51)
*HSW  igt_gem_linear_blits_interruptible  PASS(3, M40M20)  
DMESG_WARN(1, 

[Intel-gfx] [PATCH] drm/i915/i9xx: check for panel on pipe before asserting panel unlock bits

[Jesse Barnes]

Should address a warning reported in #79824.

References: https://bugs.freedesktop.org/show_bug.cgi?id=79824
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/intel_display.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c424c36..a19544b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1607,7 +1607,9 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
BUG_ON(INTEL_INFO(dev)->gen >= 5);
 
/* PLL is protected by panel, make sure we can write it */
-   if (IS_MOBILE(dev) && !IS_I830(dev))
+   if (IS_MOBILE(dev) && !IS_I830(dev) &&
+   (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
+intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP)))
assert_panel_unlocked(dev_priv, crtc->pipe);
 
/* Enable DVO 2x clock on both PLLs if necessary */
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1 364/366  365/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(3, M26)PASS(18, M26M37)   
   PASS(1, M37)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: save/restore GMBUS freq across suspend/resume on gen4

[Jesse Barnes]

On Wed, 10 Dec 2014 22:35:37 +0200
Ville Syrjälä  wrote:

> On Wed, Dec 10, 2014 at 12:16:05PM -0800, Jesse Barnes wrote:
> > Should probably just init this in the GMbus code all the time,
> > based on the cdclk and HPLL like we do on newer platforms.  Ville
> > has code for that in a rework branch, but until then we can fix
> > this bug fairly easily.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=76301
> > Signed-off-by: Jesse Barnes 
> 
> My cdclk extraction code doesn't seem to agree with this register for
> this particular bug reporter at least. So I think I need to go double
> check my code. The other options are that GMBUS clock isn't derived
> from cdclk on that platform, or that the HPLL/cdclk bits in configdb
> are simply not valid for this particular chipset.
> 
> In the meantime however, we can at least get some machines working
> with this patch. I'm not entirely sure which platforms have this
> register, but IS_GEN4() looks safe enough since my 946GZ has it and
> the reporter has a G41.
> 
> Reviewed-by: Ville Syrjälä 

Great, thanks.  Jani, can you pick this up?  I'll bounce the original
over to stable@ too.

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

[Intel-gfx] [PATCH 7/8] drm/i915: Enable eDP DRRS for CHV

[Vandana Kannan]

From: Durgadoss R 

This patch enables eDP DRRS for CHV by adding the
required IS_CHERRYVIEW() checks.
CHV uses the same register bit as VLV.

[Vandana]: Since CHV has 2 sets of M_N registers, it will follow the same code
path as gen < 8. Added CHV check in dp_set_m_n()

Signed-off-by: Durgadoss R 
Signed-off-by: Vandana Kannan 
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 drivers/gpu/drm/i915/intel_dp.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 411d34e..07a6abf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5810,8 +5810,8 @@ void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
 * for gen < 8) and if DRRS is supported (to make sure the
 * registers are not unnecessarily accessed).
 */
-   if (m2_n2 && INTEL_INFO(dev)->gen < 8 &&
-   crtc->config.has_drrs) {
+   if (m2_n2 && (IS_CHERRYVIEW(dev) || INTEL_INFO(dev)->gen < 8)
+   && crtc->config.has_drrs) {
I915_WRITE(PIPE_DATA_M2(transcoder),
TU_SIZE(m2_n2->tu) | m2_n2->gmch_m);
I915_WRITE(PIPE_DATA_N2(transcoder), m2_n2->gmch_n);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ef8fa94..092ef91 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4802,7 +4802,7 @@ static void intel_dp_set_drrs_state(struct drm_device 
*dev, int refresh_rate)
return;
}
 
-   if (INTEL_INFO(dev)->gen >= 8) {
+   if (INTEL_INFO(dev)->gen >= 8 && !IS_CHERRYVIEW(dev)) {
switch(index) {
case DRRS_HIGH_RR:
intel_dp_set_m_n(intel_crtc);
-- 
2.0.1

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

[Intel-gfx] [PATCH 2/8] drm/i915: Initialize DRRS delayed work

[Vandana Kannan]

Add DRRS work function to trigger a switch to low refresh rate when activity
is detected on screen.

Signed-off-by: Vandana Kannan 
---
 drivers/gpu/drm/i915/intel_dp.c | 36 
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 96d8e17..ef8b55d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4814,20 +4814,38 @@ static void intel_dp_set_drrs_state(struct drm_device 
*dev, int refresh_rate)
I915_WRITE(reg, val);
}
 
+   dev_priv->drrs.refresh_rate_type = index;
+
+   DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate);
+}
+
+static void intel_edp_drrs_work(struct work_struct *work)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(work, typeof(*dev_priv), drrs.work.work);
+   struct intel_dp *intel_dp = dev_priv->drrs.dp;
+
+   mutex_lock(&dev_priv->drrs.mutex);
+
+   if (!intel_dp)
+   goto unlock;
+
/*
-* mutex taken to ensure that there is no race between differnt
-* drrs calls trying to update refresh rate. This scenario may occur
-* in future when idleness detection based DRRS in kernel and
-* possible calls from user space to set differnt RR are made.
+* The delayed work can race with an invalidate hence we need to
+* recheck.
 */
 
-   mutex_lock(&dev_priv->drrs.mutex);
+   if (dev_priv->drrs.busy_frontbuffer_bits)
+   goto unlock;
 
-   dev_priv->drrs.refresh_rate_type = index;
+   if (dev_priv->drrs.refresh_rate_type != DRRS_LOW_RR)
+   intel_dp_set_drrs_state(dev_priv->dev,
+   intel_dp->attached_connector->panel.
+   downclock_mode->vrefresh);
 
-   mutex_unlock(&dev_priv->drrs.mutex);
+unlock:
 
-   DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate);
+   mutex_unlock(&dev_priv->drrs.mutex);
 }
 
 static struct drm_display_mode *
@@ -4857,6 +4875,8 @@ intel_dp_drrs_init(struct intel_connector 
*intel_connector,
return NULL;
}
 
+   INIT_DELAYED_WORK(&dev_priv->drrs.work, intel_edp_drrs_work);
+
mutex_init(&dev_priv->drrs.mutex);
 
dev_priv->drrs.type = dev_priv->vbt.drrs_type;
-- 
2.0.1

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

Re: [Intel-gfx] [PATCH] drm/i915: save/restore GMBUS freq across suspend/resume on gen4

[Ville Syrjälä]

On Wed, Dec 10, 2014 at 12:16:05PM -0800, Jesse Barnes wrote:
> Should probably just init this in the GMbus code all the time, based on
> the cdclk and HPLL like we do on newer platforms.  Ville has code for
> that in a rework branch, but until then we can fix this bug fairly
> easily.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=76301
> Signed-off-by: Jesse Barnes 

My cdclk extraction code doesn't seem to agree with this register for
this particular bug reporter at least. So I think I need to go double
check my code. The other options are that GMBUS clock isn't derived from
cdclk on that platform, or that the HPLL/cdclk bits in configdb are
simply not valid for this particular chipset.

In the meantime however, we can at least get some machines working with
this patch. I'm not entirely sure which platforms have this register,
but IS_GEN4() looks safe enough since my 946GZ has it and the reporter
has a G41.

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 1 +
>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>  drivers/gpu/drm/i915/i915_suspend.c | 8 
>  3 files changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2725243..f33102b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -925,6 +925,7 @@ struct i915_suspend_saved_registers {
>   u32 savePIPEB_LINK_N1;
>   u32 saveMCHBAR_RENDER_STANDBY;
>   u32 savePCH_PORT_HOTPLUG;
> + u16 saveGCDGMBUS;
>  };
>  
>  struct vlv_s0ix_state {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index dc03fac..f7c2856 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -76,6 +76,7 @@
>  #define   I915_GC_RENDER_CLOCK_166_MHZ   (0 << 0)
>  #define   I915_GC_RENDER_CLOCK_200_MHZ   (1 << 0)
>  #define   I915_GC_RENDER_CLOCK_333_MHZ   (4 << 0)
> +#define GCDGMBUS 0xcc
>  #define PCI_LBPC 0xf4 /* legacy/combination backlight modes, also called LBB 
> */
>  
>  
> diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
> b/drivers/gpu/drm/i915/i915_suspend.c
> index dfe6617..2636882 100644
> --- a/drivers/gpu/drm/i915/i915_suspend.c
> +++ b/drivers/gpu/drm/i915/i915_suspend.c
> @@ -303,6 +303,10 @@ int i915_save_state(struct drm_device *dev)
>   }
>   }
>  
> + if (IS_GEN4(dev))
> + pci_read_config_word(dev->pdev, GCDGMBUS,
> +  &dev_priv->regfile.saveGCDGMBUS);
> +
>   /* Cache mode state */
>   if (INTEL_INFO(dev)->gen < 7)
>   dev_priv->regfile.saveCACHE_MODE_0 = I915_READ(CACHE_MODE_0);
> @@ -331,6 +335,10 @@ int i915_restore_state(struct drm_device *dev)
>   mutex_lock(&dev->struct_mutex);
>  
>   i915_gem_restore_fences(dev);
> +
> + if (IS_GEN4(dev))
> + pci_write_config_word(dev->pdev, GCDGMBUS,
> +   dev_priv->regfile.saveGCDGMBUS);
>   i915_restore_display(dev);
>  
>   if (!drm_core_check_feature(dev, DRIVER_MODESET)) {
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH 1/8] drm/i915: Modifying structures related to DRRS

[Vandana Kannan]

Earlier, DRRS structures were specific to eDP (used only in intel_dp).
Since DRRS can be extended to other internal display types
(if the panel supports multiple RR), modifying structures
to be part of drm_i915_private and have a provision to add display related
structs like intel_dp.
Also, aligning with frontbuffer tracking mechanism, the new structure
contains data for busy frontbuffer bits.

Signed-off-by: Vandana Kannan 
---
 drivers/gpu/drm/i915/i915_drv.h  | 32 ++---
 drivers/gpu/drm/i915/intel_dp.c  | 50 ++--
 drivers/gpu/drm/i915/intel_drv.h | 18 ---
 3 files changed, 47 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 11e85cb..370cbaa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -730,11 +730,33 @@ struct i915_fbc {
} no_fbc_reason;
 };
 
-struct i915_drrs {
-   struct intel_connector *connector;
+/**
+ * HIGH_RR is the highest eDP panel refresh rate read from EDID
+ * LOW_RR is the lowest eDP panel refresh rate found from EDID
+ * parsing for same resolution.
+ */
+enum drrs_refresh_rate_type {
+   DRRS_HIGH_RR,
+   DRRS_LOW_RR,
+   DRRS_MAX_RR, /* RR count */
+};
+
+enum drrs_support_type {
+   DRRS_NOT_SUPPORTED = 0,
+   STATIC_DRRS_SUPPORT = 1,
+   SEAMLESS_DRRS_SUPPORT = 2
 };
 
 struct intel_dp;
+struct i915_drrs {
+   struct mutex mutex;
+   struct delayed_work work;
+   struct intel_dp *dp;
+   unsigned busy_frontbuffer_bits;
+   enum drrs_refresh_rate_type refresh_rate_type;
+   enum drrs_support_type type;
+};
+
 struct i915_psr {
struct mutex lock;
bool sink_support;
@@ -1300,12 +1322,6 @@ struct ddi_vbt_port_info {
uint8_t supports_dp:1;
 };
 
-enum drrs_support_type {
-   DRRS_NOT_SUPPORTED = 0,
-   STATIC_DRRS_SUPPORT = 1,
-   SEAMLESS_DRRS_SUPPORT = 2
-};
-
 enum psr_lines_to_wait {
PSR_0_LINES_TO_WAIT = 0,
PSR_1_LINE_TO_WAIT,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3fc3296..96d8e17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1269,7 +1269,7 @@ found:
   &pipe_config->dp_m_n);
 
if (intel_connector->panel.downclock_mode != NULL &&
-   intel_dp->drrs_state.type == SEAMLESS_DRRS_SUPPORT) {
+   dev_priv->drrs.type == SEAMLESS_DRRS_SUPPORT) {
pipe_config->has_drrs = true;
intel_link_compute_m_n(bpp, lane_count,
intel_connector->panel.downclock_mode->clock,
@@ -4745,24 +4745,24 @@ intel_dp_init_panel_power_sequencer_registers(struct 
drm_device *dev,
  I915_READ(pp_div_reg));
 }
 
-void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate)
+static void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *encoder;
-   struct intel_dp *intel_dp = NULL;
+   struct intel_digital_port *dig_port = NULL;
+   struct intel_dp *intel_dp = dev_priv->drrs.dp;
struct intel_crtc_config *config = NULL;
struct intel_crtc *intel_crtc = NULL;
-   struct intel_connector *intel_connector = dev_priv->drrs.connector;
u32 reg, val;
-   enum edp_drrs_refresh_rate_type index = DRRS_HIGH_RR;
+   enum drrs_refresh_rate_type index = DRRS_HIGH_RR;
 
if (refresh_rate <= 0) {
DRM_DEBUG_KMS("Refresh rate should be positive non-zero.\n");
return;
}
 
-   if (intel_connector == NULL) {
-   DRM_DEBUG_KMS("DRRS supported for eDP only.\n");
+   if (intel_dp == NULL) {
+   DRM_DEBUG_KMS("DRRS not supported.\n");
return;
}
 
@@ -4771,8 +4771,8 @@ void intel_dp_set_drrs_state(struct drm_device *dev, int 
refresh_rate)
 * platforms that cannot have PSR and DRRS enabled at the same time.
 */
 
-   encoder = intel_attached_encoder(&intel_connector->base);
-   intel_dp = enc_to_intel_dp(&encoder->base);
+   dig_port = dp_to_dig_port(intel_dp);
+   encoder = &dig_port->base;
intel_crtc = encoder->new_crtc;
 
if (!intel_crtc) {
@@ -4782,15 +4782,16 @@ void intel_dp_set_drrs_state(struct drm_device *dev, 
int refresh_rate)
 
config = &intel_crtc->config;
 
-   if (intel_dp->drrs_state.type < SEAMLESS_DRRS_SUPPORT) {
+   if (dev_priv->drrs.type < SEAMLESS_DRRS_SUPPORT) {
DRM_DEBUG_KMS("Only Seamless DRRS supported.\n");
return;
}
 
-   if (intel_connector->panel.downclock_mode->vrefresh == refresh_rate)
+   if (intel_dp->attached_connector->panel.downclock_mode->vrefresh ==
+   refresh_rate)
index 

[Intel-gfx] [PATCH 8/8] drm/i915: Add drrs_interval module parameter

[Vandana Kannan]

Adding i915 module parameter for setting drrs_interval. If this param is
set to 0, then drrs is disabled. If changed in runtime, then the new interval
value will be considered for scheduling the next drrs work.
drrs_interval is set to 0 by default, i.e. DRRS is disabled by default.

Signed-off-by: Vandana Kannan 
---
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_params.c |  8 
 drivers/gpu/drm/i915/intel_dp.c| 11 ++-
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 370cbaa..dba5844 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2381,6 +2381,7 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
+   int drrs_interval;
/* leave bools at the end to not create holes */
bool enable_hangcheck;
bool fastboot;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index c91cb20..80492e8 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -51,6 +51,7 @@ struct i915_params i915 __read_mostly = {
.disable_vtd_wa = 0,
.use_mmio_flip = 0,
.mmio_debug = 0,
+   .drrs_interval = 0,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -173,3 +174,10 @@ module_param_named(mmio_debug, i915.mmio_debug, bool, 
0600);
 MODULE_PARM_DESC(mmio_debug,
"Enable the MMIO debug code (default: false). This may negatively "
"affect performance.");
+
+module_param_named(drrs_interval, i915.drrs_interval, int, 0600);
+MODULE_PARM_DESC(drrs_interval,
+   "DRRS idleness detection interval  (default: 0 ms). "
+   "If this field is set to 0, then seamless DRRS feature "
+   "based on idleness detection is disabled. "
+   "The interval is to be set in milliseconds.");
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 092ef91..88f46906 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4931,6 +4931,9 @@ void intel_edp_drrs_invalidate(struct drm_device *dev,
if (!dev_priv->drrs.dp)
return;
 
+   if (i915.drrs_interval == 0)
+   return;
+
mutex_lock(&dev_priv->drrs.mutex);
crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
pipe = to_intel_crtc(crtc)->pipe;
@@ -4958,6 +4961,9 @@ void intel_edp_drrs_flush(struct drm_device *dev,
if (!dev_priv->drrs.dp)
return;
 
+   if (i915.drrs_interval == 0)
+   return;
+
mutex_lock(&dev_priv->drrs.mutex);
crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
pipe = to_intel_crtc(crtc)->pipe;
@@ -4968,7 +4974,7 @@ void intel_edp_drrs_flush(struct drm_device *dev,
if (dev_priv->drrs.refresh_rate_type != DRRS_LOW_RR &&
!dev_priv->drrs.busy_frontbuffer_bits)
schedule_delayed_work(&dev_priv->drrs.work,
-   msecs_to_jiffies(1000));
+   msecs_to_jiffies(i915.drrs_interval));
mutex_unlock(&dev_priv->drrs.mutex);
 }
 
@@ -4991,6 +4997,9 @@ intel_dp_drrs_init(struct intel_connector 
*intel_connector,
return NULL;
}
 
+   if (i915.drrs_interval == 0)
+   DRM_DEBUG_KMS("DRRS disable by flag\n");
+
downclock_mode = intel_find_panel_downclock
(dev, fixed_mode, connector);
 
-- 
2.0.1

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

[Intel-gfx] [PATCH 5/8] drm/i915/bdw: Add support for DRRS to switch RR

[Vandana Kannan]

For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will be used in the next frame
that is output.

Signed-off-by: Vandana Kannan 
Signed-off-by: Pradeep Bhat 
---
 drivers/gpu/drm/i915/intel_display.c |  9 +++--
 drivers/gpu/drm/i915/intel_dp.c  | 15 ++-
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a4a565c..411d34e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,9 +88,6 @@ static int intel_framebuffer_init(struct drm_device *dev,
  struct drm_i915_gem_object *obj);
 static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc);
 static void intel_set_pipe_timings(struct intel_crtc *intel_crtc);
-static void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
-struct intel_link_m_n *m_n,
-struct intel_link_m_n *m2_n2);
 static void ironlake_set_pipeconf(struct drm_crtc *crtc);
 static void haswell_set_pipeconf(struct drm_crtc *crtc);
 static void intel_set_pipe_csc(struct drm_crtc *crtc);
@@ -5795,9 +5792,9 @@ static void intel_pch_transcoder_set_m_n(struct 
intel_crtc *crtc,
I915_WRITE(PCH_TRANS_LINK_N1(pipe), m_n->link_n);
 }
 
-static void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
-struct intel_link_m_n *m_n,
-struct intel_link_m_n *m2_n2)
+void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
+struct intel_link_m_n *m_n,
+struct intel_link_m_n *m2_n2)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bc17900..38d61f2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4802,7 +4802,20 @@ static void intel_dp_set_drrs_state(struct drm_device 
*dev, int refresh_rate)
return;
}
 
-   if (INTEL_INFO(dev)->gen > 6 && INTEL_INFO(dev)->gen < 8) {
+   if (INTEL_INFO(dev)->gen >= 8) {
+   switch(index) {
+   case DRRS_HIGH_RR:
+   intel_dp_set_m_n(intel_crtc);
+   break;
+   case DRRS_LOW_RR:
+   intel_cpu_transcoder_set_m_n(intel_crtc,
+   &intel_crtc->config.dp_m2_n2, NULL);
+   break;
+   case DRRS_MAX_RR:
+   default:
+   break;
+   }
+   } else if (INTEL_INFO(dev)->gen > 6) {
reg = PIPECONF(intel_crtc->config.cpu_transcoder);
val = I915_READ(reg);
if (index > DRRS_HIGH_RR) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 763c097..bdfdea8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -952,6 +952,9 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv);
 void intel_dp_get_m_n(struct intel_crtc *crtc,
  struct intel_crtc_config *pipe_config);
 void intel_dp_set_m_n(struct intel_crtc *crtc);
+void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
+struct intel_link_m_n *m_n,
+struct intel_link_m_n *m2_n2);
 int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
 void
 ironlake_check_encoder_dotclock(const struct intel_crtc_config *pipe_config,
-- 
2.0.1

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

[Intel-gfx] [PATCH 6/8] drm/i915: Support for RR switching on VLV

[Vandana Kannan]

Definition of VLV RR switch bit and corresponding toggling in
set_drrs function.

Signed-off-by: Vandana Kannan 
Signed-off-by: Uma Shankar 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h |  1 +
 drivers/gpu/drm/i915/intel_dp.c | 10 --
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 78d89a7..16b426d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3821,6 +3821,7 @@ enum punit_power_well {
 #define   PIPECONF_INTERLACE_MODE_MASK (7 << 21)
 #define   PIPECONF_EDP_RR_MODE_SWITCH  (1 << 20)
 #define   PIPECONF_CXSR_DOWNCLOCK  (1<<16)
+#define   PIPECONF_EDP_RR_MODE_SWITCH_VLV  (1 << 14)
 #define   PIPECONF_COLOR_RANGE_SELECT  (1 << 13)
 #define   PIPECONF_BPC_MASK(0x7 << 5)
 #define   PIPECONF_8BPC(0<<5)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 38d61f2..ef8fa94 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4819,10 +4819,16 @@ static void intel_dp_set_drrs_state(struct drm_device 
*dev, int refresh_rate)
reg = PIPECONF(intel_crtc->config.cpu_transcoder);
val = I915_READ(reg);
if (index > DRRS_HIGH_RR) {
-   val |= PIPECONF_EDP_RR_MODE_SWITCH;
+   if (IS_VALLEYVIEW(dev))
+   val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
+   else
+   val |= PIPECONF_EDP_RR_MODE_SWITCH;
intel_dp_set_m_n(intel_crtc);
} else {
-   val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
+   if (IS_VALLEYVIEW(dev))
+   val &= ~PIPECONF_EDP_RR_MODE_SWITCH_VLV;
+   else
+   val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
}
I915_WRITE(reg, val);
}
-- 
2.0.1

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

[Intel-gfx] [PATCH 4/8] drm/i915: DRRS calls based on frontbuffer

[Vandana Kannan]

Calls have been added to invalidate/flush DRRS whenever invalidate/flush is
called as part of frontbuffer tracking.
Apart from calls as a result of GEM tracking to fb invalidate/flush, a
call has been added to invalidate fb obj from crtc_page_flip as well. This
is to track busyness through flip calls.
The call to fb_obj_invalidate (in flip) is placed before queuing flip for this
obj.

drrs_invalidate() and drrs_flush() check for drrs.dp which would be NULL if
it was setup in drrs_enable(). This covers for the condition when DRRS is
not supported.

Signed-off-by: Vandana Kannan 
---
 drivers/gpu/drm/i915/intel_display.c |  8 +++--
 drivers/gpu/drm/i915/intel_dp.c  | 51 
 drivers/gpu/drm/i915/intel_drv.h |  3 ++
 drivers/gpu/drm/i915/intel_frontbuffer.c |  2 ++
 4 files changed, 61 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a9bdc12..a4a565c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9717,6 +9717,11 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
if (ret)
goto cleanup_pending;
 
+   i915_gem_track_fb(work->old_fb_obj, obj,
+ INTEL_FRONTBUFFER_PRIMARY(pipe));
+
+   intel_fb_obj_invalidate(obj, ring);
+
work->gtt_offset =
i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
 
@@ -9741,9 +9746,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
work->flip_queued_vblank = drm_vblank_count(dev, intel_crtc->pipe);
work->enable_stall_check = true;
 
-   i915_gem_track_fb(work->old_fb_obj, obj,
- INTEL_FRONTBUFFER_PRIMARY(pipe));
-
intel_disable_fbc(dev);
intel_frontbuffer_flip_prepare(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7098470..bc17900 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4902,6 +4902,57 @@ unlock:
mutex_unlock(&dev_priv->drrs.mutex);
 }
 
+void intel_edp_drrs_invalidate(struct drm_device *dev,
+   unsigned frontbuffer_bits)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc;
+   enum pipe pipe;
+
+   if (!dev_priv->drrs.dp)
+   return;
+
+   mutex_lock(&dev_priv->drrs.mutex);
+   crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+   pipe = to_intel_crtc(crtc)->pipe;
+
+   if (dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR) {
+   cancel_delayed_work_sync(&dev_priv->drrs.work);
+   intel_dp_set_drrs_state(dev_priv->dev,
+   dev_priv->drrs.dp->attached_connector->panel.
+   fixed_mode->vrefresh);
+   }
+
+   frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
+
+   dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
+   mutex_unlock(&dev_priv->drrs.mutex);
+}
+
+void intel_edp_drrs_flush(struct drm_device *dev,
+   unsigned frontbuffer_bits)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc;
+   enum pipe pipe;
+
+   if (!dev_priv->drrs.dp)
+   return;
+
+   mutex_lock(&dev_priv->drrs.mutex);
+   crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+   pipe = to_intel_crtc(crtc)->pipe;
+   dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
+
+   cancel_delayed_work_sync(&dev_priv->drrs.work);
+
+   if (dev_priv->drrs.refresh_rate_type != DRRS_LOW_RR &&
+   !dev_priv->drrs.busy_frontbuffer_bits)
+   schedule_delayed_work(&dev_priv->drrs.work,
+   msecs_to_jiffies(1000));
+   mutex_unlock(&dev_priv->drrs.mutex);
+}
+
 static struct drm_display_mode *
 intel_dp_drrs_init(struct intel_connector *intel_connector,
struct drm_display_mode *fixed_mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1c3c25a..763c097 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1004,6 +1004,9 @@ int intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
 int intel_disable_plane(struct drm_plane *plane);
 void intel_edp_drrs_enable(struct intel_dp *intel_dp);
 void intel_edp_drrs_disable(struct intel_dp *intel_dp);
+void intel_edp_drrs_invalidate(struct drm_device *dev,
+   unsigned frontbuffer_bits);
+void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
 
 /* intel_dp_mst.c */
 int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int 
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/intel_frontbuffer.c
index 79f6d72..73cb6e0 10064

[Intel-gfx] [PATCH 3/8] drm/i915: Enable/disable DRRS

[Vandana Kannan]

Calling enable/disable DRRS when enable/disable DDI are called.
These functions are responsible for setup of drrs data (in enable) and
reset of drrs (in disable).
has_drrs is true when downclock_mode is found and SEAMLESS_DRRS is set in
the VBT. A check has been added for has_drrs in these functions, to make
sure the functions go through only if DRRS will work on the platform with
the attached panel.

Signed-off-by: Vandana Kannan 
---
 drivers/gpu/drm/i915/intel_ddi.c |  2 ++
 drivers/gpu/drm/i915/intel_dp.c  | 54 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 3 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 4e2e860..9a3ba72 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1600,6 +1600,7 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder)
 
intel_edp_backlight_on(intel_dp);
intel_psr_enable(intel_dp);
+   intel_edp_drrs_enable(intel_dp);
}
 
if (intel_crtc->config.has_audio) {
@@ -1625,6 +1626,7 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder)
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 
+   intel_edp_drrs_disable(intel_dp);
intel_psr_disable(intel_dp);
intel_edp_backlight_off(intel_dp);
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ef8b55d..7098470 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4819,6 +4819,60 @@ static void intel_dp_set_drrs_state(struct drm_device 
*dev, int refresh_rate)
DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate);
 }
 
+void intel_edp_drrs_enable(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_crtc *crtc = dig_port->base.base.crtc;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+   if (!intel_crtc->config.has_drrs) {
+   DRM_DEBUG_KMS("Panel doesn't support DRRS\n");
+   return;
+   }
+
+   mutex_lock(&dev_priv->drrs.mutex);
+   if (dev_priv->drrs.dp) {
+   DRM_DEBUG_KMS("DRRS already enabled\n");
+   mutex_unlock(&dev_priv->drrs.mutex);
+   return;
+   }
+
+   dev_priv->drrs.busy_frontbuffer_bits = 0;
+
+   dev_priv->drrs.dp = intel_dp;
+   mutex_unlock(&dev_priv->drrs.mutex);
+}
+
+void intel_edp_drrs_disable(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_crtc *crtc = dig_port->base.base.crtc;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+   if (!intel_crtc->config.has_drrs)
+   return;
+
+   mutex_lock(&dev_priv->drrs.mutex);
+   if (!dev_priv->drrs.dp) {
+   mutex_unlock(&dev_priv->drrs.mutex);
+   return;
+   }
+
+   if (dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR)
+   intel_dp_set_drrs_state(dev_priv->dev,
+   intel_dp->attached_connector->panel.
+   fixed_mode->vrefresh);
+
+   dev_priv->drrs.dp = NULL;
+   mutex_unlock(&dev_priv->drrs.mutex);
+
+   cancel_delayed_work_sync(&dev_priv->drrs.work);
+}
+
 static void intel_edp_drrs_work(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 066db58..1c3c25a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1002,6 +1002,8 @@ int intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
   uint32_t src_x, uint32_t src_y,
   uint32_t src_w, uint32_t src_h);
 int intel_disable_plane(struct drm_plane *plane);
+void intel_edp_drrs_enable(struct intel_dp *intel_dp);
+void intel_edp_drrs_disable(struct intel_dp *intel_dp);
 
 /* intel_dp_mst.c */
 int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int 
conn_id);
-- 
2.0.1

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

[Intel-gfx] [PATCH 0/8] eDP DRRS based on frontbuffer tracking

[Vandana Kannan]

This patch series inserts DRRS into frontbuffer tracking mechanism.

1. Previous submission for this feature was designed considering only eDP
DRRS. In this series, apart from following fb tracking, changes have been made
to make structures generic so that it can be of use to any other code
addition to support DRRS with other display types.
2. DRRS support is checked based on VBT setting and panel's capability (if
more than one RR is supported).
3. Based on DRRS support availability, related structures are initialized or
cleaned up through calls from enable/disable DDI respectively.
4. Since flip() indicates busyness, changes have been made to invalidate
DRRS during flip. This changes RR back to preferred mode RR. New work to set
low RR is scheduled after a delay of x ms.
5. This series includes patches to support RR switching on all platforms.
6. A module param has been added, carrying forward the input from the
previous submission of the feature. This param indicates the delay in ms after
which a switch to low RR can be made. By default, this is set to 0
indicating that the feature is disabled.

Durgadoss R (1):
  drm/i915: Enable eDP DRRS for CHV

Vandana Kannan (7):
  drm/i915: Modifying structures related to DRRS
  drm/i915: Initialize DRRS delayed work
  drm/i915: Enable/disable DRRS
  drm/i915: DRRS calls based on frontbuffer
  drm/i915/bdw: Add support for DRRS to switch RR
  drm/i915: Support for RR switching on VLV
  drm/i915: Add drrs_interval module parameter

 drivers/gpu/drm/i915/i915_drv.h  |  33 +++--
 drivers/gpu/drm/i915/i915_params.c   |   8 ++
 drivers/gpu/drm/i915/i915_reg.h  |   1 +
 drivers/gpu/drm/i915/intel_ddi.c |   2 +
 drivers/gpu/drm/i915/intel_display.c |  21 ++-
 drivers/gpu/drm/i915/intel_dp.c  | 217 ++-
 drivers/gpu/drm/i915/intel_drv.h |  26 ++--
 drivers/gpu/drm/i915/intel_frontbuffer.c |   2 +
 8 files changed, 239 insertions(+), 71 deletions(-)

-- 
2.0.1

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

[Intel-gfx] [PATCH] drm/i915: save/restore GMBUS freq across suspend/resume on gen4

[Jesse Barnes]

Should probably just init this in the GMbus code all the time, based on
the cdclk and HPLL like we do on newer platforms.  Ville has code for
that in a rework branch, but until then we can fix this bug fairly
easily.

References: https://bugs.freedesktop.org/show_bug.cgi?id=76301
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/i915_suspend.c | 8 
 3 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2725243..f33102b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -925,6 +925,7 @@ struct i915_suspend_saved_registers {
u32 savePIPEB_LINK_N1;
u32 saveMCHBAR_RENDER_STANDBY;
u32 savePCH_PORT_HOTPLUG;
+   u16 saveGCDGMBUS;
 };
 
 struct vlv_s0ix_state {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dc03fac..f7c2856 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -76,6 +76,7 @@
 #define   I915_GC_RENDER_CLOCK_166_MHZ (0 << 0)
 #define   I915_GC_RENDER_CLOCK_200_MHZ (1 << 0)
 #define   I915_GC_RENDER_CLOCK_333_MHZ (4 << 0)
+#define GCDGMBUS 0xcc
 #define PCI_LBPC 0xf4 /* legacy/combination backlight modes, also called LBB */
 
 
diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index dfe6617..2636882 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -303,6 +303,10 @@ int i915_save_state(struct drm_device *dev)
}
}
 
+   if (IS_GEN4(dev))
+   pci_read_config_word(dev->pdev, GCDGMBUS,
+&dev_priv->regfile.saveGCDGMBUS);
+
/* Cache mode state */
if (INTEL_INFO(dev)->gen < 7)
dev_priv->regfile.saveCACHE_MODE_0 = I915_READ(CACHE_MODE_0);
@@ -331,6 +335,10 @@ int i915_restore_state(struct drm_device *dev)
mutex_lock(&dev->struct_mutex);
 
i915_gem_restore_fences(dev);
+
+   if (IS_GEN4(dev))
+   pci_write_config_word(dev->pdev, GCDGMBUS,
+ dev_priv->regfile.saveGCDGMBUS);
i915_restore_display(dev);
 
if (!drm_core_check_feature(dev, DRIVER_MODESET)) {
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Changes required to enable DSI Video Mode on CHT

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV -1  364/364  363/364
ILK  +1-3  364/366  362/366
SNB  448/450  448/450
IVB -1  497/498  496/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*PNV  igt_gem_fd_exhaustion  PASS(2, M23)  FAIL(1, M23)
*ILK  igt_kms_flip_flip-vs-dpms-interruptible  PASS(5, M26)  
DMESG_WARN(1, M26)
 ILK  igt_kms_flip_flip-vs-panning  DMESG_WARN(1, M26)PASS(7, M26)  
DMESG_WARN(1, M26)
*ILK  igt_kms_flip_flip-vs-rmfb-interruptible  NSPT(1, M26)PASS(4, M26) 
 DMESG_WARN(1, M26)
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(3, M26)PASS(17, M26M37)   
   PASS(1, M26)
*IVB  igt_kms_cursor_crc_cursor-256x256-sliding  PASS(3, M4M21)  
DMESG_WARN(1, M21)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v2] lib: add a function to lock memory into RAM

[Thomas Wood]

Add a function to lock memory into RAM and use it in the
gem_tiled_swapping test to reduce the amount of allocated memory
required to force swapping. This also reduces the amount of time
required for the test to complete, since the data set is smaller.

The following durations were recorded on a haswell system before this
change:

  Subtest non-threaded: SUCCESS (55.889s)
  Subtest threaded: SUCCESS (810.532s)

and after:

  Subtest non-threaded: SUCCESS (11.804s)
  Subtest threaded: SUCCESS (268.336s)

v2: add various assertions and requirements and make sure
gem_tiled_swapping works on systems with less RAM (Daniel Vetter)

Signed-off-by: Thomas Wood 
---
 lib/igt_aux.c  | 57 ++
 lib/igt_aux.h  |  3 +++
 tests/gem_tiled_swapping.c | 10 +++-
 3 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 3051d84..d8d8577 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -601,3 +601,60 @@ struct type_name connector_type_names[] = {
 };
 
 type_name_fn(connector_type)
+
+
+/**
+ * igt_lock_mem: @size: the amount of memory to lock into RAM, in MB
+ *
+ * Allocate @size MB of memory and lock it into RAM. This releases any
+ * previously locked memory.
+ *
+ * Use #igt_unlock_mem to release the currently locked memory.
+ */
+static char *locked_mem;
+static size_t locked_size;
+
+void igt_lock_mem(size_t size)
+{
+   long pagesize = sysconf(_SC_PAGESIZE);
+   size_t i;
+   int ret;
+
+   if (size == 0) {
+   return;
+   }
+
+   if (locked_mem) {
+   igt_unlock_mem();
+   igt_warn("Unlocking previously locked memory.\n");
+   }
+
+   locked_size = size * 1024 * 1024;
+
+   locked_mem = malloc(locked_size);
+   igt_require_f(locked_mem,
+ "Could not allocate enough memory to lock.\n");
+
+   /* write into each page to ensure it is allocated */
+   for (i = 0; i < locked_size; i += pagesize)
+   locked_mem[i] = i;
+
+   ret = mlock(locked_mem, locked_size);
+   igt_assert_f(ret == 0, "Could not lock memory into RAM.\n");
+}
+
+/**
+ * igt_unlock_mem:
+ *
+ * Release and free the RAM used by #igt_lock_mem.
+ */
+void igt_unlock_mem(void)
+{
+   if (!locked_mem)
+   return;
+
+   munlock(locked_mem, locked_size);
+
+   free(locked_mem);
+   locked_mem = NULL;
+}
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 63e1b06..c420b3f 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -96,4 +96,7 @@ void intel_require_memory(uint32_t count, uint32_t size, 
unsigned mode);
(b) = _tmp; \
 } while (0)
 
+void igt_lock_mem(size_t size);
+void igt_unlock_mem(void);
+
 #endif /* IGT_AUX_H */
diff --git a/tests/gem_tiled_swapping.c b/tests/gem_tiled_swapping.c
index 3fac52f..1637ec7 100644
--- a/tests/gem_tiled_swapping.c
+++ b/tests/gem_tiled_swapping.c
@@ -70,6 +70,7 @@ IGT_TEST_DESCRIPTION("Exercise swizzle code for swapping.");
 static uint32_t current_tiling_mode;
 
 #define PAGE_SIZE 4096
+#define AVAIL_RAM 512
 
 static uint32_t
 create_bo_and_fill(int fd)
@@ -151,13 +152,20 @@ igt_main
int fd, n, count, num_threads;
 
igt_fixture {
+   size_t lock_size;
+
current_tiling_mode = I915_TILING_X;
 
intel_purge_vm_caches();
 
fd = drm_open_any();
+
+   /* lock RAM, leaving only 512MB available */
+   lock_size = min(0, intel_get_total_ram_mb() - AVAIL_RAM);
+   igt_lock_mem(lock_size);
+
/* need slightly more than available memory */
-   count = intel_get_total_ram_mb() + intel_get_total_swap_mb() / 
4;
+   count = lock_size * 1.25;
bo_handles = calloc(count, sizeof(uint32_t));
igt_assert(bo_handles);
 
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1 364/366  365/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(3, M26)PASS(16, M26M37)   
   PASS(1, M37)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: FIFO space query code refactor

[Dave Gordon]

When querying the GTFIFOCTL register to check the FIFO space, the read value
must be masked. The operation is repeated explicitly in several places. This
change refactors the read-and-mask code into a function call.

v2: rebased on top of Mika's forcewake patch set, specifically:
[PATCH 8/8] drm/i915: Enum forcewake domains and domain identifiers

Change-Id: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef
Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_uncore.c |   19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 66365e7..a0331a7 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -205,6 +205,13 @@ static void fw_domains_put_with_fifo(struct 
drm_i915_private *dev_priv,
gen6_gt_check_fifodbg(dev_priv);
 }
 
+static inline u32 fifo_free_entries(struct drm_i915_private *dev_priv)
+{
+   u32 count = __raw_i915_read32(dev_priv, GTFIFOCTL);
+
+   return count & GT_FIFO_FREE_ENTRIES_MASK;
+}
+
 static int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
 {
int ret = 0;
@@ -212,16 +219,15 @@ static int __gen6_gt_wait_for_fifo(struct 
drm_i915_private *dev_priv)
/* On VLV, FIFO will be shared by both SW and HW.
 * So, we need to read the FREE_ENTRIES everytime */
if (IS_VALLEYVIEW(dev_priv->dev))
-   dev_priv->uncore.fifo_count =
-   __raw_i915_read32(dev_priv, GTFIFOCTL) &
-   GT_FIFO_FREE_ENTRIES_MASK;
+   dev_priv->uncore.fifo_count = fifo_free_entries(dev_priv);
 
if (dev_priv->uncore.fifo_count < GT_FIFO_NUM_RESERVED_ENTRIES) {
int loop = 500;
-   u32 fifo = __raw_i915_read32(dev_priv, GTFIFOCTL) & 
GT_FIFO_FREE_ENTRIES_MASK;
+   u32 fifo = fifo_free_entries(dev_priv);
+
while (fifo <= GT_FIFO_NUM_RESERVED_ENTRIES && loop--) {
udelay(10);
-   fifo = __raw_i915_read32(dev_priv, GTFIFOCTL) & 
GT_FIFO_FREE_ENTRIES_MASK;
+   fifo = fifo_free_entries(dev_priv);
}
if (WARN_ON(loop < 0 && fifo <= GT_FIFO_NUM_RESERVED_ENTRIES))
++ret;
@@ -277,8 +283,7 @@ void intel_uncore_forcewake_reset(struct drm_device *dev, 
bool restore)
 
if (IS_GEN6(dev) || IS_GEN7(dev))
dev_priv->uncore.fifo_count =
-   __raw_i915_read32(dev_priv, GTFIFOCTL) &
-   GT_FIFO_FREE_ENTRIES_MASK;
+   fifo_free_entries(dev_priv);
}
 
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH] drm/i915: vlv: fix IRQ masking when uninstalling interrupts

[Ville Syrjälä]

On Thu, Nov 20, 2014 at 04:05:55PM +0200, Imre Deak wrote:
> irq_mask should include all IRQ bits that we want to mask, but atm we
> set it incorrectly to the inverse of this. If the mask is used
> subsequently to enable/disable some IRQ bits, we may unintentionally
> unmask unrelated IRQs. I can't see any way that this can lead to a real
> problem in the current -nightly code, since the first place the mask
> will be used next (after a suspend/resume cycle) is in
> valleyview_irq_postinstall(), but the mask is reset there to its proper
> value.
> 
> This causes a problem in the upstream kernel though, where - due to another
> issue - the mask is used in the above way to disable only the display IRQs.
> This other issue is fixed by:
> 
> commit 950eabaf5a87257040e0c207be09487954113f54
> Author: Imre Deak 
> Date:   Mon Sep 8 15:21:09 2014 +0300
> 
> drm/i915: vlv: fix display IRQ enable/disable
> 
> Interestingly, even with the above two bugs, we shouldn't in theory have
> any real problems (arguably a famous last sentence:). That's because
> even if we unmask something unintentionally via the VLV_IMR/VLV_IER
> register the master IRQ masking bit in VLV_MASTER_IER is still set and
> should prevent all i915 interrupts. According to my testing on an ASUS
> T100 with DSI output this isn't the case at least with the
> MIPIA_INTERRUPT. Leaving this one unmasked in IMR/IER, while having
> VLV_MASTER_IER set to 0 may lead to a lockup during system suspend as
> shown in the bugzilla ticket below. This fix should get rid of the
> problem reported there in upstream and older kernels.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85920
> Cc: sta...@vger.kernel.org (v3.15+)
> Signed-off-by: Imre Deak 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 8d169e1..4601f53 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3597,7 +3597,7 @@ static void vlv_display_irq_uninstall(struct 
> drm_i915_private *dev_priv)
>  
>   vlv_display_irq_reset(dev_priv);
>  
> - dev_priv->irq_mask = 0;
> + dev_priv->irq_mask = ~0;
>  }
>  
>  static void valleyview_irq_uninstall(struct drm_device *dev)
> -- 
> 1.8.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH v3 0/2] Multiple GGTT views

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

This series continues what was previously a single patch called "drm/i915:
Infrastructure for supporting different GGTT views per object".

v2:
 * One less patch due early prep work getting merged.
 * Main patch reworked to keep the pages pointer around for the lifetime of the
   VMA. More detailed changelog in the patch itself.

v3:
 * Addressing review comments - see individual changelogs.

Tvrtko Ursulin (2):
  drm/i915: Infrastructure for supporting different GGTT views per
object
  drm/i915: Documentation for multiple GGTT views

 Documentation/DocBook/drm.tmpl |   5 ++
 drivers/gpu/drm/i915/i915_debugfs.c|   5 +-
 drivers/gpu/drm/i915/i915_drv.h|  56 +++--
 drivers/gpu/drm/i915/i915_gem.c| 112 +++--
 drivers/gpu/drm/i915/i915_gem_context.c|  11 ++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   9 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c| 130 +++--
 drivers/gpu/drm/i915/i915_gem_gtt.h|  22 +
 drivers/gpu/drm/i915/i915_gpu_error.c  |   8 +-
 9 files changed, 286 insertions(+), 72 deletions(-)

-- 
2.1.1

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

[Intel-gfx] [PATCH 2/2] drm/i915: Documentation for multiple GGTT views

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

A short section describing background, implementation and intended usage.

v2:
* Align section name between template and DOC comment. (Michel Thierry)

For: VIZ-4544
Signed-off-by: Tvrtko Ursulin 
---
 Documentation/DocBook/drm.tmpl  |  5 
 drivers/gpu/drm/i915/i915_gem_gtt.c | 60 +
 2 files changed, 65 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 85287cb..eb84da73 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4033,6 +4033,11 @@ int num_ioctls;
 !Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and 
Execlists
 !Idrivers/gpu/drm/i915/intel_lrc.c
   
+  
+Global GTT views
+!Pdrivers/gpu/drm/i915/i915_gem_gtt.c Global GTT views
+!Idrivers/gpu/drm/i915/i915_gem_gtt.c
+  
 
 
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 73c1c0b..534ebc1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -30,6 +30,66 @@
 #include "i915_trace.h"
 #include "intel_drv.h"
 
+/**
+ * DOC: Global GTT views
+ *
+ * Background and previous state
+ *
+ * Historically objects could exists (be bound) in global GTT space only as
+ * singular instances with a view representing all of the object's backing 
pages
+ * in a linear fashion. This view will be called a normal view.
+ *
+ * To support multiple views of the same object, where the number of mapped
+ * pages is not equal to the backing store, or where the layout of the pages
+ * is not linear, concept of a GGTT view was added.
+ *
+ * One example of an alternative view is a stereo display driven by a single
+ * image. In this case we would have a framebuffer looking like this
+ * (2x2 pages):
+ *
+ *12
+ *34
+ *
+ * Above would represent a normal GGTT view as normally mapped for GPU or CPU
+ * rendering. In contrast, fed to the display engine would be an alternative
+ * view which could look something like this:
+ *
+ *   1212
+ *   3434
+ *
+ * In this example both the size and layout of pages in the alternative view is
+ * different from the normal view.
+ *
+ * Implementation and usage
+ *
+ * GGTT views are implemented using VMAs and are distinguished via enum
+ * i915_ggtt_view_type and struct i915_ggtt_view.
+ *
+ * A new flavour of core GEM functions which work with GGTT bound objects were
+ * added with the _view suffix. They take the struct i915_ggtt_view parameter
+ * encapsulating all metadata required to implement a view.
+ *
+ * As a helper for callers which are only interested in the normal view,
+ * globally const i915_ggtt_view_normal singleton instance exists. All old core
+ * GEM API functions, the ones not taking the view parameter, are operating on,
+ * or with the normal GGTT view.
+ *
+ * Code wanting to add or use a new GGTT view needs to:
+ *
+ * 1. Add a new enum with a suitable name.
+ * 2. Extend the metadata in the i915_ggtt_view structure if required.
+ * 3. Add support to i915_get_vma_pages().
+ *
+ * New views are required to build a scatter-gather table from within the
+ * i915_get_vma_pages function. This table is stored in the vma.ggtt_view and
+ * exists for the lifetime of an VMA.
+ *
+ * Core API is designed to have copy semantics which means that passed in
+ * struct i915_ggtt_view does not need to be persistent (left around after
+ * calling the core API functions).
+ *
+ */
+
 const struct i915_ggtt_view i915_ggtt_view_normal;
 
 static void bdw_setup_private_ppat(struct drm_i915_private *dev_priv);
-- 
2.1.1

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

[Intel-gfx] [PATCH 1/2] drm/i915: Infrastructure for supporting different GGTT views per object

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Things like reliable GGTT mappings and mirrored 2d-on-3d display will need
to map objects into the same address space multiple times.

Added a GGTT view concept and linked it with the VMA to distinguish between
multiple instances per address space.

New objects and GEM functions which do not take this new view as a parameter
assume the default of zero (I915_GGTT_VIEW_NORMAL) which preserves the
previous behaviour.

This now means that objects can have multiple VMA entries so the code which
assumed there will only be one also had to be modified.

Alternative GGTT views are supposed to borrow DMA addresses from obj->pages
which is DMA mapped on first VMA instantiation and unmapped on the last one
going away.

v2:
* Removed per view special casing in i915_gem_ggtt_prepare /
  finish_object in favour of creating and destroying DMA mappings
  on first VMA instantiation and last VMA destruction. (Daniel Vetter)
* Simplified i915_vma_unbind which does not need to count the GGTT views.
  (Daniel Vetter)
* Also moved obj->map_and_fenceable reset under the same check.
* Checkpatch cleanups.

v3:
* Only retire objects once the last VMA is unbound.

v4:
* Keep scatter-gather table for alternative views persistent for the
  lifetime of the VMA.
* Propagate binding errors to callers and handle appropriately.

v5:
* Explicitly look for normal GGTT view in i915_gem_obj_bound to align
  usage in i915_gem_object_ggtt_unpin. (Michel Thierry)
* Change to single if statement in i915_gem_obj_to_ggtt. (Michel Thierry)
* Removed stray semi-colon in i915_gem_object_set_cache_level.

For: VIZ-4544
Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c|   5 +-
 drivers/gpu/drm/i915/i915_drv.h|  56 +--
 drivers/gpu/drm/i915/i915_gem.c| 112 +
 drivers/gpu/drm/i915/i915_gem_context.c|  11 ++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   9 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  70 +++---
 drivers/gpu/drm/i915/i915_gem_gtt.h|  22 ++
 drivers/gpu/drm/i915/i915_gpu_error.c  |   8 +--
 8 files changed, 221 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445e..a8af667 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -152,8 +152,9 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
seq_puts(m, " (pp");
else
seq_puts(m, " (g");
-   seq_printf(m, "gtt offset: %08lx, size: %08lx)",
-  vma->node.start, vma->node.size);
+   seq_printf(m, "gtt offset: %08lx, size: %08lx, type: %u)",
+  vma->node.start, vma->node.size,
+  vma->ggtt_view.type);
}
if (obj->stolen)
seq_printf(m, " (stolen: %08lx)", obj->stolen->start);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 11e85cb..451bb6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2518,10 +2518,23 @@ void i915_gem_vma_destroy(struct i915_vma *vma);
 #define PIN_GLOBAL 0x4
 #define PIN_OFFSET_BIAS 0x8
 #define PIN_OFFSET_MASK (~4095)
+int __must_check i915_gem_object_pin_view(struct drm_i915_gem_object *obj,
+ struct i915_address_space *vm,
+ uint32_t alignment,
+ uint64_t flags,
+ const struct i915_ggtt_view *view);
+static inline
 int __must_check i915_gem_object_pin(struct drm_i915_gem_object *obj,
 struct i915_address_space *vm,
 uint32_t alignment,
-uint64_t flags);
+uint64_t flags)
+{
+   return i915_gem_object_pin_view(obj, vm, alignment, flags,
+   &i915_ggtt_view_normal);
+}
+
+int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level,
+ u32 flags);
 int __must_check i915_vma_unbind(struct i915_vma *vma);
 int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
 void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
@@ -2683,18 +2696,51 @@ struct dma_buf *i915_gem_prime_export(struct drm_device 
*dev,
 
 void i915_gem_restore_fences(struct drm_device *dev);
 
+unsigned long i915_gem_obj_offset_view(struct drm_i915_gem_object *o,
+  struct i915_address_space *vm,
+  enum i915_ggtt_view_type view);
+static inline
 unsigned long i915_gem_obj_offset(struct drm_i915_gem_object *o,
- 

[Intel-gfx] [PATCH i-g-t v2 2/2] lib: add optional log domain filtering

[Thomas Wood]

v2: add an "application" filter for the default domain (used by
applications)

Signed-off-by: Thomas Wood 
---
 docs/reference/intel-gpu-tools/igt_test_programs.xml |  6 --
 lib/igt_core.c   | 17 +++--
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/docs/reference/intel-gpu-tools/igt_test_programs.xml 
b/docs/reference/intel-gpu-tools/igt_test_programs.xml
index 970ecb9..36ad1f3 100644
--- a/docs/reference/intel-gpu-tools/igt_test_programs.xml
+++ b/docs/reference/intel-gpu-tools/igt_test_programs.xml
@@ -35,9 +35,11 @@
   
 
   
---debug
+--debug[=log-domain]
 
-print extra debugging information when running tests
+print extra debugging information when running tests and
+optionaly only show the messages from the specified log domain
+(use "application" to specifiy the default application domain)
 
   
 
diff --git a/lib/igt_core.c b/lib/igt_core.c
index b6852dd..695437c 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -228,6 +228,8 @@ enum {
  OPT_HELP = 'h'
 };
 
+static char* igt_log_domain_filter;
+
 __attribute__((format(printf, 1, 2)))
 static void kmsg(const char *format, ...)
 #define KERN_EMER  "<0>"
@@ -390,7 +392,7 @@ static void print_usage(const char *help_str, bool 
output_on_stderr)
fprintf(f, "Usage: %s [OPTIONS]\n", command_str);
fprintf(f, "  --list-subtests\n"
   "  --run-subtest \n"
-  "  --debug\n"
+  "  --debug[=log-domain]\n"
   "  --help-description\n"
   "  --help\n");
if (help_str)
@@ -422,7 +424,7 @@ static int common_init(int argc, char **argv,
{"list-subtests", 0, 0, OPT_LIST_SUBTESTS},
{"run-subtest", 1, 0, OPT_RUN_SUBTEST},
{"help-description", 0, 0, OPT_DESCRIPTION},
-   {"debug", 0, 0, OPT_DEBUG},
+   {"debug", optional_argument, 0, OPT_DEBUG},
{"help", 0, 0, OPT_HELP},
{0, 0, 0, 0}
};
@@ -510,6 +512,8 @@ static int common_init(int argc, char **argv,
switch(c) {
case OPT_DEBUG:
igt_log_level = IGT_LOG_DEBUG;
+   if (optarg && strlen(optarg) > 0)
+   igt_log_domain_filter = strdup(optarg);
break;
case OPT_LIST_SUBTESTS:
if (!run_single_subtest)
@@ -1469,6 +1473,15 @@ void igt_vlog(const char *domain, enum igt_log_level 
level, const char *format,
if (igt_log_level > level)
return;
 
+   if (igt_log_domain_filter) {
+   /* if null domain and filter is not "application", return */
+   if (!domain && strcmp(igt_log_domain_filter, "application"))
+   return;
+   /* else if domain and filter do not match, return */
+   else if (domain && strcmp(igt_log_domain_filter, domain))
+   return;
+   }
+
if (level == IGT_LOG_WARN) {
file = stderr;
fflush(stdout);
-- 
2.1.0

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

[Intel-gfx] [PATCH i-g-t v2 1/2] lib: introduce log domains

[Thomas Wood]

Log domains can be used to identify the source of log messages, such as
the test being run or the helper library.

v2: Add separate domains for different parts of the helper library and
use an empty default domain for applications.
Expand the log output to include the process name and the log level
of the message in addition to the domain and pid.
Print the expanded message only for warning and information
messages.

Signed-off-by: Thomas Wood 
---
 lib/Makefile.am |  3 ++-
 lib/igt_core.c  | 28 ++--
 lib/igt_core.h  | 18 +++---
 lib/igt_kms.c   |  2 +-
 4 files changed, 36 insertions(+), 15 deletions(-)

diff --git a/lib/Makefile.am b/lib/Makefile.am
index ab82302..3826a1c 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -10,7 +10,8 @@ noinst_HEADERS = check-ndebug.h
 
 AM_CPPFLAGS = -I$(top_srcdir)
 AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS)  \
-   -DIGT_DATADIR=\""$(abs_top_srcdir)/tests"\"
+   -DIGT_DATADIR=\""$(abs_top_srcdir)/tests"\" \
+   -DIGT_LOG_DOMAIN=\""$(subst _,-,$*)"\"
 
 
 LDADD = $(CAIRO_LIBS)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 13a52a5..b6852dd 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1429,12 +1429,12 @@ void igt_skip_on_simulation(void)
  * are disabled. "none" completely disables all output and is not recommended
  * since crucial issues only reported at the IGT_LOG_WARN level are ignored.
  */
-void igt_log(enum igt_log_level level, const char *format, ...)
+void igt_log(const char *domain, enum igt_log_level level, const char *format, 
...)
 {
va_list args;
 
va_start(args, format);
-   igt_vlog(level, format, args);
+   igt_vlog(domain, level, format, args);
va_end(args);
 }
 
@@ -1451,8 +1451,16 @@ void igt_log(enum igt_log_level level, const char 
*format, ...)
  * If there is no need to wrap up a vararg list in the caller it is simpler to
  * just use igt_log().
  */
-void igt_vlog(enum igt_log_level level, const char *format, va_list args)
+void igt_vlog(const char *domain, enum igt_log_level level, const char 
*format, va_list args)
 {
+   FILE *file;
+   const char *igt_log_level_str[] = {
+   "DEBUG",
+   "INFO",
+   "WARNING",
+   "NONE"
+   };
+
assert(format);
 
if (list_subtests)
@@ -1462,10 +1470,18 @@ void igt_vlog(enum igt_log_level level, const char 
*format, va_list args)
return;
 
if (level == IGT_LOG_WARN) {
+   file = stderr;
fflush(stdout);
-   vfprintf(stderr, format, args);
-   } else
-   vprintf(format, args);
+   }
+   else
+   file = stdout;
+
+   if (level != IGT_LOG_INFO) {
+   fprintf(file, "(%s:%d) %s%s%s: ", program_invocation_short_name,
+   getpid(), (domain) ? domain : "", (domain) ? "-" : "",
+   igt_log_level_str[level]);
+   }
+   vfprintf(file, format, args);
 }
 
 static void igt_alarm_handler(int signal)
diff --git a/lib/igt_core.h b/lib/igt_core.h
index a258348..5c5ee25 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -512,16 +512,20 @@ bool igt_run_in_simulation(void);
 void igt_skip_on_simulation(void);
 
 /* structured logging */
+#ifndef IGT_LOG_DOMAIN
+#define IGT_LOG_DOMAIN (NULL)
+#endif
+
 enum igt_log_level {
IGT_LOG_DEBUG,
IGT_LOG_INFO,
IGT_LOG_WARN,
IGT_LOG_NONE,
 };
-__attribute__((format(printf, 2, 3)))
-void igt_log(enum igt_log_level level, const char *format, ...);
-__attribute__((format(printf, 2, 0)))
-void igt_vlog(enum igt_log_level level, const char *format, va_list args);
+__attribute__((format(printf, 3, 4)))
+void igt_log(const char *domain, enum igt_log_level level, const char *format, 
...);
+__attribute__((format(printf, 3, 0)))
+void igt_vlog(const char *domain, enum igt_log_level level, const char 
*format, va_list args);
 
 /**
  * igt_debug:
@@ -529,7 +533,7 @@ void igt_vlog(enum igt_log_level level, const char *format, 
va_list args);
  *
  * Wrapper for igt_log() for message at the IGT_LOG_DEBUG level.
  */
-#define igt_debug(f...) igt_log(IGT_LOG_DEBUG, f)
+#define igt_debug(f...) igt_log(IGT_LOG_DOMAIN, IGT_LOG_DEBUG, f)
 
 /**
  * igt_info:
@@ -537,7 +541,7 @@ void igt_vlog(enum igt_log_level level, const char *format, 
va_list args);
  *
  * Wrapper for igt_log() for message at the IGT_LOG_INFO level.
  */
-#define igt_info(f...) igt_log(IGT_LOG_INFO, f)
+#define igt_info(f...) igt_log(IGT_LOG_DOMAIN, IGT_LOG_INFO, f)
 
 /**
  * igt_warn:
@@ -545,7 +549,7 @@ void igt_vlog(enum igt_log_level level, const char *format, 
va_list args);
  *
  * Wrapper for igt_log() for message at the IGT_LOG_WARN level.
  */
-#define igt_warn(f...) igt_log(IGT_LOG_WARN, f)
+#define igt_warn(f...) igt_log(IGT_LOG_DOMAIN, IGT_LOG_WARN, f)
 extern enum igt_log_level igt_log_level;
 
 /**
diff --git a/lib/igt_kms.c b/lib/i

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Disable 'get seqno' workaround for VLV

[Dave Gordon]

On 10/12/14 10:42, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:08PM +, john.c.harri...@intel.com wrote:
>> From: Dave Gordon 
>>
>> There is a workaround for a hardware bug when reading the seqno from the 
>> status
>> page. The bug does not exist on VLV however, the workaround was still being
>> applied.
> 
> Given how much trouble the missed seqno fun cause us I'd like more
> justification. What kind of (stress)-testing has been done here? And
> you're sure you've never seen the little dmesg notice that the kernel
> switched to polling?
> -Daniel

This was necessary during VLV scheduler/preemption work, where we
stressed the command streamer and IRQ path probably more than any of the
usual tests, since we were looking for out-of-sequence anomalies.

The comments in gen6_ring_get_seqno() say it's to fix a bug on ivb/snb,
and nothing in the BSpec suggests it's needed on later chips.

I think the problem was really in the fact that the workaround
implemented in gen6_ring_get_seqno() was reading a nonshadowed register,
therefore triggering forcewake activity, which was pretty buggy; so we
took out the gen6-specific code before finding that there were still
other problems with forcewake.

[Aside]
The original intention appears to have been to generate a single I/O
READ cycle, forcing all pending inbound DMA so be flushed to memory, so
that the subsequent memory read would see the latest value. But now, it
doesn't just generate a single cycle but a whole flurry of writes and
polling reads, because reading ACTHD requires forcewake (unless that was
wrong, and has now been fixed). So should gen6_ring_get_seqno() instead
read a register that doesn't require forcewake? I wouldn't object to
using it in perpetuity if it really only read one register!
[/aside]

.Dave.

>> Change-Id: Ic781fdb31e1f794ce1fa8a6d0d5ee379756c5db6
>> Signed-off-by: Dave Gordon 
>> ---
>>  drivers/gpu/drm/i915/intel_ringbuffer.c |5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index 3887f1a..f990ce4 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -2367,7 +2367,10 @@ int intel_init_render_ring_buffer(struct drm_device 
>> *dev)
>>  ring->irq_get = gen6_ring_get_irq;
>>  ring->irq_put = gen6_ring_put_irq;
>>  ring->irq_enable_mask = GT_RENDER_USER_INTERRUPT;
>> -ring->get_seqno = gen6_ring_get_seqno;
>> +if (IS_VALLEYVIEW(dev))
>> +ring->get_seqno = ring_get_seqno;
>> +else
>> +ring->get_seqno = gen6_ring_get_seqno;
>>  ring->set_seqno = ring_set_seqno;
>>  if (i915_semaphore_is_enabled(dev)) {
>>  ring->semaphore.sync_to = gen6_ring_sync;
>> -- 
>> 1.7.9.5
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

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

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Prelude to splitting i915_gem_do_execbuffer in two

[Daniel Vetter]

On Wed, Dec 10, 2014 at 04:33:14PM +, Dave Gordon wrote:
> On 10/12/14 10:58, Daniel Vetter wrote:
> > On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
> >> From: John Harrison 
> >>
> >> The scheduler decouples the submission of batch buffers to the driver with 
> >> their
> >> submission to the hardware. This basically means splitting the execbuffer()
> >> function in half. This change rearranges some code ready for the split to 
> >> occur.
> > 
> > Now there's the curios question: Where will the split in top/bottom halves
> > be? Without that I have no idea whether it makes sense and so can't review
> > this patch. At least if the goal is to really prep for the scheduler and
> > not just move a few lines around ;-)
> > -Daniel
> > 
> [snip]
> >>  
> >> +  i915_gem_execbuffer_move_to_active(vmas, ring);
> >> +
> >> +  /* To be split into two functions here... */
> >> +
> >> +  /* Unconditionally invalidate gpu caches and ensure that we do flush
> >> +   * any residual writes from the previous batch.
> >> +   */
> >> +  ret = logical_ring_invalidate_all_caches(ringbuf);
> 
> It'll be where the marker comment is above. Ahead of that point is stuff
> to do with setting up software state; after that we're talking to h/w.
> When the scheduler code goes it, it decouples the two by interposing at
> this point. Then batches go into it with s/w state set up, but don't get
> to talk to the h/w until they're selected for execution, possibly in a
> different order.

Oops, I guess I need see a doctor to check my eyesight ;-)

Two comments about code that's still in the bottom half:
- There's lots of input validation code still below that cutoff point
  which needs to be moved above to still be able to return -EINVAL. Test
  coverage is the critical part here, but I think we've closed most of our
  gaps. I guess a future patch will address this?

- retire_commands and so add_request are also in the cutoff. For shrinker
  interactions to work seamlessly we need to have both the objects on the
  active list and the request in the lists. So I expect more untangling
  there to separate the request emission to rings from the bookkeeping
  parts in add_request.

Also move_to_active will fall apart once we start to reorder requests I
think. Need to think about this case more, but we definitely need some
testcases with depencies and reordering by the scheduler.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Forcewake Register Range changes for CHV

[Daniel Vetter]

On Thu, Dec 11, 2014 at 09:42:49PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S 
> 
> According to updated BSpec, Render/Common/media Wells register range changed.
> Updating the same to match the spec and avoid extra forcewake for none
> forcewake range.
> 
> v2: Update media forcewake range (Ville)
> 
> Signed-off-by: Deepak S 
> Reviewed-by: Ville Syrjälä 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for batch buffer pools

[Michael H. Nguyen]

On 12/10/2014 08:41 AM, Bloomfield, Jon wrote:

why do we take the batch_pool lock in i915_gem_batch_pool_info() ?
i915_gem_batch_pool_info() is a new debugfs entry while 
print_batch_pool_stats() is just an internal fnc, called from the 
debugfs entry i915_gem_object_info(). i915_gem_object_info() handles the 
locks.

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Changes related to the sequence port no for

[Daniel Vetter]

On Wed, Dec 10, 2014 at 10:07:40PM +0530, Gaurav K Singh wrote:
> From now on for both DSI Ports A & C, the seq_port value has been
> set to 0. seq_port value is parsed from Sequence block#53 of VBT.
> So, for packets that needs to be read/write for DSI single link on
> Port A and Port C will now be based on the DVO port from VBT block 2,
> instead of seq_port.
> 
> Signed-off-by: Gaurav K Singh 
> Reviewed-by: Jani Nikula 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Paolo Bonzini]

On 09/12/2014 03:49, Tian, Kevin wrote:
> - Now we have XenGT/KVMGT separately maintained, and KVMGT lags
> behind XenGT regarding to features and qualities. Likely you'll continue
> see stale code (like Xen inst decoder) for some time. In the future we
> plan to maintain a single kernel repo for both, so KVMGT can share
> same quality as XenGT once KVM in-kernel dm framework is stable.
> 
> - Regarding to Qemu hacks, KVMGT really doesn't have any different 
> requirements as what have been discussed for GPU pass-through, e.g. 
> about ISA bridge. Our implementation is based on an old Qemu repo, 
> and honestly speaking not cleanly developed, because we know we
> can leverage from GPU pass-through support once it's in Qemu. At 
> that time we'll leverage the same logic with minimal changes to 
> hook KVMGT mgmt. APIs (e.g. create/destroy a vGPU instance). So
> we can ignore this area for now. :-)

Could the virtual device model introduce new registers in order to avoid
poking at the ISA bridge?  I'm not sure that you "can leverage from GPU
pass-through support once it's in Qemu", since the Xen IGD passthrough
support is being added to a separate machine that is specific to Xen IGD
passthrough; no ISA bridge hacking will probably be allowed on the "-M
pc" and "-M q35" machine types.

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

Re: [Intel-gfx] [PATCH] drm/i915: Call the lrc irq handler correctly

[Daniel, Thomas]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Wednesday, December 10, 2014 4:44 PM
> To: Intel Graphics Development
> Cc: Daniel Vetter; Daniel, Thomas; Vetter, Daniel
> Subject: [PATCH] drm/i915: Call the lrc irq handler correctly
> 
> We consistently use the _irq_handler postfix for functions called in hardirq
> context. Especially when it's a non-static function hardirq is a crazy enough
> calling context to warrant this level of ocd. So rename it.
> 
> Cc: Thomas Daniel 
> Signed-off-by: Daniel Vetter 
> ---
Possible to rename the patch "Name the lrc irq handler correctly" before 
merging?  Sounds like it was being called from the wrong place.

No problem with this renaming though so:
Reviewed-by: Thomas Daniel 

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

[Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[Daniel Vetter]

Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.

We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.

The idea to use __builtin_constant_p is from Chris Wilson.

v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
Dave. My first attempt used __cond as the temp var, which is the same
used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
sprinkle i915 into the name.

Also use a temporary variable to only evaluate the condition once,
suggested by Damien.

v3: It's crazy but apparently 32bit gcc can't compile out the
BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
why, but until clue grows just disable this nifty idea on 32bit
builds. Reported by 0-day builder.

v4: Got it all wrong, apparently its the gcc version. We need 4.9+.
Now reported by Imre.

v5: Chris suggested to add the case to MISSING_CASE for speedier
debug.

Cc: Imre Deak 
Cc: Damien Lespiau 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Dave Gordon 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 14 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  6 +++---
 drivers/gpu/drm/i915/intel_display.c |  4 ++--
 drivers/gpu/drm/i915/intel_uncore.c  |  4 ++--
 5 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 165a38f36009..479e0c119111 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum 
intel_display_power_domain domain)
case POWER_DOMAIN_INIT:
return "INIT";
default:
-   WARN_ON(1);
+   MISSING_CASE(domain);
return "?";
}
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c74dc946cbf6..aeb1ef3ef2b6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -58,7 +58,19 @@
 #define DRIVER_DATE"20141205"
 
 #undef WARN_ON
-#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
+/* Only 4.9+ gcc can compile away the BUILD_BUG_ON correctly. */
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9)
+#define WARN_ON(x) ({ \
+   bool __i915_warn_cond = (x); \
+   if (__builtin_constant_p(__i915_warn_cond)) \
+   BUILD_BUG_ON(__i915_warn_cond); \
+   WARN(__i915_warn_cond, "WARN_ON(" #x ")"); })
+#else
+#define WARN_ON(x) WARN((x), "WARN_ON(" #x ")")
+#endif
+
+#define MISSING_CASE(x) WARN(1, "Missing switch case (%lu) in %s\n", \
+(long) (x), __func__);
 
 enum pipe {
INVALID_PIPE = -1,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ac03a382000b..ce4e46c443a1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -132,7 +132,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE(level);
}
 
return pte;
@@ -156,7 +156,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE(level);
}
 
return pte;
@@ -1146,7 +1146,7 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 8)
gen8_ppgtt_enable(dev);
else
-   WARN_ON(1);
+   MISSING_CASE(INTEL_INFO(dev)->gen);
 
if (ppgtt) {
for_each_ring(ring, dev_priv, i) {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 841af6c1f50b..878c4857ff49 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4847,7 +4847,7 @@ static void cherryview_set_cdclk(struct drm_device *dev, 
int cdclk)
cmd = 0;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE(cdclk);
return;
}
 
@@ -8224,7 +8224,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 
base)
cntl |= CURSOR_MODE_256_ARGB_AX;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE(intel_crtc->cursor_width);
return;
}
cntl |= pipe << 28; /* Connect to correct pipe */
diff --git a/drivers/gpu/drm/i915/intel

[Intel-gfx] [PATCH 2/4] drm/i915: Changes related to the sequence port no for

[Gaurav K Singh]

From now on for both DSI Ports A & C, the seq_port value has been
set to 0. seq_port value is parsed from Sequence block#53 of VBT.
So, for packets that needs to be read/write for DSI single link on
Port A and Port C will now be based on the DVO port from VBT block 2,
instead of seq_port.

Signed-off-by: Gaurav K Singh 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f8c2269..5493aef 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -110,7 +110,15 @@ static u8 *mipi_exec_send_packet(struct intel_dsi 
*intel_dsi, u8 *data)
vc = (byte >> MIPI_VIRTUAL_CHANNEL_SHIFT) & 0x3;
seq_port = (byte >> MIPI_PORT_SHIFT) & 0x3;
 
-   port = intel_dsi_seq_port_to_port(seq_port);
+   /* For DSI single link on Port A & C, the seq_port value which is
+* parsed from Sequence Block#53 of VBT has been set to 0
+* Now, read/write of packets for the DSI single link on Port A and
+* Port C will based on the DVO port from VBT block 2.
+*/
+   if (intel_dsi->ports == (1 << PORT_C))
+   port = PORT_C;
+   else
+   port = intel_dsi_seq_port_to_port(seq_port);
/* LP or HS mode */
intel_dsi->hs = mode;
 
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for batch buffer pools

[Bloomfield, Jon]

> -Original Message-
> From: Nguyen, Michael H
> Sent: Wednesday, December 10, 2014 4:34 PM
> To: Bloomfield, Jon
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for
> batch buffer pools
> 
> Hi Jon,
> 
> On 12/10/2014 03:06 AM, Bloomfield, Jon wrote:
> >> -Original Message-
> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> >> Behalf Of Daniel Vetter
> >> Sent: Tuesday, December 09, 2014 1:18 PM
> >> To: Nguyen, Michael H
> >> Cc: Brad Volkin; intel-gfx@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a
> >> framework for batch buffer pools
> >>
> >> On Mon, Dec 08, 2014 at 02:33:46PM -0800, michael.h.ngu...@intel.com
> >> wrote:
> >>> From: Brad Volkin 
> >>>
> >>> This adds a small module for managing a pool of batch buffers.
> >>> The only current use case is for the command parser, as described in
> >>> the kerneldoc in the patch. The code is simple, but separating it
> >>> out makes it easier to change the underlying algorithms and to
> >>> extend to future use cases should they arise.
> >>>
> >>> The interface is simple: init to create an empty pool, fini to clean
> >>> it up, get to obtain a new buffer. Note that all buffers are
> >>> expected to be inactive before cleaning up the pool.
> >>>
> >>> Locking is currently based on the caller holding the struct_mutex.
> >>> We already do that in the places where we will use the batch pool
> >>> for the command parser.
> >>>
> >>> v2:
> >>> - s/BUG_ON/WARN_ON/ for locking assertions
> >>> - Remove the cap on pool size
> >>> - Switch from alloc/free to init/fini
> >>>
> >>> v3:
> >>> - Idiomatic looping structure in _fini
> >>> - Correct handling of purged objects
> >>> - Don't return a buffer that's too much larger than needed
> >>>
> >>> v4:
> >>> - Rebased to latest -nightly
> >>>
> >>> v5:
> >>> - Remove _put() function and clean up comments to match
> >>>
> >>> v6:
> >>> - Move purged check inside the loop (danvet, from v4 1/7 feedback)
> >>>
> >>> v7:
> >>> - Use single list instead of two. (Chris W)
> >>> - s/active_list/cache_list
> >>> - Squashed in debug patches (Chris W)
> >>>drm/i915: Add a batch pool debugfs file
> >>>
> >>>It provides some useful information about the buffers in
> >>>the global command parser batch pool.
> >>>
> >>>v2: rebase on global pool instead of per-ring pools
> >>>v3: rebase
> >>>
> >>>drm/i915: Add batch pool details to i915_gem_objects debugfs
> >>>
> >>>To better account for the potentially large memory consumption
> >>>of the batch pool.
> >>>
> >>> Issue: VIZ-4719
> >>> Signed-off-by: Brad Volkin 
> >>> ---
> >>>   Documentation/DocBook/drm.tmpl |   5 ++
> >>>   drivers/gpu/drm/i915/Makefile  |   1 +
> >>>   drivers/gpu/drm/i915/i915_debugfs.c|  71 ++--
> >>>   drivers/gpu/drm/i915/i915_drv.h|  21 +
> >>>   drivers/gpu/drm/i915/i915_gem.c|   1 +
> >>>   drivers/gpu/drm/i915/i915_gem_batch_pool.c | 132
> >>> +
> >>>   6 files changed, 222 insertions(+), 9 deletions(-)  create mode
> >>> 100644 drivers/gpu/drm/i915/i915_gem_batch_pool.c
> >>>
> >>> diff --git a/Documentation/DocBook/drm.tmpl
> >>> b/Documentation/DocBook/drm.tmpl index 85287cb..022923a 100644
> >>> --- a/Documentation/DocBook/drm.tmpl
> >>> +++ b/Documentation/DocBook/drm.tmpl
> >>> @@ -4029,6 +4029,11 @@ int num_ioctls;
> >>> !Idrivers/gpu/drm/i915/i915_cmd_parser.c
> >>> 
> >>> 
> >>> +Batchbuffer Pools
> >>> +!Pdrivers/gpu/drm/i915/i915_gem_batch_pool.c batch pool
> >>> +!Idrivers/gpu/drm/i915/i915_gem_batch_pool.c
> >>> +  
> >>> +  
> >>>   Logical Rings, Logical Ring Contexts and
> >>> Execlists  !Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings,
> >>> Logical Ring Contexts and Execlists
> >>> !Idrivers/gpu/drm/i915/intel_lrc.c
> >>> diff --git a/drivers/gpu/drm/i915/Makefile
> >>> b/drivers/gpu/drm/i915/Makefile index e4083e4..c8dbb37d 100644
> >>> --- a/drivers/gpu/drm/i915/Makefile
> >>> +++ b/drivers/gpu/drm/i915/Makefile
> >>> @@ -19,6 +19,7 @@ i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
> >>>
> >>>   # GEM code
> >>>   i915-y += i915_cmd_parser.o \
> >>> +   i915_gem_batch_pool.o \
> >>> i915_gem_context.o \
> >>> i915_gem_render_state.o \
> >>> i915_gem_debug.o \
> >>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> >>> b/drivers/gpu/drm/i915/i915_debugfs.c
> >>> index d0e445e..3c3bf98 100644
> >>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> >>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >>> @@ -359,6 +359,33 @@ static int per_file_stats(int id, void *ptr,
> >>> void
> >> *data)
> >>>   return 0;
> >>>   }
> >>>
> >>> +#define print_file_stats(m, name, stats) \
> >>> + seq_printf(m, "%s: %u objects, %zu bytes (%zu active, %zu
> >>> +inactive,
> >> %zu global, %zu shar

[Intel-gfx] [PATCH] drm/i915: Call the lrc irq handler correctly

[Daniel Vetter]

We consistently use the _irq_handler postfix for functions called in
hardirq context. Especially when it's a non-static function hardirq is
a crazy enough calling context to warrant this level of ocd. So rename
it.

Cc: Thomas Daniel 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_irq.c  | 10 +-
 drivers/gpu/drm/i915/intel_lrc.c |  4 ++--
 drivers/gpu/drm/i915/intel_lrc.h |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e6a1db36928e..e3dd2d62c992 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1385,14 +1385,14 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_device *dev,
if (rcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, ring);
if (rcs & GT_CONTEXT_SWITCH_INTERRUPT)
-   intel_execlists_handle_ctx_events(ring);
+   intel_lrc_irq_handler(ring);
 
bcs = tmp >> GEN8_BCS_IRQ_SHIFT;
ring = &dev_priv->ring[BCS];
if (bcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, ring);
if (bcs & GT_CONTEXT_SWITCH_INTERRUPT)
-   intel_execlists_handle_ctx_events(ring);
+   intel_lrc_irq_handler(ring);
} else
DRM_ERROR("The master control interrupt lied (GT0)!\n");
}
@@ -1408,14 +1408,14 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_device *dev,
if (vcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, ring);
if (vcs & GT_CONTEXT_SWITCH_INTERRUPT)
-   intel_execlists_handle_ctx_events(ring);
+   intel_lrc_irq_handler(ring);
 
vcs = tmp >> GEN8_VCS2_IRQ_SHIFT;
ring = &dev_priv->ring[VCS2];
if (vcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, ring);
if (vcs & GT_CONTEXT_SWITCH_INTERRUPT)
-   intel_execlists_handle_ctx_events(ring);
+   intel_lrc_irq_handler(ring);
} else
DRM_ERROR("The master control interrupt lied (GT1)!\n");
}
@@ -1442,7 +1442,7 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device 
*dev,
if (vcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, ring);
if (vcs & GT_CONTEXT_SWITCH_INTERRUPT)
-   intel_execlists_handle_ctx_events(ring);
+   intel_lrc_irq_handler(ring);
} else
DRM_ERROR("The master control interrupt lied (GT3)!\n");
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a82020ea9d0a..89b5577afe71 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -474,13 +474,13 @@ static bool execlists_check_remove_request(struct 
intel_engine_cs *ring,
 }
 
 /**
- * intel_execlists_handle_ctx_events() - handle Context Switch interrupts
+ * intel_lrc_irq_handler() - handle Context Switch interrupts
  * @ring: Engine Command Streamer to handle.
  *
  * Check the unread Context Status Buffers and manage the submission of new
  * contexts to the ELSP accordingly.
  */
-void intel_execlists_handle_ctx_events(struct intel_engine_cs *ring)
+void intel_lrc_irq_handler(struct intel_engine_cs *ring)
 {
struct drm_i915_private *dev_priv = ring->dev->dev_private;
u32 status_pointer;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 14b216b9be7f..960fcbd2c98a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -112,7 +112,7 @@ struct intel_ctx_submit_request {
int elsp_submitted;
 };
 
-void intel_execlists_handle_ctx_events(struct intel_engine_cs *ring);
+void intel_lrc_irq_handler(struct intel_engine_cs *ring);
 void intel_execlists_retire_requests(struct intel_engine_cs *ring);
 
 #endif /* _INTEL_LRC_H_ */
-- 
2.1.3

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

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Updating assorted register and status page definitions

[Dave Gordon]

On 10/12/14 10:40, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:06PM +, john.c.harri...@intel.com wrote:
>> From: Dave Gordon 
>>
>> Added various definitions that will be useful for the scheduler in general 
>> and
>> pre-emptive context switching in particular.
>>
>> Change-Id: Ica805b94160426def51f5d520f5ce51c60864a98
>> For: VIZ-1587
>> Signed-off-by: Dave Gordon 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h |   30 ++-
>>  drivers/gpu/drm/i915/intel_ringbuffer.h |   40 
>> +--
>>  2 files changed, 67 insertions(+), 3 deletions(-)

[snip]

>> +/*
>> + * Tracking; these are updated by the GPU at the beginning and/or end of 
>> every
>> + * batch. One pair for regular buffers, the other for preemptive ones.
>> + */
>> +#define I915_BATCH_DONE_SEQNO   0x30  /* Completed batch seqno  
>>   */
>> +#define I915_BATCH_ACTIVE_SEQNO 0x31  /* In progress batch 
>> seqno  */
>> +#define I915_PREEMPTIVE_DONE_SEQNO  0x32  /* Completed preemptive batch   */
>> +#define I915_PREEMPTIVE_ACTIVE_SEQNO0x33  /* In progress preemptive 
>> batch */
> 
> This are software define and currently not yet used I think. Imo better to
> add them together with the scheduler code that uses them. Splitting out
> #define patches only makes sense if they can be reviewed separately (e.g.
> registers with Bspec). Just adding software stuff (structs, enums, offsets
> not enforced by hw) should be added with the actual code using it.

OK

>> +
>> +/*
>> + * Preemption; these are used by the GPU to save important registers
>> + */
>> +#define I915_SAVE_PREEMPTED_RING_PTR0x34  /* HEAD before preemption 
>> */
>> +#define I915_SAVE_PREEMPTED_BB_PTR  0x35  /* BB ptr before preemption   */
>> +#define I915_SAVE_PREEMPTED_SBB_PTR 0x36  /* SBB before preemption  */
>> +#define I915_SAVE_PREEMPTED_UHPTR   0x37  /* UHPTR after preemption */
>> +#define I915_SAVE_PREEMPTED_HEAD0x38  /* HEAD after preemption  */
>> +#define I915_SAVE_PREEMPTED_TAIL0x39  /* TAIL after preemption  */
>> +#define I915_SAVE_PREEMPTED_STATUS  0x3A  /* RS preemption status   */
>> +#define I915_SAVE_PREEMPTED_NOPID   0x3B  /* Dummy  */
> 
> I guess this is hardcoded in hw? In that case a HWS instead of I915 prefix
> sounds better to me to make it clear this is not something i915/gem code
> invented. Also comment should state whether this is execlist or gen8+ or
> something like that.
> -Daniel

No, these are s/w too, so they can be added later if that's preferred.

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

Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for batch buffer pools

[Michael H. Nguyen]

Hi Jon,

On 12/10/2014 03:06 AM, Bloomfield, Jon wrote:

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Daniel Vetter
Sent: Tuesday, December 09, 2014 1:18 PM
To: Nguyen, Michael H
Cc: Brad Volkin; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for
batch buffer pools

On Mon, Dec 08, 2014 at 02:33:46PM -0800, michael.h.ngu...@intel.com
wrote:

From: Brad Volkin 

This adds a small module for managing a pool of batch buffers.
The only current use case is for the command parser, as described in
the kerneldoc in the patch. The code is simple, but separating it out
makes it easier to change the underlying algorithms and to extend to
future use cases should they arise.

The interface is simple: init to create an empty pool, fini to clean
it up, get to obtain a new buffer. Note that all buffers are expected
to be inactive before cleaning up the pool.

Locking is currently based on the caller holding the struct_mutex.
We already do that in the places where we will use the batch pool for
the command parser.

v2:
- s/BUG_ON/WARN_ON/ for locking assertions
- Remove the cap on pool size
- Switch from alloc/free to init/fini

v3:
- Idiomatic looping structure in _fini
- Correct handling of purged objects
- Don't return a buffer that's too much larger than needed

v4:
- Rebased to latest -nightly

v5:
- Remove _put() function and clean up comments to match

v6:
- Move purged check inside the loop (danvet, from v4 1/7 feedback)

v7:
- Use single list instead of two. (Chris W)
- s/active_list/cache_list
- Squashed in debug patches (Chris W)
   drm/i915: Add a batch pool debugfs file

   It provides some useful information about the buffers in
   the global command parser batch pool.

   v2: rebase on global pool instead of per-ring pools
   v3: rebase

   drm/i915: Add batch pool details to i915_gem_objects debugfs

   To better account for the potentially large memory consumption
   of the batch pool.

Issue: VIZ-4719
Signed-off-by: Brad Volkin 
---
  Documentation/DocBook/drm.tmpl |   5 ++
  drivers/gpu/drm/i915/Makefile  |   1 +
  drivers/gpu/drm/i915/i915_debugfs.c|  71 ++--
  drivers/gpu/drm/i915/i915_drv.h|  21 +
  drivers/gpu/drm/i915/i915_gem.c|   1 +
  drivers/gpu/drm/i915/i915_gem_batch_pool.c | 132
+
  6 files changed, 222 insertions(+), 9 deletions(-)  create mode
100644 drivers/gpu/drm/i915/i915_gem_batch_pool.c

diff --git a/Documentation/DocBook/drm.tmpl
b/Documentation/DocBook/drm.tmpl index 85287cb..022923a 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4029,6 +4029,11 @@ int num_ioctls;
!Idrivers/gpu/drm/i915/i915_cmd_parser.c


+Batchbuffer Pools
+!Pdrivers/gpu/drm/i915/i915_gem_batch_pool.c batch pool
+!Idrivers/gpu/drm/i915/i915_gem_batch_pool.c
+  
+  
  Logical Rings, Logical Ring Contexts and
Execlists  !Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings,
Logical Ring Contexts and Execlists
!Idrivers/gpu/drm/i915/intel_lrc.c
diff --git a/drivers/gpu/drm/i915/Makefile
b/drivers/gpu/drm/i915/Makefile index e4083e4..c8dbb37d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -19,6 +19,7 @@ i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o

  # GEM code
  i915-y += i915_cmd_parser.o \
+ i915_gem_batch_pool.o \
  i915_gem_context.o \
  i915_gem_render_state.o \
  i915_gem_debug.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445e..3c3bf98 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -359,6 +359,33 @@ static int per_file_stats(int id, void *ptr, void

*data)

return 0;
  }

+#define print_file_stats(m, name, stats) \
+   seq_printf(m, "%s: %u objects, %zu bytes (%zu active, %zu inactive,

%zu global, %zu shared, %zu unbound)\n", \

+  name, \
+  stats.count, \
+  stats.total, \
+  stats.active, \
+  stats.inactive, \
+  stats.global, \
+  stats.shared, \
+  stats.unbound)


"print_file_stats" might be better named "print_obj_stats" or similar. As it 
stands
there is nothing in its name to suggest its purpose is to describe an object.
I guess the fnc name 'print_file_stats' was chosen b/c it takes a 
'stats' parameter of type 'struct file_stats' and prints the members. 
Seems fair to leave it I think as its generic.




+
+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;
+
+   memset(&stats, 0, sizeof(stats));
+
+   list_for_each_entry(obj,
+   &de

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Prelude to splitting i915_gem_do_execbuffer in two

[Dave Gordon]

On 10/12/14 10:58, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
>> From: John Harrison 
>>
>> The scheduler decouples the submission of batch buffers to the driver with 
>> their
>> submission to the hardware. This basically means splitting the execbuffer()
>> function in half. This change rearranges some code ready for the split to 
>> occur.
> 
> Now there's the curios question: Where will the split in top/bottom halves
> be? Without that I have no idea whether it makes sense and so can't review
> this patch. At least if the goal is to really prep for the scheduler and
> not just move a few lines around ;-)
> -Daniel
> 
[snip]
>>  
>> +i915_gem_execbuffer_move_to_active(vmas, ring);
>> +
>> +/* To be split into two functions here... */
>> +
>> +/* Unconditionally invalidate gpu caches and ensure that we do flush
>> + * any residual writes from the previous batch.
>> + */
>> +ret = logical_ring_invalidate_all_caches(ringbuf);

It'll be where the marker comment is above. Ahead of that point is stuff
to do with setting up software state; after that we're talking to h/w.
When the scheduler code goes it, it decouples the two by interposing at
this point. Then batches go into it with s/w state set up, but don't get
to talk to the h/w until they're selected for execution, possibly in a
different order.

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

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Jan Kiszka]

On 2014-12-04 03:24, Jike Song wrote:
> Hi all,
> 
>  We are pleased to announce the first release of KVMGT project. KVMGT is
> the implementation of Intel GVT-g technology, a full GPU virtualization
> solution. Under Intel GVT-g, a virtual GPU instance is maintained for
> each VM, with part of performance critical resources directly assigned.
> The capability of running native graphics driver inside a VM, without
> hypervisor intervention in performance critical paths, achieves a good
> balance of performance, feature, and sharing capability.
> 
> 
>  KVMGT is still in the early stage:
> 
>   - Basic functions of full GPU virtualization works, guest can see a
> full-featured vGPU.
> We ran several 3D workloads such as lightsmark, nexuiz, urbanterror
> and warsow.
> 
>   - Only Linux guest supported so far, and PPGTT must be disabled in
> guest through a
> kernel parameter(see README.kvmgt in QEMU).
> 
>   - This drop also includes some Xen specific changes, which will be
> cleaned up later.
> 
>   - Our end goal is to upstream both XenGT and KVMGT, which shares ~90%
> logic for vGPU
> device model (will be part of i915 driver), with only difference in
> hypervisor
> specific services
> 
>   - insufficient test coverage, so please bear with stability issues :)
> 
> 
> 
>  There are things need to be improved, esp. the KVM interfacing part:
> 
> 1a domid was added to each KVMGT guest
> 
> An ID is needed for foreground OS switching, e.g.
> 
> # echo >/sys/kernel/vgt/control/foreground_vm
> 
> domid 0 is reserved for host OS.
> 
> 
>  2SRCU workarounds.
> 
> Some KVM functions, such as:
> 
> kvm_io_bus_register_dev
> install_new_memslots
> 
> must be called *without* &kvm->srcu read-locked. Otherwise it
> hangs.
> 
> In KVMGT, we need to register an iodev only *after* BAR
> registers are
> written by guest. That means, we already have &kvm->srcu hold -
> trapping/emulating PIO(BAR registers) makes us in such a condition.
> That will make kvm_io_bus_register_dev hangs.
> 
> Currently we have to disable rcu_assign_pointer() in such
> functions.
> 
> These were dirty workarounds, your suggestions are high welcome!
> 
> 
> 3syscalls were called to access "/dev/mem" from kernel
> 
> An in-kernel memslot was added for aperture, but using syscalls
> like
> open and mmap to open and access the character device "/dev/mem",
> for pass-through.
> 
>  
> 
> 
> The source codes(kernel, qemu as well as seabios) are available at github:
> 
> git://github.com/01org/KVMGT-kernel
> git://github.com/01org/KVMGT-qemu
> git://github.com/01org/KVMGT-seabios
> 
> In the KVMGT-qemu repository, there is a "README.kvmgt" to be referred.
> 
> 
> 
> More information about Intel GVT-g and KVMGT can be found at:
> 
> 
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
> 
> 
> http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%20GPU%20Virtualization%20Solution_1.pdf
> 
> 
> 
> Appreciate your comments, BUG reports, and contributions!
> 

There is an even increasing interest to keep KVM's in-kernel guest
interface as small as possible, specifically for security reasons. I'm
sure there are some good performance reasons to create a new in-kernel
device model, but I suppose those will need good evidences why things
are done in the way they finally should be - and not via a user-space
device model. This is likely not a binary decision (all userspace vs. no
userspace), it is more about the size and robustness of the in-kernel
model vs. its performance.

One aspect could also be important: Are there hardware improvements in
sight that will eventually help to reduce the in-kernel device model and
make the overall design even more robust? How will those changes fit
best into a proposed user/kernel split?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] intel mst + club 3d csv5300 hub only in clone mode + xorg crashes

[stephan schultchen]

hey,

i have a dell xps 13 with an integrated intel adapter running on kubuntu
14.10, and a club3d csv5300 displayport hub with two attached dell displays.

i am currently using the 3.18 kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/

the problem is that the displays attached to the DP hub only work in clone
mode.

and whenever i disconnect, or reconnect a display to the hub XOrg is
crashing with a segfault.

connecting and disconnecting the hub itself works fine.

here are the last lines of the xorg log:

[   310.480] (II) intel(0): resizing framebuffer to 3840x1200
[   310.485] (II) intel(0): switch to mode 1920x1080@60.0 on eDP1 using
pipe 0, position (0, 0), rotation normal, reflection none
[   310.516] (II) intel(0): switch to mode 1920x1080@60.0 on DP1 using pipe
1, position (0, 0), rotation normal, reflection none
[   310.524] (II) intel(0): switch to mode 1920x1200@60.0 on DP1 using pipe
1, position (1920, 0), rotation normal, reflection none
[   323.675] (II) intel(0): resizing framebuffer to 1920x1080
[   323.679] (II) intel(0): switch to mode 1920x1080@60.0 on eDP1 using
pipe 0, position (0, 0), rotation normal, reflection none
[   324.282] (II) intel(0): switch to mode 1920x1200@60.0 on DP1 using pipe
1, position (1920, 0), rotation normal, reflection none
[   324.808] (II) intel(0): switch to mode 1920x1080@60.0 on eDP1 using
pipe 0, position (0, 0), rotation normal, reflection none
[   324.808] (II) intel(0): switch to mode 1920x1200@60.0 on DP1 using pipe
1, position (1920, 0), rotation normal, reflection none
[   324.816] (II) intel(0): switch to mode 1920x1080@60.0 on eDP1 using
pipe 0, position (0, 0), rotation normal, reflection none
[   324.816] (II) intel(0): switch to mode 1920x1200@60.0 on DP1 using pipe
1, position (1920, 0), rotation normal, reflection none
[   324.832] (EE)
[   324.832] (EE) Backtrace:
[   324.832] (EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x7ff161614666]
[   324.832] (EE) 1: /usr/bin/X (0x7ff16145e000+0x1ba869) [0x7ff161618869]
[   324.832] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6
(0x7ff15f192000+0x36da0) [0x7ff15f1c8da0]
[   324.832] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7ff15b58+0x69d85) [0x7ff15b5e9d85]
[   324.832] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7ff15b58+0x10be22) [0x7ff15b68be22]
[   324.832] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7ff15b58+0x6cb23) [0x7ff15b5ecb23]
[   324.832] (EE) 6: /usr/bin/X (WakeupHandler+0xaa) [0x7ff1614b9e2a]
[   324.832] (EE) 7: /usr/bin/X (WaitForSomething+0x1c7) [0x7ff161611a97]
[   324.832] (EE) 8: /usr/bin/X (0x7ff16145e000+0x56ec1) [0x7ff1614b4ec1]
[   324.832] (EE) 9: /usr/bin/X (0x7ff16145e000+0x5b2a6) [0x7ff1614b92a6]
[   324.832] (EE) 10: /lib/x86_64-linux-gnu/libc.so.6
(__libc_start_main+0xf5) [0x7ff15f1b3ec5]
[   324.832] (EE) 11: /usr/bin/X (0x7ff16145e000+0x456ae) [0x7ff1614a36ae]
[   324.832] (EE)
[   324.832] (EE) Segmentation fault at address 0x1e0
[   324.832] (EE)
Fatal server error:
[   324.832] (EE) Caught signal 11 (Segmentation fault). Server aborting
[   324.832] (EE)
[   324.832] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[   324.832] (EE) Please also check the log file at "/var/log/Xorg.0.log"
for additional information.
[   324.832] (EE)
[   324.832] (II) AIGLX: Suspending AIGLX clients for VT switch
[   326.124] (EE) Server terminated with error (1). Closing log file.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Untangle execlist tracking

[Daniel Vetter]

On Wed, Nov 12, 2014 at 10:53:22AM +, Nick Hoath wrote:
> This patchset merges execlist queue items in to gem requests. It does this by 
> using the reference count added by John Harrison's "Replace seqno values with
> request structures" patchset to ensure that the gem request is available for
> the whole execlist submission lifespan.
> 
> 
> v2: merge intel_ctx_submit_request and drm_i915_gem_request, rebase changes &
>add cover letter

Ok, sorry for the long delay - I got a bit distracted and also thought it
would be better to get John's and Thomas' patches in first since this is
based upon them.

But that's now out of the way and I think this is definitely a good step
into the right direction. So can you please rebase and resend so that we
can do the review&merge dance?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request

[Daniel Vetter]

On Wed, Nov 12, 2014 at 12:13:03PM +, Nick Hoath wrote:
> On 12/11/2014 11:24, Chris Wilson wrote:
> >On Wed, Nov 12, 2014 at 10:53:26AM +, Nick Hoath wrote:
> > seq_putc(m, '\n');
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >>b/drivers/gpu/drm/i915/i915_drv.h
> >>index afa9c35..0fe238c 100644
> >>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>@@ -2027,6 +2027,28 @@ struct drm_i915_gem_request {
> >>struct list_head free_list;
> >>
> >>uint32_t uniq;
> >>+
> >>+   /**
> >>+* The ELSP only accepts two elements at a time, so we queue 
> >>context/tail
> >>+* pairs on a given queue (ring->execlist_queue) until the hardware is
> >>+* available. The queue serves a double purpose: we also use it to keep 
> >>track
> >>+* of the up to 2 contexts currently in the hardware (usually one in 
> >>execution
> >>+* and the other queued up by the GPU): We only remove elements from 
> >>the head
> >>+* of the queue when the hardware informs us that an element has been
> >>+* completed.
> >>+*
> >>+* All accesses to the queue are mediated by a spinlock 
> >>(ring->execlist_lock).
> >>+*/
> >>+
> >>+   /** Execlist link in the submission queue.*/
> >>+   struct list_head execlist_link;
> >
> >This is redundant. The request should only be one of the pending or active
> >lists at any time.
> >
> This is used by the pending execlist requests list owned by the
> intel_engine_cs. The request isn't in both the active and pending execlist
> engine lists.

I guess we'll eventually need to subsume this into the scheduler's list of
ctxs. Or reuse it there. Imo ok for now, might just need a rename
longterm.

> >>+   /** Execlists workqueue for processing this request in a bottom half */
> >>+   struct work_struct work;
> >
> >For what purpose? This is not needed.
> This worker is currently used to free up execlist requests. This goes away
> when Thomas Daniel's patchset is merged.
> I have spotted a bug in the cleanup handler with the merged
> requests/execlists cleanup though.

I guess this will drop out on a rebase now that everything has landed?

> >>+   /** Execlists no. of times this request has been sent to the ELSP */
> >>+   int elsp_submitted;
> >
> >A request can only be submitted exactly once at any time. This
> >bookkeeping is not part of the request.
> This is a refcount to preserve the request if it has been resubmitted due to
> preemption or TDR, due to a race condition between the HW finishing with the
> item and the cleanup/resubmission. Have a look at
> e1fee72c2ea2e9c0c6e6743d32a6832f21337d6c which contains a much better
> description of why this exists.

Yeah this one is still a bit crazy but guess that's just how it is ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/2] Track calls to intel(_logical)_ring_{begin, advance}

[Chris Wilson]

On Wed, Dec 10, 2014 at 03:07:07PM +, Dave Gordon wrote:
> When adding instructions to a legacy or LRC ringbuffer, the sequence of
> emit() calls must be preceded by a call to intel(_logical)_ring_begin()
> to reserve the required amount of space, and followed by a matching call
> to intel(_logical)_ring_advance().  Historically some (display) code
> didn't use begin/advance, but just inserted instructions ad hoc, which
> would then be sent to the hardware along with the current or next batch,
> but this is not supported and is now regarded as incorrect.
> 
> This commit therefore adds begin/advance tracking, with WARNings where
> various forms of misuse are detected.

Please review the suggested approach I made months ago which avoid all
this ad hoc hilarity.
-Chris

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

[Intel-gfx] [PATCH v2 0/2] Track calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance().  Historically some (display) code
didn't use begin/advance, but just inserted instructions ad hoc, which
would then be sent to the hardware along with the current or next batch,
but this is not supported and is now regarded as incorrect.

This commit therefore adds begin/advance tracking, with WARNings where
various forms of misuse are detected.

v2: remove redundant "#if 1" markers

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

[Intel-gfx] [PATCH v2 2/2] drm/i915: Track nested calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

With the current deferred-submission model, if a problem arises part-way
through the insertion of instructions into the ringbuffer (e.g. due to
one of the begin() calls finding there's not enough space), we avoid
sending the incomplete sequence to the h/w; but currently have no means
of undoing the work so far, which will lead to undefined behaviour when
the next batch is submitted (probably TDR will trigger a reset first,
though, and clean up the ring state).

A future idea is to move to an atomic-submission model, where all the
space required for a batch submission is reserved up front, and in the
event of failure partway through, the work can be abandoned without
side-effects. This will be required for the forthcoming GPU scheduler
(specifically, for preemption).

To support this, we allow nested begin/advance pairs.  Specifically,
the outermost pair defines the total space reservation; inner pairs
can be nested ad lib, but all inner reservations at any level must
fit entirely within the outermost one.  Thus, this is permitted:

begin(128) - guarantees that up to 128 dwords can now be
emitted without waiting for more freespace
begin(6)
advance
begin(10)
advance
begin(8)
advance
etc, as long as the total is no more than 128 dwords
advance-and-submit

The execbuffer code will later be enhanced to use this approach. In the
mean time, the traditional single-level begin/advance mechanism remains
fully supported.

This commit changes only the begin/advance checking code, to permit (but
not require) nested begin/advance pairs.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_ringbuffer.h |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index a6660c1..68665c7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -416,8 +416,17 @@ static inline void __intel_ringbuffer_begin(struct 
intel_ringbuffer *ringbuf,
WARN_ON(nbytes <= 0);
 
if (ringbuf->rsv_level++) {
-   /* begin() called twice or more without advance() */
-   WARN_ON(1);
+   /*
+* A nested reservation; check that it falls entirely
+* within the outer block. Don't adjust remaining space.
+*/
+   WARN_ON(ringbuf->rsv_start < 0);
+   WARN_ON(ringbuf->rsv_start & 7);
+   WARN_ON(ringbuf->tail & 7);
+   WARN_ON(ringbuf->tail > ringbuf->effective_size);
+   WARN_ON(ringbuf->tail > ringbuf->rsv_start + ringbuf->rsv_size);
+   WARN_ON(ringbuf->tail + nbytes > ringbuf->effective_size);
+   WARN_ON(ringbuf->tail + nbytes > ringbuf->rsv_start + 
ringbuf->rsv_size);
} else {
/*
 * A new reservation; validate and record the start and
@@ -436,7 +445,7 @@ static inline void __intel_ringbuffer_begin(struct 
intel_ringbuffer *ringbuf,
 
 static inline void __intel_ringbuffer_check(struct intel_ringbuffer *ringbuf)
 {
-   WARN_ON(ringbuf->rsv_level-- != 1);
+   WARN_ON(ringbuf->rsv_level-- <= 0);
WARN_ON(ringbuf->rsv_start < 0 || ringbuf->rsv_size < 0);
WARN_ON(ringbuf->tail & 7);
WARN_ON(ringbuf->tail > ringbuf->rsv_start + ringbuf->rsv_size);
-- 
1.7.9.5

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

[Intel-gfx] [PATCH v2 1/2] drm/i915: Track & check calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance() (note that this used to trigger
immediate submission to the h/w, but now actual submission is deferred
until all the instructions for a single batch submission have been
assembled). Historically some (display) code didn't use begin/advance,
but just inserted instructions ad hoc, which would then be sent to the
hardware along with the current or next batch, but this is not supported
and is now regarded as incorrect.

This commit therefore adds begin/advance tracking, with WARNings where
various forms of misuse are detected. These include:
* advance without begin
* begin without advance before submission to h/w
* multiple begins without an advance between
* exceeding the space reserved by begin
* leaving the ring misaligned
* ring buffer overrun (negative freespace)

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_lrc.c|4 ++-
 drivers/gpu/drm/i915/intel_lrc.h|   11 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |   10 --
 drivers/gpu/drm/i915/intel_ringbuffer.h |   54 ++-
 4 files changed, 74 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a82020e..56e3636 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -825,6 +825,7 @@ void intel_logical_ring_advance_and_submit(struct 
intel_ringbuffer *ringbuf)
struct intel_context *ctx = ringbuf->FIXME_lrc_ctx;
 
intel_logical_ring_advance(ringbuf);
+   WARN_ON(ringbuf->rsv_level != 0);
 
if (intel_ring_stopped(ring))
return;
@@ -1084,7 +1085,8 @@ int intel_logical_ring_begin(struct intel_ringbuffer 
*ringbuf, int num_dwords)
if (ret)
return ret;
 
-   ringbuf->space -= num_dwords * sizeof(uint32_t);
+   __intel_ringbuffer_begin(ringbuf, num_dwords);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 14b216b..9a0457e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -48,8 +48,17 @@ void intel_logical_ring_advance_and_submit(struct 
intel_ringbuffer *ringbuf);
  */
 static inline void intel_logical_ring_advance(struct intel_ringbuffer *ringbuf)
 {
-   ringbuf->tail &= ringbuf->size - 1;
+   __intel_ringbuffer_check(ringbuf);
+
+   /*
+* Tail == effecive_size is legitimate (buffer exactly full).
+* Tail > effective_size is not, and should give a warning,
+* but we'll reset tail in both cases to prevent further chaos
+*/
+   if (ringbuf->tail >= ringbuf->effective_size)
+   ringbuf->tail -= ringbuf->effective_size;
 }
+
 /**
  * intel_logical_ring_emit() - write a DWORD to the ringbuffer.
  * @ringbuf: Ringbuffer to write to.
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 83accb7..5874eab 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -55,6 +55,7 @@ int __intel_ring_space(int head, int tail, int size)
int space = head - tail;
if (space <= 0)
space += size;
+   WARN_ON(space < I915_RING_FREE_SPACE);
return space - I915_RING_FREE_SPACE;
 }
 
@@ -84,7 +85,10 @@ bool intel_ring_stopped(struct intel_engine_cs *ring)
 void __intel_ring_advance(struct intel_engine_cs *ring)
 {
struct intel_ringbuffer *ringbuf = ring->buffer;
-   ringbuf->tail &= ringbuf->size - 1;
+
+   intel_ring_advance(ring);
+   WARN_ON(ringbuf->rsv_level != 0);
+
if (intel_ring_stopped(ring))
return;
ring->write_tail(ring, ringbuf->tail);
@@ -1911,6 +1915,7 @@ static int intel_ring_wait_request(struct intel_engine_cs 
*ring, int n)
return 0;
 
list_for_each_entry(request, &ring->request_list, list) {
+   /* Would completion of this request free enough space? */
if (__intel_ring_space(request->tail, ringbuf->tail,
   ringbuf->size) >= n) {
break;
@@ -2096,7 +2101,8 @@ int intel_ring_begin(struct intel_engine_cs *ring,
if (ret)
return ret;
 
-   ring->buffer->space -= num_dwords * sizeof(uint32_t);
+   __intel_ringbuffer_begin(ring->buffer, num_dwords);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 6dbb6f4..a6660c1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -112,6 +112,11 @@ struct intel_ringbuffer {
int size;
int effective_size;
 
+   /* these let advance() chec

[Intel-gfx] [PATCH v2] drm/i915: Forcewake Register Range changes for CHV

[deepak . s]

From: Deepak S 

According to updated BSpec, Render/Common/media Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
forcewake range.

v2: Update media forcewake range (Ville)

Signed-off-by: Deepak S 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_uncore.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 46de8d7..ffdd042 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -647,9 +647,9 @@ void assert_force_wake_inactive(struct drm_i915_private 
*dev_priv)
 
 #define FORCEWAKE_CHV_RENDER_RANGE_OFFSET(reg) \
(REG_RANGE((reg), 0x2000, 0x4000) || \
-REG_RANGE((reg), 0x5000, 0x8000) || \
+REG_RANGE((reg), 0x5200, 0x8000) || \
 REG_RANGE((reg), 0x8300, 0x8500) || \
-REG_RANGE((reg), 0xB000, 0xC000) || \
+REG_RANGE((reg), 0xB000, 0xB480) || \
 REG_RANGE((reg), 0xE000, 0xE800))
 
 #define FORCEWAKE_CHV_MEDIA_RANGE_OFFSET(reg) \
@@ -658,17 +658,14 @@ void assert_force_wake_inactive(struct drm_i915_private 
*dev_priv)
 REG_RANGE((reg), 0x12000, 0x14000) || \
 REG_RANGE((reg), 0x1A000, 0x1C000) || \
 REG_RANGE((reg), 0x1E800, 0x1EA00) || \
-REG_RANGE((reg), 0x3, 0x4))
+REG_RANGE((reg), 0x3, 0x38000))
 
 #define FORCEWAKE_CHV_COMMON_RANGE_OFFSET(reg) \
(REG_RANGE((reg), 0x4000, 0x5000) || \
 REG_RANGE((reg), 0x8000, 0x8300) || \
 REG_RANGE((reg), 0x8500, 0x8600) || \
 REG_RANGE((reg), 0x9000, 0xB000) || \
-REG_RANGE((reg), 0xC000, 0xC800) || \
-REG_RANGE((reg), 0xF000, 0x1) || \
-REG_RANGE((reg), 0x14000, 0x14400) || \
-REG_RANGE((reg), 0x22000, 0x24000))
+REG_RANGE((reg), 0xF000, 0x1))
 
 #define FORCEWAKE_GEN9_UNCORE_RANGE_OFFSET(reg) \
REG_RANGE((reg), 0xB00,  0x2000)
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Forcewake Register Range changes for CHV

[Deepak S]

On Wednesday 10 December 2014 08:01 PM, Ville Syrjälä wrote:

On Thu, Dec 11, 2014 at 12:48:41PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S 

According to updated BSpec, Render/Common Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
forcewake range.

Signed-off-by: Deepak S 
---
  drivers/gpu/drm/i915/intel_uncore.c | 9 +++--
  1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 46de8d7..dd36f9b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -647,9 +647,9 @@ void assert_force_wake_inactive(struct drm_i915_private 
*dev_priv)
  
  #define FORCEWAKE_CHV_RENDER_RANGE_OFFSET(reg) \

(REG_RANGE((reg), 0x2000, 0x4000) || \
-REG_RANGE((reg), 0x5000, 0x8000) || \
+REG_RANGE((reg), 0x5200, 0x8000) || \
 REG_RANGE((reg), 0x8300, 0x8500) || \
-REG_RANGE((reg), 0xB000, 0xC000) || \
+REG_RANGE((reg), 0xB000, 0xB480) || \
 REG_RANGE((reg), 0xE000, 0xE800))
  
  #define FORCEWAKE_CHV_MEDIA_RANGE_OFFSET(reg) \

@@ -665,10 +665,7 @@ void assert_force_wake_inactive(struct drm_i915_private 
*dev_priv)
 REG_RANGE((reg), 0x8000, 0x8300) || \
 REG_RANGE((reg), 0x8500, 0x8600) || \
 REG_RANGE((reg), 0x9000, 0xB000) || \
-REG_RANGE((reg), 0xC000, 0xC800) || \
-REG_RANGE((reg), 0xF000, 0x1) || \
-REG_RANGE((reg), 0x14000, 0x14400) || \
-REG_RANGE((reg), 0x22000, 0x24000))
+REG_RANGE((reg), 0xF000, 0x1))

Looks correct.

It looks like the media offsets could use a small adjustment as well:
- REG_RANGE((reg), 0x3, 0x4)
+ REG_RANGE((reg), 0x3, 0x38000)

So with that changed
Reviewed-by: Ville Syrjälä 


Thanks for reviewing...


One thing I don't understand though; Why is the [0x10,0x18[ range
marked as GWK in the spreadsheet? That's where the forcewake req/ack
registers live as well as some other GTFIFO stuff etc. How can you take
forcewake if the forcewake req/ack itself would need forcewake. I think
this must be an error in the spreadsheet and that range should be GNW.


I think [0x10,0x18] is already above the forecewake range [0x4]. We 
need request for a spec update.
It should be GNK


  
  #define FORCEWAKE_GEN9_UNCORE_RANGE_OFFSET(reg) \

REG_RANGE((reg), 0xB00,  0x2000)
--
1.9.1


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

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Specify bsd rings through exec flag

[Dave Gordon]

On 10/12/14 09:11, Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 02:18:15AM +, Gong, Zhipeng wrote:
>> On Tue, 2014-12-09 at 10:46 +0100, Daniel Vetter wrote:
>>> On Mon, Dec 08, 2014 at 01:55:56PM -0800, Rodrigo Vivi wrote:

[snip]

 diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 index e1ed85a..d9081ec 100644
 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 @@ -1273,8 +1273,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
 *data,
   else if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
   if (HAS_BSD2(dev)) {
   int ring_id;
 - ring_id = gen8_dispatch_bsd_ring(dev, file);
 - ring = &dev_priv->ring[ring_id];
 +
 + switch (args->flags & I915_EXEC_BSD_MASK) {
 + case I915_EXEC_BSD_DEFAULT:
 + ring_id = gen8_dispatch_bsd_ring(dev, file);
 + ring = &dev_priv->ring[ring_id];
 + break;
 + case I915_EXEC_BSD_RING1:
 + ring = &dev_priv->ring[VCS];
>>>
>>> Do we have any use-case for selecting ring1 specifically? I've thought
>>> it's only ring2 that is special?
>> The HEVC GPU commands should be dispatched to BSD RING 1 instead of BSD
>> RING2 as the two rings are asymmetrical. 
>> For the H264 decoding/encoding either ring is OK.
> 
> Well then same arguments applies with ring2 since only ring1 is special?
> It's just to minimize abi and reduce the amount of rope we hand to
> userspace.

Anyone who knows to use any of these flags is taking responsibility for
doing explicit engine allocation, so why not give them all the options
-- if for no other reason, more symmetry is good.

As an examle, there could be a case where userspace knows better than
the kernel how long each batch will take, and can predict an optimal
allocation pattern rather than just flip-flopping. So even when a batch
*can* run on either engine, there might be a reason to pick a specific one.

e.g.short-1 -> ring 1
short-2 -> ring 1
long-1  -> ring 2
short-3 -> ring 1
long-2  -> ring 1

because the program knows that the three short batches together will
take less time than the one first long one.

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Track & check calls to intel(_logical)_ring_{begin, advance}

[Daniel Vetter]

On Wed, Dec 10, 2014 at 03:07:08PM +, Dave Gordon wrote:
> @@ -401,11 +406,59 @@ static inline void intel_ring_emit(struct 
> intel_engine_cs *ring,
>   iowrite32(data, ringbuf->virtual_start + ringbuf->tail);
>   ringbuf->tail += 4;
>  }
> +
> +static inline void __intel_ringbuffer_begin(struct intel_ringbuffer *ringbuf,
> + int num_dwords)
> +{
> + int nbytes = num_dwords * sizeof(uint32_t);
> +#if  1   /* DEBUG CODE */

No #ifdef's in code please, they tend to be either just go stale or just
obfuscate the code.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/4] Add a MAINTAINERS file

[Jani Nikula]

On Wed, 10 Dec 2014, Thomas Wood  wrote:
> Signed-off-by: Thomas Wood 
> ---
>  CONTRIBUTING | 9 +++--
>  MAINTAINERS  | 2 ++
>  2 files changed, 5 insertions(+), 6 deletions(-)
>  create mode 100644 MAINTAINERS
>
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index 0ad0c3a..a2ddf09 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -33,12 +33,9 @@ A short list of contribution guidelines:
>  
>  - When patches from new contributors (without commit access) are stuck, for
>anything related to the regular releases, issues with packaging and
> -  integrating platform support or anything else really please contact the 
> i-g-t
> -  maintainer:
> -
> -Thomas Wood 
> -
> -  Of course please also cc the intel-gfx mailing list.
> +  integrating platform support or any other intel-gpu-tools issues, please
> +  contact one of the maintainers (listed in the MAINTAIENRS file) and cc the

You forgot to git mv MAINTAINERS MAINTAIENRS ;)

Jani.

> +  intel-gfx mailing list.
>  
>  - Especially changes to the testcase should get tested on relevant platforms
>before committing. For Intel employees that's best done using PRTS, see the
> diff --git a/MAINTAINERS b/MAINTAINERS
> new file mode 100644
> index 000..7825e1e
> --- /dev/null
> +++ b/MAINTAINERS
> @@ -0,0 +1,2 @@
> +Daniel Vetter 
> +Thomas Wood 
> -- 
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Quietly reject attempts to create non-pagealigned stolen objects

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1 364/366  365/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(2, M26)PASS(15, M26M37)   
   PASS(1, M37)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Track & check calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance() (note that this used to trigger
immediate submission to the h/w, but now actual submission is deferred
until all the instructions for a single batch submission have been
assembled). Historically some (display) code didn't use begin/advance,
but just inserted instructions ad hoc, which would then be sent to the
hardware along with the current or next batch, but this is not supported
and is now regarded as incorrect.

This commit therefore adds begin/advance tracking, with WARNings where
various forms of misuse are detected. These include:
* advance without begin
* begin without advance before submission to h/w
* multiple begins without an advance between
* exceeding the space reserved by begin
* leaving the ring misaligned
* ring buffer overrun (negative freespace)

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_lrc.c|4 ++-
 drivers/gpu/drm/i915/intel_lrc.h|   11 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |   10 --
 drivers/gpu/drm/i915/intel_ringbuffer.h |   55 ++-
 4 files changed, 75 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a82020e..56e3636 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -825,6 +825,7 @@ void intel_logical_ring_advance_and_submit(struct 
intel_ringbuffer *ringbuf)
struct intel_context *ctx = ringbuf->FIXME_lrc_ctx;
 
intel_logical_ring_advance(ringbuf);
+   WARN_ON(ringbuf->rsv_level != 0);
 
if (intel_ring_stopped(ring))
return;
@@ -1084,7 +1085,8 @@ int intel_logical_ring_begin(struct intel_ringbuffer 
*ringbuf, int num_dwords)
if (ret)
return ret;
 
-   ringbuf->space -= num_dwords * sizeof(uint32_t);
+   __intel_ringbuffer_begin(ringbuf, num_dwords);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 14b216b..9a0457e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -48,8 +48,17 @@ void intel_logical_ring_advance_and_submit(struct 
intel_ringbuffer *ringbuf);
  */
 static inline void intel_logical_ring_advance(struct intel_ringbuffer *ringbuf)
 {
-   ringbuf->tail &= ringbuf->size - 1;
+   __intel_ringbuffer_check(ringbuf);
+
+   /*
+* Tail == effecive_size is legitimate (buffer exactly full).
+* Tail > effective_size is not, and should give a warning,
+* but we'll reset tail in both cases to prevent further chaos
+*/
+   if (ringbuf->tail >= ringbuf->effective_size)
+   ringbuf->tail -= ringbuf->effective_size;
 }
+
 /**
  * intel_logical_ring_emit() - write a DWORD to the ringbuffer.
  * @ringbuf: Ringbuffer to write to.
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 83accb7..5874eab 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -55,6 +55,7 @@ int __intel_ring_space(int head, int tail, int size)
int space = head - tail;
if (space <= 0)
space += size;
+   WARN_ON(space < I915_RING_FREE_SPACE);
return space - I915_RING_FREE_SPACE;
 }
 
@@ -84,7 +85,10 @@ bool intel_ring_stopped(struct intel_engine_cs *ring)
 void __intel_ring_advance(struct intel_engine_cs *ring)
 {
struct intel_ringbuffer *ringbuf = ring->buffer;
-   ringbuf->tail &= ringbuf->size - 1;
+
+   intel_ring_advance(ring);
+   WARN_ON(ringbuf->rsv_level != 0);
+
if (intel_ring_stopped(ring))
return;
ring->write_tail(ring, ringbuf->tail);
@@ -1911,6 +1915,7 @@ static int intel_ring_wait_request(struct intel_engine_cs 
*ring, int n)
return 0;
 
list_for_each_entry(request, &ring->request_list, list) {
+   /* Would completion of this request free enough space? */
if (__intel_ring_space(request->tail, ringbuf->tail,
   ringbuf->size) >= n) {
break;
@@ -2096,7 +2101,8 @@ int intel_ring_begin(struct intel_engine_cs *ring,
if (ret)
return ret;
 
-   ring->buffer->space -= num_dwords * sizeof(uint32_t);
+   __intel_ringbuffer_begin(ring->buffer, num_dwords);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 6dbb6f4..a10d271 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -112,6 +112,11 @@ struct intel_ringbuffer {
int size;
int effective_size;
 
+   /* these let advance() chec

[Intel-gfx] [PATCH 2/2] drm/i915: Track nested calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

With the current deferred-submission model, if a problem arises part-way
through the insertion of instructions into the ringbuffer (e.g. due to
one of the begin() calls finding there's not enough space), we avoid
sending the incomplete sequence to the h/w; but currently have no means
of undoing the work so far, which will lead to undefined behaviour when
the next batch is submitted (probably TDR will trigger a reset first,
though, and clean up the ring state).

A future idea is to move to an atomic-submission model, where all the
space required for a batch submission is reserved up front, and in the
event of failure partway through, the work can be abandoned without
side-effects. This will be required for the forthcoming GPU scheduler
(specifically, for preemption).

To support this, we allow nested begin/advance pairs.  Specifically,
the outermost pair defines the total space reservation; inner pairs
can be nested ad lib, but all inner reservations at any level must
fit entirely within the outermost one.  Thus, this is permitted:

begin(128) - guarantees that up to 128 dwords can now be
emitted without waiting for more freespace
begin(6)
advance
begin(10)
advance
begin(8)
advance
etc, as long as the total is no more than 128 dwords
advance-and-submit

The execbuffer code will later be enhanced to use this approach. In the
mean time, the traditional single-level begin/advance mechanism remains
fully supported.

This commit changes only the begin/advance checking code, to permit (but
not require) nested begin/advance pairs.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_ringbuffer.h |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index a10d271..71cb3ef 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -416,8 +416,17 @@ static inline void __intel_ringbuffer_begin(struct 
intel_ringbuffer *ringbuf,
WARN_ON(nbytes <= 0);
 
if (ringbuf->rsv_level++) {
-   /* begin() called twice or more without advance() */
-   WARN_ON(1);
+   /*
+* A nested reservation; check that it falls entirely
+* within the outer block. Don't adjust remaining space.
+*/
+   WARN_ON(ringbuf->rsv_start < 0);
+   WARN_ON(ringbuf->rsv_start & 7);
+   WARN_ON(ringbuf->tail & 7);
+   WARN_ON(ringbuf->tail > ringbuf->effective_size);
+   WARN_ON(ringbuf->tail > ringbuf->rsv_start + ringbuf->rsv_size);
+   WARN_ON(ringbuf->tail + nbytes > ringbuf->effective_size);
+   WARN_ON(ringbuf->tail + nbytes > ringbuf->rsv_start + 
ringbuf->rsv_size);
} else {
/*
 * A new reservation; validate and record the start and
@@ -437,7 +446,7 @@ static inline void __intel_ringbuffer_begin(struct 
intel_ringbuffer *ringbuf,
 static inline void __intel_ringbuffer_check(struct intel_ringbuffer *ringbuf)
 {
 #if1
-   WARN_ON(ringbuf->rsv_level-- != 1);
+   WARN_ON(ringbuf->rsv_level-- <= 0);
WARN_ON(ringbuf->rsv_start < 0 || ringbuf->rsv_size < 0);
WARN_ON(ringbuf->tail & 7);
WARN_ON(ringbuf->tail > ringbuf->rsv_start + ringbuf->rsv_size);
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 0/2] Track calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance().  Historically some (display) code
didn't use begin/advance, but just inserted instructions ad hoc, which
would then be sent to the hardware along with the current or next batch,
but this is not supported and is now regarded as incorrect.

This commit therefore adds begin/advance tracking, with WARNings where
various forms of misuse are detected.

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

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Add WaForceEnableNonCoherent label

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK -5  364/366  359/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt_kms_render_direct-render  PASS(5, M26)  DMESG_WARN(1, M26)
*ILK  igt_kms_flip_bcs-flip-vs-modeset-interruptible  PASS(4, M26)  
DMESG_WARN(1, M26)
*ILK  igt_kms_flip_flip-vs-panning  PASS(6, M26)  DMESG_WARN(1, M26)
*ILK  igt_kms_flip_flip-vs-rmfb-interruptible  NSPT(1, M26)PASS(3, M26) 
 DMESG_WARN(1, M26)
*ILK  igt_kms_flip_rcs-flip-vs-panning  PASS(4, M26)  NSPT(1, M26)
*ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(2, M26)PASS(14, M26M37)   
   NSPT(1, M26)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Quietly reject attempts to create non-pagealigned stolen objects

[Ville Syrjälä]

On Wed, Dec 10, 2014 at 02:53:01PM +0100, Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 11:13:28AM +, Chris Wilson wrote:
> > On Wed, Dec 10, 2014 at 11:23:44AM +0100, Daniel Vetter wrote:
> > > On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> > > > This added as a BUG_ON as it considered that no one would ever request
> > > > an unaligned object. However, it turns out that some BIOSes will
> > > > allocate a scanout that is offset from 0 and not aligned to a page
> > > > boundary, and we were passing this through and hitting the BUG_ON during
> > > > boot.
> > > > 
> > > > Quietly reject such a request to reserve the unaligned stolen object and
> > > > let the boot continue, restoring previous behaviour (i.e. no BIOS
> > > > framebuffer preservation).
> > > > 
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: sta...@vger.kernel.org
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_gem_stolen.c | 10 ++
> > > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> > > > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > > index 5c616ec2c5c8..a3bc0fa07c6c 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > > @@ -646,13 +646,15 @@ 
> > > > i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
> > > > DRM_DEBUG_KMS("creating preallocated stolen object: 
> > > > stolen_offset=%x, gtt_offset=%x, size=%x\n",
> > > > stolen_offset, gtt_offset, size);
> > > >  
> > > > -   /* KISS and expect everything to be page-aligned */
> > > > -   BUG_ON(stolen_offset & 4095);
> > > > -   BUG_ON(size & 4095);
> > > > -
> > > > if (WARN_ON(size == 0))
> > > > return NULL;
> > > >  
> > > > +   /* KISS and expect everything to be GTT page-aligned */
> > > > +   if ((stolen_offset | size) & 4095) {
> > > 
> > > Imo we should stil WARN_ON and fixup up the takeover code to align things
> > > properly ...
> > 
> > You shot down my idea for storing deltas into objects in the past...
> > 
> > The BIOS scanout is properly aligned to the rules of the display engine,
> > just not according to our mm restrictions. The bigger question is
> > whether our 1:1 offset-to-stolen mapping is correct. It could well be
> > that that the framebuffer is at stolen address 0, but just has a GTT
> > offset.
> > 
> > So the only question is whether we reject the object reservation at the
> > stolen layer or at the plane config layer. I decided that stolen was
> > better, because it is failing to meet our mm restrictions not
> > hardware restrictions.
> 
> The framebuffer layer can very much cope with offsets, so no need to
> reject it. We just need to patch up the framebuffer we create a bit.
> Offsets are in pixels but that should align well.

Or someone can dig out my old fb->offsets[] handling patch (and double check
that it's sane, fixing if not).

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

[Intel-gfx] [PATCH i-g-t 3/4] NEWS: Updates

[Thomas Wood]

Signed-off-by: Thomas Wood 
---
 NEWS | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 103c7cd..447ba77 100644
--- a/NEWS
+++ b/NEWS
@@ -1,18 +1,30 @@
 Release 1.9 (-XX-XX)
 
 
-- As usual piles of new testcases and improvements to existing ones.
+- New test cases added: drm_import_export, gem_gpgpu_fill, gem_ppgtt,
+  gem_tiled_wb, kms_pwrite_crc.
 
 - New helper for interactive progress indicators (see igt_print_activity and
   igt_progress), which can be disabled by setting the log-level to warn (Thomas
   and Daniel).
 
-- Basic skl support: pci ids, rendercpy&mediafill (Damien, Zhao Yakui).
+- Basic skl support: pci ids, rendercopy & mediafill (Damien, Zhao Yakui).
 
 - chv support for the iosf sideband tools and a few other improvements (Ville).
 
 - Fence register support for intel_reg_dumper on bdw+ (Rodrigo).
 
+- Support for skl in quick_dump (Damien).
+
+- Golden state generation infrastructure (Mika).
+
+- New skl watermark tool (Damien).
+
+- New EDID test block that includes multiple display modes (Thomas).
+
+- Individual test documentation available in generated documentation and from
+  the test binaries (Thomas).
+
 Release 1.8 (2014-09-08)
 
 
-- 
2.1.0

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

[Intel-gfx] [PATCH i-g-t 2/4] Add a MAINTAINERS file

[Thomas Wood]

Signed-off-by: Thomas Wood 
---
 CONTRIBUTING | 9 +++--
 MAINTAINERS  | 2 ++
 2 files changed, 5 insertions(+), 6 deletions(-)
 create mode 100644 MAINTAINERS

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 0ad0c3a..a2ddf09 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -33,12 +33,9 @@ A short list of contribution guidelines:
 
 - When patches from new contributors (without commit access) are stuck, for
   anything related to the regular releases, issues with packaging and
-  integrating platform support or anything else really please contact the i-g-t
-  maintainer:
-
-Thomas Wood 
-
-  Of course please also cc the intel-gfx mailing list.
+  integrating platform support or any other intel-gpu-tools issues, please
+  contact one of the maintainers (listed in the MAINTAIENRS file) and cc the
+  intel-gfx mailing list.
 
 - Especially changes to the testcase should get tested on relevant platforms
   before committing. For Intel employees that's best done using PRTS, see the
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 000..7825e1e
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,2 @@
+Daniel Vetter 
+Thomas Wood 
-- 
2.1.0

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

[Intel-gfx] [PATCH i-g-t 4/4] tools: add missing copyright headers

[Thomas Wood]

Signed-off-by: Thomas Wood 
---
 tools/ddi_compute_wrpll.c | 23 +++
 tools/intel_l3_udev_listener.c| 23 +++
 tools/quick_dump/chipset_macro_wrap.c | 23 +++
 tools/skl_ddb_allocation.c| 23 +++
 4 files changed, 92 insertions(+)

diff --git a/tools/ddi_compute_wrpll.c b/tools/ddi_compute_wrpll.c
index 45c28e1..e27cc34 100644
--- a/tools/ddi_compute_wrpll.c
+++ b/tools/ddi_compute_wrpll.c
@@ -1,3 +1,26 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
 #include 
 #include 
 #include 
diff --git a/tools/intel_l3_udev_listener.c b/tools/intel_l3_udev_listener.c
index c50820c..261630e 100644
--- a/tools/intel_l3_udev_listener.c
+++ b/tools/intel_l3_udev_listener.c
@@ -1,3 +1,26 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
 #ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif
diff --git a/tools/quick_dump/chipset_macro_wrap.c 
b/tools/quick_dump/chipset_macro_wrap.c
index 7b67340..fa568d6 100644
--- a/tools/quick_dump/chipset_macro_wrap.c
+++ b/tools/quick_dump/chipset_macro_wrap.c
@@ -1,3 +1,26 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
 #include 
 #include 
 #include 
diff --git a/tools/skl_ddb_allocation.c b/tools/skl_ddb_allocation.c
index 4d8e6d1..c7bfb27 100644
--- a/tools/skl_ddb_allocation.c
+++ b/tools/skl_ddb_allocation.c
@@ -1,3 +1,26 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the

[Intel-gfx] [PATCH i-g-t 1/4] Update README

[Thomas Wood]

Signed-off-by: Thomas Wood 
---
 README | 46 +-
 1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/README b/README
index 8bdaebd..f1aab58 100644
--- a/README
+++ b/README
@@ -1,17 +1,22 @@
-This is a collection of tools for development and testing of the Intel DRM
-driver.  There are many macro-level test suites that get used against our
-driver, including xtest, rendercheck, piglit, and oglconform, but failures
+Intel GPU Tools
+===
+
+Description
+---
+
+Intel GPU Tools is a collection of tools for development and testing of the
+Intel DRM driver. There are many macro-level test suites that get used against
+the driver, including xtest, rendercheck, piglit, and oglconform, but failures
 from those can be difficult to track down to kernel changes, and many require
 complicated build procedures or specific testing environments to get useful
-results.
+results. Therefore, Intel GPU Tools includes low-level tools and tests
+specifically for development and testing of the Intel DRM Driver.
 
-Thus, intel-graphics-tools was a project I started to collect some low-level
-tools I intended to build.
+Intel GPU Tools is split into several sections:
 
 benchmarks/
-   This should be a collection of useful microbenchmarks.  The hope is
-   that people can use these to tune some pieces of DRM code in relevant
-   ways.
+   This is a collection of useful microbenchmarks that can be used to tune
+   DRM code in relevant ways.
 
The benchmarks require KMS to be enabled.  When run with an X Server
running, they must be run as root to avoid the authentication
@@ -21,8 +26,11 @@ benchmarks/
 
 tests/
This is a set of automated tests to run against the DRM to validate
-   changes.  Hopefully this can cover the relevant cases we need to
-   worry about, including backwards compatibility.
+   changes. Many of the tests have subtests, which can be listed by using
+   the --list-subtests command line option and then run using the
+   --run-subtest option. If --run-subtest is not used, all subtests will
+   be run. Some tests have futher options and these are detailed by using
+   the --help option.
 
The test suite can be run using the run-tests.sh script available in
the scripts directory. Piglit is used to run the tests and can either
@@ -115,9 +123,10 @@ debugger/
The debugger must be run as root: "sudo debugger/eudb"
 
 docs/
-   Thus far just contains the autogenerated intel-gpu-tools libraries
-   reference documenation in docs/reference/ You need to have the gtk doc
-   tools installed to generate this API documentation.
+   Contains the automatically generated intel-gpu-tools libraries
+   reference documentation in docs/reference/. You need to have the
+   gtk-doc tools installed and use the "--enable-gtk-doc" configure flag
+   to generate this API documentation.
 
To regenerate the html files when updating documentation, use:
 
@@ -128,9 +137,12 @@ docs/
intel-gpu-tools-sections.txt. Entirely new sections will also need to be
added to intel-gpu-tools-docs.xml in the appropriate place.
 
-DEPENDENCIES
-   This is a non-exchaustive list of package dependencies required for
-   building everything:
+
+Requirements
+
+
+This is a non-exhaustive list of package dependencies required for
+building everything:
 
libpciaccess-dev
libdrm-dev
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Protect against leaks in pipe_crc_set_source

[Ville Syrjälä]

On Wed, Dec 10, 2014 at 11:02:20AM +0100, Daniel Vetter wrote:
> Stupid userspace (there is no evil userspace in debugfs by assumption)
> might provoke a leak since we allocate the new array without holding
> any locks. Drop in an unconditional kfree to deal with this - kfree
> can handle NULL.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Daniel Vetter 

I thought we had some higher level protection in pipe_crc_set_source()
but indeed we don't. So yeah it can still race with itself, but no
longer leak with your fix.

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 72bb5aef9590..923e7575bb53 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3433,6 +3433,7 @@ static int pipe_crc_set_source(struct drm_device *dev, 
> enum pipe pipe,
>   hsw_disable_ips(crtc);
>  
>   spin_lock_irq(&pipe_crc->lock);
> + kfree(pipe_crc->entries);
>   pipe_crc->entries = entries;
>   pipe_crc->head = 0;
>   pipe_crc->tail = 0;
> -- 
> 2.1.1

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove '& 0xffff' from the mask given to WA_REG()

[Jani Nikula]

On Mon, 08 Dec 2014, Damien Lespiau  wrote:
> We may be hidding bugs by doing that, so let remove it and have the
> actual mask value shine through, for better or worse.
>
> Signed-off-by: Damien Lespiau 

Pushed these two to drm-intel-next-fixes, thanks for the patches.

BR,
Jani.



> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 4f63c39..c715ef0 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -734,10 +734,10 @@ static int wa_add(struct drm_i915_private *dev_priv,
>   }
>  
>  #define WA_SET_BIT_MASKED(addr, mask) \
> - WA_REG(addr, (mask) & 0x, _MASKED_BIT_ENABLE(mask))
> + WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
>  
>  #define WA_CLR_BIT_MASKED(addr, mask) \
> - WA_REG(addr, (mask) & 0x, _MASKED_BIT_DISABLE(mask))
> + WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
>  
>  #define WA_SET_FIELD_MASKED(addr, mask, value) \
>   WA_REG(addr, mask, _MASKED_FIELD(mask, value))
> -- 
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[Daniel Vetter]

Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.

We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.

The idea to use __builtin_constant_p is from Chris Wilson.

v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
Dave. My first attempt used __cond as the temp var, which is the same
used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
sprinkle i915 into the name.

Also use a temporary variable to only evaluate the condition once,
suggested by Damien.

v3: It's crazy but apparently 32bit gcc can't compile out the
BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
why, but until clue grows just disable this nifty idea on 32bit
builds. Reported by 0-day builder.

v4: Got it all wrong, apparently its the gcc version. We need 4.9+.
Now reported by Imre.

Cc: Imre Deak 
Cc: Damien Lespiau 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Dave Gordon 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 13 -
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  6 +++---
 drivers/gpu/drm/i915/intel_display.c |  4 ++--
 drivers/gpu/drm/i915/intel_uncore.c  |  4 ++--
 5 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445eca9ce..f44a844a48db 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum 
intel_display_power_domain domain)
case POWER_DOMAIN_INIT:
return "INIT";
default:
-   WARN_ON(1);
+   MISSING_CASE();
return "?";
}
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95dfa2dd35b9..4532526deb5f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -58,7 +58,18 @@
 #define DRIVER_DATE"20141205"
 
 #undef WARN_ON
-#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
+/* Only 4.9+ gcc can compile away the BUILD_BUG_ON correctly. */
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9)
+#define WARN_ON(x) ({ \
+   bool __i915_warn_cond = (x); \
+   if (__builtin_constant_p(__i915_warn_cond)) \
+   BUILD_BUG_ON(__i915_warn_cond); \
+   WARN(__i915_warn_cond, "WARN_ON(" #x ")"); })
+#else
+#define WARN_ON(x) WARN((x), "WARN_ON(" #x ")")
+#endif
+
+#define MISSING_CASE() WARN(1, "Missing switch case in %s\n", __func__);
 
 enum pipe {
INVALID_PIPE = -1,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ac03a382000b..3b5807c11427 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -132,7 +132,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
}
 
return pte;
@@ -156,7 +156,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
}
 
return pte;
@@ -1146,7 +1146,7 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 8)
gen8_ppgtt_enable(dev);
else
-   WARN_ON(1);
+   MISSING_CASE();
 
if (ppgtt) {
for_each_ring(ring, dev_priv, i) {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d5153a4f90fe..b7155d5efc10 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4847,7 +4847,7 @@ static void cherryview_set_cdclk(struct drm_device *dev, 
int cdclk)
cmd = 0;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
return;
}
 
@@ -8224,7 +8224,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 
base)
cntl |= CURSOR_MODE_256_ARGB_AX;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
return;
}
cntl |= pipe << 28; /* Connect to correct pipe */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 46de8d75b4bf..83ab530fee06 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1202,7 +1202

Re: [Intel-gfx] [PATCH] drm/i915: Forcewake Register Range changes for CHV

[Ville Syrjälä]

On Thu, Dec 11, 2014 at 12:48:41PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S 
> 
> According to updated BSpec, Render/Common Wells register range changed.
> Updating the same to match the spec and avoid extra forcewake for none
> forcewake range.
> 
> Signed-off-by: Deepak S 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 46de8d7..dd36f9b 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -647,9 +647,9 @@ void assert_force_wake_inactive(struct drm_i915_private 
> *dev_priv)
>  
>  #define FORCEWAKE_CHV_RENDER_RANGE_OFFSET(reg) \
>   (REG_RANGE((reg), 0x2000, 0x4000) || \
> -  REG_RANGE((reg), 0x5000, 0x8000) || \
> +  REG_RANGE((reg), 0x5200, 0x8000) || \
>REG_RANGE((reg), 0x8300, 0x8500) || \
> -  REG_RANGE((reg), 0xB000, 0xC000) || \
> +  REG_RANGE((reg), 0xB000, 0xB480) || \
>REG_RANGE((reg), 0xE000, 0xE800))
>  
>  #define FORCEWAKE_CHV_MEDIA_RANGE_OFFSET(reg) \
> @@ -665,10 +665,7 @@ void assert_force_wake_inactive(struct drm_i915_private 
> *dev_priv)
>REG_RANGE((reg), 0x8000, 0x8300) || \
>REG_RANGE((reg), 0x8500, 0x8600) || \
>REG_RANGE((reg), 0x9000, 0xB000) || \
> -  REG_RANGE((reg), 0xC000, 0xC800) || \
> -  REG_RANGE((reg), 0xF000, 0x1) || \
> -  REG_RANGE((reg), 0x14000, 0x14400) || \
> -  REG_RANGE((reg), 0x22000, 0x24000))
> +  REG_RANGE((reg), 0xF000, 0x1))

Looks correct.

It looks like the media offsets could use a small adjustment as well:
- REG_RANGE((reg), 0x3, 0x4)
+ REG_RANGE((reg), 0x3, 0x38000)

So with that changed 
Reviewed-by: Ville Syrjälä 

One thing I don't understand though; Why is the [0x10,0x18[ range
marked as GWK in the spreadsheet? That's where the forcewake req/ack
registers live as well as some other GTFIFO stuff etc. How can you take
forcewake if the forcewake req/ack itself would need forcewake. I think
this must be an error in the spreadsheet and that range should be GNW.

>  
>  #define FORCEWAKE_GEN9_UNCORE_RANGE_OFFSET(reg) \
>   REG_RANGE((reg), 0xB00,  0x2000)
> -- 
> 1.9.1

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

[Intel-gfx] [PATCH] drm/i915: Changes required to enable DSI Video Mode on CHT

[Gaurav K Singh]

For CHT changes are required for calculating the correct m,n & p with
minimal error +/- for the required DSI clock, so that the correct dividor
& ctrl values are written in cck regs for DSI. This patch has been tested
on CHT RVP with 1200 x 1920 panel.

Signed-off-by: Gaurav K Singh 
---
 drivers/gpu/drm/i915/intel_dsi_pll.c |   43 ++
 1 file changed, 33 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 8957f10..9236b66 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -162,7 +162,8 @@ static u32 dsi_clk_from_pclk(u32 pclk, int pixel_format, 
int lane_count)
 
 #endif
 
-static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp *dsi_mnp)
+static int dsi_calc_mnp(struct drm_i915_private *dev_priv,
+   u32 dsi_clk, struct dsi_mnp *dsi_mnp)
 {
u32 m, n, p;
u32 ref_clk;
@@ -173,6 +174,10 @@ static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp 
*dsi_mnp)
u32 calc_m;
u32 calc_p;
u32 m_seed;
+   u32 m_start;
+   u32 m_limit;
+   u32 n_limit;
+   u32 p_limit;
 
/* dsi_clk is expected in KHZ */
if (dsi_clk < 30 || dsi_clk > 115) {
@@ -180,18 +185,33 @@ static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp 
*dsi_mnp)
return -ECHRNG;
}
 
-   ref_clk = 25000;
+   if (IS_CHERRYVIEW(dev_priv->dev)) {
+   ref_clk = 10;
+   m_start = 70;
+   m_limit = 96;
+   n_limit = 4;
+   p_limit = 6;
+   } else if (IS_VALLEYVIEW(dev_priv->dev)) {
+   ref_clk = 25000;
+   m_start = 62;
+   m_limit = 92;
+   n_limit = 1;
+   p_limit = 6;
+   } else {
+   DRM_ERROR("Unsupported device\n");
+   return -ENODEV;
+   }
target_dsi_clk = dsi_clk;
error = 0x;
tmp_error = 0x;
calc_m = 0;
calc_p = 0;
 
-   for (m = 62; m <= 92; m++) {
-   for (p = 2; p <= 6; p++) {
+   for (m = m_start; m <= m_limit; m++) {
+   for (p = 2; p <= p_limit; p++) {
/* Find the optimal m and p divisors
   with minimal error +/- the required clock */
-   calc_dsi_clk = (m * ref_clk) / p;
+   calc_dsi_clk = (m * ref_clk) / (p * n_limit);
if (calc_dsi_clk == target_dsi_clk) {
calc_m = m;
calc_p = p;
@@ -212,11 +232,14 @@ static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp 
*dsi_mnp)
}
 
m_seed = lfsr_converts[calc_m - 62];
-   n = 1;
+   n = n_limit;
dsi_mnp->dsi_pll_ctrl = 1 << (DSI_PLL_P1_POST_DIV_SHIFT + calc_p - 2);
-   dsi_mnp->dsi_pll_div = (n - 1) << DSI_PLL_N1_DIV_SHIFT |
-   m_seed << DSI_PLL_M1_DIV_SHIFT;
-
+   if (IS_CHERRYVIEW(dev_priv->dev))
+   dsi_mnp->dsi_pll_div = (n/2) << DSI_PLL_N1_DIV_SHIFT |
+   m_seed << DSI_PLL_M1_DIV_SHIFT;
+   else
+   dsi_mnp->dsi_pll_div = (n - 1) << DSI_PLL_N1_DIV_SHIFT |
+   m_seed << DSI_PLL_M1_DIV_SHIFT;
return 0;
 }
 
@@ -235,7 +258,7 @@ static void vlv_configure_dsi_pll(struct intel_encoder 
*encoder)
dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk, intel_dsi->pixel_format,
intel_dsi->lane_count);
 
-   ret = dsi_calc_mnp(dsi_clk, &dsi_mnp);
+   ret = dsi_calc_mnp(dev_priv, dsi_clk, &dsi_mnp);
if (ret) {
DRM_DEBUG_KMS("dsi_calc_mnp failed\n");
return;
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH v3] drm/i915/bdw: Fix the write setting up the WIZ hashing mode

[Daniel Vetter]

On Wed, Dec 10, 2014 at 12:03:20PM +, Damien Lespiau wrote:
> On Wed, Dec 10, 2014 at 11:42:13AM +0200, Jani Nikula wrote:
> > Pushed to drm-intel-next-fixes, replacing the old version. Thanks for
> > the patch.
> > 
> > Now the question is, do we want [1] for 3.19 or 3.20?
> > 
> > [1] 
> > http://mid.gmane.org/1418060138-5004-1-git-send-email-damien.lesp...@intel.com
> 
> I think that one is for 3.20, not really fixing a bug.

I suggested 3.19/dinf because it'll make merging easier. And it's
expressingly ok for Linus to merge cleanup stuff even in the merge
window/-rc1 if it makes things easier (as long as it's just obvious
refactoring without any functional change).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[Chris Wilson]

On Wed, Dec 10, 2014 at 02:49:05PM +0100, Daniel Vetter wrote:
> Faster feedback to errors is always better. This is inspired by the
> addition to WARN_ONs to mask/enable helpers for registers to make sure
> callers have the arguments ordered correctly: Pretty much always the
> arguments are static.
> 
> We use WARN_ON(1) a lot in default switch statements though where we
> should always handle all cases. So add a new macro specifically for
> that.
> 
> The idea to use __builtin_constant_p is from Chris Wilson.
> 
> v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
> Dave. My first attempt used __cond as the temp var, which is the same
> used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
> sprinkle i915 into the name.
> 
> Also use a temporary variable to only evaluate the condition once,
> suggested by Damien.
> 
> v3: It's crazy but apparently 32bit gcc can't compile out the
> BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
> why, but until clue grows just disable this nifty idea on 32bit
> builds. Reported by 0-day builder.
> 
> Cc: Damien Lespiau 
> Cc: Chris Wilson 
> Cc: Jani Nikula 
> Cc: Dave Gordon 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h  | 13 -
>  drivers/gpu/drm/i915/i915_gem_gtt.c  |  6 +++---
>  drivers/gpu/drm/i915/intel_display.c |  4 ++--
>  drivers/gpu/drm/i915/intel_uncore.c  |  4 ++--
>  5 files changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d0e445eca9ce..f44a844a48db 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum 
> intel_display_power_domain domain)
>   case POWER_DOMAIN_INIT:
>   return "INIT";
>   default:
> - WARN_ON(1);
> + MISSING_CASE();

Whilst you are doing this janitorial task, if we add the case value to
the macro, that may speed up debugging when they are hit.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Quietly reject attempts to create non-pagealigned stolen objects

[Daniel Vetter]

On Wed, Dec 10, 2014 at 11:13:28AM +, Chris Wilson wrote:
> On Wed, Dec 10, 2014 at 11:23:44AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> > > This added as a BUG_ON as it considered that no one would ever request
> > > an unaligned object. However, it turns out that some BIOSes will
> > > allocate a scanout that is offset from 0 and not aligned to a page
> > > boundary, and we were passing this through and hitting the BUG_ON during
> > > boot.
> > > 
> > > Quietly reject such a request to reserve the unaligned stolen object and
> > > let the boot continue, restoring previous behaviour (i.e. no BIOS
> > > framebuffer preservation).
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883
> > > Signed-off-by: Chris Wilson 
> > > Cc: sta...@vger.kernel.org
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem_stolen.c | 10 ++
> > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> > > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > index 5c616ec2c5c8..a3bc0fa07c6c 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > @@ -646,13 +646,15 @@ 
> > > i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
> > >   DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, 
> > > gtt_offset=%x, size=%x\n",
> > >   stolen_offset, gtt_offset, size);
> > >  
> > > - /* KISS and expect everything to be page-aligned */
> > > - BUG_ON(stolen_offset & 4095);
> > > - BUG_ON(size & 4095);
> > > -
> > >   if (WARN_ON(size == 0))
> > >   return NULL;
> > >  
> > > + /* KISS and expect everything to be GTT page-aligned */
> > > + if ((stolen_offset | size) & 4095) {
> > 
> > Imo we should stil WARN_ON and fixup up the takeover code to align things
> > properly ...
> 
> You shot down my idea for storing deltas into objects in the past...
> 
> The BIOS scanout is properly aligned to the rules of the display engine,
> just not according to our mm restrictions. The bigger question is
> whether our 1:1 offset-to-stolen mapping is correct. It could well be
> that that the framebuffer is at stolen address 0, but just has a GTT
> offset.
> 
> So the only question is whether we reject the object reservation at the
> stolen layer or at the plane config layer. I decided that stolen was
> better, because it is failing to meet our mm restrictions not
> hardware restrictions.

The framebuffer layer can very much cope with offsets, so no need to
reject it. We just need to patch up the framebuffer we create a bit.
Offsets are in pixels but that should align well.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC][PATCH 6/8] drm/i915: Remove intel_crtc->new_config pointer

[Ander Conselvan de Oliveira]

On 12/08/2014 06:36 PM, Daniel Vetter wrote:

On Mon, Dec 08, 2014 at 05:21:07PM +0200, Ander Conselvan de Oliveira wrote:

There are no more users of that pointer since the new config is now
passed down the call chain during mode set. Also, when the switch to
atomic happens, the right config (state) should be derived from an
atomic state structure.


Ah, doesn't seem much work actually to remove our usage of ->new_config.
Which is nice since it'll align us more with how the helpers work.


Except for the ugliness in patch 5, it was pretty straight forward. But 
that can be fixed once we have a global state object.



So overall I think this patch series is good to go (but I've done only a
rather cursory high-level reading).


For some reason PRTS ignored this one (maybe because it is an RFC?), so 
I submitted a task manually. If that succeeds, I'll resend without the 
RFC status.


Cheers,
Ander



Thanks, Daniel


---
  drivers/gpu/drm/i915/intel_display.c | 46 
  drivers/gpu/drm/i915/intel_drv.h |  1 -
  2 files changed, 10 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a9f3034..a032a1d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8583,7 +8583,6 @@ retry:

intel_crtc = to_intel_crtc(crtc);
intel_crtc->new_enabled = true;
-   intel_crtc->new_config = &intel_crtc->config;
old->dpms_mode = connector->dpms;
old->load_detect_temp = true;
old->release_fb = NULL;
@@ -8623,10 +8622,6 @@ retry:

   fail:
intel_crtc->new_enabled = crtc->enabled;
-   if (intel_crtc->new_enabled)
-   intel_crtc->new_config = &intel_crtc->config;
-   else
-   intel_crtc->new_config = NULL;
  fail_unlock:
if (ret == -EDEADLK) {
drm_modeset_backoff(ctx);
@@ -8653,7 +8648,6 @@ void intel_release_load_detect_pipe(struct drm_connector 
*connector,
to_intel_connector(connector)->new_encoder = NULL;
intel_encoder->new_crtc = NULL;
intel_crtc->new_enabled = false;
-   intel_crtc->new_config = NULL;
intel_set_mode(crtc, NULL, 0, 0, NULL);

if (old->release_fb) {
@@ -9839,14 +9833,8 @@ static void 
intel_modeset_update_staged_output_state(struct drm_device *dev)
to_intel_crtc(encoder->base.crtc);
}

-   for_each_intel_crtc(dev, crtc) {
+   for_each_intel_crtc(dev, crtc)
crtc->new_enabled = crtc->base.enabled;
-
-   if (crtc->new_enabled)
-   crtc->new_config = &crtc->config;
-   else
-   crtc->new_config = NULL;
-   }
  }

  /**
@@ -10355,12 +10343,8 @@ intel_modeset_update_state(struct drm_device *dev, 
unsigned prepare_pipes)
intel_modeset_commit_output_state(dev);

/* Double check state. */
-   for_each_intel_crtc(dev, intel_crtc) {
+   for_each_intel_crtc(dev, intel_crtc)
WARN_ON(intel_crtc->base.enabled != 
intel_crtc_in_use(&intel_crtc->base));
-   WARN_ON(intel_crtc->new_config &&
-   intel_crtc->new_config != &intel_crtc->config);
-   WARN_ON(intel_crtc->base.enabled != !!intel_crtc->new_config);
-   }

list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (!connector->encoder || !connector->encoder->crtc)
@@ -10957,9 +10941,6 @@ static int __intel_set_mode(struct drm_crtc *crtc,

*saved_mode = crtc->mode;

-   if (modeset_pipes)
-   to_intel_crtc(crtc)->new_config = pipe_config;
-
/*
 * See if the config requires any additional preparation, e.g.
 * to adjust global state with pipes off.  We need to do this
@@ -10984,7 +10965,13 @@ static int __intel_set_mode(struct drm_crtc *crtc,
goto done;

for_each_intel_crtc_masked(dev, modeset_pipes, intel_crtc) {
-   struct intel_crtc_state *state = intel_crtc->new_config;
+   struct intel_crtc_state *state;
+
+   if (&intel_crtc->base == crtc)
+   state = pipe_config;
+   else
+   state = intel_crtc->config;
+
ret = dev_priv->display.crtc_compute_clock(intel_crtc,
   state);
if (ret) {
@@ -11014,7 +11001,6 @@ static int __intel_set_mode(struct drm_crtc *crtc,
/* mode_set/enable/disable functions rely on a correct pipe
 * config. */
to_intel_crtc(crtc)->config = *pipe_config;
-   to_intel_crtc(crtc)->new_config = &to_intel_crtc(crtc)->config;

/*
 * Calcu

[Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[Daniel Vetter]

Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.

We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.

The idea to use __builtin_constant_p is from Chris Wilson.

v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
Dave. My first attempt used __cond as the temp var, which is the same
used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
sprinkle i915 into the name.

Also use a temporary variable to only evaluate the condition once,
suggested by Damien.

v3: It's crazy but apparently 32bit gcc can't compile out the
BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
why, but until clue grows just disable this nifty idea on 32bit
builds. Reported by 0-day builder.

Cc: Damien Lespiau 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Dave Gordon 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 13 -
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  6 +++---
 drivers/gpu/drm/i915/intel_display.c |  4 ++--
 drivers/gpu/drm/i915/intel_uncore.c  |  4 ++--
 5 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445eca9ce..f44a844a48db 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum 
intel_display_power_domain domain)
case POWER_DOMAIN_INIT:
return "INIT";
default:
-   WARN_ON(1);
+   MISSING_CASE();
return "?";
}
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95dfa2dd35b9..51d7948a7e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -58,7 +58,18 @@
 #define DRIVER_DATE"20141205"
 
 #undef WARN_ON
-#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
+#if BITS_PER_LONG == 64
+#define WARN_ON(x) ({ \
+   bool __i915_warn_cond = (x); \
+   if (__builtin_constant_p(__i915_warn_cond)) \
+   BUILD_BUG_ON(__i915_warn_cond); \
+   WARN(__i915_warn_cond, "WARN_ON(" #x ")"); })
+#else
+/* Somehow 32bit gcc can't compile out the BUILD_BUG_ON. */
+#define WARN_ON(x) WARN((x), "WARN_ON(" #x ")")
+#endif
+
+#define MISSING_CASE() WARN(1, "Missing switch case in %s\n", __func__);
 
 enum pipe {
INVALID_PIPE = -1,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ac03a382000b..3b5807c11427 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -132,7 +132,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
}
 
return pte;
@@ -156,7 +156,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
}
 
return pte;
@@ -1146,7 +1146,7 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 8)
gen8_ppgtt_enable(dev);
else
-   WARN_ON(1);
+   MISSING_CASE();
 
if (ppgtt) {
for_each_ring(ring, dev_priv, i) {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d5153a4f90fe..b7155d5efc10 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4847,7 +4847,7 @@ static void cherryview_set_cdclk(struct drm_device *dev, 
int cdclk)
cmd = 0;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
return;
}
 
@@ -8224,7 +8224,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 
base)
cntl |= CURSOR_MODE_256_ARGB_AX;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
return;
}
cntl |= pipe << 28; /* Connect to correct pipe */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 46de8d75b4bf..83ab530fee06 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1202,7 +1202,7 @@ void intel_uncore_init(struct drm_device *dev)
 
switch (INTEL_INFO(dev)->gen) {
default:
-   WARN_ON(1);
+ 

Re: [Intel-gfx] [PRTS] Kernel Patch testing [PATCH 10/10] drm/i915: Cache ringbuf pointer in

[He, Shuang]

From: Harrison, John C
Sent: Wednesday, December 10, 2014 9:06 PM
To: Intel-GFX@Lists.FreeDesktop.Org
Cc: He, Shuang
Subject: Re: [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in

Is anyone else having problems reading the PRTS logs?

It looks like I got a merge failure complaint, presumably because I need to 
rebase to a newer nightly tree. However, the log file itself does not say 
anything useful. There is a bit of pre-amble which finishes by saying 'This 
file include 3 part: output, error and dmesg. The file opening is: 4260699.out' 
and then I get 13MB of repeated '' tags and that's it. Not a particularly 
useful log!

Also, why are the emails copied to 
'quarkon...@wo.com.cn'?
[He, Shuang] It's my personal push mail, I'll get short message on my mobile 
phone, when you send to that email. So basically I can check what's going on 
with my mobile phone. And take action accordingly, like this email did.

Thanks
   --Shuang


On 09/12/2014 14:07, shuang...@intel.com wrote:
Re:[PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: Cache 
ringbuf pointer in

Received the [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in mail(2014-12-09-22:10:10)

task_id(2014-12-09-22:10:10)

4212

user_id(2014-12-09-22:10:10)

53

user_name(2014-12-09-22:10:10)

Harrison

user_email(2014-12-09-22:10:10)

john.c.harri...@intel.com

task_result link(2014-12-09-22:10:10)

http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=4212


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