[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

2016-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent 
forcewake auto-release timeout across kernel configs
URL   : https://patchwork.freedesktop.org/series/5424/
State : failure

== Summary ==

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

Test drv_getparams_basic:
Subgroup basic-subslice-total:
dmesg-warn -> PASS   (bsw-nuc-2)
Test drv_module_reload_basic:
incomplete -> PASS   (bsw-nuc-2)
Test gem_basic:
Subgroup bad-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-fd-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_param_basic:
Subgroup basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-ctx-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-get:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup root-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_switch:
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_basic:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup gtt-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-render:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_whisper:
Subgroup basic:
skip   -> PASS   (bsw-nuc-2)
Test gem_mmap:
Subgroup basic-small-bo:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-write:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-write-gtt:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-hang:
skip   -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_tiled_pread_basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup addfb25-modifier-no-flag:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup addfb25-y-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup bad-pitch-65536:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-x-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup framebuffer-vs-set-tiling:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup too-wide:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-wf_vblank:
dmesg-fail -> PASS   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
dmesg-fail -> PASS   (bsw-nuc-2)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test prime_self_import:
Subgroup basic-with_fd_dup:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-with_one_bo_two_files:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:158  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:131  dwarn:1   dfail:0   fail:0   skip:64 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
BOOT FAILED for bdw-nuci7

Results at /archive/results/CI_IGT_test/Patchwork_1835/

851708c7e97537ed618fadbe5d342eaf8fa5146d drm-intel-nightly: 
2016y-04m-07d-13h-56m-00s UTC integration manifest
92e5b39bf422197014aa097e20e66bdaa93af717 drm/i915: Do not serialize forcewake 
acquire across domains
e55b59fd4e7f7999f9d4d6def7bcb009285237bc drm/i915: S

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: add INTEL_GEN() helper shorthand for INTEL_INFO()->gen (rev2)

2016-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915: add INTEL_GEN() helper shorthand for INTEL_INFO()->gen (rev2)
URL   : https://patchwork.freedesktop.org/series/5407/
State : failure

== Summary ==

  CC [M]  drivers/net/usb/cdc_ncm.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_i210.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_ptp.o
  LD  drivers/usb/storage/usb-storage.o
  LD  drivers/usb/storage/built-in.o
  CC  drivers/usb/host/uhci-hcd.o
  LD  drivers/tty/vt/built-in.o
  LD  drivers/tty/built-in.o
  CC  drivers/usb/host/xhci.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  CC  drivers/usb/host/xhci-mem.o
  CC  drivers/usb/host/xhci-ring.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_hwmon.o
  CC  drivers/usb/host/xhci-hub.o
  CC  drivers/usb/host/xhci-dbg.o
  LD  drivers/pci/pcie/aer/aerdriver.o
  CC  drivers/usb/host/xhci-trace.o
  LD  drivers/pci/pcie/aer/built-in.o
  CC  drivers/usb/host/xhci-pci.o
  LD  drivers/pci/pcie/built-in.o
  LD  drivers/pci/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:962: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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


Re: [Intel-gfx] [PATCH] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

2016-04-08 Thread Ander Conselvan De Oliveira
On Thu, 2016-04-07 at 09:20 -0700, Jim Bride wrote:
> On Thu, Apr 07, 2016 at 11:15:38AM +0300, Ander Conselvan De Oliveira wrote:
> > On Wed, 2016-04-06 at 16:00 -0700, Jim Bride wrote:
> > > In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some
> > > much needed clean-up was done, but unfortunately part of the change
> > > broke DP MST.  The real issue was setting the connector state to
> > > disconnected in the MST case, which is good, but the code then (after
> > > a goto) checks if the connector state is not connected and shuts down
> > > MST if this is the case, which is bad.  With this change both SST and
> > > MST seem to be happy.
> > > 
> > > cc: Sivakumar Thulasimani 
> > > cc: Shubhangi Shrivastava 
> > > cc: Ander Conselvan de Oliveira 
> > > cc: Nathan D Ciobanu 
> > 
> > Fixes: commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse")
> > 
> > > Signed-off-by: Jim Bride 
> > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 15 ++-
> > >  1 file changed, 2 insertions(+), 13 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index da0c3d2..2d8783e 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4665,20 +4665,9 @@ intel_dp_long_pulse(struct intel_connector
> > > *intel_connector)
> > >   }
> > >  
> > >  out:
> > > - if (status != connector_status_connected) {
> > > + if ((status != connector_status_connected) &&
> > > + (intel_dp->is_mst == false))
> > >   intel_dp_unset_edid(intel_dp);
> > > - /*
> > > -  * If we were in MST mode, and device is not there,
> > > -  * get out of MST mode
> > > -  */
> > > - if (intel_dp->is_mst) {
> > > - DRM_DEBUG_KMS("MST device may have disappeared %d
> > > vs
> > > %d\n",
> > > -   intel_dp->is_mst, intel_dp
> > > ->mst_mgr.mst_state);
> > > - intel_dp->is_mst = false;
> > > - drm_dp_mst_topology_mgr_set_mst(&intel_dp
> > > ->mst_mgr,
> > > - intel_dp
> > > ->is_mst);
> > > - }
> > > - }
> > 
> > The point of that code was to get out of MST mode in case of a
> > disconnection,
> > but it does the wrong thing there. With the deletion, the device would be is
> > MST
> > until the next time something is plugged to the port. I haven't checked what
> > are
> > the consequences of that though.
> > 
> > So maybe move that code before the first "goto out". That should cover the
> > was
> > mst and is now disconnected case.
> 
> I don't think that would work either.  For what you're talking about it seems
> to
> me that the most reliable way to catch this case would be to check that we can
> read the branch OUI, and if we cannot then we should shut down MST.
> 
> Thoughts?

There's intel_dp_probe_mst() to determine if MST should be used when there is
something plugged in. I don't know if that should consider branch OUI. But for
the case where the branch device was disconnected, any DPCD read will fail, so
there is no point in reading the OUI. The current code just skips it and reports
it as disconnected.

I've tried the patch below locally, and it seems to do the right thing.

[drm:intel_hpd_irq_storm_detect] Received HPD interrupt on PIN 5 - cnt: 0
[drm:intel_dp_hpd_pulse] got hpd irq on port B - long
[drm:intel_dp_long_pulse] MST device may have disappeared 1 vs 1


diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d2..8e725d7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4608,6 +4608,14 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_dp->compliance_test_type = 0;
intel_dp->compliance_test_data = 0;
 
+   if (intel_dp->is_mst) {
+   DRM_DEBUG_KMS("MST device may have disappeared %d vs 
%d\n",
+ intel_dp->is_mst, 
intel_dp->mst_mgr.mst_state);
+   intel_dp->is_mst = false;
+   drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
+   intel_dp->is_mst);
+   }
+
goto out;
}
 
@@ -4667,17 +4675,6 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
 out:
if (status != connector_status_connected) {
intel_dp_unset_edid(intel_dp);
-   /*
-* If we were in MST mode, and device is not there,
-* get out of MST mode
-*/
-   if (intel_dp->is_mst) {
-   DRM_DEBUG_KMS("MST device may have disappeared %d vs 
%d\n",
- intel_dp->is_mst, 
intel_dp->mst_mgr.mst_state);
-   intel_dp->is_mst = false;
-   drm_dp_mst_topology_mgr_s

[Intel-gfx] ✗ Fi.CI.BAT: failure for Fixes and workarounds for GuC/doorbell setup

2016-04-08 Thread Patchwork
== Series Details ==

Series: Fixes and workarounds for GuC/doorbell setup
URL   : https://patchwork.freedesktop.org/series/5426/
State : failure

== Summary ==

Series 5426v1 Fixes and workarounds for GuC/doorbell setup
http://patchwork.freedesktop.org/api/1.0/series/5426/revisions/1/mbox/

Test drv_getparams_basic:
Subgroup basic-subslice-total:
dmesg-warn -> PASS   (bsw-nuc-2)
Test drv_module_reload_basic:
incomplete -> PASS   (bsw-nuc-2)
Test gem_basic:
Subgroup bad-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-fd-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_param_basic:
Subgroup basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-ctx-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-get:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup root-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_switch:
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (skl-i7k-2)
Test gem_exec_basic:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup gtt-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-render:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_whisper:
Subgroup basic:
skip   -> PASS   (bsw-nuc-2)
Test gem_mmap:
Subgroup basic-small-bo:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-write:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-write-gtt:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-hang:
skip   -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_tiled_pread_basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup addfb25-modifier-no-flag:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup addfb25-y-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup bad-pitch-65536:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-x-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup framebuffer-vs-set-tiling:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup too-wide:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-fail -> PASS   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
dmesg-fail -> PASS   (bsw-nuc-2)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test prime_self_import:
Subgroup basic-with_fd_dup:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-with_one_bo_two_files:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
skl-i7k-2total:196  pass:172  dwarn:1   dfail:0   fail:0   skip:23 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
BOOT FAILED for bdw-ultra
BOOT FAILED for ilk-hp8440p
BOOT FAILED for ivb-t430s

Results at /archive/results/CI_IGT_test/Patchwork_1837/

851708c7e97537ed618fadbe5d342eaf8fa5146d drm-intel-nightly: 
2016y-04m-07d-13h-56m-00s UTC integration manifest
a9619071522d956fc6ff3aa5b5208a692f258842 DO NOT MERGE: add enable_guc_loading 
parameter
64bea5d51362b9a78a1686291e680c86ef957678 drm/i915/guc: disable GuC submission 
earlier during GuC (re)load
ee186c856e0469d5f0ec3993e2bd58c2ce961e16 drm/i915/guc: (re)initialise doorbell 
h/w wh

Re: [Intel-gfx] [RFC] Convert INTEL_INFO(...)->gen to INTEL_GEN(...)

2016-04-08 Thread Jani Nikula
On Thu, 07 Apr 2016, Dave Gordon  wrote:
> Since Jani has given us this macro, I thought I'd make use of it by
> converting all existing instances of this construct with a really
> simple little Coccinelle script:
>
> @intel_gen@
> expression E;
> @@
> <...
> -   INTEL_INFO(E)->gen
> +   INTEL_GEN(E)
> ...>

I intentionally did not do this because I think it causes more trouble
than it's worth. Basically this will conflict with roughly all patches
currently in flight. Yes, I admit I did tell people to go wild, but
please let's do this piecemeal.


BR,
Jani.


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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Minor i915_dp_mst_info output enhancements (rev2)

2016-04-08 Thread Patchwork
== Series Details ==

Series: Minor i915_dp_mst_info output enhancements (rev2)
URL   : https://patchwork.freedesktop.org/series/5346/
State : failure

== Summary ==

Series 5346v2 Minor i915_dp_mst_info output enhancements
http://patchwork.freedesktop.org/api/1.0/series/5346/revisions/2/mbox/

Test drv_getparams_basic:
Subgroup basic-subslice-total:
dmesg-warn -> PASS   (bsw-nuc-2)
Test drv_module_reload_basic:
incomplete -> PASS   (bsw-nuc-2)
Test gem_basic:
Subgroup bad-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-fd-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_param_basic:
Subgroup basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-ctx-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-get:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup root-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_switch:
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_basic:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup gtt-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-render:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_whisper:
Subgroup basic:
skip   -> PASS   (bsw-nuc-2)
Test gem_mmap:
Subgroup basic-small-bo:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-write:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-write-gtt:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-hang:
skip   -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_tiled_pread_basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup addfb25-modifier-no-flag:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup addfb25-y-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup bad-pitch-65536:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-x-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup framebuffer-vs-set-tiling:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup too-wide:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-fail -> PASS   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
dmesg-fail -> PASS   (bsw-nuc-2)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test prime_self_import:
Subgroup basic-with_fd_dup:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-with_one_bo_two_files:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
BOOT FAILED for bdw-ultra
BOOT FAILED for ilk-hp8440p
BOOT FAILED for ivb-t430s

Results at /archive/results/CI_IGT_test/Patchwork_1838/

851708c7e97537ed618fadbe5d342eaf8fa5146d drm-intel-nightly: 
2016y-04m-07d-13h-56m-00s UTC integration manifest
d6c0df3791168c85675b94b5f460be6a15ee5a92 drm/i915/dp/mst: Add source port info 
to debugfs output
ad413419060a77507dd44d5b18622bc63950da88 drm/dp/mst: Enhance DP MST debugfs 
output
f67c19b2a4169592141d30a2b7dfe08817f92da0 drm/edid: Add 
drm_edid_get_monitor_name()

___
Intel-gfx mailing

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

2016-04-08 Thread Chris Wilson
On Fri, Apr 08, 2016 at 07:02:35AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent 
> forcewake auto-release timeout across kernel configs
> URL   : https://patchwork.freedesktop.org/series/5424/
> State : failure
> 
> == Summary ==
> 
> Series 5424v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/5424/revisions/1/mbox/
> 
> Test drv_getparams_basic:
> Subgroup basic-subslice-total:
> dmesg-warn -> PASS   (bsw-nuc-2)

Even though bsw is (currently) unstable, this is a good result as it
means that the change is not fundamentally broken on Braswell!
-Chris

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/3] drm/i915: Use i915_vm_to_ppgtt instead of manual container_of (rev2)

2016-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [v4,1/3] drm/i915: Use i915_vm_to_ppgtt instead of 
manual container_of (rev2)
URL   : https://patchwork.freedesktop.org/series/5403/
State : failure

== Summary ==

Series 5403v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5403/revisions/2/mbox/

Test drv_getparams_basic:
Subgroup basic-subslice-total:
dmesg-warn -> PASS   (bsw-nuc-2)
Test drv_module_reload_basic:
incomplete -> PASS   (bsw-nuc-2)
Test gem_basic:
Subgroup bad-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-fd-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_param_basic:
Subgroup basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-ctx-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-get:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup root-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_switch:
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_basic:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup gtt-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-render:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_whisper:
Subgroup basic:
skip   -> PASS   (bsw-nuc-2)
Test gem_mmap:
Subgroup basic-small-bo:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-write:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-write-gtt:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-hang:
skip   -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_tiled_pread_basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup addfb25-modifier-no-flag:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup addfb25-y-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup bad-pitch-65536:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-x-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup framebuffer-vs-set-tiling:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup too-wide:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-fail -> PASS   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
dmesg-fail -> PASS   (bsw-nuc-2)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test prime_self_import:
Subgroup basic-with_fd_dup:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-with_one_bo_two_files:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
BOOT FAILED for bdw-ultra
BOOT FAILED for ilk-hp8440p
BOOT FAILED for ivb-t430s

Results at /archive/results/CI_IGT_test/Patchwork_1839/

851708c7e97537ed618fadbe5d342eaf8fa5146d drm-intel-nightly: 
2016y-04m-07d-13h-56m-00s UTC integration manifest
4c8b72095410492238babc716c363766498c1d9b Prefer INTEL_INFO(dev_priv) to 
INTEL_INFO(dev)

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


Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/bxt: Corrected the guid for bxt.

2016-04-08 Thread Jani Nikula
On Thu, 07 Apr 2016, Animesh Manna  wrote:
> Guid is changed for bxt platform, so corrected the guid for bxt.
>
> Signed-off-by: Ananth Krishna R 
> Signed-off-by: Bharath K Veera 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/intel_acpi.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
> b/drivers/gpu/drm/i915/intel_acpi.c
> index 8f3d672..8ba30b3 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -17,7 +17,7 @@ static struct intel_dsm_priv {
>   acpi_handle dhandle;
>  } intel_dsm_priv;
>  
> -static const u8 intel_dsm_guid[] = {
> +static u8 intel_dsm_guid[] = {
>   0xd3, 0x73, 0xd8, 0x7e,
>   0xd0, 0xc2,
>   0x4f, 0x4e,
> @@ -25,6 +25,9 @@ static const u8 intel_dsm_guid[] = {
>   0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
>  };
>  
> +static u8 intel_bxt_dsm_guid[] =
> + "3E5B41C6-EB1D-4260-9D15-C71FBADAE414";
> +

So I want both of these to be either in string form or in binary uuid
form, not a mixture. Having them in binary makes the code simpler, so
I'd go for that.

BR,
Jani.

>  static char *intel_dsm_port_name(u8 id)
>  {
>   switch (id) {
> @@ -143,6 +146,9 @@ static bool intel_dsm_pci_probe(struct pci_dev *pdev)
>  
>   intel_dsm_priv.dhandle = dhandle;
>  
> + if (IS_BROXTON(dev))
> + acpi_str_to_uuid(intel_bxt_dsm_guid, intel_dsm_guid);
> +
>   if (acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
>   1 << INTEL_DSM_FN_PLATFORM_MUX_INFO))
>   intel_dsm_platform_mux_info();

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


Re: [Intel-gfx] [PATCH v4 4/4] drm/i915/bxt: add bxt dsi gpio element support

2016-04-08 Thread Jani Nikula
On Thu, 07 Apr 2016, kbuild test robot  wrote:
> Hi Jani,
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [cannot apply to v4.6-rc2 next-20160407]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-dsi-improved-gpio-element-support-for-vlv-chv-bxt/20160407-223107
> base:   git://anongit.freedesktop.org/drm-intel for-linux-next
> config: x86_64-randconfig-a0-04072115 (attached as .config)

Meh, including linux/gpio.h works for CONFIG_GPIOLIB=y, but it fails to
include the consumer function stubs for CONFIG_GPIOLIB=n. The fix is to
include linux/gpio/consumer.h instead.

BR,
Jani.


> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
>
> All errors (new ones prefixed by >>):
>
>drivers/gpu/drm/i915/intel_dsi_panel_vbt.c: In function 'bxt_exec_gpio':
>>> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c:307:15: error: implicit 
>>> declaration of function 'devm_gpiod_get_index' 
>>> [-Werror=implicit-function-declaration]
>   gpio_desc = devm_gpiod_get_index(dev_priv->dev->dev,
>   ^
>>> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c:309:16: error: 'GPIOD_OUT_LOW' 
>>> undeclared (first use in this function)
>value ? GPIOD_OUT_LOW :
>^
>drivers/gpu/drm/i915/intel_dsi_panel_vbt.c:309:16: note: each undeclared 
> identifier is reported only once for each function it appears in
>>> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c:310:8: error: 'GPIOD_OUT_HIGH' 
>>> undeclared (first use in this function)
>GPIOD_OUT_HIGH);
>^
>>> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c:321:2: error: implicit 
>>> declaration of function 'gpiod_set_value' 
>>> [-Werror=implicit-function-declaration]
>  gpiod_set_value(gpio_desc, value);
>  ^
>cc1: some warnings being treated as errors
>
> vim +/devm_gpiod_get_index +307 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>
>301{
>302/* XXX: this table is a quick ugly hack. */
>303static struct gpio_desc *bxt_gpio_table[U8_MAX + 1];
>304struct gpio_desc *gpio_desc = 
> bxt_gpio_table[gpio_index];
>305
>306if (!gpio_desc) {
>  > 307gpio_desc = 
> devm_gpiod_get_index(dev_priv->dev->dev,
>308 NULL, 
> gpio_index,
>  > 309 value ? 
> GPIOD_OUT_LOW :
>  > 310 
> GPIOD_OUT_HIGH);
>311
>312if (IS_ERR_OR_NULL(gpio_desc)) {
>313DRM_ERROR("GPIO index %u request failed 
> (%ld)\n",
>314  gpio_index, 
> PTR_ERR(gpio_desc));
>315return;
>316}
>317
>318bxt_gpio_table[gpio_index] = gpio_desc;
>319}
>320
>  > 321gpiod_set_value(gpio_desc, value);
>322}
>323
>324static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, 
> const u8 *data)
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

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


[Intel-gfx] [PATCH 1/6] drm/i915: remove IS_ERR_OR_NULL check

2016-04-08 Thread Matthew Auld
A call to i915_gem_alloc_object can only ever return NULL in the event
of an error.

Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b342f67..84db11a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5336,7 +5336,7 @@ i915_gem_object_create_from_data(struct drm_device *dev,
int ret;
 
obj = i915_gem_alloc_object(dev, round_up(size, PAGE_SIZE));
-   if (IS_ERR_OR_NULL(obj))
+   if (!obj)
return obj;
 
ret = i915_gem_object_set_to_cpu_domain(obj, true);
-- 
2.4.11

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


[Intel-gfx] [PATCH 3/6] drm/i915: combine overflow checks

2016-04-08 Thread Matthew Auld
Looks a little neater and ever so slightly reduces the size of the
binary.

Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 066d5aead..180dbd8 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1223,10 +1223,7 @@ static int gen8_alloc_va_range_3lvl(struct 
i915_address_space *vm,
/* Wrap is never okay since we can only represent 48b, and we don't
 * actually use the other side of the canonical address space.
 */
-   if (WARN_ON(start + length < start))
-   return -ENODEV;
-
-   if (WARN_ON(start + length > vm->total))
+   if (WARN_ON(start > vm->total || length > vm->total - start))
return -ENODEV;
 
ret = alloc_gen8_temp_bitmaps(&new_page_dirs, &new_page_tables, pdpes);
-- 
2.4.11

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


[Intel-gfx] [PATCH 6/6] drm/i915: call kunmap_px on pt_vaddr

2016-04-08 Thread Matthew Auld
We need to kunmap pt_vadrr and not pt itself, otherwise we end up
mapping a bunch of pages without ever unmapping them.

Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b0fa166..f426a66 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -746,7 +746,7 @@ static void gen8_ppgtt_clear_pte_range(struct 
i915_address_space *vm,
num_entries--;
}
 
-   kunmap_px(ppgtt, pt);
+   kunmap_px(ppgtt, pt_vaddr);
 
pte = 0;
if (++pde == I915_PDES) {
-- 
2.4.11

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


[Intel-gfx] [PATCH 2/6] drm/i915: reference ppgtt->base.dev directly

2016-04-08 Thread Matthew Auld
Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.

Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index da6e3a5..066d5aead 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -905,11 +905,10 @@ static int gen8_init_scratch(struct i915_address_space 
*vm)
 static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt *ppgtt, bool create)
 {
enum vgt_g2v_type msg;
-   struct drm_device *dev = ppgtt->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = to_i915(ppgtt->base.dev);
int i;
 
-   if (USES_FULL_48BIT_PPGTT(dev)) {
+   if (USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {
u64 daddr = px_dma(&ppgtt->pml4);
 
I915_WRITE(vgtif_reg(pdp[0].lo), lower_32_bits(daddr));
-- 
2.4.11

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


[Intel-gfx] [PATCH 4/6] drm/i915: handle potential overflow

2016-04-08 Thread Matthew Auld
Much like with the equivalent gen8_alloc_va_range.

Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 180dbd8..5589a8d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1857,7 +1857,8 @@ static int gen6_alloc_va_range(struct i915_address_space 
*vm,
uint32_t pde, temp;
int ret;
 
-   if (WARN_ON(start_in + length_in > ppgtt->base.total))
+   if (WARN_ON(start_in > ppgtt->base.total || length_in >
+   ppgtt->base.total - start_in))
return -ENODEV;
 
start = start_save = start_in;
-- 
2.4.11

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


[Intel-gfx] [PATCH 5/6] drm/i915: bail in alloc_pdp when !FULL_48BIT_PPGTT

2016-04-08 Thread Matthew Auld
If we are not in FULL_48BIT_PPGTT mode then we really shouldn't
continue on with our allocations, given that the call to free_dpd would
bail early without freeing everything, thus leaking memory.

Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5589a8d..b0fa166 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -569,7 +569,8 @@ i915_page_directory_pointer *alloc_pdp(struct drm_device 
*dev)
struct i915_page_directory_pointer *pdp;
int ret = -ENOMEM;
 
-   WARN_ON(!USES_FULL_48BIT_PPGTT(dev));
+   if (WARN_ON(!USES_FULL_48BIT_PPGTT(dev)))
+   return ERR_PTR(-EINVAL);
 
pdp = kzalloc(sizeof(*pdp), GFP_KERNEL);
if (!pdp)
-- 
2.4.11

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


Re: [Intel-gfx] [PATCH v2 1/3] drm/edid: Add drm_edid_get_monitor_name()

2016-04-08 Thread Jani Nikula
On Thu, 07 Apr 2016, Jim Bride  wrote:
> In order to include monitor name information in debugfs
> output we needed to add a function that would extract the
> monitor name from the EDID, and that function needed to
> reside in the file  where the rest of the EDID helper
> functions are implemented.
>
> v2: Refactor to have drm_edid_get_monitor_name() and drm_edid_to_eld()
> use a common helper function to extract the monitor name from the
> edid. [Jani] + rebase.
>
> cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Jim Bride 
> ---
>  drivers/gpu/drm/drm_edid.c | 50 
> +-
>  include/drm/drm_crtc.h |  2 ++
>  2 files changed, 43 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 558ef9f..daf53df 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3293,6 +3293,45 @@ monitor_name(struct detailed_timing *t, void *data)
>   *(u8 **)data = t->data.other_data.data.str.str;
>  }
>  
> +static int get_monitor_name(struct edid *edid, char name[13])
> +{
> + char *edid_name = NULL;
> + int mnl;
> +
> + if (!edid || !name)
> + return 0;
> +
> + drm_for_each_detailed_block((u8 *)edid, monitor_name, &edid_name);
> + for (mnl = 0; edid_name && mnl < 13; mnl++) {
> + if (edid_name[mnl] == 0x0a)
> + break;
> +
> + name[mnl] = edid_name[mnl];
> + }
> +
> + return mnl;
> +}
> +
> +/**
> + * drm_edid_get_monitor_name - fetch the monitor name from the edid
> + * @edid: monitor EDID information
> + * @name: pointer to a character array to hold the name of the monitor
> + * @bufsize: The size of the name buffer (should be at least 13 chars.)
> + *
> + */
> +void drm_edid_get_monitor_name(struct edid *edid, char *name, int bufsize)
> +{
> + int name_length = -1;
> +
> + if (bufsize < 13)
> + return;
> +
> + name_length = get_monitor_name(edid, name);
> + if (name_length)
> + name[name_length] = '\0';

I was thinking something along the lines of:

char buf[13];
int len;

if (bufsize <= 0)
return;

len = min(get_monitor_name(edid, buf), bufsize - 1);
memcpy(name, buf, len);
name[len] = '\0';

BR,
Jani.

> +}
> +EXPORT_SYMBOL(drm_edid_get_monitor_name);
> +
>  /**
>   * drm_edid_to_eld - build ELD from EDID
>   * @connector: connector corresponding to the HDMI/DP sink
> @@ -3306,7 +3345,6 @@ void drm_edid_to_eld(struct drm_connector *connector, 
> struct edid *edid)
>  {
>   uint8_t *eld = connector->eld;
>   u8 *cea;
> - u8 *name;
>   u8 *db;
>   int total_sad_count = 0;
>   int mnl;
> @@ -3320,14 +3358,8 @@ void drm_edid_to_eld(struct drm_connector *connector, 
> struct edid *edid)
>   return;
>   }
>  
> - name = NULL;
> - drm_for_each_detailed_block((u8 *)edid, monitor_name, &name);
> - /* max: 13 bytes EDID, 16 bytes ELD */
> - for (mnl = 0; name && mnl < 13; mnl++) {
> - if (name[mnl] == 0x0a)
> - break;
> - eld[20 + mnl] = name[mnl];
> - }
> + mnl = get_monitor_name(edid, eld + 20);
> +
>   eld[4] = (cea[1] << 5) | mnl;
>   DRM_DEBUG_KMS("ELD monitor %s\n", eld + 20);
>  
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8cb377c..6d46842 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2500,6 +2500,8 @@ extern int drm_edid_header_is_valid(const u8 *raw_edid);
>  extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
> print_bad_edid,
>bool *edid_corrupt);
>  extern bool drm_edid_is_valid(struct edid *edid);
> +extern void drm_edid_get_monitor_name(struct edid *edid, char *name,
> +   int buflen);
>  
>  extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device 
> *dev,
>char topology[8]);

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


Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move modeset state checker calls.

2016-04-08 Thread Maarten Lankhorst
Op 08-04-16 om 01:23 schreef Matt Roper:
> On Wed, Mar 23, 2016 at 02:58:07PM +0100, Maarten Lankhorst wrote:
>> The modeset state checker no longer has full access to the hardware,
>> instead it should only check affected crtc's.
>>
>> Looking for disabled stuff can be checked immediately after all crtc
>> disables have completed, while each enabled crtc can be checked right
>> after being enabled.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 24 +---
>>  1 file changed, 5 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 4148b262f2a7..b6a75aa32e5a 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -13027,28 +13027,13 @@ check_disabled_dpll_state(struct drm_device *dev)
>>  }
>>  
>>  static void
>> -intel_modeset_check_disabled(struct drm_device *dev,
>> - struct drm_atomic_state *old_state)
>> +intel_modeset_check_disabled(struct drm_device *dev)
>>  {
>>  check_encoder_state(dev);
>>  check_connector_state(dev, NULL);
>>  check_disabled_dpll_state(dev);
>>  }
>>  
>> -static void
>> -intel_modeset_check_state(struct drm_device *dev,
>> -  struct drm_atomic_state *old_state)
>> -{
>> -struct drm_crtc_state *old_crtc_state;
>> -struct drm_crtc *crtc;
>> -int i;
>> -
>> -for_each_crtc_in_state(old_state, crtc, old_crtc_state, i)
>> -intel_modeset_check_crtc(crtc, old_crtc_state, crtc->state);
>> -
>> -intel_modeset_check_disabled(dev, old_state);
>> -}
>> -
>>  static void update_scanline_offset(struct intel_crtc *crtc)
>>  {
>>  struct drm_device *dev = crtc->base.dev;
>> @@ -13616,6 +13601,8 @@ static int intel_atomic_commit(struct drm_device 
>> *dev,
>>  if (dev_priv->display.modeset_commit_cdclk &&
>>  intel_state->dev_cdclk != dev_priv->cdclk_freq)
>>  dev_priv->display.modeset_commit_cdclk(state);
>> +
>> +intel_modeset_check_disabled(dev);
> As noted on patch #1, since we're checking all disabled state (and not
> just the things that are newly-disabled by this transaction), we may not
> hold full locks over everything that's disabled here and might be racing
> with other updates.  But we're no worse off than we were before.
>
> As a minor behavior change, it looks like we're also no longer calling
> this when we're doing non-modeset pipe updates, but that should be fine.
>
This is true, but enabling a pipe requires connection_mutex, which is always 
held if we do a modeset anyway..
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 2/3] drm/dp/mst: Enhance DP MST debugfs output

2016-04-08 Thread Jani Nikula
On Thu, 07 Apr 2016, Jim Bride  wrote:
> Add some additional information (input vs. output port, sink associated
> with VC, peer device type, max number of VCs supported) and ensure that
> any embedded '\0' characters in a branch device's devid string are not
> written to debugfs.
>
> v2: Rebase + change drm_edid_get_monitor_name() call to reflect new
> signature.
>
> cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Jim Bride 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 35 
> ++-
>  1 file changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 27fbd79..0d3873e 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2729,7 +2729,7 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
>  
>   seq_printf(m, "%smst: %p, %d\n", prefix, mstb, mstb->num_ports);
>   list_for_each_entry(port, &mstb->ports, next) {
> - seq_printf(m, "%sport: %d: ddps: %d ldps: %d, sdp: %d/%d, %p, 
> conn: %p\n", prefix, port->port_num, port->ddps, port->ldps, 
> port->num_sdp_streams, port->num_sdp_stream_sinks, port, port->connector);
> + seq_printf(m, "%sport: %d: input: %d: pdt: %d, ddps: %d ldps: 
> %d, sdp: %d/%d, %p, conn: %p\n", prefix, port->port_num, port->input, 
> port->pdt, port->ddps, port->ldps, port->num_sdp_streams, 
> port->num_sdp_stream_sinks, port, port->connector);
>   if (port->mstb)
>   drm_dp_mst_dump_mstb(m, port->mstb);
>   }
> @@ -2750,6 +2750,18 @@ static bool dump_dp_payload_table(struct 
> drm_dp_mst_topology_mgr *mgr,
>   return false;
>  }
>  
> +static void fetch_monitor_name(struct drm_dp_mst_topology_mgr *mgr,
> +struct drm_dp_mst_port *port, char *name,
> +int namelen)
> +{
> + struct edid *mst_edid = NULL;

No need to initialize.

> +
> + mst_edid = drm_dp_mst_get_edid(port->connector, mgr, port);
> + if (mst_edid == NULL)
> + return;

Leave this check out to ensure a terminated name for mst_edid == NULL
from the call below.

> + drm_edid_get_monitor_name(mst_edid, name, namelen);
> +}
> +
>  /**
>   * drm_dp_mst_dump_topology(): dump topology to seq file.
>   * @m: seq_file to dump output to
> @@ -2762,6 +2774,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>  {
>   int i;
>   struct drm_dp_mst_port *port;
> +
>   mutex_lock(&mgr->lock);
>   if (mgr->mst_primary)
>   drm_dp_mst_dump_mstb(m, mgr->mst_primary);
> @@ -2770,14 +2783,22 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>   mutex_unlock(&mgr->lock);
>  
>   mutex_lock(&mgr->payload_lock);
> - seq_printf(m, "vcpi: %lx %lx\n", mgr->payload_mask, mgr->vcpi_mask);
> + seq_printf(m, "vcpi: %lx %lx %d\n", mgr->payload_mask, mgr->vcpi_mask,
> + mgr->max_payloads);
>  
>   for (i = 0; i < mgr->max_payloads; i++) {
>   if (mgr->proposed_vcpis[i]) {
> + char name[13];

You'll need 14 chars (i.e. +1 for termination).

> +
> + memset(name, 0, 13 * sizeof(char));

This is no longer needed.

>   port = container_of(mgr->proposed_vcpis[i], struct 
> drm_dp_mst_port, vcpi);
> - seq_printf(m, "vcpi %d: %d %d %d\n", i, port->port_num, 
> port->vcpi.vcpi, port->vcpi.num_slots);
> + fetch_monitor_name(mgr, port, name, 13);

Replace 13 with sizeof(name).

> + seq_printf(m, "vcpi %d: %d %d %d sink name: %s\n", i,
> +port->port_num, port->vcpi.vcpi,
> +port->vcpi.num_slots,
> +(name[0] != 0) ? name :  "Unknown");

Perhaps *name ? name : "Unknown"?

>   } else
> - seq_printf(m, "vcpi %d:unsed\n", i);
> + seq_printf(m, "vcpi %d:unused\n", i);
>   }
>   for (i = 0; i < mgr->max_payloads; i++) {
>   seq_printf(m, "payload %d: %d, %d, %d\n",
> @@ -2818,7 +2839,11 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
>   seq_printf(m, "%02x", buf[i]);
>   seq_printf(m, " devid: ");
>   for (i = 0x3; i < 0x8; i++)

You could just make the loop condition i < 0x8 && buf[i].

> - seq_printf(m, "%c", buf[i]);
> + if (buf[i] != '\0')
> + seq_printf(m, "%c", buf[i]);
> + else
> + break;
> +
>   seq_printf(m, " revision: hw: %x.%x sw: %x.%x", buf[0x9] >> 4, 
> buf[0x9] & 0xf, buf[0xa], buf[0xb]);
>   seq_printf(m, "\n");
>   bret = dump_dp_payload_table(mgr, buf);

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mail

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Apply WaC6DisallowByGfxPause prior to SKL B0 / BXT A1

2016-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915: Apply WaC6DisallowByGfxPause prior to SKL B0 / BXT A1
URL   : https://patchwork.freedesktop.org/series/5438/
State : failure

== Summary ==

Series 5438v1 drm/i915: Apply WaC6DisallowByGfxPause prior to SKL B0 / BXT A1
http://patchwork.freedesktop.org/api/1.0/series/5438/revisions/1/mbox/

Test drv_getparams_basic:
Subgroup basic-subslice-total:
dmesg-warn -> PASS   (bsw-nuc-2)
Test drv_module_reload_basic:
incomplete -> PASS   (bsw-nuc-2)
Test gem_basic:
Subgroup bad-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-fd-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_param_basic:
Subgroup basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-ctx-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-get:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup root-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_switch:
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_basic:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup gtt-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-render:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_whisper:
Subgroup basic:
skip   -> PASS   (bsw-nuc-2)
Test gem_mmap:
Subgroup basic-small-bo:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-write:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-write-gtt:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-hang:
skip   -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_tiled_pread_basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup addfb25-modifier-no-flag:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup addfb25-y-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup bad-pitch-65536:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-x-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup framebuffer-vs-set-tiling:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup too-wide:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-wf_vblank:
dmesg-fail -> PASS   (bsw-nuc-2)
Test kms_force_connector_basic:
Subgroup force-edid:
skip   -> PASS   (ivb-t430s)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
dmesg-fail -> PASS   (bsw-nuc-2)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test prime_self_import:
Subgroup basic-with_fd_dup:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-with_one_bo_two_files:
dmesg-warn -> PASS   (bsw-nuc-2)

bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:131  dwarn:1   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-x220ttotal:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33 
BOOT FAILED for bdw-nuci7
BOOT FAILED for bdw-ultra
BOOT FAILED for snb-dellxps

Results at /archive/results/CI_IGT_test/Patchwork_1840/

851708c7e97537ed618fadbe5d342eaf8fa5146

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: remove IS_ERR_OR_NULL check

2016-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [1/6] drm/i915: remove IS_ERR_OR_NULL check
URL   : https://patchwork.freedesktop.org/series/5453/
State : failure

== Summary ==

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

Test drv_getparams_basic:
Subgroup basic-subslice-total:
dmesg-warn -> PASS   (bsw-nuc-2)
Test drv_module_reload_basic:
incomplete -> PASS   (bsw-nuc-2)
Test gem_basic:
Subgroup bad-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup create-fd-close:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_param_basic:
Subgroup basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-ctx-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-get:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup invalid-param-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup root-set:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ctx_switch:
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_basic:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup gtt-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-render:
skip   -> PASS   (bsw-nuc-2)
Subgroup readonly-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-bsd:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-default:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_exec_whisper:
Subgroup basic:
skip   -> PASS   (bsw-nuc-2)
Test gem_mmap:
Subgroup basic-small-bo:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-write:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-write-gtt:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-hang:
skip   -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-blt:
skip   -> PASS   (bsw-nuc-2)
Subgroup basic-vebox:
skip   -> PASS   (bsw-nuc-2)
Test gem_tiled_pread_basic:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup addfb25-modifier-no-flag:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup addfb25-y-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup bad-pitch-65536:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-x-tiled:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup framebuffer-vs-set-tiling:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup too-wide:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-fail -> PASS   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
dmesg-fail -> PASS   (bsw-nuc-2)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test prime_self_import:
Subgroup basic-with_fd_dup:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-with_one_bo_two_files:
dmesg-warn -> PASS   (bsw-nuc-2)

bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
BOOT FAILED for bdw-ultra
BOOT FAILED for hsw-gt2
BOOT FAILED for ilk-hp8440p
BOOT FAILED for ivb-t430s
BOOT FAILED for snb-x220t

Results at /archive/results/CI_IGT_test/Patchwork_1841/

851708c7e97537ed618fadbe5d342eaf8fa5146d drm-intel-nightly: 
2016y-04m-07d-13h-56m-00s UTC integration manifest
d1c691ef8fb989054ba0741ae602b3f4a6a5c0e1 drm/i915: call kunmap_px on pt_vaddr
7d49ab2650954a18622f0a75eea234738720d779 drm/i915: bail in alloc_pdp when 
!FULL_48BIT_PPGTT
60619f8d0cb4b5b410532ffe350f5b04f60b2120 drm/i915: handle potential overflow
7744ec046199c77939db325caa51ce222c1abcfe drm/i915: combine overflow checks
4fe9ce09e4b19212e6d9208d8abd9ded86f1c773 drm/i915: reference ppgtt->base.dev 
directly
34c6258df91bea31087d433c

Re: [Intel-gfx] [PATCH 2/6] drm/i915: reference ppgtt->base.dev directly

2016-04-08 Thread Joonas Lahtinen
On pe, 2016-04-08 at 10:32 +0100, Matthew Auld wrote:
> Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.
> 
> Cc: Joonas Lahtinen 
> Signed-off-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index da6e3a5..066d5aead 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -905,11 +905,10 @@ static int gen8_init_scratch(struct i915_address_space 
> *vm)
>  static int gen8_ppgtt_notify_vgt(struct i915_hw_ppgtt *ppgtt, bool create)
>  {
>   enum vgt_g2v_type msg;
> - struct drm_device *dev = ppgtt->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_i915_private *dev_priv = to_i915(ppgtt->base.dev);
>   int i;
>  
> - if (USES_FULL_48BIT_PPGTT(dev)) {
> + if (USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) {

All the QUESTION_MACROS() want dev_priv (they can figure it out from
dev too), so just pass it directly when it is available.

Regards, Joonas

>   u64 daddr = px_dma(&ppgtt->pml4);
>  
>   I915_WRITE(vgtif_reg(pdp[0].lo), lower_32_bits(daddr));
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/6] drm/i915: handle potential overflow

2016-04-08 Thread Chris Wilson
On Fri, Apr 08, 2016 at 10:32:32AM +0100, Matthew Auld wrote:
> Much like with the equivalent gen8_alloc_va_range.

Just delete the warn and make the allocation paths stronger if you feel
paranoid.
-Chris

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


Re: [Intel-gfx] [PATCH 1/6] drm/i915: remove IS_ERR_OR_NULL check

2016-04-08 Thread Chris Wilson
On Fri, Apr 08, 2016 at 10:32:29AM +0100, Matthew Auld wrote:
> A call to i915_gem_alloc_object can only ever return NULL in the event
> of an error.

We are planning to report the real error back.
-Chris

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


[Intel-gfx] [PATCH v2 6/6] drm/i915: Avoid allocating a vmap arena for a single page

2016-04-08 Thread Chris Wilson
If we want a contiguous mapping of a single page sized object, we can
forgo using vmap() and just use a regular kmap(). Note that this is only
suitable if the desired pgprot_t is compatible.

v2: Use is_vmalloc_addr()

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_gem.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fa810226bd8b..b37ffea8b458 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2233,7 +2233,10 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
*obj)
list_del(&obj->global_list);
 
if (obj->mapping) {
-   vunmap(obj->mapping);
+   if (is_vmalloc_addr(obj->mapping))
+   vunmap(obj->mapping);
+   else
+   kunmap(kmap_to_page(obj->mapping));
obj->mapping = NULL;
}
 
@@ -2418,13 +2421,19 @@ void *i915_gem_object_pin_map(struct 
drm_i915_gem_object *obj)
i915_gem_object_pin_pages(obj);
 
if (obj->mapping == NULL) {
-   struct sg_page_iter sg_iter;
struct page **pages;
-   int n;
 
-   n = obj->base.size >> PAGE_SHIFT;
-   pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
+   pages = NULL;
+   if (obj->base.size == PAGE_SIZE)
+   obj->mapping = kmap(sg_page(obj->pages->sgl));
+   else
+   pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
+  sizeof(*pages),
+  GFP_TEMPORARY);
if (pages != NULL) {
+   struct sg_page_iter sg_iter;
+   int n;
+
n = 0;
for_each_sg_page(obj->pages->sgl, &sg_iter,
 obj->pages->nents, 0)
-- 
2.8.0.rc3

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


[Intel-gfx] [PATCH v2 3/6] drm/i915: Refactor duplicate object vmap functions

2016-04-08 Thread Chris Wilson
We now have two implementations for vmapping a whole object, one for
dma-buf and one for the ringbuffer. If we couple the mapping into the
obj->pages lifetime, then we can reuse an obj->mapping for both and at
the same time couple it into the shrinker. There is a third vmapping
routine in the cmdparser that maps only a range within the object, for
the time being that is left alone, but will eventually use these routines
in order to cache the mapping between invocations.

v2: Mark the failable kmalloc() as __GFP_NOWARN (vsyrjala)
v3: Call unpin_vmap from the right dmabuf unmapper

v4: Rename vmap to map as we don't wish to imply the type of mapping
involved, just that it contiguously maps the object into kernel space.
Add kerneldoc and lockdep annotations

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_drv.h | 37 ++---
 drivers/gpu/drm/i915/i915_gem.c | 44 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c  | 49 -
 drivers/gpu/drm/i915/intel_ringbuffer.c | 26 ++---
 4 files changed, 84 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a93e5dd4fa9a..eda4218e2ede 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2169,10 +2169,7 @@ struct drm_i915_gem_object {
struct scatterlist *sg;
int last;
} get_page;
-
-   /* prime dma-buf support */
-   void *dma_buf_vmapping;
-   int vmapping_count;
+   void *mapping;
 
/** Breadcrumb of last rendering to the buffer.
 * There can only be one writer, but we allow for multiple readers.
@@ -2988,12 +2985,44 @@ static inline void i915_gem_object_pin_pages(struct 
drm_i915_gem_object *obj)
BUG_ON(obj->pages == NULL);
obj->pages_pin_count++;
 }
+
 static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
 {
BUG_ON(obj->pages_pin_count == 0);
obj->pages_pin_count--;
 }
 
+/**
+ * i915_gem_object_pin_map - return a contiguous mapping of the entire object
+ * @obj - the object to map into kernel address space
+ *
+ * Calls i915_gem_object_pin_pages() to prevent reaping of the object's
+ * pages and then returns a contiguous mapping of the backing storage into
+ * the kernel address space.
+ *
+ * The caller must hold the struct_mutex.
+ *
+ * Returns the pointer through which to access the backing storage.
+ */
+void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj);
+
+/**
+ * i915_gem_object_unpin_map - releases an earlier mapping
+ * @obj - the object to unmap
+ *
+ * After pinning the object and mapping its pages, once you are finished
+ * with your access, call i915_gem_object_unpin_map() to release the pin
+ * upon the mapping. Once the pin count reaches zero, that mapping may be
+ * removed.
+ *
+ * The caller must hold the struct_mutex.
+ */
+static inline void i915_gem_object_unpin_map(struct drm_i915_gem_object *obj)
+{
+   lockdep_assert_held(&obj->base.dev->struct_mutex);
+   i915_gem_object_unpin_pages(obj);
+}
+
 int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
 int i915_gem_object_sync(struct drm_i915_gem_object *obj,
 struct intel_engine_cs *to,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5a65a7663b88..fcbd47d36dcf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2232,6 +2232,11 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
*obj)
 * lists early. */
list_del(&obj->global_list);
 
+   if (obj->mapping) {
+   vunmap(obj->mapping);
+   obj->mapping = NULL;
+   }
+
ops->put_pages(obj);
obj->pages = NULL;
 
@@ -2400,6 +2405,45 @@ i915_gem_object_get_pages(struct drm_i915_gem_object 
*obj)
return 0;
 }
 
+void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj)
+{
+   int ret;
+
+   lockdep_assert_held(&obj->base.dev->struct_mutex);
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret)
+   return ERR_PTR(ret);
+
+   i915_gem_object_pin_pages(obj);
+
+   if (obj->mapping == NULL) {
+   struct sg_page_iter sg_iter;
+   struct page **pages;
+   int n;
+
+   n = obj->base.size >> PAGE_SHIFT;
+   pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
+   if (pages == NULL)
+   pages = drm_malloc_ab(n, sizeof(*pages));
+   if (pages != NULL) {
+   n = 0;
+   for_each_sg_page(obj->pages->sgl, &sg_iter,
+obj->pages->nents, 0)
+   pages[n++] = sg_page_iter_page(&sg_iter);
+
+   obj->mapping =

[Intel-gfx] vmap consolidation to obj->mapping

2016-04-08 Thread Chris Wilson
Now with a new lick of paint, I introduce the cached obj->mapping pointer
for all your contiguous accesses!

Enjoy,
-Chris

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


[Intel-gfx] [PATCH v2 1/6] drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_buf

2016-04-08 Thread Chris Wilson
We only need the struct_mutex to manipulate the pages_pin_count on the
object, we do not need to hold our BKL when freeing the exported
scatterlist.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 0506016e18e0..b7d46800c49f 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -95,14 +95,12 @@ static void i915_gem_unmap_dma_buf(struct 
dma_buf_attachment *attachment,
 {
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
 
-   mutex_lock(&obj->base.dev->struct_mutex);
-
dma_unmap_sg(attachment->dev, sg->sgl, sg->nents, dir);
sg_free_table(sg);
kfree(sg);
 
+   mutex_lock(&obj->base.dev->struct_mutex);
i915_gem_object_unpin_pages(obj);
-
mutex_unlock(&obj->base.dev->struct_mutex);
 }
 
-- 
2.8.0.rc3

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


[Intel-gfx] [PATCH v2 5/6] drm,i915: Introduce drm_malloc_gfp()

2016-04-08 Thread Chris Wilson
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want to
try a high-order kmalloc() before using a vmalloc().

So refactor my usage into drm_malloc_gfp().

Signed-off-by: Chris Wilson 
Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
Acked-by: Dave Airlie 
---
 drivers/gpu/drm/i915/i915_gem.c|  4 +---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  8 +++-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  5 +++--
 drivers/gpu/drm/i915/i915_gem_userptr.c| 16 +---
 include/drm/drm_mem_util.h | 19 +++
 5 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fcbd47d36dcf..fa810226bd8b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2423,9 +2423,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj)
int n;
 
n = obj->base.size >> PAGE_SHIFT;
-   pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
-   if (pages == NULL)
-   pages = drm_malloc_ab(n, sizeof(*pages));
+   pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
if (pages != NULL) {
n = 0;
for_each_sg_page(obj->pages->sgl, &sg_iter,
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0ee61fd014df..6ee4f00f620c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1783,11 +1783,9 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
return -EINVAL;
}
 
-   exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count,
-GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
-   if (exec2_list == NULL)
-   exec2_list = drm_malloc_ab(sizeof(*exec2_list),
-  args->buffer_count);
+   exec2_list = drm_malloc_gfp(args->buffer_count,
+   sizeof(*exec2_list),
+   GFP_TEMPORARY);
if (exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
  args->buffer_count);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index da6e3a533095..c5cb04907525 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3401,8 +3401,9 @@ intel_rotate_fb_obj_pages(struct intel_rotation_info 
*rot_info,
int ret = -ENOMEM;
 
/* Allocate a temporary list of source pages for random access. */
-   page_addr_list = drm_malloc_ab(obj->base.size / PAGE_SIZE,
-  sizeof(dma_addr_t));
+   page_addr_list = drm_malloc_gfp(obj->base.size / PAGE_SIZE,
+   sizeof(dma_addr_t),
+   GFP_TEMPORARY);
if (!page_addr_list)
return ERR_PTR(ret);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 962cb4c507cb..0f94b6c5c9cc 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -494,10 +494,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct 
*_work)
ret = -ENOMEM;
pinned = 0;
 
-   pvec = kmalloc(npages*sizeof(struct page *),
-  GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
-   if (pvec == NULL)
-   pvec = drm_malloc_ab(npages, sizeof(struct page *));
+   pvec = drm_malloc_gfp(npages, sizeof(struct page *), GFP_TEMPORARY);
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;
 
@@ -634,14 +631,11 @@ i915_gem_userptr_get_pages(struct drm_i915_gem_object 
*obj)
pvec = NULL;
pinned = 0;
if (obj->userptr.mm->mm == current->mm) {
-   pvec = kmalloc(num_pages*sizeof(struct page *),
-  GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
+   pvec = drm_malloc_gfp(num_pages, sizeof(struct page *),
+ GFP_TEMPORARY);
if (pvec == NULL) {
-   pvec = drm_malloc_ab(num_pages, sizeof(struct page *));
-   if (pvec == NULL) {
-   __i915_gem_userptr_set_active(obj, false);
-   return -ENOMEM;
-   }
+   __i915_gem_userptr_set_active(obj, false);
+   return -ENOMEM;
}
 
pinned = __get_user_pages_fast(obj->userptr.ptr, num_pages,
diff --git a/include/drm/drm_mem_util.h b/inc

[Intel-gfx] [PATCH v2 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

2016-04-08 Thread Chris Wilson
When called because we have run out of vmap address space, we only need
to recover objects that have vmappings and not all.

v2: Start using is_vmalloc_addr()

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 10 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eda4218e2ede..4061a11e4234 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3338,6 +3338,7 @@ unsigned long i915_gem_shrink(struct drm_i915_private 
*dev_priv,
 #define I915_SHRINK_UNBOUND 0x2
 #define I915_SHRINK_BOUND 0x4
 #define I915_SHRINK_ACTIVE 0x8
+#define I915_SHRINK_VMAPS 0x10
 unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv);
 void i915_gem_shrinker_init(struct drm_i915_private *dev_priv);
 void i915_gem_shrinker_cleanup(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 39943793edcc..d46388f25e04 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -167,6 +167,10 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
obj->madv != I915_MADV_DONTNEED)
continue;
 
+   if (flags & I915_SHRINK_VMAPS &&
+   !is_vmalloc_addr(obj->mapping))
+   continue;
+
if ((flags & I915_SHRINK_ACTIVE) == 0 && obj->active)
continue;
 
@@ -388,7 +392,11 @@ i915_gem_shrinker_vmap(struct notifier_block *nb, unsigned 
long event, void *ptr
if (!i915_gem_shrinker_lock_uninterruptible(dev_priv, &slu, 5000))
return NOTIFY_DONE;
 
-   freed_pages = i915_gem_shrink_all(dev_priv);
+   freed_pages = i915_gem_shrink(dev_priv, -1UL,
+ I915_SHRINK_BOUND |
+ I915_SHRINK_UNBOUND |
+ I915_SHRINK_ACTIVE |
+ I915_SHRINK_VMAPS);
 
i915_gem_shrinker_unlock_uninterruptible(dev_priv, &slu);
 
-- 
2.8.0.rc3

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


[Intel-gfx] [PATCH v2 2/6] drm/i915: Consolidate common error handling in intel_pin_and_map_ringbuffer_obj

2016-04-08 Thread Chris Wilson
After we pin the ringbuffer into the GGTT, all error paths need to unpin
it again. Move this common step into one block, and make the unable to
iomap error code consistent (i.e. treat it as out of memory to avoid
confusing it with a invalid argument).

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6b4952031e30..600ccc403b1f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2121,15 +2121,13 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
return ret;
 
ret = i915_gem_object_set_to_cpu_domain(obj, true);
-   if (ret) {
-   i915_gem_object_ggtt_unpin(obj);
-   return ret;
-   }
+   if (ret)
+   goto err_unpin;
 
ringbuf->virtual_start = vmap_obj(obj);
if (ringbuf->virtual_start == NULL) {
-   i915_gem_object_ggtt_unpin(obj);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err_unpin;
}
} else {
ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
@@ -2137,10 +2135,8 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
return ret;
 
ret = i915_gem_object_set_to_gtt_domain(obj, true);
-   if (ret) {
-   i915_gem_object_ggtt_unpin(obj);
-   return ret;
-   }
+   if (ret)
+   goto err_unpin;
 
/* Access through the GTT requires the device to be awake. */
assert_rpm_wakelock_held(dev_priv);
@@ -2148,14 +2144,17 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
ringbuf->virtual_start = ioremap_wc(ggtt->mappable_base +

i915_gem_obj_ggtt_offset(obj), ringbuf->size);
if (ringbuf->virtual_start == NULL) {
-   i915_gem_object_ggtt_unpin(obj);
-   return -EINVAL;
+   ret = -ENOMEM;
+   goto err_unpin;
}
}
 
ringbuf->vma = i915_gem_obj_to_ggtt(obj);
-
return 0;
+
+err_unpin:
+   i915_gem_object_ggtt_unpin(obj);
+   return ret;
 }
 
 static void intel_destroy_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
-- 
2.8.0.rc3

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


Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/bxt: Block D3 during suspend.

2016-04-08 Thread David Weinehall
On Thu, Apr 07, 2016 at 08:22:11PM +0530, Animesh Manna wrote:
> For BXT, display engine can not generate interrupt when in D3.
> On the othen hand S0ix can be achieved without display in D3. So,

other

> Display should not put into D3 for HPD to work and will not
> have any power impact.
> 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 020a31c..6b8c906 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1547,6 +1547,9 @@ static int intel_runtime_suspend(struct device *device)
>  
>   assert_forcewakes_inactive(dev_priv);
>  
> + if (dev_priv->vbt.hpd_wakeup_enabled)
> + pci_save_state(pdev);
> +
>   DRM_DEBUG_KMS("Device suspended\n");
>   return 0;
>  }
> @@ -1563,6 +1566,9 @@ static int intel_runtime_resume(struct device *device)
>  
>   DRM_DEBUG_KMS("Resuming device\n");
>  
> + if (dev_priv->vbt.hpd_wakeup_enabled)
> + pci_restore_state(pdev);

If the state hasn't been saved pci_restore_state() will return
without doing anything, so the conditional shouldn't be necessary.

> +
>   WARN_ON_ONCE(atomic_read(&dev_priv->pm.wakeref_count));
>   disable_rpm_wakeref_asserts(dev_priv);

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


[Intel-gfx] [PATCH 2/3] drm/i915: Store and use edram capabilities

2016-04-08 Thread Mika Kuoppala
Store the edram capabilities instead of only the size of
edram. This is preparatory patch to allow edram size calculation
based on edram capability bits for gen9+. With gen9 the
edram is behind llc and is a separate entity. With hsw/bdw
it was more of a victim cache for LLC so the name 'eLLC' might
be warranted. Regardless, rename all mentions of eLLC to EDRAM to
clear the confusion.

v2: return bytes for edram size (Chris)
s/eLLC/eDRAM in output if we are gen > 8

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  5 +++--
 drivers/gpu/drm/i915/i915_drv.h |  7 +--
 drivers/gpu/drm/i915/i915_gem.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  3 ++-
 drivers/gpu/drm/i915/i915_reg.h |  2 +-
 drivers/gpu/drm/i915/intel_uncore.c | 39 +
 6 files changed, 39 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ebbf4e400684..dc9a987acff6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2402,10 +2402,11 @@ static int i915_llc(struct seq_file *m, void *data)
struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   const bool edram = INTEL_INFO(dev_priv)->gen > 8;
 
-   /* Size calculation for LLC is a bit of a pain. Ignore for now. */
seq_printf(m, "LLC: %s\n", yesno(HAS_LLC(dev)));
-   seq_printf(m, "eLLC: %zuMB\n", dev_priv->ellc_size);
+   seq_printf(m, "%s: %lluMB\n", edram ? "eDRAM" : "eLLC",
+  intel_uncore_edram_size(dev_priv)/1024/1024);
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a93e5dd4fa9a..80ae4c7307d8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1863,7 +1863,7 @@ struct drm_i915_private {
struct intel_l3_parity l3_parity;
 
/* Cannot be determined by PCIID. You must always read a register. */
-   size_t ellc_size;
+   u32 edram_cap;
 
/* gen6+ rps state */
struct intel_gen6_power_mgmt rps;
@@ -2616,8 +2616,9 @@ struct drm_i915_cmd_table {
 #define HAS_VEBOX(dev) (INTEL_INFO(dev)->ring_mask & VEBOX_RING)
 #define HAS_LLC(dev)   (INTEL_INFO(dev)->has_llc)
 #define HAS_SNOOP(dev) (INTEL_INFO(dev)->has_snoop)
+#define HAS_EDRAM(dev) (__I915__(dev)->edram_cap & EDRAM_ENABLED)
 #define HAS_WT(dev)((IS_HASWELL(dev) || IS_BROADWELL(dev)) && \
-__I915__(dev)->ellc_size)
+HAS_EDRAM(dev))
 #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
 
 #define HAS_HW_CONTEXTS(dev)   (INTEL_INFO(dev)->gen >= 6)
@@ -2794,6 +2795,8 @@ void intel_uncore_forcewake_get__locked(struct 
drm_i915_private *dev_priv,
enum forcewake_domains domains);
 void intel_uncore_forcewake_put__locked(struct drm_i915_private *dev_priv,
enum forcewake_domains domains);
+u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv);
+
 void assert_forcewakes_inactive(struct drm_i915_private *dev_priv);
 static inline bool intel_vgpu_active(struct drm_device *dev)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 71db5ca04483..7310da8f08b9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4841,7 +4841,7 @@ i915_gem_init_hw(struct drm_device *dev)
/* Double layer security blanket, see i915_gem_init() */
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
-   if (dev_priv->ellc_size && INTEL_INFO(dev)->gen < 9)
+   if (HAS_EDRAM(dev) && INTEL_INFO(dev)->gen < 9)
I915_WRITE(HSW_IDICR, I915_READ(HSW_IDICR) | IDIHASHMSK(0xf));
 
if (IS_HASWELL(dev))
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index da6e3a533095..75c2109dfc6c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3172,7 +3172,8 @@ int i915_ggtt_init_hw(struct drm_device *dev)
} else if (INTEL_INFO(dev)->gen < 8) {
ggtt->probe = gen6_gmch_probe;
ggtt->base.cleanup = gen6_gmch_remove;
-   if (IS_HASWELL(dev) && dev_priv->ellc_size)
+
+   if (HAS_EDRAM(dev))
ggtt->base.pte_encode = iris_pte_encode;
else if (IS_HASWELL(dev))
ggtt->base.pte_encode = hsw_pte_encode;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0744759170d3..3bd52185b946 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6870,7 +6870,7 @@ enum skl_disp_power_wells {
 
 #define  HSW_IDICR _MMIO(0x9008)
 #define  

[Intel-gfx] [PATCH 1/3] drm/i915: Don't program eLLC IDI hash mask for gen9+

2016-04-08 Thread Mika Kuoppala
For gen9 onwards, eDRAM is a true memory side cache. So
there is no need to program idi has mask as it is for eLLC
only.

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5a65a7663b88..71db5ca04483 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4841,7 +4841,7 @@ i915_gem_init_hw(struct drm_device *dev)
/* Double layer security blanket, see i915_gem_init() */
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
-   if (dev_priv->ellc_size)
+   if (dev_priv->ellc_size && INTEL_INFO(dev)->gen < 9)
I915_WRITE(HSW_IDICR, I915_READ(HSW_IDICR) | IDIHASHMSK(0xf));
 
if (IS_HASWELL(dev))
-- 
2.5.0

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


[Intel-gfx] [PATCH 3/3] drm/i915: Calculate edram size

2016-04-08 Thread Mika Kuoppala
With gen9+ the edram capabilities are defined so
that we can calculate the edram (ellc) size accordingly.

Note that there are undefined combinations for some subset of
edram capability bits. Return the closest size for undefined indexes.
Even if we get it wrong with beginning of future gen enabling, the size
information is currently only used for boot message and in debugfs entry.

v2: Use function instead of hard to read macro (Daniel)

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_reg.h |  3 +++
 drivers/gpu/drm/i915/intel_uncore.c | 21 +
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3bd52185b946..7fa3598a15e7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6872,6 +6872,9 @@ enum skl_disp_power_wells {
 #defineIDIHASHMSK(x)   (((x) & 0x3f) << 16)
 #define  HSW_EDRAM_CAP _MMIO(0x120010)
 #defineEDRAM_ENABLED   0x1
+#defineEDRAM_NUM_BANKS(cap)(((cap) >> 1) & 0xf)
+#defineEDRAM_WAYS_IDX(cap) (((cap) >> 5) & 0x7)
+#defineEDRAM_SETS_IDX(cap) (((cap) >> 8) & 0x3)
 
 #define GEN6_UCGCTL1   _MMIO(0x9400)
 # define GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE (1 << 16)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 2cd975856eeb..2798295f6e51 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -310,17 +310,30 @@ void intel_uncore_forcewake_reset(struct drm_device *dev, 
bool restore)
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
 }
 
+static u64 gen9_edram_size(struct drm_i915_private *dev_priv)
+{
+   const unsigned int ways[8] = { 4, 8, 12, 16, 16, 16, 16, 16 };
+   const unsigned int sets[4] = { 1, 1, 2, 2 };
+   const u32 cap = dev_priv->edram_cap;
+
+   return EDRAM_NUM_BANKS(cap) *
+   ways[EDRAM_WAYS_IDX(cap)] *
+   sets[EDRAM_SETS_IDX(cap)] *
+   1024 * 1024;
+}
+
 u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv)
 {
if (!HAS_EDRAM(dev_priv))
return 0;
 
-   /* The docs do not explain exactly how the calculation can be
-* made. It is somewhat guessable, but for now, it's always
-* 128MB.
+   /* The needed capability bits for size calculation
+* are not there with pre gen9 so return 128MB always.
 */
+   if (INTEL_INFO(dev_priv)->gen < 9)
+   return 128 * 1024 * 1024;
 
-   return 128 * 1024 * 1024;
+   return gen9_edram_size(dev_priv);
 }
 
 static void intel_uncore_edram_detect(struct drm_i915_private *dev_priv)
-- 
2.5.0

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


[Intel-gfx] [PATCH 0/3] edram size calculation

2016-04-08 Thread Mika Kuoppala
The skl I have reported wrong amount in dmesg.

Mika Kuoppala (3):
  drm/i915: Don't program eLLC IDI hash mask for gen9+
  drm/i915: Store and use edram capabilities
  drm/i915: Calculate edram size

 drivers/gpu/drm/i915/i915_debugfs.c |  5 ++--
 drivers/gpu/drm/i915/i915_drv.h |  7 +++--
 drivers/gpu/drm/i915/i915_gem.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |  3 ++-
 drivers/gpu/drm/i915/i915_reg.h |  5 +++-
 drivers/gpu/drm/i915/intel_uncore.c | 52 -
 6 files changed, 55 insertions(+), 19 deletions(-)

-- 
2.5.0

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915: Don't program eLLC IDI hash mask for gen9+

2016-04-08 Thread Chris Wilson
On Fri, Apr 08, 2016 at 02:54:03PM +0300, Mika Kuoppala wrote:
> For gen9 onwards, eDRAM is a true memory side cache. So
> there is no need to program idi has mask as it is for eLLC
> only.
> 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 5a65a7663b88..71db5ca04483 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4841,7 +4841,7 @@ i915_gem_init_hw(struct drm_device *dev)
>   /* Double layer security blanket, see i915_gem_init() */
>   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
>  
> - if (dev_priv->ellc_size)
> + if (dev_priv->ellc_size && INTEL_INFO(dev)->gen < 9)

INTEL_GEN(dev_priv) < 9
-Chris

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


Re: [Intel-gfx] [PATCH 2/3] drm/i915: Store and use edram capabilities

2016-04-08 Thread Chris Wilson
On Fri, Apr 08, 2016 at 02:54:04PM +0300, Mika Kuoppala wrote:
> Store the edram capabilities instead of only the size of
> edram. This is preparatory patch to allow edram size calculation
> based on edram capability bits for gen9+. With gen9 the
> edram is behind llc and is a separate entity. With hsw/bdw
> it was more of a victim cache for LLC so the name 'eLLC' might
> be warranted. Regardless, rename all mentions of eLLC to EDRAM to
> clear the confusion.
> 
> v2: return bytes for edram size (Chris)
> s/eLLC/eDRAM in output if we are gen > 8
> 
> Signed-off-by: Mika Kuoppala 

With INTEL_GEN where introduced
Reviewed-by: Chris Wilson 
-Chris

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2,1/6] drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_buf

2016-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [v2,1/6] drm/i915/dmabuf: Tighten struct_mutex for 
unmap_dma_buf
URL   : https://patchwork.freedesktop.org/series/5454/
State : warning

== Summary ==

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

Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (skl-i7k-2)
Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> SKIP   (snb-x220t)
Test pm_rpm:
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:172  dwarn:1   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:161  dwarn:0   dfail:0   fail:1   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1842/

949884a57b51aa158e3ae9afe1f08130cdb7a3ef drm-intel-nightly: 
2016y-04m-08d-10h-45m-28s UTC integration manifest
8d7c7c27f5609b0ba9af71fa1fd4cfeeff632757 drm/i915: Avoid allocating a vmap 
arena for a single page
4485414d9cff3cac069b328a526c64f7bc615c8f drm,i915: Introduce drm_malloc_gfp()
b8c857a26ca887a36535fb1d107c41333419921f drm/i915/shrinker: Restrict vmap purge 
to objects with vmaps
94e5014d54ccbb1fef06141c0ae801f6e7631b55 drm/i915: Refactor duplicate object 
vmap functions
1c7d13206cd237ef9f1b34edebefae80592f74a3 drm/i915: Consolidate common error 
handling in intel_pin_and_map_ringbuffer_obj
d94080d534d0b0f0054ca3aa7550fcdfe7cf4780 drm/i915/dmabuf: Tighten struct_mutex 
for unmap_dma_buf

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


Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/bxt: Corrected the guid for bxt.

2016-04-08 Thread David Weinehall
On Fri, Apr 08, 2016 at 12:00:22PM +0300, Jani Nikula wrote:
> On Thu, 07 Apr 2016, Animesh Manna  wrote:
> > Guid is changed for bxt platform, so corrected the guid for bxt.
> >
> > Signed-off-by: Ananth Krishna R 
> > Signed-off-by: Bharath K Veera 
> > Signed-off-by: Animesh Manna 
> > ---
> >  drivers/gpu/drm/i915/intel_acpi.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
> > b/drivers/gpu/drm/i915/intel_acpi.c
> > index 8f3d672..8ba30b3 100644
> > --- a/drivers/gpu/drm/i915/intel_acpi.c
> > +++ b/drivers/gpu/drm/i915/intel_acpi.c
> > @@ -17,7 +17,7 @@ static struct intel_dsm_priv {
> > acpi_handle dhandle;
> >  } intel_dsm_priv;
> >  
> > -static const u8 intel_dsm_guid[] = {
> > +static u8 intel_dsm_guid[] = {
> > 0xd3, 0x73, 0xd8, 0x7e,
> > 0xd0, 0xc2,
> > 0x4f, 0x4e,
> > @@ -25,6 +25,9 @@ static const u8 intel_dsm_guid[] = {
> > 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
> >  };
> >  
> > +static u8 intel_bxt_dsm_guid[] =
> > +   "3E5B41C6-EB1D-4260-9D15-C71FBADAE414";
> > +
> 
> So I want both of these to be either in string form or in binary uuid
> form, not a mixture. Having them in binary makes the code simpler, so
> I'd go for that.

I was just gonna suggest the same.  Also, isn't this a fix we want
merged independently from the HPD-related changes?  If so this
should submitted separately (or at least be modified so it can be
the first patch in the series).


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


[Intel-gfx] ✓ Fi.CI.BAT: success for edram size calculation

2016-04-08 Thread Patchwork
== Series Details ==

Series: edram size calculation
URL   : https://patchwork.freedesktop.org/series/5457/
State : success

== Summary ==

Series 5457v1 edram size calculation
http://patchwork.freedesktop.org/api/1.0/series/5457/revisions/1/mbox/

Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1843/

949884a57b51aa158e3ae9afe1f08130cdb7a3ef drm-intel-nightly: 
2016y-04m-08d-10h-45m-28s UTC integration manifest
2708ebba186b507cd7e6f9b745d9e38f4c7b67c0 drm/i915: Calculate edram size
1350456345505fe31d7b60b2ad0ddce6de9bdcf2 drm/i915: Store and use edram 
capabilities
7eb48c897775f11f3b55777567a424a4eefcec34 drm/i915: Don't program eLLC IDI hash 
mask for gen9+

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


Re: [Intel-gfx] [RFC/PATCH xf86-video-intel] sna: Let modestting + glamor handle gen9+

2016-04-08 Thread Hans de Goede

Hi,

On 11-03-16 11:07, Timo Aaltonen wrote:

29.02.2016, 16:47, Hans de Goede kirjoitti:

sna has no meaningfull accel for gen9+, this causes problems with i.e.
apps using XVideo since the sprite XVideo support does not work well
for many apps.

Therefor it is better to just let the xserver fall back to modesetting +
glamor. This is implemented by returning FALSE from the probe methods,
just like how nouveau handles falling back to modesetting for newer cards.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1305369
Signed-off-by: Hans de Goede 


I've been trying to make this work, but there are cases where it fails bad:

# a config file with a Device section that loads 'intel' makes the
server fail
[10.153] (EE) No devices detected.
[10.153] (EE)
Fatal server error:
[10.153] (EE) no screens found(EE)

ie. no fallback in that case

# with X run as root (wrapper or not), same thing different cause
[   145.943] (EE) modeset(0): drmSetMaster failed: Invalid argument
[   145.943] (EE)
Fatal server error:
[   145.943] (EE) AddScreen/ScreenInit failed for driver 0


but it does work with startx run by a user. Tests done on Debian with
1.18.1 and intel ddx git.


This must be some Debian specific issue, I just tried this with Xorg-1.18.3
on Fedora, with a Xwrapper.config forcing X to always run as root and it works
fine (using startx).

In that case systemd-logind integration should still work though, so it may
be that the way you are starting Xorg causes the systemd-logind integration
to not work though, and that the fallback paths for opening the /dev/drm/card#
in the modesetting driver are broken. How exactly are you starting X ?

Can you provide full logs of a failed start ?

Regards,

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


[Intel-gfx] [PATCH 3/3] drm/i915: Get panel_type from OpRegion panel details

2016-04-08 Thread ville . syrjala
From: Ville Syrjälä 

We've had problems on several occasions with using the panel type
from the VBT block 40. Usually it seems to be 2, which often
doesn't give us the correct timings for the panel. After some
more digging I found a way to get a panel type via the OpRegion
SWSCI GBDA "Get Panel Details" method. Let's try to use it.

The spec has this to say about the output:
"Bits [15:8] - Panel Type
 Bits contain the panel type user setting from CMOS
 00h = Not Valid, use default Panel Type & Timings from VBT
 01h - 0Fh = Panel Number"

The other bits in the output don't look relevant for the problem at
hand.

The input is specified as:
"Bits [31:4] - Reserved
 Reserved (must be zero)
 Bits [3:0] - Panel Number
 These bits contain the sequential index of Panel, starting at 0 and
 counting upwards from the first integrated Internal Flat-Panel Display
 Encoder present, and then from the first external Display Encoder
 (e.g., S/DVO-B then S/DVO-C) which supports Internal Flat-Panels.
 0h - 0Fh = Panel number"

For now I've just hardcoded the input panel number as 0. That would seem
like a decent choise for LVDS. Not so sure about eDP when port != A.

Cc: Rob Kramer 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h   |  5 +
 drivers/gpu/drm/i915/intel_bios.c | 13 ++---
 drivers/gpu/drm/i915/intel_opregion.c | 13 +
 3 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 53ace572b292..533263a7a12d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3421,6 +3421,7 @@ extern int intel_opregion_notify_encoder(struct 
intel_encoder *intel_encoder,
 bool enable);
 extern int intel_opregion_notify_adapter(struct drm_device *dev,
 pci_power_t state);
+extern int intel_opregion_get_panel_type(struct drm_device *dev);
 #else
 static inline int intel_opregion_setup(struct drm_device *dev) { return 0; }
 static inline void intel_opregion_init(struct drm_device *dev) { return; }
@@ -3436,6 +3437,10 @@ intel_opregion_notify_adapter(struct drm_device *dev, 
pci_power_t state)
 {
return 0;
 }
+static inline int intel_opregion_get_panel_type(struct drm_device *dev)
+{
+   return 0;
+}
 #endif
 
 /* intel_acpi.c */
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index d9568be4b33b..718e49931b5f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -205,16 +205,23 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
struct drm_display_mode *panel_fixed_mode;
int panel_type;
int drrs_mode;
+   int ret;
 
lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
if (!lvds_options)
return;
 
dev_priv->vbt.lvds_dither = lvds_options->pixel_dither;
-   if (lvds_options->panel_type > 0xf)
-   return;
 
-   panel_type = lvds_options->panel_type;
+   ret = intel_opregion_get_panel_type(dev_priv->dev);
+   if (ret >= 0x1 && ret <= 0xf) {
+   panel_type = ret;
+   } else {
+   if (lvds_options->panel_type > 0xf)
+   return;
+   panel_type = lvds_options->panel_type;
+   }
+
dev_priv->vbt.panel_type = panel_type;
 
drrs_mode = (lvds_options->dps_panel_type_bits
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index c15718b4862a..5e17fa5dc869 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -1024,3 +1024,16 @@ err_out:
memunmap(base);
return err;
 }
+
+int
+intel_opregion_get_panel_type(struct drm_device *dev)
+{
+   u32 panel_details;
+   int ret;
+
+   ret = swsci(dev, SWSCI_GBDA_PANEL_DETAILS, 0x0, &panel_details);
+   if (ret)
+   return ret;
+
+   return (panel_details >> 8) & 0xff;
+}
-- 
2.7.4

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


[Intel-gfx] [PATCH 2/3] drm/i915: Replace the static panel_type variable with dev_priv->vbt.panel_type

2016-04-08 Thread ville . syrjala
From: Ville Syrjälä 

Store the extracted panel_type under dev_priv.vbt instead of keeping
around a static variable for it.

Cc: Rob Kramer 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c | 13 +
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4ebd3ff02803..53ace572b292 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1443,6 +1443,7 @@ struct intel_vbt_data {
unsigned int lvds_use_ssc:1;
unsigned int display_clock_mode:1;
unsigned int fdi_rx_polarity_inverted:1;
+   unsigned int panel_type:4;
int lvds_ssc_freq;
unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
 
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 13bdd4316092..d9568be4b33b 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -58,8 +58,6 @@
 #defineSLAVE_ADDR1 0x70
 #defineSLAVE_ADDR2 0x72
 
-static int panel_type;
-
 /* Get BDB block size given a pointer to Block ID. */
 static u32 _get_blocksize(const u8 *block_base)
 {
@@ -205,6 +203,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
const struct lvds_dvo_timing *panel_dvo_timing;
const struct lvds_fp_timing *fp_timing;
struct drm_display_mode *panel_fixed_mode;
+   int panel_type;
int drrs_mode;
 
lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
@@ -216,6 +215,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
return;
 
panel_type = lvds_options->panel_type;
+   dev_priv->vbt.panel_type = panel_type;
 
drrs_mode = (lvds_options->dps_panel_type_bits
>> (panel_type * 2)) & MODE_MASK;
@@ -251,7 +251,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
 
panel_dvo_timing = get_lvds_dvo_timing(lvds_lfp_data,
   lvds_lfp_data_ptrs,
-  lvds_options->panel_type);
+  panel_type);
 
panel_fixed_mode = kzalloc(sizeof(*panel_fixed_mode), GFP_KERNEL);
if (!panel_fixed_mode)
@@ -266,7 +266,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
 
fp_timing = get_lvds_fp_timing(bdb, lvds_lfp_data,
   lvds_lfp_data_ptrs,
-  lvds_options->panel_type);
+  panel_type);
if (fp_timing) {
/* check the resolution, just to be sure */
if (fp_timing->x_res == panel_fixed_mode->hdisplay &&
@@ -284,6 +284,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
 {
const struct bdb_lfp_backlight_data *backlight_data;
const struct bdb_lfp_backlight_data_entry *entry;
+   int panel_type = dev_priv->vbt.panel_type;
 
backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
if (!backlight_data)
@@ -546,6 +547,7 @@ parse_edp(struct drm_i915_private *dev_priv, const struct 
bdb_header *bdb)
const struct bdb_edp *edp;
const struct edp_power_seq *edp_pps;
const struct edp_link_params *edp_link_params;
+   int panel_type = dev_priv->vbt.panel_type;
 
edp = find_section(bdb, BDB_EDP);
if (!edp) {
@@ -657,6 +659,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct 
bdb_header *bdb)
 {
const struct bdb_psr *psr;
const struct psr_table *psr_table;
+   int panel_type = dev_priv->vbt.panel_type;
 
psr = find_section(bdb, BDB_PSR);
if (!psr) {
@@ -703,6 +706,7 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
const struct bdb_mipi_config *start;
const struct mipi_config *config;
const struct mipi_pps_data *pps;
+   int panel_type = dev_priv->vbt.panel_type;
 
/* parse MIPI blocks only if LFP type is MIPI */
if (!intel_bios_is_dsi_present(dev_priv, NULL))
@@ -910,6 +914,7 @@ static void
 parse_mipi_sequence(struct drm_i915_private *dev_priv,
const struct bdb_header *bdb)
 {
+   int panel_type = dev_priv->vbt.panel_type;
const struct bdb_mipi_sequence *sequence;
const u8 *seq_data;
u32 seq_size;
-- 
2.7.4

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


[Intel-gfx] [PATCH 1/3] drm/i915: Reject panel_type > 0xf from VBT

2016-04-08 Thread ville . syrjala
From: Ville Syrjälä 

VBT can only contain 16 panel entries, indexed with the panel_type.
To play it safe we should reject panel_type > 0xf, so that we don't
read past the valid data.

Cc: Rob Kramer 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_bios.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index eb756c41d9e1..13bdd4316092 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -212,7 +212,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
return;
 
dev_priv->vbt.lvds_dither = lvds_options->pixel_dither;
-   if (lvds_options->panel_type == 0xff)
+   if (lvds_options->panel_type > 0xf)
return;
 
panel_type = lvds_options->panel_type;
-- 
2.7.4

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


[Intel-gfx] [RFC 2/4] drm/i915/guc: Keep the previous context pinned until the next one has been completed

2016-04-08 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

In GuC mode submitting requests is only putting them into the
GuC queue with the actual submission to hardware following at
some future point. This makes the per engine last context
tracking insufficient for closing the premature context
unpin race.

Instead we need to make requests track and pin the previous
context on the same engine, and only unpin them when they
themselves are retired. This will ensure contexts remain pinned
in all cases until the are fully saved by the GPU.

v2: Only track contexts.

Signed-off-by: Tvrtko Ursulin 
Cc: Alex Dai 
Cc: Dave Gordon 
Cc: Nick Hoath 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |  4 +++-
 drivers/gpu/drm/i915/i915_gem.c  |  5 +
 drivers/gpu/drm/i915/intel_lrc.c | 17 +
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fa199b7e51b5..216b2297ae3e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2283,6 +2283,9 @@ struct drm_i915_gem_request {
struct intel_context *ctx;
struct intel_ringbuffer *ringbuf;
 
+   /** Context preceding this one on the same engine. Can be NULL. */
+   struct intel_context *prev_ctx;
+
/** Batch buffer related to this request if any (used for
error state dump only) */
struct drm_i915_gem_object *batch_obj;
@@ -2318,7 +2321,6 @@ struct drm_i915_gem_request {
 
/** Execlists no. of times this request has been sent to the ELSP */
int elsp_submitted;
-
 };
 
 struct drm_i915_gem_request * __must_check
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c1df696f9002..118911ce7231 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1445,6 +1445,11 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
 */
request->ringbuf->last_retired_head = request->postfix;
 
+   if (request->prev_ctx) {
+   intel_lr_context_unpin(request->prev_ctx, request->engine);
+   request->prev_ctx = NULL;
+   }
+
__i915_gem_request_release(request);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 31445aa3429b..3d08dac0a9b0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -798,6 +798,23 @@ intel_logical_ring_advance_and_submit(struct 
drm_i915_gem_request *request)
if (intel_engine_stopped(engine))
return 0;
 
+   /*
+* Pin the previous context on this engine to ensure it is not
+* prematurely unpinned in GuC mode.
+* Previous context will be unpinned when this request is retired,
+* ensuring the GPU has switched out from the previous context and into
+* a new context at that point.
+*/
+   if (engine->last_context) {
+   if (engine->last_context != request->i915->kernel_context) {
+   intel_lr_context_pin(engine->last_context, engine);
+   request->prev_ctx = engine->last_context;
+   }
+   }
+
+   /*
+* Track and pin the last context submitted on an engine.
+*/
if (engine->last_context != request->ctx) {
if (engine->last_context)
intel_lr_context_unpin(engine->last_context, engine);
-- 
1.9.1

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


[Intel-gfx] [RFC 3/4] drm/i915: Use new i915_gem_object_pin_map for LRC

2016-04-08 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

We can use the new pin/lazy unpin API for more performance
in the execlist submission paths.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3d08dac0a9b0..5e967943ce49 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -,8 +,8 @@ static int intel_lr_context_do_pin(struct intel_context 
*ctx,
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *ctx_obj = ctx->engine[engine->id].state;
struct intel_ringbuffer *ringbuf = ctx->engine[engine->id].ringbuf;
-   struct page *lrc_state_page;
-   uint32_t *lrc_reg_state;
+   void *obj_addr;
+   u32 *lrc_reg_state;
int ret;
 
WARN_ON(!mutex_is_locked(&engine->dev->struct_mutex));
@@ -1122,11 +1122,11 @@ static int intel_lr_context_do_pin(struct intel_context 
*ctx,
if (ret)
return ret;
 
-   lrc_state_page = i915_gem_object_get_dirty_page(ctx_obj, LRC_STATE_PN);
-   if (WARN_ON(!lrc_state_page)) {
-   ret = -ENODEV;
+   obj_addr = i915_gem_object_pin_map(ctx_obj);
+   if (!obj_addr)
goto unpin_ctx_obj;
-   }
+
+   lrc_reg_state = obj_addr + LRC_STATE_PN * PAGE_SIZE;
 
ret = intel_pin_and_map_ringbuffer_obj(engine->dev, ringbuf);
if (ret)
@@ -1134,7 +1134,6 @@ static int intel_lr_context_do_pin(struct intel_context 
*ctx,
 
ctx->engine[engine->id].lrc_vma = i915_gem_obj_to_ggtt(ctx_obj);
intel_lr_context_descriptor_update(ctx, engine);
-   lrc_reg_state = kmap(lrc_state_page);
lrc_reg_state[CTX_RING_BUFFER_START+1] = ringbuf->vma->node.start;
ctx->engine[engine->id].lrc_reg_state = lrc_reg_state;
ctx_obj->dirty = true;
@@ -1177,7 +1176,7 @@ void intel_lr_context_unpin(struct intel_context *ctx,
 
WARN_ON(!mutex_is_locked(&ctx->i915->dev->struct_mutex));
if (--ctx->engine[engine->id].pin_count == 0) {
-   kunmap(kmap_to_page(ctx->engine[engine->id].lrc_reg_state));
+   i915_gem_object_unpin_map(ctx_obj);
intel_unpin_ringbuffer_obj(ctx->engine[engine->id].ringbuf);
i915_gem_object_ggtt_unpin(ctx_obj);
ctx->engine[engine->id].lrc_vma = NULL;
-- 
1.9.1

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


[Intel-gfx] [RFC 0/4] Eliminating the execlist retired request queue

2016-04-08 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Retired request queue coupled with retired work handler is a scalability
concern on some workloads of which one dramatic example is gem_close_race.

This series depend on i915_gem_object_pin_map series by Chris Wilson.

Brief outline of patches:

 1/4) Allow lockless request unreference - needed for 4/4.
 2/4) Pin the LRC until the following request is completed - needed for
  GuC mode on its own and also enables 4/4.
 3/4) Use i915_gem_object_pin_map in execlists to alleviate increase in
  LRC pin/unpin this series adds.
 4/4) Removes retired_req_queue.

Lightly tested so RFC for now. Did not spot any performance difference in
my usual benchmarks but did not look very closely yet. There may be wins in
CPU usage. TBD.

Easiest way to see the change is gem_close_race which finishes in 10-20 seconds
with this series and otherwise takes ten minutes to half an hour.

TODO:

1) Patches 2 and 3 should probably swap order.
2) More benchmarking including CPU usage and power.
3) Need a better cover letter as well.

Chris Wilson (1):
  drm/i915: Move releasing of the GEM request from free to retire/cancel

Tvrtko Ursulin (3):
  drm/i915/guc: Keep the previous context pinned until the next one has
been completed
  drm/i915: Use new i915_gem_object_pin_map for LRC
  drm/i915: Stop tracking execlists retired requests

 drivers/gpu/drm/i915/i915_drv.h | 18 ++--
 drivers/gpu/drm/i915/i915_gem.c | 63 +-
 drivers/gpu/drm/i915/intel_display.c|  2 +-
 drivers/gpu/drm/i915/intel_lrc.c| 78 -
 drivers/gpu/drm/i915/intel_lrc.h|  2 +-
 drivers/gpu/drm/i915/intel_pm.c |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
 7 files changed, 74 insertions(+), 92 deletions(-)

-- 
1.9.1

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


[Intel-gfx] [RFC 1/4] drm/i915: Move releasing of the GEM request from free to retire/cancel

2016-04-08 Thread Tvrtko Ursulin
From: Chris Wilson 

If we move the release of the GEM request (i.e. decoupling it from the
various lists used for client and context tracking) after it is complete
(either by the GPU retiring the request, or by the caller cancelling the
request), we can remove the requirement that the final unreference of
the GEM request need to be under the struct_mutex.

v2: Execlists as always is badly asymetric and year old patches still
haven't landed to fix it up.

v3: Extracted, rebased and fixed for GuC. (Tvrtko Ursulin)

Signed-off-by: Chris Wilson 
Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h  | 14 --
 drivers/gpu/drm/i915/i915_gem.c  | 50 ++--
 drivers/gpu/drm/i915/intel_display.c |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  |  2 +-
 4 files changed, 27 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index da403f4fc679..fa199b7e51b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2352,23 +2352,9 @@ i915_gem_request_reference(struct drm_i915_gem_request 
*req)
 static inline void
 i915_gem_request_unreference(struct drm_i915_gem_request *req)
 {
-   WARN_ON(!mutex_is_locked(&req->engine->dev->struct_mutex));
kref_put(&req->ref, i915_gem_request_free);
 }
 
-static inline void
-i915_gem_request_unreference__unlocked(struct drm_i915_gem_request *req)
-{
-   struct drm_device *dev;
-
-   if (!req)
-   return;
-
-   dev = req->engine->dev;
-   if (kref_put_mutex(&req->ref, i915_gem_request_free, 
&dev->struct_mutex))
-   mutex_unlock(&dev->struct_mutex);
-}
-
 static inline void i915_gem_request_assign(struct drm_i915_gem_request **pdst,
   struct drm_i915_gem_request *src)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 239452933a89..c1df696f9002 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1410,10 +1410,31 @@ i915_gem_request_remove_from_client(struct 
drm_i915_gem_request *request)
request->pid = NULL;
 }
 
+static void __i915_gem_request_release(struct drm_i915_gem_request *request)
+{
+   if (i915.enable_execlists) {
+   if (request->ctx != request->i915->kernel_context)
+   intel_lr_context_unpin(request->ctx, request->engine);
+   }
+
+   i915_gem_request_remove_from_client(request);
+
+   i915_gem_context_unreference(request->ctx);
+   i915_gem_request_unreference(request);
+}
+
+void i915_gem_request_cancel(struct drm_i915_gem_request *req)
+{
+   intel_ring_reserved_space_cancel(req->ringbuf);
+   __i915_gem_request_release(req);
+}
+
 static void i915_gem_request_retire(struct drm_i915_gem_request *request)
 {
trace_i915_gem_request_retire(request);
 
+   list_del_init(&request->list);
+
/* We know the GPU must have read the request to have
 * sent us the seqno + interrupt, so use the position
 * of tail of the request to update the last known position
@@ -1424,10 +1445,7 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
 */
request->ringbuf->last_retired_head = request->postfix;
 
-   list_del_init(&request->list);
-   i915_gem_request_remove_from_client(request);
-
-   i915_gem_request_unreference(request);
+   __i915_gem_request_release(request);
 }
 
 static void
@@ -2723,18 +2741,7 @@ static void i915_set_reset_status(struct 
drm_i915_private *dev_priv,
 void i915_gem_request_free(struct kref *req_ref)
 {
struct drm_i915_gem_request *req = container_of(req_ref,
-typeof(*req), ref);
-   struct intel_context *ctx = req->ctx;
-
-   if (req->file_priv)
-   i915_gem_request_remove_from_client(req);
-
-   if (ctx) {
-   if (i915.enable_execlists && ctx != req->i915->kernel_context)
-   intel_lr_context_unpin(ctx, req->engine);
-
-   i915_gem_context_unreference(ctx);
-   }
+   typeof(*req), ref);
 
kmem_cache_free(req->i915->requests, req);
 }
@@ -2830,13 +2837,6 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
return err ? ERR_PTR(err) : req;
 }
 
-void i915_gem_request_cancel(struct drm_i915_gem_request *req)
-{
-   intel_ring_reserved_space_cancel(req->ringbuf);
-
-   i915_gem_request_unreference(req);
-}
-
 struct drm_i915_gem_request *
 i915_gem_find_active_request(struct intel_engine_cs *engine)
 {
@@ -3194,7 +3194,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file)
ret = __i915_wait_request(req[i], reset_counter, true,
  args->timeout_ns > 0 ? 
&args->timeout_ns : NULL,
   

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Reject panel_type > 0xf from VBT

2016-04-08 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915: Reject panel_type > 0xf from VBT
URL   : https://patchwork.freedesktop.org/series/5458/
State : failure

== Summary ==

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

Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
pass   -> INCOMPLETE (bdw-nuci7)
Test pm_rpm:
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:183  pass:170  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1844/

949884a57b51aa158e3ae9afe1f08130cdb7a3ef drm-intel-nightly: 
2016y-04m-08d-10h-45m-28s UTC integration manifest
b960eee70e97b57ff7a03f51161dfd6aea81b9f8 drm/i915: Get panel_type from OpRegion 
panel details
734e95750f44ce78ccd687ff7c308bfcb92d075d drm/i915: Replace the static 
panel_type variable with dev_priv->vbt.panel_type
8d6d67a9694026f62862b6f98296c5c334248ae1 drm/i915: Reject panel_type > 0xf from 
VBT

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


[Intel-gfx] [RFC 4/4] drm/i915: Stop tracking execlists retired requests

2016-04-08 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

With the previous patch having extended the pinned lifetime of
contexts by referencing the previous context from the current
request until the latter is retired (completed by the GPU),
we can now remove usage of execlist retired queue entirely.

This is because the above now guarantees that all execlist
object access requirements are satisfied by this new tracking,
and we can stop taking additional references and stop keeping
request on the execlists retired queue.

The latter was a source of significant scalability issues in
the driver causing performance hits on some tests. Most
dramatical of which was igt/gem_close_race which had run time
in tens of minutes which is now reduced to tens of seconds.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 10 +--
 drivers/gpu/drm/i915/intel_lrc.c| 46 ++---
 drivers/gpu/drm/i915/intel_lrc.h|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
 4 files changed, 16 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 118911ce7231..2f4bfe93b20c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2901,13 +2901,7 @@ static void i915_gem_reset_engine_cleanup(struct 
drm_i915_private *dev_priv,
/* Ensure irq handler finishes or is cancelled. */
tasklet_kill(&engine->irq_tasklet);
 
-   spin_lock_bh(&engine->execlist_lock);
-   /* list_splice_tail_init checks for empty lists */
-   list_splice_tail_init(&engine->execlist_queue,
- &engine->execlist_retired_req_list);
-   spin_unlock_bh(&engine->execlist_lock);
-
-   intel_execlists_retire_requests(engine);
+   intel_execlists_cancel_requests(engine);
}
 
/*
@@ -3029,8 +3023,6 @@ i915_gem_retire_requests(struct drm_device *dev)
spin_lock_bh(&engine->execlist_lock);
idle &= list_empty(&engine->execlist_queue);
spin_unlock_bh(&engine->execlist_lock);
-
-   intel_execlists_retire_requests(engine);
}
}
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5e967943ce49..f241cf6e4227 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -456,8 +456,8 @@ static void execlists_context_unqueue(struct 
intel_engine_cs *engine)
/* Same ctx: ignore first request, as second request
 * will update tail past first request's workload */
cursor->elsp_submitted = req0->elsp_submitted;
-   list_move_tail(&req0->execlist_link,
-  &engine->execlist_retired_req_list);
+   list_del(&req0->execlist_link);
+   i915_gem_request_unreference(req0);
req0 = cursor;
} else {
req1 = cursor;
@@ -499,19 +499,17 @@ execlists_check_remove_request(struct intel_engine_cs 
*engine, u32 request_id)
struct drm_i915_gem_request,
execlist_link);
 
-   if (!head_req)
-   return 0;
-
-   if (unlikely(intel_execlists_ctx_id(head_req->ctx, engine) != 
request_id))
-   return 0;
+   if (WARN_ON(!head_req ||
+   (intel_execlists_ctx_id(head_req->ctx, engine) != request_id)))
+   return 0;
 
WARN(head_req->elsp_submitted == 0, "Never submitted head request\n");
 
if (--head_req->elsp_submitted > 0)
return 0;
 
-   list_move_tail(&head_req->execlist_link,
-  &engine->execlist_retired_req_list);
+   list_del(&head_req->execlist_link);
+   i915_gem_request_unreference(head_req);
 
return 1;
 }
@@ -615,11 +613,6 @@ static void execlists_context_queue(struct 
drm_i915_gem_request *request)
struct drm_i915_gem_request *cursor;
int num_elements = 0;
 
-   if (request->ctx != request->i915->kernel_context)
-   intel_lr_context_pin(request->ctx, engine);
-
-   i915_gem_request_reference(request);
-
spin_lock_bh(&engine->execlist_lock);
 
list_for_each_entry(cursor, &engine->execlist_queue, execlist_link)
@@ -636,11 +629,12 @@ static void execlists_context_queue(struct 
drm_i915_gem_request *request)
if (request->ctx == tail_req->ctx) {
WARN(tail_req->elsp_submitted != 0,
"More than 2 already-submitted reqs queued\n");
-   list_move_tail(&tail_req->execlist_link,
-  &engine->execlist_retired_req_list);
+  

[Intel-gfx] [PATCH] drm/i915: Fix CHV data lane soft reset for HDMI

2016-04-08 Thread Ander Conselvan de Oliveira
The function chv_data_lane_soft_reset() uses the lane count to decide
which lanes to set/reset. However, the HDMI code never sets lane count,
since it always uses the four lanes of the phy. Note that before commit
a8f327fb8464 ("drm/i915: Clean up CHV lane soft reset programming"), all
lanes were reset, regardless of lane count, so this patch restores that
behavior.

Cc: Ville Syrjälä 
Cc: Deepak S 
Fixes: a8f327fb8464 ("drm/i915: Clean up CHV lane soft reset programming")
Signed-off-by: Ander Conselvan de Oliveira 

---

I noticed this while reading CHV code, so this is only compiled tested. I
don't know if this could cause real issues.

Ander

---
 drivers/gpu/drm/i915/intel_hdmi.c | 30 +-
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index b199ede..5410d1a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1670,14 +1670,12 @@ static void chv_data_lane_soft_reset(struct 
intel_encoder *encoder,
val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
 
-   if (crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
-   if (reset)
-   val &= ~(DPIO_PCS_TX_LANE2_RESET | 
DPIO_PCS_TX_LANE1_RESET);
-   else
-   val |= DPIO_PCS_TX_LANE2_RESET | 
DPIO_PCS_TX_LANE1_RESET;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
-   }
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
+   if (reset)
+   val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
+   else
+   val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
 
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
val |= CHV_PCS_REQ_SOFTRESET_EN;
@@ -1687,15 +1685,13 @@ static void chv_data_lane_soft_reset(struct 
intel_encoder *encoder,
val |= DPIO_PCS_CLK_SOFT_RESET;
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
 
-   if (crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
-   val |= CHV_PCS_REQ_SOFTRESET_EN;
-   if (reset)
-   val &= ~DPIO_PCS_CLK_SOFT_RESET;
-   else
-   val |= DPIO_PCS_CLK_SOFT_RESET;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
-   }
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
+   val |= CHV_PCS_REQ_SOFTRESET_EN;
+   if (reset)
+   val &= ~DPIO_PCS_CLK_SOFT_RESET;
+   else
+   val |= DPIO_PCS_CLK_SOFT_RESET;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
 }
 
 static void chv_hdmi_pre_pll_enable(struct intel_encoder *encoder)
-- 
2.4.11

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Eliminating the execlist retired request queue

2016-04-08 Thread Patchwork
== Series Details ==

Series: Eliminating the execlist retired request queue
URL   : https://patchwork.freedesktop.org/series/5459/
State : failure

== Summary ==

  CC [M]  drivers/gpu/drm/i915/intel_dpll_mgr.o
  CC [M]  drivers/gpu/drm/i915/intel_fbc.o
  CC [M]  drivers/gpu/drm/i915/intel_fifo_underrun.o
  CC [M]  drivers/gpu/drm/i915/intel_frontbuffer.o
  CC [M]  drivers/gpu/drm/i915/intel_hotplug.o
  CC [M]  drivers/gpu/drm/i915/intel_modes.o
  CC [M]  drivers/gpu/drm/i915/intel_overlay.o
  CC [M]  drivers/gpu/drm/i915/intel_psr.o
  CC [M]  drivers/gpu/drm/i915/intel_sideband.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/usb/host/built-in.o
  CC [M]  drivers/gpu/drm/i915/intel_sprite.o
  LD  drivers/usb/built-in.o
  CC [M]  drivers/gpu/drm/i915/intel_acpi.o
  CC [M]  drivers/gpu/drm/i915/intel_opregion.o
  CC [M]  drivers/gpu/drm/i915/dvo_ch7017.o
  CC [M]  drivers/gpu/drm/i915/intel_fbdev.o
  CC [M]  drivers/gpu/drm/i915/dvo_ch7xxx.o
cc1: some warnings being treated as errors
scripts/Makefile.build:291: recipe for target 
'drivers/gpu/drm/i915/intel_lrc.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_lrc.o] Error 1
make[4]: *** Waiting for unfinished jobs
scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:440: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:962: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Reject panel_type > 0xf from VBT

2016-04-08 Thread Ville Syrjälä
On Fri, Apr 08, 2016 at 01:56:15PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [1/3] drm/i915: Reject panel_type > 0xf from VBT
> URL   : https://patchwork.freedesktop.org/series/5458/
> State : failure
> 
> == Summary ==
> 
> Series 5458v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/5458/revisions/1/mbox/
> 
> Test gem_exec_basic:
> Subgroup basic-bsd:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test gem_sync:
> Subgroup basic-bsd:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test kms_pipe_crc_basic:
> Subgroup hang-read-crc-pipe-c:
> pass   -> INCOMPLETE (bdw-nuci7)

Machine died or something? Last thing in the log

[  518.517277] kms_pipe_crc_basic: starting subtest hang-read-crc-pipe-C
[  518.517713] [drm:i915_ring_stop_set] Stopping rings 0x0001
[  519.708140] [drm:intel_print_rc6_info] Enabling RC6 states: RC6 on

> Test pm_rpm:
> Subgroup basic-rte:
> dmesg-warn -> PASS   (bsw-nuc-2)
> 
> bdw-nuci7total:183  pass:170  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
> bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
> byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
> hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
> hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
> ilk-hp8440p  total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
> ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
> skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
> skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
> snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
> snb-x220ttotal:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1844/
> 
> 949884a57b51aa158e3ae9afe1f08130cdb7a3ef drm-intel-nightly: 
> 2016y-04m-08d-10h-45m-28s UTC integration manifest
> b960eee70e97b57ff7a03f51161dfd6aea81b9f8 drm/i915: Get panel_type from 
> OpRegion panel details
> 734e95750f44ce78ccd687ff7c308bfcb92d075d drm/i915: Replace the static 
> panel_type variable with dev_priv->vbt.panel_type
> 8d6d67a9694026f62862b6f98296c5c334248ae1 drm/i915: Reject panel_type > 0xf 
> from VBT

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


Re: [Intel-gfx] [PATCH] drm/i915: Fix CHV data lane soft reset for HDMI

2016-04-08 Thread Ville Syrjälä
On Fri, Apr 08, 2016 at 05:06:04PM +0300, Ander Conselvan de Oliveira wrote:
> The function chv_data_lane_soft_reset() uses the lane count to decide
> which lanes to set/reset. However, the HDMI code never sets lane count,
> since it always uses the four lanes of the phy. Note that before commit
> a8f327fb8464 ("drm/i915: Clean up CHV lane soft reset programming"), all
> lanes were reset, regardless of lane count, so this patch restores that
> behavior.
> 
> Cc: Ville Syrjälä 
> Cc: Deepak S 
> Fixes: a8f327fb8464 ("drm/i915: Clean up CHV lane soft reset programming")
> Signed-off-by: Ander Conselvan de Oliveira 
> 

At some point we really should just eliminate the duplicated PHY code
by moving it to someting like intel_dpio.c, and then I suppose we should
populate lane_count for HDMI as well. But for now this is good enough.

Reviewed-by: Ville Syrjälä 

> ---
> 
> I noticed this while reading CHV code, so this is only compiled tested. I
> don't know if this could cause real issues.
> 
> Ander
> 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 30 +-
>  1 file changed, 13 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index b199ede..5410d1a 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1670,14 +1670,12 @@ static void chv_data_lane_soft_reset(struct 
> intel_encoder *encoder,
>   val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
>   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
>  
> - if (crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> - if (reset)
> - val &= ~(DPIO_PCS_TX_LANE2_RESET | 
> DPIO_PCS_TX_LANE1_RESET);
> - else
> - val |= DPIO_PCS_TX_LANE2_RESET | 
> DPIO_PCS_TX_LANE1_RESET;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
> - }
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> + if (reset)
> + val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
> + else
> + val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
>  
>   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
>   val |= CHV_PCS_REQ_SOFTRESET_EN;
> @@ -1687,15 +1685,13 @@ static void chv_data_lane_soft_reset(struct 
> intel_encoder *encoder,
>   val |= DPIO_PCS_CLK_SOFT_RESET;
>   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
>  
> - if (crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
> - val |= CHV_PCS_REQ_SOFTRESET_EN;
> - if (reset)
> - val &= ~DPIO_PCS_CLK_SOFT_RESET;
> - else
> - val |= DPIO_PCS_CLK_SOFT_RESET;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
> - }
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
> + val |= CHV_PCS_REQ_SOFTRESET_EN;
> + if (reset)
> + val &= ~DPIO_PCS_CLK_SOFT_RESET;
> + else
> + val |= DPIO_PCS_CLK_SOFT_RESET;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
>  }
>  
>  static void chv_hdmi_pre_pll_enable(struct intel_encoder *encoder)
> -- 
> 2.4.11

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915: Reject panel_type > 0xf from VBT

2016-04-08 Thread Jani Nikula
On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> VBT can only contain 16 panel entries, indexed with the panel_type.
> To play it safe we should reject panel_type > 0xf, so that we don't
> read past the valid data.
>
> Cc: Rob Kramer 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_bios.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index eb756c41d9e1..13bdd4316092 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -212,7 +212,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
>   return;
>  
>   dev_priv->vbt.lvds_dither = lvds_options->pixel_dither;
> - if (lvds_options->panel_type == 0xff)
> + if (lvds_options->panel_type > 0xf)

Debug logging on this?

Reviewed-by: Jani Nikula 



>   return;
>  
>   panel_type = lvds_options->panel_type;

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


Re: [Intel-gfx] [PATCH 2/3] drm/i915: Replace the static panel_type variable with dev_priv->vbt.panel_type

2016-04-08 Thread Jani Nikula
On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Store the extracted panel_type under dev_priv.vbt instead of keeping
> around a static variable for it.
>
> Cc: Rob Kramer 
> Signed-off-by: Ville Syrjälä 

Yes please.

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_bios.c | 13 +
>  2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4ebd3ff02803..53ace572b292 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1443,6 +1443,7 @@ struct intel_vbt_data {
>   unsigned int lvds_use_ssc:1;
>   unsigned int display_clock_mode:1;
>   unsigned int fdi_rx_polarity_inverted:1;
> + unsigned int panel_type:4;
>   int lvds_ssc_freq;
>   unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
>  
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 13bdd4316092..d9568be4b33b 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -58,8 +58,6 @@
>  #define  SLAVE_ADDR1 0x70
>  #define  SLAVE_ADDR2 0x72
>  
> -static int panel_type;
> -
>  /* Get BDB block size given a pointer to Block ID. */
>  static u32 _get_blocksize(const u8 *block_base)
>  {
> @@ -205,6 +203,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
>   const struct lvds_dvo_timing *panel_dvo_timing;
>   const struct lvds_fp_timing *fp_timing;
>   struct drm_display_mode *panel_fixed_mode;
> + int panel_type;
>   int drrs_mode;
>  
>   lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
> @@ -216,6 +215,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
>   return;
>  
>   panel_type = lvds_options->panel_type;
> + dev_priv->vbt.panel_type = panel_type;
>  
>   drrs_mode = (lvds_options->dps_panel_type_bits
>   >> (panel_type * 2)) & MODE_MASK;
> @@ -251,7 +251,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
>  
>   panel_dvo_timing = get_lvds_dvo_timing(lvds_lfp_data,
>  lvds_lfp_data_ptrs,
> -lvds_options->panel_type);
> +panel_type);
>  
>   panel_fixed_mode = kzalloc(sizeof(*panel_fixed_mode), GFP_KERNEL);
>   if (!panel_fixed_mode)
> @@ -266,7 +266,7 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
>  
>   fp_timing = get_lvds_fp_timing(bdb, lvds_lfp_data,
>  lvds_lfp_data_ptrs,
> -lvds_options->panel_type);
> +panel_type);
>   if (fp_timing) {
>   /* check the resolution, just to be sure */
>   if (fp_timing->x_res == panel_fixed_mode->hdisplay &&
> @@ -284,6 +284,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
>  {
>   const struct bdb_lfp_backlight_data *backlight_data;
>   const struct bdb_lfp_backlight_data_entry *entry;
> + int panel_type = dev_priv->vbt.panel_type;
>  
>   backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
>   if (!backlight_data)
> @@ -546,6 +547,7 @@ parse_edp(struct drm_i915_private *dev_priv, const struct 
> bdb_header *bdb)
>   const struct bdb_edp *edp;
>   const struct edp_power_seq *edp_pps;
>   const struct edp_link_params *edp_link_params;
> + int panel_type = dev_priv->vbt.panel_type;
>  
>   edp = find_section(bdb, BDB_EDP);
>   if (!edp) {
> @@ -657,6 +659,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct 
> bdb_header *bdb)
>  {
>   const struct bdb_psr *psr;
>   const struct psr_table *psr_table;
> + int panel_type = dev_priv->vbt.panel_type;
>  
>   psr = find_section(bdb, BDB_PSR);
>   if (!psr) {
> @@ -703,6 +706,7 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
>   const struct bdb_mipi_config *start;
>   const struct mipi_config *config;
>   const struct mipi_pps_data *pps;
> + int panel_type = dev_priv->vbt.panel_type;
>  
>   /* parse MIPI blocks only if LFP type is MIPI */
>   if (!intel_bios_is_dsi_present(dev_priv, NULL))
> @@ -910,6 +914,7 @@ static void
>  parse_mipi_sequence(struct drm_i915_private *dev_priv,
>   const struct bdb_header *bdb)
>  {
> + int panel_type = dev_priv->vbt.panel_type;
>   const struct bdb_mipi_sequence *sequence;
>   const u8 *seq_data;
>   u32 seq_size;

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


Re: [Intel-gfx] [RFC 2/4] drm/i915/guc: Keep the previous context pinned until the next one has been completed

2016-04-08 Thread Chris Wilson
On Fri, Apr 08, 2016 at 02:54:56PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> In GuC mode submitting requests is only putting them into the
> GuC queue with the actual submission to hardware following at
> some future point. This makes the per engine last context
> tracking insufficient for closing the premature context
> unpin race.
> 
> Instead we need to make requests track and pin the previous
> context on the same engine, and only unpin them when they
> themselves are retired. This will ensure contexts remain pinned
> in all cases until the are fully saved by the GPU.
> 
> v2: Only track contexts.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Alex Dai 
> Cc: Dave Gordon 
> Cc: Nick Hoath 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  4 +++-
>  drivers/gpu/drm/i915/i915_gem.c  |  5 +
>  drivers/gpu/drm/i915/intel_lrc.c | 17 +
>  3 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fa199b7e51b5..216b2297ae3e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2283,6 +2283,9 @@ struct drm_i915_gem_request {
>   struct intel_context *ctx;
>   struct intel_ringbuffer *ringbuf;
>  
> + /** Context preceding this one on the same engine. Can be NULL. */
> + struct intel_context *prev_ctx;
> +
>   /** Batch buffer related to this request if any (used for
>   error state dump only) */
>   struct drm_i915_gem_object *batch_obj;
> @@ -2318,7 +2321,6 @@ struct drm_i915_gem_request {
>  
>   /** Execlists no. of times this request has been sent to the ELSP */
>   int elsp_submitted;
> -
>  };
>  
>  struct drm_i915_gem_request * __must_check
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c1df696f9002..118911ce7231 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1445,6 +1445,11 @@ static void i915_gem_request_retire(struct 
> drm_i915_gem_request *request)
>*/
>   request->ringbuf->last_retired_head = request->postfix;
>  
> + if (request->prev_ctx) {
> + intel_lr_context_unpin(request->prev_ctx, request->engine);
> + request->prev_ctx = NULL;
> + }
> +
>   __i915_gem_request_release(request);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 31445aa3429b..3d08dac0a9b0 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -798,6 +798,23 @@ intel_logical_ring_advance_and_submit(struct 
> drm_i915_gem_request *request)
>   if (intel_engine_stopped(engine))
>   return 0;
>  
> + /*
> +  * Pin the previous context on this engine to ensure it is not
> +  * prematurely unpinned in GuC mode.
> +  * Previous context will be unpinned when this request is retired,
> +  * ensuring the GPU has switched out from the previous context and into
> +  * a new context at that point.
> +  */
> + if (engine->last_context) {
> + if (engine->last_context != request->i915->kernel_context) {
> + intel_lr_context_pin(engine->last_context, engine);
> + request->prev_ctx = engine->last_context;
> + }
> + }
> +
> + /*
> +  * Track and pin the last context submitted on an engine.
> +  */
>   if (engine->last_context != request->ctx) {
>   if (engine->last_context)
>   intel_lr_context_unpin(engine->last_context, engine);

We can use pinned_context to reduce the code complexity, not make it
worse.

If you first apply the execlists default context fix, adding
pinned_context is a reduction is code.
-Chris

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


Re: [Intel-gfx] [RFC 3/4] drm/i915: Use new i915_gem_object_pin_map for LRC

2016-04-08 Thread Chris Wilson
On Fri, Apr 08, 2016 at 02:54:57PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> We can use the new pin/lazy unpin API for more performance
> in the execlist submission paths.

The sticking point for me was the ringbuffer and Braswell having to
re-ioremap it every context pin. I hadn't noticed the kmap of the
context, but this does seem like a valid use for pin_map so I'm not
complaining... (Just saying this half the solution ;)

Oh, and you don't have pin_map for your ringbuffer either yet.
-Chris

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


Re: [Intel-gfx] [PATCH 3/3] drm/i915: Get panel_type from OpRegion panel details

2016-04-08 Thread Jani Nikula
On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> We've had problems on several occasions with using the panel type
> from the VBT block 40. Usually it seems to be 2, which often
> doesn't give us the correct timings for the panel. After some
> more digging I found a way to get a panel type via the OpRegion
> SWSCI GBDA "Get Panel Details" method. Let's try to use it.
>
> The spec has this to say about the output:
> "Bits [15:8] - Panel Type
>  Bits contain the panel type user setting from CMOS
>  00h = Not Valid, use default Panel Type & Timings from VBT
>  01h - 0Fh = Panel Number"
>
> The other bits in the output don't look relevant for the problem at
> hand.
>
> The input is specified as:
> "Bits [31:4] - Reserved
>  Reserved (must be zero)
>  Bits [3:0] - Panel Number
>  These bits contain the sequential index of Panel, starting at 0 and
>  counting upwards from the first integrated Internal Flat-Panel Display
>  Encoder present, and then from the first external Display Encoder
>  (e.g., S/DVO-B then S/DVO-C) which supports Internal Flat-Panels.
>  0h - 0Fh = Panel number"
>
> For now I've just hardcoded the input panel number as 0. That would seem
> like a decent choise for LVDS. Not so sure about eDP when port != A.

Frankly, I didn't understand the point of the input parameter for
figuring out the output. The spec is written for someone who already
knows what they're doing...

>
> Cc: Rob Kramer 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  5 +
>  drivers/gpu/drm/i915/intel_bios.c | 13 ++---
>  drivers/gpu/drm/i915/intel_opregion.c | 13 +
>  3 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 53ace572b292..533263a7a12d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3421,6 +3421,7 @@ extern int intel_opregion_notify_encoder(struct 
> intel_encoder *intel_encoder,
>bool enable);
>  extern int intel_opregion_notify_adapter(struct drm_device *dev,
>pci_power_t state);
> +extern int intel_opregion_get_panel_type(struct drm_device *dev);
>  #else
>  static inline int intel_opregion_setup(struct drm_device *dev) { return 0; }
>  static inline void intel_opregion_init(struct drm_device *dev) { return; }
> @@ -3436,6 +3437,10 @@ intel_opregion_notify_adapter(struct drm_device *dev, 
> pci_power_t state)
>  {
>   return 0;
>  }
> +static inline int intel_opregion_get_panel_type(struct drm_device *dev)
> +{
> + return 0;
> +}
>  #endif
>  
>  /* intel_acpi.c */
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index d9568be4b33b..718e49931b5f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -205,16 +205,23 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
>   struct drm_display_mode *panel_fixed_mode;
>   int panel_type;
>   int drrs_mode;
> + int ret;
>  
>   lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
>   if (!lvds_options)
>   return;
>  
>   dev_priv->vbt.lvds_dither = lvds_options->pixel_dither;
> - if (lvds_options->panel_type > 0xf)
> - return;
>  
> - panel_type = lvds_options->panel_type;
> + ret = intel_opregion_get_panel_type(dev_priv->dev);
> + if (ret >= 0x1 && ret <= 0xf) {

Undecided whether I'd like to have this check within
intel_opregion_get_panel_type(). Just make that return 0 for "use vbt"
(and CONFIG_ACPI=n), and valid stuff otherwise? *shrug*

> + panel_type = ret;
> + } else {
> + if (lvds_options->panel_type > 0xf)
> + return;
> + panel_type = lvds_options->panel_type;
> + }
> +

If this actually works, I'd like to have some debug logging for pretty
much all the code paths here.

Other than that, seems fine.

BR,
Jani.

>   dev_priv->vbt.panel_type = panel_type;
>  
>   drrs_mode = (lvds_options->dps_panel_type_bits
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index c15718b4862a..5e17fa5dc869 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1024,3 +1024,16 @@ err_out:
>   memunmap(base);
>   return err;
>  }
> +
> +int
> +intel_opregion_get_panel_type(struct drm_device *dev)
> +{
> + u32 panel_details;
> + int ret;
> +
> + ret = swsci(dev, SWSCI_GBDA_PANEL_DETAILS, 0x0, &panel_details);
> + if (ret)
> + return ret;
> +
> + return (panel_details >> 8) & 0xff;
> +}

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
htt

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix CHV data lane soft reset for HDMI

2016-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix CHV data lane soft reset for HDMI
URL   : https://patchwork.freedesktop.org/series/5461/
State : warning

== Summary ==

Series 5461v1 drm/i915: Fix CHV data lane soft reset for HDMI
http://patchwork.freedesktop.org/api/1.0/series/5461/revisions/1/mbox/

Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-edid:
pass   -> SKIP   (snb-x220t)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:158  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:196  pass:131  dwarn:1   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:161  dwarn:0   dfail:0   fail:1   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1846/

949884a57b51aa158e3ae9afe1f08130cdb7a3ef drm-intel-nightly: 
2016y-04m-08d-10h-45m-28s UTC integration manifest
a63f315f919d3cdb8acab94b53951dbfa4cbbe9c drm/i915: Fix CHV data lane soft reset 
for HDMI

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


Re: [Intel-gfx] [RFC 4/4] drm/i915: Stop tracking execlists retired requests

2016-04-08 Thread Chris Wilson
On Fri, Apr 08, 2016 at 02:54:58PM +0100, Tvrtko Ursulin wrote:
> @@ -615,11 +613,6 @@ static void execlists_context_queue(struct 
> drm_i915_gem_request *request)
>   struct drm_i915_gem_request *cursor;
>   int num_elements = 0;
>  
> - if (request->ctx != request->i915->kernel_context)
> - intel_lr_context_pin(request->ctx, engine);
> -
> - i915_gem_request_reference(request);
> -
>   spin_lock_bh(&engine->execlist_lock);
>  
>   list_for_each_entry(cursor, &engine->execlist_queue, execlist_link)
> @@ -636,11 +629,12 @@ static void execlists_context_queue(struct 
> drm_i915_gem_request *request)
>   if (request->ctx == tail_req->ctx) {
>   WARN(tail_req->elsp_submitted != 0,
>   "More than 2 already-submitted reqs queued\n");
> - list_move_tail(&tail_req->execlist_link,
> -&engine->execlist_retired_req_list);
> + list_del(&tail_req->execlist_link);
> + i915_gem_request_unreference(tail_req);
>   }
>   }
>  
> + i915_gem_request_reference(request);
>   list_add_tail(&request->execlist_link, &engine->execlist_queue);

If you want to get truly radical, we do not need the ref on the request
until it is submitted to hardware. (As the request cannot be retired
until it has done so, it can leave the execlist_queue until we commit it
to hw, or perform the cancel).

Lgtm,
-Chris

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


Re: [Intel-gfx] [PATCH 3/3] drm/i915: Get panel_type from OpRegion panel details

2016-04-08 Thread Ville Syrjälä
On Fri, Apr 08, 2016 at 05:50:06PM +0300, Jani Nikula wrote:
> On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > We've had problems on several occasions with using the panel type
> > from the VBT block 40. Usually it seems to be 2, which often
> > doesn't give us the correct timings for the panel. After some
> > more digging I found a way to get a panel type via the OpRegion
> > SWSCI GBDA "Get Panel Details" method. Let's try to use it.
> >
> > The spec has this to say about the output:
> > "Bits [15:8] - Panel Type
> >  Bits contain the panel type user setting from CMOS
> >  00h = Not Valid, use default Panel Type & Timings from VBT
> >  01h - 0Fh = Panel Number"
> >
> > The other bits in the output don't look relevant for the problem at
> > hand.
> >
> > The input is specified as:
> > "Bits [31:4] - Reserved
> >  Reserved (must be zero)
> >  Bits [3:0] - Panel Number
> >  These bits contain the sequential index of Panel, starting at 0 and
> >  counting upwards from the first integrated Internal Flat-Panel Display
> >  Encoder present, and then from the first external Display Encoder
> >  (e.g., S/DVO-B then S/DVO-C) which supports Internal Flat-Panels.
> >  0h - 0Fh = Panel number"
> >
> > For now I've just hardcoded the input panel number as 0. That would seem
> > like a decent choise for LVDS. Not so sure about eDP when port != A.
> 
> Frankly, I didn't understand the point of the input parameter for
> figuring out the output. The spec is written for someone who already
> knows what they're doing...
> 
> >
> > Cc: Rob Kramer 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h   |  5 +
> >  drivers/gpu/drm/i915/intel_bios.c | 13 ++---
> >  drivers/gpu/drm/i915/intel_opregion.c | 13 +
> >  3 files changed, 28 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 53ace572b292..533263a7a12d 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3421,6 +3421,7 @@ extern int intel_opregion_notify_encoder(struct 
> > intel_encoder *intel_encoder,
> >  bool enable);
> >  extern int intel_opregion_notify_adapter(struct drm_device *dev,
> >  pci_power_t state);
> > +extern int intel_opregion_get_panel_type(struct drm_device *dev);
> >  #else
> >  static inline int intel_opregion_setup(struct drm_device *dev) { return 0; 
> > }
> >  static inline void intel_opregion_init(struct drm_device *dev) { return; }
> > @@ -3436,6 +3437,10 @@ intel_opregion_notify_adapter(struct drm_device 
> > *dev, pci_power_t state)
> >  {
> > return 0;
> >  }
> > +static inline int intel_opregion_get_panel_type(struct drm_device *dev)
> > +{
> > +   return 0;
> > +}
> >  #endif
> >  
> >  /* intel_acpi.c */
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index d9568be4b33b..718e49931b5f 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -205,16 +205,23 @@ parse_lfp_panel_data(struct drm_i915_private 
> > *dev_priv,
> > struct drm_display_mode *panel_fixed_mode;
> > int panel_type;
> > int drrs_mode;
> > +   int ret;
> >  
> > lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
> > if (!lvds_options)
> > return;
> >  
> > dev_priv->vbt.lvds_dither = lvds_options->pixel_dither;
> > -   if (lvds_options->panel_type > 0xf)
> > -   return;
> >  
> > -   panel_type = lvds_options->panel_type;
> > +   ret = intel_opregion_get_panel_type(dev_priv->dev);
> > +   if (ret >= 0x1 && ret <= 0xf) {
> 
> Undecided whether I'd like to have this check within
> intel_opregion_get_panel_type(). Just make that return 0 for "use vbt"
> (and CONFIG_ACPI=n), and valid stuff otherwise? *shrug*

We don't compile intel_opregion.c when ACPI==n.

> 
> > +   panel_type = ret;
> > +   } else {
> > +   if (lvds_options->panel_type > 0xf)
> > +   return;
> > +   panel_type = lvds_options->panel_type;
> > +   }
> > +
> 
> If this actually works, I'd like to have some debug logging for pretty
> much all the code paths here.

Yeah that would be nice for figuring out where the information came 
from or why it was rejected.

> 
> Other than that, seems fine.
> 
> BR,
> Jani.
> 
> > dev_priv->vbt.panel_type = panel_type;
> >  
> > drrs_mode = (lvds_options->dps_panel_type_bits
> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> > b/drivers/gpu/drm/i915/intel_opregion.c
> > index c15718b4862a..5e17fa5dc869 100644
> > --- a/drivers/gpu/drm/i915/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/intel_opregion.c
> > @@ -1024,3 +1024,16 @@ err_out:
> > memunmap(base);
> > return err;
> >  }
> > +
> > +int
> > +intel_opre

[Intel-gfx] [PATCH] drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI

2016-04-08 Thread Jani Nikula
The whole file is ignored on CONFIG_ACPI=n.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_opregion.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index c15718b4862a..d5a4cb80273e 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -246,7 +246,6 @@ struct opregion_asle_ext {
 
 #define MAX_DSLP   1500
 
-#ifdef CONFIG_ACPI
 static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -905,9 +904,6 @@ static void swsci_setup(struct drm_device *dev)
 opregion->swsci_gbda_sub_functions,
 opregion->swsci_sbcb_sub_functions);
 }
-#else /* CONFIG_ACPI */
-static inline void swsci_setup(struct drm_device *dev) {}
-#endif  /* CONFIG_ACPI */
 
 static int intel_no_opregion_vbt_callback(const struct dmi_system_id *id)
 {
@@ -950,9 +946,7 @@ int intel_opregion_setup(struct drm_device *dev)
return -ENOTSUPP;
}
 
-#ifdef CONFIG_ACPI
INIT_WORK(&opregion->asle_work, asle_work);
-#endif
 
base = memremap(asls, OPREGION_SIZE, MEMREMAP_WB);
if (!base)
-- 
2.1.4

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


Re: [Intel-gfx] [RFC 1/4] drm/i915: Move releasing of the GEM request from free to retire/cancel

2016-04-08 Thread Chris Wilson
On Fri, Apr 08, 2016 at 02:54:55PM +0100, Tvrtko Ursulin wrote:
> From: Chris Wilson 
> 
> If we move the release of the GEM request (i.e. decoupling it from the
> various lists used for client and context tracking) after it is complete
> (either by the GPU retiring the request, or by the caller cancelling the
> request), we can remove the requirement that the final unreference of
> the GEM request need to be under the struct_mutex.
> 
> v2: Execlists as always is badly asymetric and year old patches still
> haven't landed to fix it up.
> 
> v3: Extracted, rebased and fixed for GuC. (Tvrtko Ursulin)

After you mentioned the unbalanced, the patches I reordered to fix that
are:

https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet&id=83dcde26caa26f4113c3e441c3c96c504fd88e13
https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet&id=9f386a21d3f28db763102b5c4f97a90bd0dcfd08
https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet&id=9afd878e2c9f7825b99dc839c7b5deb553b62e32
https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet&id=a842a2b0b7e90148966f35488209c969a9a9da54
-Chris

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


Re: [Intel-gfx] [PATCH 3/3] drm/i915: Get panel_type from OpRegion panel details

2016-04-08 Thread Jani Nikula
On Fri, 08 Apr 2016, Ville Syrjälä  wrote:
> On Fri, Apr 08, 2016 at 05:50:06PM +0300, Jani Nikula wrote:
>> On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä 
>> >
>> > We've had problems on several occasions with using the panel type
>> > from the VBT block 40. Usually it seems to be 2, which often
>> > doesn't give us the correct timings for the panel. After some
>> > more digging I found a way to get a panel type via the OpRegion
>> > SWSCI GBDA "Get Panel Details" method. Let's try to use it.
>> >
>> > The spec has this to say about the output:
>> > "Bits [15:8] - Panel Type
>> >  Bits contain the panel type user setting from CMOS
>> >  00h = Not Valid, use default Panel Type & Timings from VBT
>> >  01h - 0Fh = Panel Number"
>> >
>> > The other bits in the output don't look relevant for the problem at
>> > hand.
>> >
>> > The input is specified as:
>> > "Bits [31:4] - Reserved
>> >  Reserved (must be zero)
>> >  Bits [3:0] - Panel Number
>> >  These bits contain the sequential index of Panel, starting at 0 and
>> >  counting upwards from the first integrated Internal Flat-Panel Display
>> >  Encoder present, and then from the first external Display Encoder
>> >  (e.g., S/DVO-B then S/DVO-C) which supports Internal Flat-Panels.
>> >  0h - 0Fh = Panel number"
>> >
>> > For now I've just hardcoded the input panel number as 0. That would seem
>> > like a decent choise for LVDS. Not so sure about eDP when port != A.
>> 
>> Frankly, I didn't understand the point of the input parameter for
>> figuring out the output. The spec is written for someone who already
>> knows what they're doing...
>> 
>> >
>> > Cc: Rob Kramer 
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/i915/i915_drv.h   |  5 +
>> >  drivers/gpu/drm/i915/intel_bios.c | 13 ++---
>> >  drivers/gpu/drm/i915/intel_opregion.c | 13 +
>> >  3 files changed, 28 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> > b/drivers/gpu/drm/i915/i915_drv.h
>> > index 53ace572b292..533263a7a12d 100644
>> > --- a/drivers/gpu/drm/i915/i915_drv.h
>> > +++ b/drivers/gpu/drm/i915/i915_drv.h
>> > @@ -3421,6 +3421,7 @@ extern int intel_opregion_notify_encoder(struct 
>> > intel_encoder *intel_encoder,
>> > bool enable);
>> >  extern int intel_opregion_notify_adapter(struct drm_device *dev,
>> > pci_power_t state);
>> > +extern int intel_opregion_get_panel_type(struct drm_device *dev);
>> >  #else
>> >  static inline int intel_opregion_setup(struct drm_device *dev) { return 
>> > 0; }
>> >  static inline void intel_opregion_init(struct drm_device *dev) { return; }
>> > @@ -3436,6 +3437,10 @@ intel_opregion_notify_adapter(struct drm_device 
>> > *dev, pci_power_t state)
>> >  {
>> >return 0;
>> >  }
>> > +static inline int intel_opregion_get_panel_type(struct drm_device *dev)
>> > +{
>> > +  return 0;
>> > +}
>> >  #endif
>> >  
>> >  /* intel_acpi.c */
>> > diff --git a/drivers/gpu/drm/i915/intel_bios.c 
>> > b/drivers/gpu/drm/i915/intel_bios.c
>> > index d9568be4b33b..718e49931b5f 100644
>> > --- a/drivers/gpu/drm/i915/intel_bios.c
>> > +++ b/drivers/gpu/drm/i915/intel_bios.c
>> > @@ -205,16 +205,23 @@ parse_lfp_panel_data(struct drm_i915_private 
>> > *dev_priv,
>> >struct drm_display_mode *panel_fixed_mode;
>> >int panel_type;
>> >int drrs_mode;
>> > +  int ret;
>> >  
>> >lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
>> >if (!lvds_options)
>> >return;
>> >  
>> >dev_priv->vbt.lvds_dither = lvds_options->pixel_dither;
>> > -  if (lvds_options->panel_type > 0xf)
>> > -  return;
>> >  
>> > -  panel_type = lvds_options->panel_type;
>> > +  ret = intel_opregion_get_panel_type(dev_priv->dev);
>> > +  if (ret >= 0x1 && ret <= 0xf) {
>> 
>> Undecided whether I'd like to have this check within
>> intel_opregion_get_panel_type(). Just make that return 0 for "use vbt"
>> (and CONFIG_ACPI=n), and valid stuff otherwise? *shrug*
>
> We don't compile intel_opregion.c when ACPI==n.

Yeah I meant the static inline stub in i915_drv.h for ACPI=n. Which does
return 0.

BR,
Jani.


>
>> 
>> > +  panel_type = ret;
>> > +  } else {
>> > +  if (lvds_options->panel_type > 0xf)
>> > +  return;
>> > +  panel_type = lvds_options->panel_type;
>> > +  }
>> > +
>> 
>> If this actually works, I'd like to have some debug logging for pretty
>> much all the code paths here.
>
> Yeah that would be nice for figuring out where the information came 
> from or why it was rejected.
>
>> 
>> Other than that, seems fine.
>> 
>> BR,
>> Jani.
>> 
>> >dev_priv->vbt.panel_type = panel_type;
>> >  
>> >drrs_mode = (lvds_options->dps_panel_type_bits
>> > diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
>> > b/drivers/gpu/drm/i915/intel_opregion.c
>> > inde

[Intel-gfx] [PATCH 1/6] drm/i915: Set crtc_state->lane_count for HDMI

2016-04-08 Thread Ander Conselvan de Oliveira
Set the lane count for HDMI to 4. This will make it easier to
unduplicate CHV phy code.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index b199ede..2dc6e00 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1337,6 +1337,8 @@ bool intel_hdmi_compute_config(struct intel_encoder 
*encoder,
/* Set user selected PAR to incoming mode's member */
adjusted_mode->picture_aspect_ratio = intel_hdmi->aspect_ratio;
 
+   pipe_config->lane_count = 4;
+
return true;
 }
 
-- 
2.4.11

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


[Intel-gfx] [PATCH 2/6] drm/i915: Unduplicate CHV signal level code

2016-04-08 Thread Ander Conselvan de Oliveira
The code for programming voltage swing and emphasis was duplicated
between DP and HDMI code. Move that to a new file, intel_dpio_phy.c.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_drv.h   |   5 ++
 drivers/gpu/drm/i915/intel_dp.c   | 103 ++--
 drivers/gpu/drm/i915/intel_dpio_phy.c | 122 ++
 drivers/gpu/drm/i915/intel_hdmi.c |  72 +---
 5 files changed, 136 insertions(+), 167 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_dpio_phy.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b..eb45e28 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -57,6 +57,7 @@ i915-y += intel_audio.o \
  intel_bios.o \
  intel_color.o \
  intel_display.o \
+ intel_dpio_phy.o \
  intel_dpll_mgr.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4ebd3ff..3c393e3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3504,6 +3504,11 @@ void intel_sbi_write(struct drm_i915_private *dev_priv, 
u16 reg, u32 value,
 u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
 void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
 
+/* intel_dpio_phy.c */
+void chv_set_phy_signal_level(struct intel_encoder *encoder,
+ u32 deemph_reg_value, u32 margin_reg_value,
+ bool uniq_trans_scale);
+
 int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
 int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d2..5ba72b0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3339,23 +3339,12 @@ static uint32_t vlv_signal_levels(struct intel_dp 
*intel_dp)
return 0;
 }
 
-static bool chv_need_uniq_trans_scale(uint8_t train_set)
-{
-   return (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) == 
DP_TRAIN_PRE_EMPH_LEVEL_0 &&
-   (train_set & DP_TRAIN_VOLTAGE_SWING_MASK) == 
DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
-}
-
 static uint32_t chv_signal_levels(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 *dport = dp_to_dig_port(intel_dp);
-   struct intel_crtc *intel_crtc = to_intel_crtc(dport->base.base.crtc);
-   u32 deemph_reg_value, margin_reg_value, val;
+   struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+   u32 deemph_reg_value, margin_reg_value;
+   bool uniq_trans_scale = false;
uint8_t train_set = intel_dp->train_set[0];
-   enum dpio_channel ch = vlv_dport_to_channel(dport);
-   enum pipe pipe = intel_crtc->pipe;
-   int i;
 
switch (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) {
case DP_TRAIN_PRE_EMPH_LEVEL_0:
@@ -3375,7 +3364,7 @@ static uint32_t chv_signal_levels(struct intel_dp 
*intel_dp)
case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
deemph_reg_value = 128;
margin_reg_value = 154;
-   /* FIXME extra to set for 1200 */
+   uniq_trans_scale = true;
break;
default:
return 0;
@@ -3427,88 +3416,8 @@ static uint32_t chv_signal_levels(struct intel_dp 
*intel_dp)
return 0;
}
 
-   mutex_lock(&dev_priv->sb_lock);
-
-   /* Clear calc init */
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
-   val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
-   val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
-   val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
-
-   if (intel_crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
-   val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | 
DPIO_PCS_SWING_CALC_TX1_TX3);
-   val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
-   val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
-   }
-
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW9(ch));
-   val &= ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
-   val |= DPIO_PCS_TX1MARGIN_000 | DPIO_PCS_TX2MARGIN_000;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW9(ch), val);
-
-   if (intel_crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW9(ch));
-   val &= ~(DPIO_PCS_TX1MA

[Intel-gfx] [PATCH 6/6] drm/i915: Undiplicate CHV encoders' post pll disable code

2016-04-08 Thread Ander Conselvan de Oliveira
The exact same code was used by HDMI and DP encoders, so move it to
intel_dpio_phy.c.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_dp.c   | 30 +-
 drivers/gpu/drm/i915/intel_dpio_phy.c | 33 +
 drivers/gpu/drm/i915/intel_hdmi.c | 30 +-
 4 files changed, 36 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e1b2f48..5db6459 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3513,6 +3513,7 @@ void chv_data_lane_soft_reset(struct intel_encoder 
*encoder,
 void chv_phy_pre_pll_enable(struct intel_encoder *encoder);
 void chv_phy_pre_encoder_enable(struct intel_encoder *encoder);
 void chv_phy_release_cl2_override(struct intel_encoder *encoder);
+void chv_phy_post_disable(struct intel_encoder *encoder);
 
 int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
 int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8735738..7fe3326 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2867,35 +2867,7 @@ static void chv_dp_pre_pll_enable(struct intel_encoder 
*encoder)
 
 static void chv_dp_post_pll_disable(struct intel_encoder *encoder)
 {
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   enum pipe pipe = to_intel_crtc(encoder->base.crtc)->pipe;
-   u32 val;
-
-   mutex_lock(&dev_priv->sb_lock);
-
-   /* disable left/right clock distribution */
-   if (pipe != PIPE_B) {
-   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
-   val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
-   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
-   } else {
-   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
-   val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
-   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
-   }
-
-   mutex_unlock(&dev_priv->sb_lock);
-
-   /*
-* Leave the power down bit cleared for at least one
-* lane so that chv_powergate_phy_ch() will power
-* on something when the channel is otherwise unused.
-* When the port is off and the override is removed
-* the lanes power down anyway, so otherwise it doesn't
-* really matter what the state of power down bits is
-* after this.
-*/
-   chv_phy_powergate_lanes(encoder, false, 0x0);
+   chv_phy_post_disable(encoder);
 }
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 6078e74..1796f9b 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -337,3 +337,36 @@ void chv_phy_release_cl2_override(struct intel_encoder 
*encoder)
dport->release_cl2_override = false;
}
 }
+
+void chv_phy_post_disable(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   enum pipe pipe = to_intel_crtc(encoder->base.crtc)->pipe;
+   u32 val;
+
+   mutex_lock(&dev_priv->sb_lock);
+
+   /* disable left/right clock distribution */
+   if (pipe != PIPE_B) {
+   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
+   val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
+   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
+   } else {
+   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
+   val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
+   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
+   }
+
+   mutex_unlock(&dev_priv->sb_lock);
+
+   /*
+* Leave the power down bit cleared for at least one
+* lane so that chv_powergate_phy_ch() will power
+* on something when the channel is otherwise unused.
+* When the port is off and the override is removed
+* the lanes power down anyway, so otherwise it doesn't
+* really matter what the state of power down bits is
+* after this.
+*/
+   chv_phy_powergate_lanes(encoder, false, 0x0);
+}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1eb6667..9d23953 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1665,35 +1665,7 @@ static void chv_hdmi_pre_pll_enable(struct intel_encoder 
*encoder)
 
 static void chv_hdmi_post_pll_disable(struct intel_encoder *encoder)
 {
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   enum pipe pipe = to_intel_crtc(encoder->base.crtc)->pipe;
-   u32 val;
-
-   mutex_lock(&dev_priv->sb_lock);
-

[Intel-gfx] [PATCH 4/6] drm/i915: Unduplicate CHV phy-releated pre pll enabling code

2016-04-08 Thread Ander Conselvan de Oliveira
The same logic is used for DP and HDMI so move it to intel_dpio_phy.c.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_dp.c   | 83 +--
 drivers/gpu/drm/i915/intel_dpio_phy.c | 81 ++
 drivers/gpu/drm/i915/intel_drv.h  |  5 +++
 drivers/gpu/drm/i915/intel_hdmi.c | 74 +--
 5 files changed, 89 insertions(+), 155 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 52e5e88..7b2f453 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3510,6 +3510,7 @@ void chv_set_phy_signal_level(struct intel_encoder 
*encoder,
  bool uniq_trans_scale);
 void chv_data_lane_soft_reset(struct intel_encoder *encoder,
  bool reset);
+void chv_phy_pre_pll_enable(struct intel_encoder *encoder);
 
 int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
 int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4d15166..fb0c9c5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -131,11 +131,6 @@ static void vlv_steal_power_sequencer(struct drm_device 
*dev,
  enum pipe pipe);
 static void intel_dp_unset_edid(struct intel_dp *intel_dp);
 
-static unsigned int intel_dp_unused_lane_mask(int lane_count)
-{
-   return ~((1 << lane_count) - 1) & 0xf;
-}
-
 static int
 intel_dp_max_link_bw(struct intel_dp  *intel_dp)
 {
@@ -2945,85 +2940,9 @@ static void chv_pre_enable_dp(struct intel_encoder 
*encoder)
 
 static void chv_dp_pre_pll_enable(struct intel_encoder *encoder)
 {
-   struct intel_digital_port *dport = enc_to_dig_port(&encoder->base);
-   struct drm_device *dev = encoder->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc =
-   to_intel_crtc(encoder->base.crtc);
-   enum dpio_channel ch = vlv_dport_to_channel(dport);
-   enum pipe pipe = intel_crtc->pipe;
-   unsigned int lane_mask =
-   intel_dp_unused_lane_mask(intel_crtc->config->lane_count);
-   u32 val;
-
intel_dp_prepare(encoder);
 
-   /*
-* Must trick the second common lane into life.
-* Otherwise we can't even access the PLL.
-*/
-   if (ch == DPIO_CH0 && pipe == PIPE_B)
-   dport->release_cl2_override =
-   !chv_phy_powergate_ch(dev_priv, DPIO_PHY0, DPIO_CH1, 
true);
-
-   chv_phy_powergate_lanes(encoder, true, lane_mask);
-
-   mutex_lock(&dev_priv->sb_lock);
-
-   /* Assert data lane reset */
-   chv_data_lane_soft_reset(encoder, true);
-
-   /* program left/right clock distribution */
-   if (pipe != PIPE_B) {
-   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
-   val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
-   if (ch == DPIO_CH0)
-   val |= CHV_BUFLEFTENA1_FORCE;
-   if (ch == DPIO_CH1)
-   val |= CHV_BUFRIGHTENA1_FORCE;
-   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
-   } else {
-   val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
-   val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
-   if (ch == DPIO_CH0)
-   val |= CHV_BUFLEFTENA2_FORCE;
-   if (ch == DPIO_CH1)
-   val |= CHV_BUFRIGHTENA2_FORCE;
-   vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
-   }
-
-   /* program clock channel usage */
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW8(ch));
-   val |= CHV_PCS_USEDCLKCHANNEL_OVRRIDE;
-   if (pipe != PIPE_B)
-   val &= ~CHV_PCS_USEDCLKCHANNEL;
-   else
-   val |= CHV_PCS_USEDCLKCHANNEL;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW8(ch), val);
-
-   if (intel_crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW8(ch));
-   val |= CHV_PCS_USEDCLKCHANNEL_OVRRIDE;
-   if (pipe != PIPE_B)
-   val &= ~CHV_PCS_USEDCLKCHANNEL;
-   else
-   val |= CHV_PCS_USEDCLKCHANNEL;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW8(ch), val);
-   }
-
-   /*
-* This a a bit weird since generally CL
-* matches the pipe, but here we need to
-* pick the CL based on the port.
-*/
-   val = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW19(ch));
-   if (pipe != PIPE_B)
-   val &= ~CHV_CMN_USEDCLKCHANNEL;
-   else
-   val |= CHV_CMN_USEDCLKCHANNEL;
-   vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW1

[Intel-gfx] [PATCH 3/6] drm/i915: Unduplicate chv_data_lane_soft_reset()

2016-04-08 Thread Ander Conselvan de Oliveira
The function chv_data_lane_soft_reset() was duplicated in DP and HDMI
code. Move it to intel_dpio_phy.c.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/intel_dp.c   | 44 ---
 drivers/gpu/drm/i915/intel_dpio_phy.c | 43 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 44 ---
 4 files changed, 45 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3c393e3..52e5e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3508,6 +3508,8 @@ void vlv_flisdsi_write(struct drm_i915_private *dev_priv, 
u32 reg, u32 val);
 void chv_set_phy_signal_level(struct intel_encoder *encoder,
  u32 deemph_reg_value, u32 margin_reg_value,
  bool uniq_trans_scale);
+void chv_data_lane_soft_reset(struct intel_encoder *encoder,
+ bool reset);
 
 int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
 int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5ba72b0..4d15166 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2451,50 +2451,6 @@ static void vlv_post_disable_dp(struct intel_encoder 
*encoder)
intel_dp_link_down(intel_dp);
 }
 
-static void chv_data_lane_soft_reset(struct intel_encoder *encoder,
-bool reset)
-{
-   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-   enum dpio_channel ch = 
vlv_dport_to_channel(enc_to_dig_port(&encoder->base));
-   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
-   enum pipe pipe = crtc->pipe;
-   uint32_t val;
-
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
-   if (reset)
-   val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
-   else
-   val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
-
-   if (crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
-   if (reset)
-   val &= ~(DPIO_PCS_TX_LANE2_RESET | 
DPIO_PCS_TX_LANE1_RESET);
-   else
-   val |= DPIO_PCS_TX_LANE2_RESET | 
DPIO_PCS_TX_LANE1_RESET;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
-   }
-
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
-   val |= CHV_PCS_REQ_SOFTRESET_EN;
-   if (reset)
-   val &= ~DPIO_PCS_CLK_SOFT_RESET;
-   else
-   val |= DPIO_PCS_CLK_SOFT_RESET;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
-
-   if (crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
-   val |= CHV_PCS_REQ_SOFTRESET_EN;
-   if (reset)
-   val &= ~DPIO_PCS_CLK_SOFT_RESET;
-   else
-   val |= DPIO_PCS_CLK_SOFT_RESET;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
-   }
-}
-
 static void chv_post_disable_dp(struct intel_encoder *encoder)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index cbe1703d..9854c93 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -120,3 +120,46 @@ void chv_set_phy_signal_level(struct intel_encoder 
*encoder,
 
 }
 
+void chv_data_lane_soft_reset(struct intel_encoder *encoder,
+ bool reset)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   enum dpio_channel ch = 
vlv_dport_to_channel(enc_to_dig_port(&encoder->base));
+   struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
+   enum pipe pipe = crtc->pipe;
+   uint32_t val;
+
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
+   if (reset)
+   val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
+   else
+   val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
+
+   if (crtc->config->lane_count > 2) {
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
+   if (reset)
+   val &= ~(DPIO_PCS_TX_LANE2_RESET | 
DPIO_PCS_TX_LANE1_RESET);
+   else
+   val |= DPIO_PCS_TX_LANE2_RESET | 
DPIO_PCS_TX_LANE1_RESET;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
+   }
+
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(c

[Intel-gfx] [PATCH 0/6] Unduplicate CHV phy code

2016-04-08 Thread Ander Conselvan de Oliveira
There was a lot of duplication between the CHV specific code in DP and
HDMI encoders. This series moves those to a new file: intel_dpio_phy.c.

I don't really know all the details about that code, so couldn't come
up with decent names for the new funcions. Perhaps Ville can suggest
something better and also what to write for kerneldoc.

Note that I only compile-tested this.

Cc: Ville Syrjälä 

Ander Conselvan de Oliveira (6):
  drm/i915: Set crtc_state->lane_count for HDMI
  drm/i915: Unduplicate CHV signal level code
  drm/i915: Unduplicate chv_data_lane_soft_reset()
  drm/i915: Unduplicate CHV phy-releated pre pll enabling code
  drm/i915: Unduplicate CHV pre-encoder enabling phy logic
  drm/i915: Undiplicate CHV encoders' post pll disable code

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_drv.h   |  11 +
 drivers/gpu/drm/i915/intel_dp.c   | 344 +--
 drivers/gpu/drm/i915/intel_dpio_phy.c | 372 ++
 drivers/gpu/drm/i915/intel_drv.h  |   5 +
 drivers/gpu/drm/i915/intel_hdmi.c | 289 +-
 6 files changed, 406 insertions(+), 616 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_dpio_phy.c

-- 
2.4.11

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


[Intel-gfx] [PATCH 5/6] drm/i915: Unduplicate CHV pre-encoder enabling phy logic

2016-04-08 Thread Ander Conselvan de Oliveira
The only difference between the DP and HDMI versions was the lane count.
Since lane_count is now set appropriately for HDMI too, get rid of the
duplication and move this to intel_dpio_phy.c

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.h   |  2 +
 drivers/gpu/drm/i915/intel_dp.c   | 84 +--
 drivers/gpu/drm/i915/intel_dpio_phy.c | 93 +++
 drivers/gpu/drm/i915/intel_hdmi.c | 69 +-
 4 files changed, 99 insertions(+), 149 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b2f453..e1b2f48 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3511,6 +3511,8 @@ void chv_set_phy_signal_level(struct intel_encoder 
*encoder,
 void chv_data_lane_soft_reset(struct intel_encoder *encoder,
  bool reset);
 void chv_phy_pre_pll_enable(struct intel_encoder *encoder);
+void chv_phy_pre_encoder_enable(struct intel_encoder *encoder);
+void chv_phy_release_cl2_override(struct intel_encoder *encoder);
 
 int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
 int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fb0c9c5..8735738 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2851,91 +2851,11 @@ static void vlv_dp_pre_pll_enable(struct intel_encoder 
*encoder)
 
 static void chv_pre_enable_dp(struct intel_encoder *encoder)
 {
-   struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
-   struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
-   struct drm_device *dev = encoder->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc =
-   to_intel_crtc(encoder->base.crtc);
-   enum dpio_channel ch = vlv_dport_to_channel(dport);
-   int pipe = intel_crtc->pipe;
-   int data, i, stagger;
-   u32 val;
-
-   mutex_lock(&dev_priv->sb_lock);
-
-   /* allow hardware to manage TX FIFO reset source */
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
-   val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
-
-   if (intel_crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
-   val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
-   }
-
-   /* Program Tx lane latency optimal setting*/
-   for (i = 0; i < intel_crtc->config->lane_count; i++) {
-   /* Set the upar bit */
-   if (intel_crtc->config->lane_count == 1)
-   data = 0x0;
-   else
-   data = (i == 1) ? 0x0 : 0x1;
-   vlv_dpio_write(dev_priv, pipe, CHV_TX_DW14(ch, i),
-   data << DPIO_UPAR_SHIFT);
-   }
-
-   /* Data lane stagger programming */
-   if (intel_crtc->config->port_clock > 27)
-   stagger = 0x18;
-   else if (intel_crtc->config->port_clock > 135000)
-   stagger = 0xd;
-   else if (intel_crtc->config->port_clock > 67500)
-   stagger = 0x7;
-   else if (intel_crtc->config->port_clock > 33750)
-   stagger = 0x4;
-   else
-   stagger = 0x2;
-
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
-   val |= DPIO_TX2_STAGGER_MASK(0x1f);
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
-
-   if (intel_crtc->config->lane_count > 2) {
-   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
-   val |= DPIO_TX2_STAGGER_MASK(0x1f);
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
-   }
-
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW12(ch),
-  DPIO_LANESTAGGER_STRAP(stagger) |
-  DPIO_LANESTAGGER_STRAP_OVRD |
-  DPIO_TX1_STAGGER_MASK(0x1f) |
-  DPIO_TX1_STAGGER_MULT(6) |
-  DPIO_TX2_STAGGER_MULT(0));
-
-   if (intel_crtc->config->lane_count > 2) {
-   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW12(ch),
-  DPIO_LANESTAGGER_STRAP(stagger) |
-  DPIO_LANESTAGGER_STRAP_OVRD |
-  DPIO_TX1_STAGGER_MASK(0x1f) |
-  DPIO_TX1_STAGGER_MULT(7) |
-  DPIO_TX2_STAGGER_MULT(5));
-   }
-
-   /* Deassert data lane reset */
-   chv_data_lane_soft_reset(encoder, false);
-
-   mutex_unlock(&dev_priv->sb_lock);
+   chv_phy_pre_encoder_enable(encoder);
 
intel_enable_dp(encoder);
 
-   /* Second common lane will stay alive on its o

Re: [Intel-gfx] [PATCH] drm/i915: Fix CHV data lane soft reset for HDMI

2016-04-08 Thread Ander Conselvan De Oliveira
On Fri, 2016-04-08 at 17:11 +0300, Ville Syrjälä wrote:
> On Fri, Apr 08, 2016 at 05:06:04PM +0300, Ander Conselvan de Oliveira wrote:
> > The function chv_data_lane_soft_reset() uses the lane count to decide
> > which lanes to set/reset. However, the HDMI code never sets lane count,
> > since it always uses the four lanes of the phy. Note that before commit
> > a8f327fb8464 ("drm/i915: Clean up CHV lane soft reset programming"), all
> > lanes were reset, regardless of lane count, so this patch restores that
> > behavior.
> > 
> > Cc: Ville Syrjälä 
> > Cc: Deepak S 
> > Fixes: a8f327fb8464 ("drm/i915: Clean up CHV lane soft reset programming")
> > Signed-off-by: Ander Conselvan de Oliveira <
> > ander.conselvan.de.olive...@intel.com>
> 
> At some point we really should just eliminate the duplicated PHY code
> by moving it to someting like intel_dpio.c, and then I suppose we should
> populate lane_count for HDMI as well. But for now this is good enough.

I took the bait and did that for CHV, except I couldn't come up with good names
and kerneldoc for stuff. I can do the same for VLV, but that will have to wait
until Monday.

Cheers,
Ander

> 
> Reviewed-by: Ville Syrjälä 
> 
> > ---
> > 
> > I noticed this while reading CHV code, so this is only compiled tested. I
> > don't know if this could cause real issues.
> > 
> > Ander
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_hdmi.c | 30 +-
> >  1 file changed, 13 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index b199ede..5410d1a 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1670,14 +1670,12 @@ static void chv_data_lane_soft_reset(struct
> > intel_encoder *encoder,
> > val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
> > vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
> >  
> > -   if (crtc->config->lane_count > 2) {
> > -   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> > -   if (reset)
> > -   val &= ~(DPIO_PCS_TX_LANE2_RESET |
> > DPIO_PCS_TX_LANE1_RESET);
> > -   else
> > -   val |= DPIO_PCS_TX_LANE2_RESET |
> > DPIO_PCS_TX_LANE1_RESET;
> > -   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
> > -   }
> > +   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> > +   if (reset)
> > +   val &= ~(DPIO_PCS_TX_LANE2_RESET |
> > DPIO_PCS_TX_LANE1_RESET);
> > +   else
> > +   val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
> > +   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
> >  
> > val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
> > val |= CHV_PCS_REQ_SOFTRESET_EN;
> > @@ -1687,15 +1685,13 @@ static void chv_data_lane_soft_reset(struct
> > intel_encoder *encoder,
> > val |= DPIO_PCS_CLK_SOFT_RESET;
> > vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
> >  
> > -   if (crtc->config->lane_count > 2) {
> > -   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
> > -   val |= CHV_PCS_REQ_SOFTRESET_EN;
> > -   if (reset)
> > -   val &= ~DPIO_PCS_CLK_SOFT_RESET;
> > -   else
> > -   val |= DPIO_PCS_CLK_SOFT_RESET;
> > -   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
> > -   }
> > +   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
> > +   val |= CHV_PCS_REQ_SOFTRESET_EN;
> > +   if (reset)
> > +   val &= ~DPIO_PCS_CLK_SOFT_RESET;
> > +   else
> > +   val |= DPIO_PCS_CLK_SOFT_RESET;
> > +   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
> >  }
> >  
> >  static void chv_hdmi_pre_pll_enable(struct intel_encoder *encoder)
> > -- 
> > 2.4.11
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/3] drm/i915: Get panel_type from OpRegion panel details

2016-04-08 Thread Ville Syrjälä
On Fri, Apr 08, 2016 at 06:01:41PM +0300, Jani Nikula wrote:
> On Fri, 08 Apr 2016, Ville Syrjälä  wrote:
> > On Fri, Apr 08, 2016 at 05:50:06PM +0300, Jani Nikula wrote:
> >> On Fri, 08 Apr 2016, ville.syrj...@linux.intel.com wrote:
> >> > From: Ville Syrjälä 
> >> >
> >> > We've had problems on several occasions with using the panel type
> >> > from the VBT block 40. Usually it seems to be 2, which often
> >> > doesn't give us the correct timings for the panel. After some
> >> > more digging I found a way to get a panel type via the OpRegion
> >> > SWSCI GBDA "Get Panel Details" method. Let's try to use it.
> >> >
> >> > The spec has this to say about the output:
> >> > "Bits [15:8] - Panel Type
> >> >  Bits contain the panel type user setting from CMOS
> >> >  00h = Not Valid, use default Panel Type & Timings from VBT
> >> >  01h - 0Fh = Panel Number"
> >> >
> >> > The other bits in the output don't look relevant for the problem at
> >> > hand.
> >> >
> >> > The input is specified as:
> >> > "Bits [31:4] - Reserved
> >> >  Reserved (must be zero)
> >> >  Bits [3:0] - Panel Number
> >> >  These bits contain the sequential index of Panel, starting at 0 and
> >> >  counting upwards from the first integrated Internal Flat-Panel Display
> >> >  Encoder present, and then from the first external Display Encoder
> >> >  (e.g., S/DVO-B then S/DVO-C) which supports Internal Flat-Panels.
> >> >  0h - 0Fh = Panel number"
> >> >
> >> > For now I've just hardcoded the input panel number as 0. That would seem
> >> > like a decent choise for LVDS. Not so sure about eDP when port != A.
> >> 
> >> Frankly, I didn't understand the point of the input parameter for
> >> figuring out the output. The spec is written for someone who already
> >> knows what they're doing...
> >> 
> >> >
> >> > Cc: Rob Kramer 
> >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
> >> > Signed-off-by: Ville Syrjälä 
> >> > ---
> >> >  drivers/gpu/drm/i915/i915_drv.h   |  5 +
> >> >  drivers/gpu/drm/i915/intel_bios.c | 13 ++---
> >> >  drivers/gpu/drm/i915/intel_opregion.c | 13 +
> >> >  3 files changed, 28 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> > b/drivers/gpu/drm/i915/i915_drv.h
> >> > index 53ace572b292..533263a7a12d 100644
> >> > --- a/drivers/gpu/drm/i915/i915_drv.h
> >> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> > @@ -3421,6 +3421,7 @@ extern int intel_opregion_notify_encoder(struct 
> >> > intel_encoder *intel_encoder,
> >> >   bool enable);
> >> >  extern int intel_opregion_notify_adapter(struct drm_device *dev,
> >> >   pci_power_t state);
> >> > +extern int intel_opregion_get_panel_type(struct drm_device *dev);
> >> >  #else
> >> >  static inline int intel_opregion_setup(struct drm_device *dev) { return 
> >> > 0; }
> >> >  static inline void intel_opregion_init(struct drm_device *dev) { 
> >> > return; }
> >> > @@ -3436,6 +3437,10 @@ intel_opregion_notify_adapter(struct drm_device 
> >> > *dev, pci_power_t state)
> >> >  {
> >> >  return 0;
> >> >  }
> >> > +static inline int intel_opregion_get_panel_type(struct drm_device *dev)
> >> > +{
> >> > +return 0;
> >> > +}
> >> >  #endif
> >> >  
> >> >  /* intel_acpi.c */
> >> > diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> >> > b/drivers/gpu/drm/i915/intel_bios.c
> >> > index d9568be4b33b..718e49931b5f 100644
> >> > --- a/drivers/gpu/drm/i915/intel_bios.c
> >> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> >> > @@ -205,16 +205,23 @@ parse_lfp_panel_data(struct drm_i915_private 
> >> > *dev_priv,
> >> >  struct drm_display_mode *panel_fixed_mode;
> >> >  int panel_type;
> >> >  int drrs_mode;
> >> > +int ret;
> >> >  
> >> >  lvds_options = find_section(bdb, BDB_LVDS_OPTIONS);
> >> >  if (!lvds_options)
> >> >  return;
> >> >  
> >> >  dev_priv->vbt.lvds_dither = lvds_options->pixel_dither;
> >> > -if (lvds_options->panel_type > 0xf)
> >> > -return;
> >> >  
> >> > -panel_type = lvds_options->panel_type;
> >> > +ret = intel_opregion_get_panel_type(dev_priv->dev);
> >> > +if (ret >= 0x1 && ret <= 0xf) {
> >> 
> >> Undecided whether I'd like to have this check within
> >> intel_opregion_get_panel_type(). Just make that return 0 for "use vbt"
> >> (and CONFIG_ACPI=n), and valid stuff otherwise? *shrug*
> >
> > We don't compile intel_opregion.c when ACPI==n.
> 
> Yeah I meant the static inline stub in i915_drv.h for ACPI=n. Which does
> return 0.

I'm a bit lost here. Oh, maybe the ACPI=n note just confused me.
Did you just mean that I should do the 0x1-0xf check in
intel_opregion_get_panel_type() already?

> >> > +panel_type = ret;
> >> > +} else {
> >> > +if (lvds_options->panel_type > 0xf)
> >> > +return;
> >> > + 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI

2016-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI
URL   : https://patchwork.freedesktop.org/series/5462/
State : failure

== Summary ==

Series 5462v1 drm/i915/opregion: remove unnecessary ifdefs on CONFIG_ACPI
http://patchwork.freedesktop.org/api/1.0/series/5462/revisions/1/mbox/

Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test pm_rpm:
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
ilk-hp8440p  total:196  pass:131  dwarn:1   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33 
BOOT FAILED for hsw-gt2

Results at /archive/results/CI_IGT_test/Patchwork_1847/

949884a57b51aa158e3ae9afe1f08130cdb7a3ef drm-intel-nightly: 
2016y-04m-08d-10h-45m-28s UTC integration manifest
0b3264d006064f3bf9705fac57204494b3a9c980 drm/i915/opregion: remove unnecessary 
ifdefs on CONFIG_ACPI

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


[Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL.

2016-04-08 Thread Bob Paauwe
The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync with the atomic version of the properties.

Until the driver is full atomic, make sure we update the non-atomic
version of the properties.

igt-testcase: kms_pipe_color / legacy-gamma-reset-pipeX
Signed-off-by: Bob Paauwe 
---
 drivers/gpu/drm/i915/intel_display.c | 38 +++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5155efb6..ff09a18 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13885,8 +13885,44 @@ out:
 
 #undef for_each_intel_crtc_masked
 
+/*
+ * TODO: Remove this once we have full atomic implmented.
+ */
+static void intel_atomic_legacy_gamma_set(struct drm_crtc *crtc,
+ u16 *red, u16 *green, u16 *blue,
+ uint32_t start, uint32_t size)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_mode_config *config = &dev->mode_config;
+   struct drm_crtc_state *state;
+
+   drm_atomic_helper_legacy_gamma_set(crtc, red, green, blue, start, size);
+
+   /*
+* Make sure we update the legacy properties so this works when
+* atomic is not enabled.
+*/
+
+   state = crtc->state;
+
+   drm_object_property_set_value(&crtc->base,
+ config->degamma_lut_property,
+ (state->degamma_lut) ?
+ state->degamma_lut->base.id : 0);
+
+   drm_object_property_set_value(&crtc->base,
+ config->ctm_property,
+ (state->ctm) ?
+ state->ctm->base.id : 0);
+
+   drm_object_property_set_value(&crtc->base,
+ config->gamma_lut_property,
+ (state->gamma_lut) ?
+ state->gamma_lut->base.id : 0);
+}
+
 static const struct drm_crtc_funcs intel_crtc_funcs = {
-   .gamma_set = drm_atomic_helper_legacy_gamma_set,
+   .gamma_set = intel_atomic_legacy_gamma_set,
.set_config = drm_atomic_helper_set_config,
.set_property = drm_atomic_helper_crtc_set_property,
.destroy = intel_crtc_destroy,
-- 
2.5.5

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


[Intel-gfx] [PATCH] drm/i915: add missing condition for committing planes on crtc

2016-04-08 Thread Lionel Landwerlin
We are currently missing the color management update condition to
commit planes on crtc.

Fixes: 20a34e78f0d7 (drm/i915: Update color management during vblank evasion.)
Cc: Maarten Lankhorst 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/intel_display.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index feb7028..670b2ad 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13480,6 +13480,13 @@ static bool needs_vblank_wait(struct intel_crtc_state 
*crtc_state)
return false;
 }
 
+static bool needs_commit_planes_on_crtc(struct drm_crtc_state *crtc_state)
+{
+   return (crtc_state->planes_changed ||
+   crtc_state->color_mgmt_changed ||
+   to_intel_crtc_state(crtc_state)->update_pipe);
+}
+
 /**
  * intel_atomic_commit - commit validated state object
  * @dev: DRM device
@@ -13583,7 +13590,6 @@ static int intel_atomic_commit(struct drm_device *dev,
bool modeset = needs_modeset(crtc->state);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->state);
-   bool update_pipe = !modeset && pipe_config->update_pipe;
 
if (modeset && crtc->state->active) {
update_scanline_offset(to_intel_crtc(crtc));
@@ -13597,8 +13603,8 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_get_existing_plane_state(state, crtc->primary))
intel_fbc_enable(intel_crtc);
 
-   if (crtc->state->active &&
-   (crtc->state->planes_changed || update_pipe))
+   if (crtc->state->active && !modeset &&
+   needs_commit_planes_on_crtc(crtc->state))
drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
 
if (pipe_config->base.active && needs_vblank_wait(pipe_config))
-- 
2.8.0.rc3

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


[Intel-gfx] [PATCH i-g-t v2] test/gem_mocs_settings: Testing MOCS register settings

2016-04-08 Thread Peter Antoine
The MOCS registers were added in Gen9 and define the caching policy.
The registers are split into two sets. The first set controls the
EDRAM policy and have a set for each engine, the second set controls
the L3 policy. The two sets use the same index.

The RCS registers and the L3CC registers are stored in the RCS context.

The test checks that the registers are correct by checking the values by
directly reading them via MMIO, then again it tests them by reading them
from within a batch buffer. RCS engine is tested last as it programs the
registers via a batch buffer and this will invalidate the test for
workloads that don't use the render ring or don't run a render batch
first.

v2: Reorganised the structure.
Added more tests. (Chris Wilson)

Signed-off-by: Peter Antoine 
---
 tests/Makefile.sources|   1 +
 tests/gem_mocs_settings.c | 566 ++
 2 files changed, 567 insertions(+)
 create mode 100644 tests/gem_mocs_settings.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 43f232f..d483c9e 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -148,6 +148,7 @@ TESTS_progs = \
gem_lut_handle \
gem_mmap_offset_exhaustion \
gem_media_fill \
+   gem_mocs_settings \
gem_gpgpu_fill \
gem_pin \
gem_reg_read \
diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
new file mode 100644
index 000..df4174c
--- /dev/null
+++ b/tests/gem_mocs_settings.c
@@ -0,0 +1,566 @@
+/*
+ * Copyright © 2016 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.
+ *
+ */
+
+/** @file gem_mocs_settings.c
+ *
+ * Check that the MOCs cache settings are valid.
+ */
+
+#include "igt.h"
+#include "igt_gt.h"
+
+#define MAX_NUMBER_MOCS_REGISTERS  (64)
+
+enum {
+   NONE,
+   RESET,
+   SUSPEND,
+   HIBERNATE
+};
+
+#define GEN9_LNCFCMOCS0(0xB020)/* L3 Cache Control 
base */
+#define GEN9_GFX_MOCS_0(0xc800)/* Graphics MOCS base 
register*/
+#define GEN9_MFX0_MOCS_0   (0xc900)/* Media 0 MOCS base register*/
+#define GEN9_MFX1_MOCS_0   (0xcA00)/* Media 1 MOCS base register*/
+#define GEN9_VEBOX_MOCS_0  (0xcB00)/* Video MOCS base register*/
+#define GEN9_BLT_MOCS_0(0xcc00)/* Blitter MOCS base 
register*/
+
+#define ENGINE_GFX (I915_EXEC_RENDER)
+#define ENGINE_MFX0(I915_EXEC_BSD)
+#define ENGINE_MFX0_ALT(I915_EXEC_BSD | 1 << 13)
+#define ENGINE_MFX1(I915_EXEC_BSD | 2 << 13)
+#define ENGINE_BLT (I915_EXEC_BLT)
+#define ENGINE_VEBOX   (I915_EXEC_VEBOX)
+
+struct mocs_entry {
+   uint32_tcontrol_value;
+   uint16_tl3cc_value;
+};
+
+struct mocs_table {
+   uint32_tsize;
+   const struct mocs_entry *table;
+};
+
+static const struct mocs_entry skylake_mocs_table[] = {
+   { 0x0009, 0x0010 },
+   { 0x0038, 0x0030 },
+   { 0x003b, 0x0030 },
+};
+
+static const struct mocs_entry broxton_mocs_table[] = {
+   { 0x0009, 0x0010 },
+   { 0x0038, 0x0030 },
+   { 0x003b, 0x0030 },
+};
+
+static const struct mocs_entry dirty_table_mocs_table[] = {
+   { 0x7FFF, 0x003F },
+   { 0x7FFF, 0x003F },
+   { 0x7FFF, 0x003F },
+};
+
+static const uint32_t write_values[] = {
+   0x,
+   0x,
+   0x,
+   0x
+};
+
+static bool get_mocs_settings(uint32_t devid,
+   struct mocs_table *table,
+   bool dirty)
+{
+   bool result = false;
+
+   if (dirty) {
+   table->size  = ARRAY_SIZE(dirty_table_mocs_table);
+   table->table = dirty_table_mocs_table;
+   result = true;
+   } else if (IS_SKYLAKE(devid) || IS_KABYLAKE(devid)) {
+   table->size  =

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Set legacy properties when using legacy gamma set IOCTL.

2016-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915: Set legacy properties when using legacy gamma set IOCTL.
URL   : https://patchwork.freedesktop.org/series/5466/
State : failure

== Summary ==

Series 5466v1 drm/i915: Set legacy properties when using legacy gamma set IOCTL.
http://patchwork.freedesktop.org/api/1.0/series/5466/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_basic:
Subgroup create-fd-close:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_cs_prefetch:
Subgroup basic-default:
skip   -> INCOMPLETE (bdw-nuci7)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_ctx_basic:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_ctx_param_basic:
Subgroup basic:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup invalid-ctx-get:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup invalid-param-set:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup invalid-size-get:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup non-root-set:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup root-set-no-zeromap-disabled:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-render:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup gtt-bsd2:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup gtt-vebox:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup readonly-render:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_exec_nop:
Subgroup basic:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_exec_parse:
Subgroup basic-allowed:
skip   -> INCOMPLETE (bdw-nuci7)
Test gem_exec_store:
Subgroup basic-all:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup basic-blt:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup basic-render:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_flink_basic:
Subgroup basic:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_mmap_gtt:
Subgroup basic-short:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup basic-small-bo-tiledy:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup basic-write-read:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_render_tiled_blits:
Subgroup basic:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_storedw_loop:
Subgroup basic-bsd2:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup basic-render:
pass   -> INCOMPLETE (bdw-nuci7) UNSTABLE
Subgroup basic-vebox:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> INCOMPLETE (bdw-nuci7)
Test gem_tiled_pread_basic:
pass   -> INCOMPLETE (bdw-nuci7)
Test kms_addfb_basic:
Subgroup addfb25-framebuffer-vs-set-tiling:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup addfb25-x-tiled:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup addfb25-y-tiled-small:
skip   -> INCOMPLETE (bdw-nuci7)
Subgroup bad-pitch-128:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup bad-pitch-32:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup bad-pitch-65536:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup small-bo:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup too-wide:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup unused-offsets:
pass   -> INCOMPLETE (bdw-nuci7)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> SKIP   (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> INCOMPLETE (bdw-nuci7)
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (skl-nuci5)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
pass   -> INCOMPLETE (bdw-nuci7)
Test kms_sink_crc_basic:

[Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

2016-04-08 Thread Lionel Landwerlin
Color management properties are a bit of an odd use case because
they're not marked as atomic properties. Currently we're not updating
the non atomic values so the drm_crtc_state is out of sync with the
values stored in the crtc object.

Cc: Maarten Lankhorst 
Cc: Bob Paauwe 
Cc: 
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/drm_atomic_helper.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 7bf678e..4aacd44 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2964,16 +2964,22 @@ retry:
config->degamma_lut_property, 0);
if (ret)
goto fail;
+   drm_object_property_set_value(&crtc->base,
+   config->degamma_lut_property, 0);
 
ret = drm_atomic_crtc_set_property(crtc, crtc_state,
config->ctm_property, 0);
if (ret)
goto fail;
+   drm_object_property_set_value(&crtc->base,
+   config->ctm_property, 0);
 
ret = drm_atomic_crtc_set_property(crtc, crtc_state,
config->gamma_lut_property, blob->base.id);
if (ret)
goto fail;
+   drm_object_property_set_value(&crtc->base,
+   config->gamma_lut_property, blob->base.id);
 
ret = drm_atomic_commit(state);
if (ret)
-- 
2.8.0.rc3

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


Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL.

2016-04-08 Thread Lionel Landwerlin

Hi Paul,

Unfortunate that we've been writing the same patch at the same time :(
I think this we've got pretty much the same fix, but it probably needs 
to be done at the DRM level, because this can impact other drivers too.


Cheers,

-
Lionel

On 08/04/16 17:26, Bob Paauwe wrote:

The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync with the atomic version of the properties.

Until the driver is full atomic, make sure we update the non-atomic
version of the properties.

igt-testcase: kms_pipe_color / legacy-gamma-reset-pipeX
Signed-off-by: Bob Paauwe 
---
  drivers/gpu/drm/i915/intel_display.c | 38 +++-
  1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5155efb6..ff09a18 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13885,8 +13885,44 @@ out:
  
  #undef for_each_intel_crtc_masked
  
+/*

+ * TODO: Remove this once we have full atomic implmented.
+ */
+static void intel_atomic_legacy_gamma_set(struct drm_crtc *crtc,
+ u16 *red, u16 *green, u16 *blue,
+ uint32_t start, uint32_t size)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_mode_config *config = &dev->mode_config;
+   struct drm_crtc_state *state;
+
+   drm_atomic_helper_legacy_gamma_set(crtc, red, green, blue, start, size);
+
+   /*
+* Make sure we update the legacy properties so this works when
+* atomic is not enabled.
+*/
+
+   state = crtc->state;
+
+   drm_object_property_set_value(&crtc->base,
+ config->degamma_lut_property,
+ (state->degamma_lut) ?
+ state->degamma_lut->base.id : 0);
+
+   drm_object_property_set_value(&crtc->base,
+ config->ctm_property,
+ (state->ctm) ?
+ state->ctm->base.id : 0);
+
+   drm_object_property_set_value(&crtc->base,
+ config->gamma_lut_property,
+ (state->gamma_lut) ?
+ state->gamma_lut->base.id : 0);
+}
+
  static const struct drm_crtc_funcs intel_crtc_funcs = {
-   .gamma_set = drm_atomic_helper_legacy_gamma_set,
+   .gamma_set = intel_atomic_legacy_gamma_set,
.set_config = drm_atomic_helper_set_config,
.set_property = drm_atomic_helper_crtc_set_property,
.destroy = intel_crtc_destroy,


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


Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL.

2016-04-08 Thread Lionel Landwerlin

Hi Paul,

Unfortunate that we've been writing the same patch at the same time :(
I think this we've got pretty much the same fix, but it probably needs 
to be done at the DRM level, because this can impact other drivers too.


Cheers,

-
Lionel

On 08/04/16 17:26, Bob Paauwe wrote:

The i915 driver is now using atomic properties and atomic commit
to handle the legacy set gamma IOCTL. However, if the driver is
configured without atomic (nuclear_pageflip = false), it won't
update the legacy properties for degamma_lut, gamma_lut and ctm
leaving them out of sync with the atomic version of the properties.

Until the driver is full atomic, make sure we update the non-atomic
version of the properties.

igt-testcase: kms_pipe_color / legacy-gamma-reset-pipeX
Signed-off-by: Bob Paauwe 
---
  drivers/gpu/drm/i915/intel_display.c | 38 +++-
  1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5155efb6..ff09a18 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13885,8 +13885,44 @@ out:
  
  #undef for_each_intel_crtc_masked
  
+/*

+ * TODO: Remove this once we have full atomic implmented.
+ */
+static void intel_atomic_legacy_gamma_set(struct drm_crtc *crtc,
+ u16 *red, u16 *green, u16 *blue,
+ uint32_t start, uint32_t size)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_mode_config *config = &dev->mode_config;
+   struct drm_crtc_state *state;
+
+   drm_atomic_helper_legacy_gamma_set(crtc, red, green, blue, start, size);
+
+   /*
+* Make sure we update the legacy properties so this works when
+* atomic is not enabled.
+*/
+
+   state = crtc->state;
+
+   drm_object_property_set_value(&crtc->base,
+ config->degamma_lut_property,
+ (state->degamma_lut) ?
+ state->degamma_lut->base.id : 0);
+
+   drm_object_property_set_value(&crtc->base,
+ config->ctm_property,
+ (state->ctm) ?
+ state->ctm->base.id : 0);
+
+   drm_object_property_set_value(&crtc->base,
+ config->gamma_lut_property,
+ (state->gamma_lut) ?
+ state->gamma_lut->base.id : 0);
+}
+
  static const struct drm_crtc_funcs intel_crtc_funcs = {
-   .gamma_set = drm_atomic_helper_legacy_gamma_set,
+   .gamma_set = intel_atomic_legacy_gamma_set,
.set_config = drm_atomic_helper_set_config,
.set_property = drm_atomic_helper_crtc_set_property,
.destroy = intel_crtc_destroy,


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


Re: [Intel-gfx] [PATCH 02/16] drm/i915/bxt: Fix GRC code register field definitions

2016-04-08 Thread Ville Syrjälä
On Fri, Apr 01, 2016 at 04:02:33PM +0300, Imre Deak wrote:
> This has been corrected in BSpec quite some time ago, but we missed it
> somehow. The wrong field definitions resulted in configuring PHY0 with
> an incorrect GRC value.
> 
> CC: Arthur J Runyan 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6df3c59..f4a91bb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1373,10 +1373,10 @@ enum skl_disp_power_wells {
>   * FIXME: BSpec/CHV ConfigDB disagrees on the following two fields, fix them
>   * after testing.
>   */

The FIXME can go, no?

Matches my PHY docs as well as bspec now.

Reviewed-by: Ville Syrjälä 

> -#define   GRC_CODE_SHIFT 23
> -#define   GRC_CODE_MASK  (0x1FF << GRC_CODE_SHIFT)
> +#define   GRC_CODE_SHIFT 24
> +#define   GRC_CODE_MASK  (0xFF << GRC_CODE_SHIFT)
>  #define   GRC_CODE_FAST_SHIFT16
> -#define   GRC_CODE_FAST_MASK (0x7F << GRC_CODE_FAST_SHIFT)
> +#define   GRC_CODE_FAST_MASK (0xFF << GRC_CODE_FAST_SHIFT)
>  #define   GRC_CODE_SLOW_SHIFT8
>  #define   GRC_CODE_SLOW_MASK (0xFF << GRC_CODE_SLOW_SHIFT)
>  #define   GRC_CODE_NOM_MASK  0xFF
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 02/16] drm/i915/bxt: Fix GRC code register field definitions

2016-04-08 Thread Imre Deak
On pe, 2016-04-08 at 20:22 +0300, Ville Syrjälä wrote:
> On Fri, Apr 01, 2016 at 04:02:33PM +0300, Imre Deak wrote:
> > This has been corrected in BSpec quite some time ago, but we missed
> > it
> > somehow. The wrong field definitions resulted in configuring PHY0
> > with
> > an incorrect GRC value.
> > 
> > CC: Arthur J Runyan 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 6df3c59..f4a91bb 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1373,10 +1373,10 @@ enum skl_disp_power_wells {
> >   * FIXME: BSpec/CHV ConfigDB disagrees on the following two
> > fields, fix them
> >   * after testing.
> >   */
> 
> The FIXME can go, no?

Ah yea will remove it. So we did think about this already earlier..

> Matches my PHY docs as well as bspec now.
> 
> Reviewed-by: Ville Syrjälä 
> 
> > -#define   GRC_CODE_SHIFT   23
> > -#define   GRC_CODE_MASK(0x1FF <<
> > GRC_CODE_SHIFT)
> > +#define   GRC_CODE_SHIFT   24
> > +#define   GRC_CODE_MASK(0xFF <<
> > GRC_CODE_SHIFT)
> >  #define   GRC_CODE_FAST_SHIFT  16
> > -#define   GRC_CODE_FAST_MASK   (0x7F <<
> > GRC_CODE_FAST_SHIFT)
> > +#define   GRC_CODE_FAST_MASK   (0xFF <<
> > GRC_CODE_FAST_SHIFT)
> >  #define   GRC_CODE_SLOW_SHIFT  8
> >  #define   GRC_CODE_SLOW_MASK   (0xFF <<
> > GRC_CODE_SLOW_SHIFT)
> >  #define   GRC_CODE_NOM_MASK0xFF
> > -- 
> > 2.5.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL.

2016-04-08 Thread Bob Paauwe
On Fri, 8 Apr 2016 18:21:51 +0100
Lionel Landwerlin  wrote:

> Hi Paul,
> 
> Unfortunate that we've been writing the same patch at the same time :(
> I think this we've got pretty much the same fix, but it probably needs 
> to be done at the DRM level, because this can impact other drivers too.
> 
> Cheers,
> 
> -
> Lionel

In this case, it's happening because the i915 driver is using the
atomic set property paths to implement the set gamma IOCTL. This is
fine if the i915 driver is fully using atomic (nuclear_pageflip = true)
because queries for the properties will go through the atomic path.
But if i915 is not using atomic, then queries for the properties will
not go through the atomic path and will get the incorrect or out of
sync legacy property values.

So this would only effect other drivers if they implemented the set
gamma IOCTL the same way and have two code paths for querying the
properties.

This patch is really a temporary fix until we move to
nuclear_pageflip=true as the default/only mode for the i915 driver.

Bob
> 
> On 08/04/16 17:26, Bob Paauwe wrote:
> > The i915 driver is now using atomic properties and atomic commit
> > to handle the legacy set gamma IOCTL. However, if the driver is
> > configured without atomic (nuclear_pageflip = false), it won't
> > update the legacy properties for degamma_lut, gamma_lut and ctm
> > leaving them out of sync with the atomic version of the properties.
> >
> > Until the driver is full atomic, make sure we update the non-atomic
> > version of the properties.
> >
> > igt-testcase: kms_pipe_color / legacy-gamma-reset-pipeX
> > Signed-off-by: Bob Paauwe 
> > ---
> >   drivers/gpu/drm/i915/intel_display.c | 38 
> > +++-
> >   1 file changed, 37 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 5155efb6..ff09a18 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13885,8 +13885,44 @@ out:
> >   
> >   #undef for_each_intel_crtc_masked
> >   
> > +/*
> > + * TODO: Remove this once we have full atomic implmented.
> > + */
> > +static void intel_atomic_legacy_gamma_set(struct drm_crtc *crtc,
> > + u16 *red, u16 *green, u16 *blue,
> > + uint32_t start, uint32_t size)
> > +{
> > +   struct drm_device *dev = crtc->dev;
> > +   struct drm_mode_config *config = &dev->mode_config;
> > +   struct drm_crtc_state *state;
> > +
> > +   drm_atomic_helper_legacy_gamma_set(crtc, red, green, blue, start, size);
> > +
> > +   /*
> > +* Make sure we update the legacy properties so this works when
> > +* atomic is not enabled.
> > +*/
> > +
> > +   state = crtc->state;
> > +
> > +   drm_object_property_set_value(&crtc->base,
> > + config->degamma_lut_property,
> > + (state->degamma_lut) ?
> > + state->degamma_lut->base.id : 0);
> > +
> > +   drm_object_property_set_value(&crtc->base,
> > + config->ctm_property,
> > + (state->ctm) ?
> > + state->ctm->base.id : 0);
> > +
> > +   drm_object_property_set_value(&crtc->base,
> > + config->gamma_lut_property,
> > + (state->gamma_lut) ?
> > + state->gamma_lut->base.id : 0);
> > +}
> > +
> >   static const struct drm_crtc_funcs intel_crtc_funcs = {
> > -   .gamma_set = drm_atomic_helper_legacy_gamma_set,
> > +   .gamma_set = intel_atomic_legacy_gamma_set,
> > .set_config = drm_atomic_helper_set_config,
> > .set_property = drm_atomic_helper_crtc_set_property,
> > .destroy = intel_crtc_destroy,  
> 



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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


Re: [Intel-gfx] [PATCH 03/16] drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-only

2016-04-08 Thread Ville Syrjälä
On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote:
> This register is read-only, so we have never actually set
> OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a code
> comment about this. I filed a specification update request to clarify
> this there.

Hmm. Interesting. It's r/w on my CHV, and the PHY spec agrees. Of course
I can't really tell whether it has any effect on the x1 PHY. If I set it
on the x2 PHY it definitely makes the channel unusable.

> 
> CC: Arthur J Runyan 
> Signed-off-by: Imre Deak 
> 
> ---
> 
> [ Art, CC'ing you in case you know if this would have an effect on
>   anything. ]
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 2758622..f91306e 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1798,6 +1798,9 @@ static void broxton_phy_init(struct drm_i915_private 
> *dev_priv,
>* enabled.
>* TODO: port C is only connected on BXT-P, so on BXT0/1 we should
>* power down the second channel on PHY0 as well.
> +  *
> +  * FIXME: Clarify programming of the following, the register is
> +  * read-only with bit 6 fixed at 0 at least in stepping A.
>*/
>   if (phy == DPIO_PHY1)
>   val |= OCL2_LDOFUSE_PWR_DIS;
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 09/16] drm/i915/bxt: Pass drm_i915_private to DDI PHY, CDCLK helpers

2016-04-08 Thread Ville Syrjälä
On Fri, Apr 01, 2016 at 04:02:40PM +0300, Imre Deak wrote:
> For internal APIs passing dev_priv is preferred to reduce indirections,
> so convert over a few DDI PHY, CDCLK helpers.
> 
> No functional change.
> 
> Signed-off-by: Imre Deak 

Acked-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_drv.c   | 12 
>  drivers/gpu/drm/i915/intel_ddi.c  | 10 --
>  drivers/gpu/drm/i915/intel_display.c  | 18 +++---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c |  4 ++--
>  drivers/gpu/drm/i915/intel_drv.h  |  8 
>  5 files changed, 21 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index aa7df10..3998f6a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1070,12 +1070,10 @@ static int hsw_suspend_complete(struct 
> drm_i915_private *dev_priv)
>  
>  static int bxt_suspend_complete(struct drm_i915_private *dev_priv)
>  {
> - struct drm_device *dev = dev_priv->dev;
> -
>   /* TODO: when DC5 support is added disable DC5 here. */
>  
> - broxton_ddi_phy_uninit(dev);
> - broxton_uninit_cdclk(dev);
> + broxton_ddi_phy_uninit(dev_priv);
> + broxton_uninit_cdclk(dev_priv);
>   bxt_enable_dc9(dev_priv);
>  
>   return 0;
> @@ -1083,8 +1081,6 @@ static int bxt_suspend_complete(struct drm_i915_private 
> *dev_priv)
>  
>  static int bxt_resume_prepare(struct drm_i915_private *dev_priv)
>  {
> - struct drm_device *dev = dev_priv->dev;
> -
>   /* TODO: when CSR FW support is added make sure the FW is loaded */
>  
>   bxt_disable_dc9(dev_priv);
> @@ -1093,8 +1089,8 @@ static int bxt_resume_prepare(struct drm_i915_private 
> *dev_priv)
>* TODO: when DC5 support is added enable DC5 here if the CSR FW
>* is available.
>*/
> - broxton_init_cdclk(dev);
> - broxton_ddi_phy_init(dev);
> + broxton_init_cdclk(dev_priv);
> + broxton_ddi_phy_init(dev_priv);
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f91306e..29017a4 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1834,11 +1834,11 @@ static void broxton_phy_init(struct drm_i915_private 
> *dev_priv,
>   I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
>  }
>  
> -void broxton_ddi_phy_init(struct drm_device *dev)
> +void broxton_ddi_phy_init(struct drm_i915_private *dev_priv)
>  {
>   /* Enable PHY1 first since it provides Rcomp for PHY0 */
> - broxton_phy_init(dev->dev_private, DPIO_PHY1);
> - broxton_phy_init(dev->dev_private, DPIO_PHY0);
> + broxton_phy_init(dev_priv, DPIO_PHY1);
> + broxton_phy_init(dev_priv, DPIO_PHY0);
>  }
>  
>  static void broxton_phy_uninit(struct drm_i915_private *dev_priv,
> @@ -1851,10 +1851,8 @@ static void broxton_phy_uninit(struct drm_i915_private 
> *dev_priv,
>   I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
>  }
>  
> -void broxton_ddi_phy_uninit(struct drm_device *dev)
> +void broxton_ddi_phy_uninit(struct drm_i915_private *dev_priv)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
>   broxton_phy_uninit(dev_priv, DPIO_PHY1);
>   broxton_phy_uninit(dev_priv, DPIO_PHY0);
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e6b5ee5..d9da89d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5322,9 +5322,8 @@ static void intel_update_cdclk(struct drm_device *dev)
>   intel_update_max_cdclk(dev);
>  }
>  
> -static void broxton_set_cdclk(struct drm_device *dev, int frequency)
> +static void broxton_set_cdclk(struct drm_i915_private *dev_priv, int 
> frequency)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
>   uint32_t divider;
>   uint32_t ratio;
>   uint32_t current_freq;
> @@ -5438,12 +5437,11 @@ static void broxton_set_cdclk(struct drm_device *dev, 
> int frequency)
>   return;
>   }
>  
> - intel_update_cdclk(dev);
> + intel_update_cdclk(dev_priv->dev);
>  }
>  
> -void broxton_init_cdclk(struct drm_device *dev)
> +void broxton_init_cdclk(struct drm_i915_private *dev_priv)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
>   uint32_t val;
>  
>   /*
> @@ -5472,7 +5470,7 @@ void broxton_init_cdclk(struct drm_device *dev)
>* - check if setting the max (or any) cdclk freq is really necessary
>*   here, it belongs to modeset time
>*/
> - broxton_set_cdclk(dev, 624000);
> + broxton_set_cdclk(dev_priv, 624000);
>  
>   I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
>   POSTING_READ(DBUF_CTL);
> @@ -5483,10 +5481,8 @@ void broxton_init_cdclk(struct drm_device *dev)
>   DRM_ERROR("DBuf power enable timeout!\n");
>  }
>  
> -void broxton_uninit_cdclk(struct drm_device *dev)
> +void broxton_

Re: [Intel-gfx] [PATCH 10/16] drm/i915/bxt: Power down DDI PHYs separately during the per PHY uninit

2016-04-08 Thread Ville Syrjälä
On Fri, Apr 01, 2016 at 04:02:41PM +0300, Imre Deak wrote:
> The power-down step logically belongs to the individual PHY uninit
> sequence so move it there. The only functional change is that we will
> power down now PHY 1 separately before PHY 0 and preserve the other bits
> in the register which are defined as reserved.
> 
> Signed-off-by: Imre Deak 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 29017a4..d16effd 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1849,15 +1849,16 @@ static void broxton_phy_uninit(struct 
> drm_i915_private *dev_priv,
>   val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
>   val &= ~COMMON_RESET_DIS;
>   I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
> +
> + val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
> + val &= ~GT_DISPLAY_POWER_ON(phy);
> + I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
>  }
>  
>  void broxton_ddi_phy_uninit(struct drm_i915_private *dev_priv)
>  {
>   broxton_phy_uninit(dev_priv, DPIO_PHY1);
>   broxton_phy_uninit(dev_priv, DPIO_PHY0);
> -
> - /* FIXME: do this in broxton_phy_uninit per phy */
> - I915_WRITE(BXT_P_CR_GT_DISP_PWRON, 0);
>  }
>  
>  void intel_ddi_prepare_link_retrain(struct intel_dp *intel_dp)
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 03/16] drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-only

2016-04-08 Thread Imre Deak
On pe, 2016-04-08 at 21:02 +0300, Ville Syrjälä wrote:
> On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote:
> > This register is read-only, so we have never actually set
> > OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a
> > code
> > comment about this. I filed a specification update request to
> > clarify
> > this there.
> 
> Hmm. Interesting. It's r/w on my CHV, and the PHY spec agrees. Of
> course
> I can't really tell whether it has any effect on the x1 PHY. If I set
> it
> on the x2 PHY it definitely makes the channel unusable.

Note that meanwhile the corresponding BSpec change request got updated
to "Confirmed"/"Won't be fixed".

> > CC: Arthur J Runyan 
> > Signed-off-by: Imre Deak 
> > 
> > ---
> > 
> > [ Art, CC'ing you in case you know if this would have an effect on
> >   anything. ]
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 2758622..f91306e 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1798,6 +1798,9 @@ static void broxton_phy_init(struct
> > drm_i915_private *dev_priv,
> >      * enabled.
> >      * TODO: port C is only connected on BXT-P, so on BXT0/1
> > we should
> >      * power down the second channel on PHY0 as well.
> > +    *
> > +    * FIXME: Clarify programming of the following, the
> > register is
> > +    * read-only with bit 6 fixed at 0 at least in stepping A.
> >      */
> >     if (phy == DPIO_PHY1)
> >     val |= OCL2_LDOFUSE_PWR_DIS;
> > -- 
> > 2.5.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

2016-04-08 Thread Bob Paauwe
On Fri, 8 Apr 2016 18:17:51 +0100
Lionel Landwerlin  wrote:

> Color management properties are a bit of an odd use case because
> they're not marked as atomic properties. Currently we're not updating
> the non atomic values so the drm_crtc_state is out of sync with the
> values stored in the crtc object.
> 
> Cc: Maarten Lankhorst 
> Cc: Bob Paauwe 
> Cc: 
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 7bf678e..4aacd44 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2964,16 +2964,22 @@ retry:
>   config->degamma_lut_property, 0);
>   if (ret)
>   goto fail;
> + drm_object_property_set_value(&crtc->base,
> + config->degamma_lut_property, 0);
>  
>   ret = drm_atomic_crtc_set_property(crtc, crtc_state,
>   config->ctm_property, 0);
>   if (ret)
>   goto fail;
> + drm_object_property_set_value(&crtc->base,
> + config->ctm_property, 0);
>  
>   ret = drm_atomic_crtc_set_property(crtc, crtc_state,
>   config->gamma_lut_property, blob->base.id);
>   if (ret)
>   goto fail;
> + drm_object_property_set_value(&crtc->base,
> + config->gamma_lut_property, blob->base.id);
>  

This is similar to what I originally did to fix this problem.
But if the commit below fails, you've now changed the non atomic
values, but the atomic values would be reverted back to the original
state so they're out of sync again.  So just moving the set_value calls
to after the commit succeeds might be a better solution.

>   ret = drm_atomic_commit(state);
>   if (ret)



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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


Re: [Intel-gfx] [PATCH 03/16] drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-only

2016-04-08 Thread Imre Deak
On pe, 2016-04-08 at 21:12 +0300, Imre Deak wrote:
> On pe, 2016-04-08 at 21:02 +0300, Ville Syrjälä wrote:
> > On Fri, Apr 01, 2016 at 04:02:34PM +0300, Imre Deak wrote:
> > > This register is read-only, so we have never actually set
> > > OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add
> > > a
> > > code
> > > comment about this. I filed a specification update request to
> > > clarify
> > > this there.
> > 
> > Hmm. Interesting. It's r/w on my CHV, and the PHY spec agrees. Of
> > course
> > I can't really tell whether it has any effect on the x1 PHY. If I
> > set
> > it
> > on the x2 PHY it definitely makes the channel unusable.
> 
> Note that meanwhile the corresponding BSpec change request got
> updated
> to "Confirmed"/"Won't be fixed".

Sorry, it's just "Confirmed".

> > > CC: Arthur J Runyan 
> > > Signed-off-by: Imre Deak 
> > > 
> > > ---
> > > 
> > > [ Art, CC'ing you in case you know if this would have an effect
> > > on
> > >   anything. ]
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 2758622..f91306e 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -1798,6 +1798,9 @@ static void broxton_phy_init(struct
> > > drm_i915_private *dev_priv,
> > >    * enabled.
> > >    * TODO: port C is only connected on BXT-P, so on BXT0/1
> > > we should
> > >    * power down the second channel on PHY0 as well.
> > > +  *
> > > +  * FIXME: Clarify programming of the following, the
> > > register is
> > > +  * read-only with bit 6 fixed at 0 at least in stepping
> > > A.
> > >    */
> > >   if (phy == DPIO_PHY1)
> > >   val |= OCL2_LDOFUSE_PWR_DIS;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 13/16] drm/i915/bxt: Don't reprogram an already enabled DDI PHY

2016-04-08 Thread Ville Syrjälä
On Fri, Apr 01, 2016 at 04:02:44PM +0300, Imre Deak wrote:
> If BIOS has already programmed and enabled a PHY, don't reprogram it as
> that may interfere with the currently active outputs. A follow-up patch
> will add state verification, so we can catch any misconfiguration on
> BIOS's behalf.
> 
> Signed-off-by: Imre Deak 

Looks sane.
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 40 
> 
>  1 file changed, 40 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index d16effd..8f06d6c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1722,12 +1722,52 @@ static void intel_disable_ddi(struct intel_encoder 
> *intel_encoder)
>   }
>  }
>  
> +static bool broxton_phy_is_enabled(struct drm_i915_private *dev_priv,
> +enum dpio_phy phy)
> +{
> + if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & GT_DISPLAY_POWER_ON(phy)))
> + return false;
> +
> + if ((I915_READ(BXT_PORT_CL1CM_DW0(phy)) &
> +  (PHY_POWER_GOOD | PHY_RESERVED)) != PHY_POWER_GOOD) {
> + DRM_DEBUG_DRIVER("DDI PHY %d powered, but power hasn't 
> settled\n",
> +  phy);
> +
> + return false;
> + }
> +
> + if (phy == DPIO_PHY1 &&
> +!(I915_READ(BXT_PORT_REF_DW3(DPIO_PHY1)) & GRC_DONE)) {
> + DRM_DEBUG_DRIVER("DDI PHY 1 powered, but GRC isn't done\n");
> +
> + return false;
> + }
> +
> + if (!(I915_READ(BXT_PHY_CTL_FAMILY(phy)) & COMMON_RESET_DIS)) {
> + DRM_DEBUG_DRIVER("DDI PHY %d powered, but still in reset\n",
> +  phy);
> +
> + return false;
> + }
> +
> + return true;
> +}
> +
>  static void broxton_phy_init(struct drm_i915_private *dev_priv,
>enum dpio_phy phy)
>  {
>   enum port port;
>   u32 ports, val;
>  
> + if (broxton_phy_is_enabled(dev_priv, phy)) {
> + DRM_DEBUG_DRIVER("DDI PHY %d already enabled, "
> +  "won't reprogram it\n", phy);
> +
> + return;
> + }
> +
> + DRM_DEBUG_DRIVER("DDI PHY %d not enabled, enabling it\n", phy);
> +
>   val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
>   val |= GT_DISPLAY_POWER_ON(phy);
>   I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 11/16] drm/i915/bxt: Don't toggle power well 1 on-demand

2016-04-08 Thread Ville Syrjälä
On Fri, Apr 01, 2016 at 04:02:42PM +0300, Imre Deak wrote:
> Power well 1 is managed by the DMC firmware so don't toggle it on-demand
> from the driver. This means we need to follow the BSpec display
> initialization sequence during driver loading and resuming (both system
> and runtime) and enable power well 1 only once there. Afterwards DMC
> will toggle power well 1 whenever entering/exiting DC5.
> 
> For this to work we also need to do away getting the PLL power domain,
> since that just kept runtime PM disabled for good.
> 
> Signed-off-by: Imre Deak 

Make it more like SKL (which also needs more work in this area,
but that's another matter).

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 15 +--
>  drivers/gpu/drm/i915/intel_display.c| 17 
>  drivers/gpu/drm/i915/intel_dpll_mgr.c   |  5 +--
>  drivers/gpu/drm/i915/intel_drv.h|  2 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 75 
> +++--
>  5 files changed, 66 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3998f6a..3f56ddf 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1070,10 +1070,7 @@ static int hsw_suspend_complete(struct 
> drm_i915_private *dev_priv)
>  
>  static int bxt_suspend_complete(struct drm_i915_private *dev_priv)
>  {
> - /* TODO: when DC5 support is added disable DC5 here. */
> -
> - broxton_ddi_phy_uninit(dev_priv);
> - broxton_uninit_cdclk(dev_priv);
> + bxt_display_core_uninit(dev_priv);
>   bxt_enable_dc9(dev_priv);
>  
>   return 0;
> @@ -1081,16 +1078,8 @@ static int bxt_suspend_complete(struct 
> drm_i915_private *dev_priv)
>  
>  static int bxt_resume_prepare(struct drm_i915_private *dev_priv)
>  {
> - /* TODO: when CSR FW support is added make sure the FW is loaded */
> -
>   bxt_disable_dc9(dev_priv);
> -
> - /*
> -  * TODO: when DC5 support is added enable DC5 here if the CSR FW
> -  * is available.
> -  */
> - broxton_init_cdclk(dev_priv);
> - broxton_ddi_phy_init(dev_priv);
> + bxt_display_core_init(dev_priv, true);
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d9da89d..1fbe619 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5442,21 +5442,6 @@ static void broxton_set_cdclk(struct drm_i915_private 
> *dev_priv, int frequency)
>  
>  void broxton_init_cdclk(struct drm_i915_private *dev_priv)
>  {
> - uint32_t val;
> -
> - /*
> -  * NDE_RSTWRN_OPT RST PCH Handshake En must always be 0b on BXT
> -  * or else the reset will hang because there is no PCH to respond.
> -  * Move the handshake programming to initialization sequence.
> -  * Previously was left up to BIOS.
> -  */
> - val = I915_READ(HSW_NDE_RSTWRN_OPT);
> - val &= ~RESET_PCH_HANDSHAKE_ENABLE;
> - I915_WRITE(HSW_NDE_RSTWRN_OPT, val);
> -
> - /* Enable PG1 for cdclk */
> - intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
> -
>   /* check if cd clock is enabled */
>   if (I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_PLL_ENABLE) {
>   DRM_DEBUG_KMS("Display already initialized\n");
> @@ -5493,8 +5478,6 @@ void broxton_uninit_cdclk(struct drm_i915_private 
> *dev_priv)
>  
>   /* Set minimum (bypass) frequency, in effect turning off the DE PLL */
>   broxton_set_cdclk(dev_priv, 19200);
> -
> - intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
>  }
>  
>  static const struct skl_cdclk_entry {
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index fbe88b8..a060b67 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -1644,10 +1644,7 @@ static void intel_ddi_pll_init(struct drm_device *dev)
>   DRM_DEBUG_KMS("Sanitized cdclk programmed by pre-os\n");
>   if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
>   DRM_ERROR("LCPLL1 is disabled\n");
> - } else if (IS_BROXTON(dev)) {
> - broxton_init_cdclk(dev_priv);
> - broxton_ddi_phy_init(dev_priv);
> - } else {
> + } else if (!IS_BROXTON(dev_priv)) {
>   /*
>* The LCPLL register should be turned on by the BIOS. For now
>* let's just check its state and print errors in case
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index e8843a7..4c2083d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1460,6 +1460,8 @@ int intel_power_domains_init(struct drm_i915_private *);
>  void intel_power_domains_fini(struct drm_i915_private *);
>  void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool 
> resume);
>  void intel_power_doma

Re: [Intel-gfx] drm modeset identifiers and xf86-video-intel

2016-04-08 Thread Mark Kettenis
> Date: Thu, 7 Apr 2016 21:49:22 +0100
> From: Chris Wilson 
> 
> On Thu, Apr 07, 2016 at 08:20:15PM +0200, Mark Kettenis wrote:
> > On OpenBSD I implemented idr_alloc() to return random IDs.  While the
> > xf86-video-modesetting driver is perfectly happy with this, the
> > xf86-video-intel driver doesn't like it very much.  I quickly figured
> > out that that driver truncates the identifiers to 8-bits when it
> > stores the values in its sna_crtc data structure.  But the modeset
> > identifiers are clearly 32-bit in the drm API, and the idr_alloc()
> > call that allocates them doesn't limit their values in any way.  So
> > I'd say this is a bug in the xf86-video-intel driver.  Or do people
> > consider it reasonable for the driver to expect the values to be
> > smaller than 256?  Then the drm kernel code should probably specify an
> > upper limit in the idr_alloc call.
> > 
> > Fixing the xf86-video-intel driver isn't completely trivial.  But of
> > people do agree this is something that should be fixed, I'll give it a
> > go.
> 
> Neither does it limit the kernel ABI since it is using inside knowledge
> of how linux works, nor is it difficult to change if you really want to use
> randomised numbers and a hash lookup in the kernel.
> -Chris

Hi Chris,

The main motivation for using the randomised IDs is to make the
numbers returned by the DRM_IOCTL_GEM_FLINK ioctl a little bit harder
to guess.  It seems that in other places, sequential IDs make more
sense.  I do however wonder if it is possible to end up creating more
than 255 modeset objects.  That would cause problems even on Linux.
If there is no such risk, I'll probably change the OpenBSD
implementation of idr_alloc() to do sequential allocations, and use
the randomising allocator only for the identifiers returned by the
DRM_IOCTL_GEM_FLINK ioctl.

Thanks,

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


Re: [Intel-gfx] [PATCH i-g-t v2] test/gem_mocs_settings: Testing MOCS register settings

2016-04-08 Thread Chris Wilson
On Fri, Apr 08, 2016 at 05:44:13PM +0100, Peter Antoine wrote:
> +static int create_read_batch(struct drm_i915_gem_relocation_entry *reloc,
> +  uint32_t *batch,
> +  uint32_t dst_handle,
> +  uint32_t size,
> +  uint32_t reg_base)
> +{
> + unsigned int index;
> + unsigned int offset = 0;
> +
> + for (index = 0, offset = 0; index < size; index++, offset += 4)

offset = 0 twice

> + {
> + batch[offset]   = MI_STORE_REGISTER_MEM_64_BIT_ADDR;
> + batch[offset+1] = reg_base + (index * sizeof(uint32_t));
> + batch[offset+2] = index * sizeof(uint32_t); /* reloc */
> + batch[offset+3] = 0;
> +
> + reloc[index].offset = (offset + 2) * sizeof(uint32_t);
> + reloc[index].delta = index * sizeof(uint32_t);
> + reloc[index].target_handle = dst_handle;

Missed something.

> + }
> +
> + batch[offset++] = MI_BATCH_BUFFER_END;
> + batch[offset++] = 0;
> +
> + return offset * sizeof(uint32_t);
> +}
> +
> +static void do_read_registers(int fd,
> +   uint32_t ctx_id,
> +   uint32_t dst_handle,
> +   uint32_t reg_base,
> +   uint32_t size,
> +   uint32_t engine_id)
> +{
> + struct drm_i915_gem_execbuffer2 execbuf;
> + struct drm_i915_gem_exec_object2 gem_exec[2];
> + struct drm_i915_gem_relocation_entry reloc[MAX_NUMBER_MOCS_REGISTERS];
> + uint32_t batch[MAX_NUMBER_MOCS_REGISTERS * 4 + 4];
> + uint32_t handle = gem_create(fd, 4096);
> +
> + memset(reloc, 0, sizeof(reloc));
> + memset(gem_exec, 0, sizeof(gem_exec));
> + memset(&execbuf, 0, sizeof(execbuf));
> +
> + gem_exec[0].handle = dst_handle;
> + gem_set_domain(fd, dst_handle, I915_GEM_DOMAIN_CPU, 0);

??

> + gem_exec[1].handle = handle;
> + gem_exec[1].relocation_count = size;
> + gem_exec[1].relocs_ptr = (uintptr_t) reloc;
> +
> + execbuf.buffers_ptr = (uintptr_t)gem_exec;
> + execbuf.buffer_count = 2;
> + execbuf.batch_len = create_read_batch(reloc,
> +   batch,
> +   dst_handle,
> +   size,
> +   reg_base);
> +
> + gem_write(fd, handle, 0, batch, execbuf.batch_len);
> +
> + if (ctx_id != 0)
> + i915_execbuffer2_set_context_id(execbuf, ctx_id);

Just set it.

> +
> + execbuf.flags = I915_EXEC_SECURE | engine_id;
> +
> + gem_execbuf(fd, &execbuf);
> + gem_sync(fd, handle);

^ Papering over a bug in your code.

Hint: did you tell anyone that you were writing into the buffer?

> +
> + gem_close(fd, handle);
> +}
> +
> +#define LOCAL_MI_LOAD_REGISTER_IMM   (0x22 << 23)
> +
> +static int create_write_batch(uint32_t *batch,
> +   const uint32_t *values,
> +   uint32_t size,
> +   uint32_t reg_base)
> +{
> + unsigned int i;
> + unsigned int offset = 0;
> +
> + batch[offset++] = LOCAL_MI_LOAD_REGISTER_IMM | (size * 2 - 1);
> +
> + for (i = 0; i < size; i++) {
> + batch[offset++] = reg_base + (i * 4);
> + batch[offset++] = values[i];
> + }
> +
> + batch[offset++] = 0;
> + batch[offset++] = MI_BATCH_BUFFER_END;
> + batch[offset++] = 0;
> +
> + return offset * sizeof(uint32_t);
> +}
> +
> +static void write_registers(int fd,
> + uint32_t ctx_id,
> + uint32_t reg_base,
> + const uint32_t *values,
> + uint32_t size,
> + uint32_t engine_id)
> +{
> + struct drm_i915_gem_exec_object2 gem_exec;
> + struct drm_i915_gem_execbuffer2 execbuf;
> + uint32_t batch[MAX_NUMBER_MOCS_REGISTERS * 4 + 4];
> + uint32_t handle = gem_create(fd, 4096);
> +
> + memset(&gem_exec, 0, sizeof(gem_exec));
> + memset(&execbuf, 0, sizeof(execbuf));
> +
> + gem_exec.handle = handle;
> +
> + execbuf.buffers_ptr = (uintptr_t)&gem_exec;
> + execbuf.buffer_count = 1;
> + execbuf.batch_len = create_write_batch(batch, values, size, reg_base);
> +
> + gem_write(fd, handle, 0, batch, execbuf.batch_len);
> +
> + if (ctx_id != 0)
> + i915_execbuffer2_set_context_id(execbuf, ctx_id);
> +
> + execbuf.flags = I915_EXEC_SECURE | engine_id;
> +
> + gem_execbuf(fd, &execbuf);
> + gem_sync(fd, handle);
> +
> + gem_close(fd, handle);
> +}
> +
> +static void check_control_registers(int fd,
> + const struct intel_execution_engine *engine,
> + uint32_t ctx_id,
> + bool dirty)
> +{
> + uint32_t dst_handle = gem_crea

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: add missing condition for committing planes on crtc

2016-04-08 Thread Patchwork
== Series Details ==

Series: drm/i915: add missing condition for committing planes on crtc
URL   : https://patchwork.freedesktop.org/series/5467/
State : failure

== Summary ==

Series 5467v1 drm/i915: add missing condition for committing planes on crtc
http://patchwork.freedesktop.org/api/1.0/series/5467/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (skl-i7k-2)
pass   -> DMESG-WARN (bdw-ultra)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (bsw-nuc-2)
pass   -> FAIL   (ivb-t430s)
pass   -> DMESG-FAIL (bdw-ultra)
pass   -> FAIL   (skl-i7k-2)
pass   -> FAIL   (byt-nuc)
pass   -> FAIL   (snb-x220t)
pass   -> FAIL   (snb-dellxps)
pass   -> FAIL   (hsw-brixbox)
pass   -> DMESG-FAIL (bdw-nuci7)
skip   -> FAIL   (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup hang-read-crc-pipe-b:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup hang-read-crc-pipe-c:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-c:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-b:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-c:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (bdw-nuci7)
pass   -> DMESG-WARN (bdw-ultra)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (bdw-ultra)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: atomic: fix legacy gamma set helper

2016-04-08 Thread Patchwork
== Series Details ==

Series: drm: atomic: fix legacy gamma set helper
URL   : https://patchwork.freedesktop.org/series/5471/
State : warning

== Summary ==

Series 5471v1 drm: atomic: fix legacy gamma set helper
http://patchwork.freedesktop.org/api/1.0/series/5471/revisions/1/mbox/

Test gem_exec_basic:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-bsd:
dmesg-warn -> PASS   (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (snb-x220t)
Subgroup force-load-detect:
pass   -> SKIP   (snb-x220t)
Subgroup prune-stale-modes:
pass   -> SKIP   (ivb-t430s)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (byt-nuc)
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:196  pass:160  dwarn:1   dfail:0   fail:0   skip:35 
hsw-brixbox  total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
ilk-hp8440p  total:196  pass:131  dwarn:1   dfail:0   fail:0   skip:64 
ivb-t430stotal:196  pass:170  dwarn:0   dfail:0   fail:0   skip:26 
skl-i7k-2total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:196  pass:162  dwarn:0   dfail:0   fail:0   skip:34 
snb-x220ttotal:196  pass:160  dwarn:0   dfail:0   fail:1   skip:35 

Results at /archive/results/CI_IGT_test/Patchwork_1851/

949884a57b51aa158e3ae9afe1f08130cdb7a3ef drm-intel-nightly: 
2016y-04m-08d-10h-45m-28s UTC integration manifest
ff2301ce4c39a6e755adac9f45225f4e1648336f drm: atomic: fix legacy gamma set 
helper

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