[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Support to enable TRTT on GEN9 (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915: Support to enable TRTT on GEN9 (rev5)
URL   : https://patchwork.freedesktop.org/series/2321/
State : failure

== Summary ==

  CC  drivers/usb/storage/usual-tables.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mbx.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_i210.o
  LD  drivers/usb/host/xhci-hcd.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_ptp.o
  CC [M]  drivers/net/ethernet/intel/e1000/e1000_hw.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_hwmon.o
  CC [M]  drivers/net/ethernet/intel/e1000/e1000_ethtool.o
  LD  drivers/usb/host/built-in.o
  CC [M]  drivers/net/ethernet/intel/e1000e/80003es2lan.o
  CC [M]  drivers/net/ethernet/intel/e1000/e1000_param.o
  CC [M]  drivers/net/ethernet/intel/e1000e/mac.o
  CC [M]  drivers/net/ethernet/intel/e1000e/manage.o
  LD  drivers/usb/storage/usb-storage.o
  LD  drivers/usb/storage/built-in.o
  LD  drivers/usb/built-in.o
  CC [M]  drivers/net/ethernet/intel/e1000e/nvm.o
  CC [M]  drivers/net/ethernet/intel/e1000e/phy.o
  CC [M]  drivers/net/ethernet/intel/e1000e/param.o
  CC [M]  drivers/net/ethernet/intel/e1000e/ethtool.o
  CC [M]  drivers/net/ethernet/intel/e1000e/netdev.o
  CC [M]  drivers/net/ethernet/intel/e1000e/ptp.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:950: 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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/skl: SKL CDCLK change on modeset tracking VCO (rev7)

[Patchwork]

== Series Details ==

Series: drm/i915/skl: SKL CDCLK change on modeset tracking VCO (rev7)
URL   : https://patchwork.freedesktop.org/series/1609/
State : warning

== Summary ==

Series 1609v7 drm/i915/skl: SKL CDCLK change on modeset tracking VCO
http://patchwork.freedesktop.org/api/1.0/series/1609/revisions/7/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (ilk-hp8440p)
Test gem_ringfill:
Subgroup basic-default-s3:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-plain-flip:
dmesg-warn -> PASS   (hsw-gt2)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (bdw-ultra)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (snb-dellxps)
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7total:193  pass:181  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:193  pass:171  dwarn:1   dfail:0   fail:0   skip:21 
bsw-nuc-2total:193  pass:154  dwarn:2   dfail:0   fail:0   skip:37 
byt-nuc  total:193  pass:158  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:193  pass:169  dwarn:2   dfail:0   fail:0   skip:22 
hsw-gt2  total:193  pass:176  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:193  pass:129  dwarn:1   dfail:0   fail:0   skip:63 
skl-i5k-2total:193  pass:170  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:193  pass:170  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:193  pass:157  dwarn:2   dfail:0   fail:0   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1555/

ab403b26610034afe0e0c97d960782bad98b97d0 drm-intel-nightly: 
2016y-03m-09d-09h-25m-31s UTC integration manifest
b2f7da9e8179722e64f851a2cd28cd0cc7b135e3 drm/i915/skl: SKL CDCLK change on 
modeset tracking VCO

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

[Intel-gfx] [PATCH v5] drm/i915: Support to enable TRTT on GEN9

[akash . goel]

From: Akash Goel 

Gen9 has an additional address translation hardware support in form of
Tiled Resource Translation Table (TR-TT) which provides an extra level
of abstraction over PPGTT.
This is useful for mapping Sparse/Tiled texture resources.
Sparse resources are created as virtual-only allocations. Regions of the
resource that the application intends to use is bound to the physical memory
on the fly and can be re-bound to different memory allocations over the
lifetime of the resource.

TR-TT is tightly coupled with PPGTT, a new instance of TR-TT will be required
for a new PPGTT instance, but TR-TT may not enabled for every context.
1/16th of the 48bit PPGTT space is earmarked for the translation by TR-TT,
which such chunk to use is conveyed to HW through a register.
Any GFX address, which lies in that reserved 44 bit range will be translated
through TR-TT first and then through PPGTT to get the actual physical address,
so the output of translation from TR-TT will be a PPGTT offset.

TRTT is constructed as a 3 level tile Table. Each tile is 64KB is size which
leaves behind 44-16=28 address bits. 28bits are partitioned as 9+9+10, and
each level is contained within a 4KB page hence L3 and L2 is composed of
512 64b entries and L1 is composed of 1024 32b entries.

There is a provision to keep TR-TT Tables in virtual space, where the pages of
TRTT tables will be mapped to PPGTT.
Currently this is the supported mode, in this mode UMD will have a full control
on TR-TT management, with bare minimum support from KMD.
So the entries of L3 table will contain the PPGTT offset of L2 Table pages,
similarly entries of L2 table will contain the PPGTT offset of L1 Table pages.
The entries of L1 table will contain the PPGTT offset of BOs actually backing
the Sparse resources.
UMD will have to allocate the L3/L2/L1 table pages as a regular BO only &
assign them a PPGTT address through the Soft Pin API (for example, use soft pin
to assign l3_table_address to the L3 table BO, when used).
UMD will also program the entries in the TR-TT page tables using regular batch
commands (MI_STORE_DATA_IMM), or via mmapping of the page table BOs.
UMD may do the complete PPGTT address space management, on the pretext that it
could help minimize the conflicts.

Any space in TR-TT segment not bound to any Sparse texture, will be handled
through Invalid tile, User is expected to initialize the entries of a new
L3/L2/L1 table page with the Invalid tile pattern. The entries corresponding to
the holes in the Sparse texture resource will be set with the Null tile pattern
The improper programming of TRTT should only lead to a recoverable GPU hang,
eventually leading to banning of the culprit context without victimizing others.

The association of any Sparse resource with the BOs will be known only to UMD,
and only the Sparse resources shall be assigned an offset from the TR-TT segment
by UMD. The use of TR-TT segment or mapping of Sparse resources will be
transparent to the KMD, UMD will do the address assignment from TR-TT segment
autonomously and KMD will be oblivious of it.
Any object must not be assigned an address from TR-TT segment, they will be
mapped to PPGTT in a regular way by KMD.

This patch provides an interface through which UMD can convey KMD to enable
TR-TT for a given context. A new I915_CONTEXT_PARAM_TRTT param has been
added to I915_GEM_CONTEXT_SETPARAM ioctl for that purpose.
UMD will have to pass the GFX address of L3 table page, start location of TR-TT
segment alongwith the pattern value for the Null & invalid Tile registers.

v2:
 - Support context_getparam for TRTT also and dispense with a separate
   GETPARAM case for TRTT (Chris).
 - Use i915_dbg to log errors for the invalid TRTT ABI parameters passed
   from user space (Chris).
 - Move all the argument checking for TRTT in context_setparam to the
   set_trtt function (Chris).
 - Change the type of 'flags' field inside 'intel_context' to unsigned (Chris)
 - Rename certain functions to rightly reflect their purpose, rename
   the new param for TRTT in gem_context_param to I915_CONTEXT_PARAM_TRTT,
   rephrase few lines in the commit message body, add more comments (Chris).
 - Extend ABI to allow User specify TRTT segment location also.
 - Fix for selective enabling of TRTT on per context basis, explicitly
   disable TR-TT at the start of a new context.

v3:
 - Check the return value of gen9_emit_trtt_regs (Chris)
 - Update the kernel doc for intel_context structure.
 - Rebased.

v4:
 - Fix the warnings reported by 'checkpatch.pl --strict' (Michel)
 - Fix the context_getparam implementation avoiding the reset of size field,
   affecting the TRTT case.

v5:
 - Update the TR-TT params right away in context_setparam, by constructing
   & submitting a request emitting LRIs, instead of deferring it and
   conflating with the next batch submission (Chris)
 - Follow the struct_mutex handling related prescribed rules, while accessing
   User space buffer, 

Re: [Intel-gfx] [iGVT-g] Ask for comments of getting guest framebuffer in igvt-g

[Tian, Kevin]

> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Tuesday, March 08, 2016 4:37 PM
> 
>   Hi,
> 
> > btw I don't think this vblank issue would be very significant. The main
> > targeted usage of GVT-g is for server virtualization/cloud, where
> > a remoting protocol is required for customer to see the content through
> > network.
> 
> The plan for that is to let the gpu video encoder process the guest
> framebuffer.  So the video encoder still being busy processing the
> buffer while the guest already started updating it can certainly lead to
> visible tearing.
> 
> I think using vblank to signal the guest when the host is done
> processing the framebuffer makes sense.  It'll simply throttle the guest
> in case the host is too busy to keep up.

Thanks Gerd for elaborating this part. We can have this requirement
considered once this new interface is agreed here. There may need
more consideration how to align "host is done processing" with virtual
vblank delivery. 

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

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Dave Airlie]

>
> To sum up, and if we take the above patches into consideration:
> - on boot, one or more GPUs are powered on, an init script would queue
> a GPU switch to the integrated one. The other GPU would be switched off
> (automatically?)
> - when X/wayland is running, queue the requests using DIGD or DDIS. If
> the integrated GPU is used, allow offloading to the discrete GPU with
> DRI_PRIME (which will again power up automatically thanks to the
> runtime PM patches above).

> My concerns here would be:
> - Do we know how to turn off the integrated GPU automatically, if the
> user only used the internal screen and wanted to use the discrete GPU?
> - If only the discrete GPU is powered on, do we know how to power on
> the integrated GPU so it can drive the external screen when plugged in?
> - While plymouth is short-lived at boot, Wayland and X11 GNOME sessions
> use the GPU. The first user session will run on a VT that's separate
> from the greeter to implement fast-user switching. So, if we wanted to
> force using the other GPU for future sessions, we'd need to tell gdm to
> kill its graphical session and to respawn it so it doesn't hog the GPU
> and avoid the switch happening. Correct?
>
> FWIW, this is what I had written down a couple of months ago, about
> supporting dual-GPU computers with GNOME:
> https://wiki.gnome.org/Design/OS/DualGPU
>
> Those use-cases are a lot simpler than what could be achieved with the
> vga_switcheroo sub-system, but they probably cover the "90%" use cases
> we're interested in.
>
> Once I've managed to get the MacBook Pro into a good state, I also have
> a Lenovo machine around with dual GPU, though I couldn't tell you what
> the discrete one is.

Okay so I'm not sure you are heading in the best direction here.

My first suggestion is to stop using the MBP, start using the Lenovo.
At least from a Fedora perspective, that is the hw we have more installs of and
care more about.

Apple HW is not the same as PC hw in this case and we aren't going to achieve
the same level of integration that OSX has, not without some serious rewrites of
mutter and the whole X stack.

You shouldn't be caring about the MUX. MUXed hw apart from the MBP is pretty
much gone since Windows 7 timeframes. So I don't think we should be putting
too much effort into the MUX yet. With the current way we keep gdm running,
we can't do MUX switch on logout anymore. It was only ever a hack. So I'd just
not send commands to vga switcheroo at all.

So I'm missing what the overall goal here is. To provide better
support for dual-gpu
laptops and hotpluggable USB devices in the DE?

Under X, Fedora carries a server patch to autoconfigure providers,
we'd need to drop
that and have something in the DE notice when a new provider shows up
and configures it,
perhaps something to allow removal of providers that are already bound
(so we could detach
a secondary GPU for boxes to passthrough).

Then we need something in the DE to allow us to launch or have some
app info that would
decide to launch certain 3D using apps on the more powerful processor.
However since
nouveau doesn't quite reclock most of the secondary GPUs that can
often end up not being
that much more powerful.

We also want reverse prime to work properly, so if you plug in an
external monitor to
a port connected to the secondary GPU that we can pick it up and
configure it just like
all the other monitors.

As for the MBP, if we want to spend time chasing the rainbow of OS X,
then we've a lot of work
to do. OSX can smoothly switch the compositor from rendering on the
intel gpu to the nvidia
gpu in a vblank. It's truly seamless. To do that we'd need to a) move
to wayland, b) get mutter
to be a lot smarter than mutter currently is.

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

[Intel-gfx] [PATCH V8] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

[clinton . a . taylor]

From: Clint Taylor 

WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected
to DDI1 the system will hard hang during a cold boot. Occurs when DDI1
is enabled when the cdclk is less then required. DP connected to DDI2
and HPD on either port works correctly.

Set cdclk based on the max required pixel clock based on VCO
selected. Track boot vco instead of boot cdclk.

The vco is now tracked at the atomic level and all CRTCs updated if
the required vco is changed. Not tested with eDP v1.4 panels that
require 8640 vco due to availability.

V1: initial version
V2: add vco tracking in intel_dp_compute_config(), rename
skl_boot_cdclk.
V3: rebase, V2 feedback not possible as encoders are not aware of
atomic.
V4: track target vco is atomic state. modeset all CRTCs if vco changes
V5: rename atomic variable, cleaner if/else logic, use existing vco if
  encoder does not return a new vco value. check_patch.pl cleanup
V6: simplify logic in intel_modeset_checks.
V7: reorder an IF for readability and whitespace fix.
V8: use dev_cdclk for tracking new cdclk during atomic

Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/i915/i915_drv.h  |2 +-
 drivers/gpu/drm/i915/intel_ddi.c |2 +-
 drivers/gpu/drm/i915/intel_display.c |  109 +-
 drivers/gpu/drm/i915/intel_dp.c  |5 ++
 drivers/gpu/drm/i915/intel_drv.h |5 ++
 5 files changed, 105 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f37ac12..83bb3fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1833,7 +1833,7 @@ struct drm_i915_private {
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
 
unsigned int fsb_freq, mem_freq, is_ddr3;
-   unsigned int skl_boot_cdclk;
+   unsigned int skl_vco_freq;
unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
unsigned int max_dotclk_freq;
unsigned int rawclk_freq;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 62de9f4..f628647 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3003,7 +3003,7 @@ void intel_ddi_pll_init(struct drm_device *dev)
int cdclk_freq;
 
cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
-   dev_priv->skl_boot_cdclk = cdclk_freq;
+   dev_priv->skl_vco_freq = skl_cdclk_get_vco(cdclk_freq);
if (skl_sanitize_cdclk(dev_priv))
DRM_DEBUG_KMS("Sanitized cdclk programmed by pre-os\n");
if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 62d36a7..10cdeb7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5811,7 +5811,7 @@ static unsigned int skl_cdclk_decimal(unsigned int freq)
return (freq - 1000) / 500;
 }
 
-static unsigned int skl_cdclk_get_vco(unsigned int freq)
+unsigned int skl_cdclk_get_vco(unsigned int freq)
 {
unsigned int i;
 
@@ -5969,17 +5969,21 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
 
 void skl_init_cdclk(struct drm_i915_private *dev_priv)
 {
-   unsigned int required_vco;
+   unsigned int cdclk;
 
/* DPLL0 not enabled (happens on early BIOS versions) */
if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE)) {
/* enable DPLL0 */
-   required_vco = skl_cdclk_get_vco(dev_priv->skl_boot_cdclk);
-   skl_dpll0_enable(dev_priv, required_vco);
+   if (dev_priv->skl_vco_freq != 8640)
+   dev_priv->skl_vco_freq = 8100;
+   skl_dpll0_enable(dev_priv, dev_priv->skl_vco_freq);
+   cdclk = ((dev_priv->skl_vco_freq == 8100) ? 337500 : 308570);
+   } else {
+   cdclk = dev_priv->cdclk_freq;
}
 
-   /* set CDCLK to the frequency the BIOS chose */
-   skl_set_cdclk(dev_priv, dev_priv->skl_boot_cdclk);
+   /* set CDCLK to the lowest frequency, Modeset follows */
+   skl_set_cdclk(dev_priv, cdclk);
 
/* enable DBUF power */
I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
@@ -5995,7 +5999,7 @@ int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
 {
uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
uint32_t cdctl = I915_READ(CDCLK_CTL);
-   int freq = dev_priv->skl_boot_cdclk;
+   int freq = dev_priv->cdclk_freq;
 
/*
 * check if the pre-os intialized the display
@@ -6019,11 +6023,7 @@ int skl_sanitize_cdclk(struct drm_i915_private *dev_priv)
/* All well; nothing to sanitize */
return false;
 sanitize:
-   /*
-* As of now initialize with max cdclk till
-* we get dynamic cdclk support
-* 

Re: [Intel-gfx] [PATCH] drm/i915: add sanity check for partial view creation

[Matthew Auld]

> If this concerns you that, please look at the API,
and please review the outstanding patches.

Could you elaborate on this please?
What patches are you referring to?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: implement WaClearTdlStateAckDirtyBits

[kbuild test robot]

Hi Tim,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.5-rc7 next-20160309]
[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/tim-gore-intel-com/drm-i915-implement-WaClearTdlStateAckDirtyBits/20160310-004816
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_lrc.c: In function 'gen9_init_perctx_bb':
>> drivers/gpu/drm/i915/intel_lrc.c:1216:18: error: incompatible types when 
>> assigning to type 'uint32_t' from type 'i915_reg_t'
  batch[__index] = (cmd); \
 ^
   drivers/gpu/drm/i915/intel_lrc.c:1463:3: note: in expansion of macro 
'wa_ctx_emit'
  wa_ctx_emit(batch, index, GEN7_ROW_CHICKEN2);
  ^

vim +1216 drivers/gpu/drm/i915/intel_lrc.c

83b8a982 Arun Siluvery 2015-07-08  1210  #define wa_ctx_emit(batch, index, cmd) 
\
17ee950d Arun Siluvery 2015-06-19  1211 do {
\
83b8a982 Arun Siluvery 2015-07-08  1212 int __index = 
(index)++;\
83b8a982 Arun Siluvery 2015-07-08  1213 if (WARN_ON(__index >= 
(PAGE_SIZE / sizeof(uint32_t { \
17ee950d Arun Siluvery 2015-06-19  1214 return -ENOSPC; 
\
17ee950d Arun Siluvery 2015-06-19  1215 }   
\
83b8a982 Arun Siluvery 2015-07-08 @1216 batch[__index] = (cmd); 
\
17ee950d Arun Siluvery 2015-06-19  1217 } while (0)
17ee950d Arun Siluvery 2015-06-19  1218  
8f40db77 Ville Syrjälä 2015-11-04  1219  #define wa_ctx_emit_reg(batch, index, 
reg) \

:: The code at line 1216 was first introduced by commit
:: 83b8a982b101c48fc025066a7b08beaf6fa756f0 drm/i915: Update wa_ctx_emit() 
macro as per kernel coding guidelines

:: TO: Arun Siluvery <arun.siluv...@linux.intel.com>
:: CC: Daniel Vetter <daniel.vet...@ffwll.ch>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
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 drm/i915: CHV regressions fixes

[Ville Syrjälä]

On Wed, Mar 09, 2016 at 05:31:34PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: CHV regressions fixes
> URL   : https://patchwork.freedesktop.org/series/4283/
> State : failure
> 
> == Summary ==
> 
> Series 4283v1 drm/i915: CHV regressions fixes
> http://patchwork.freedesktop.org/api/1.0/series/4283/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (ilk-hp8440p)
> Test kms_flip:
> Subgroup basic-flip-vs-modeset:
> dmesg-warn -> PASS   (bdw-ultra)
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> FAIL   (byt-nuc)

(kms_flip:6823) DEBUG: name = flip
last_ts = 282.573849 usec
last_received_ts = 282.573600 usec
last_seq = 6777
current_ts = 282.757264 usec
current_received_ts = 282.757213 usec
current_seq = 6788
count = 77
seq_step = 1
(kms_flip:6823) CRITICAL: Test assertion failure function check_state, file 
kms_flip.c:692:
(kms_flip:6823) CRITICAL: Failed assertion: fabsdouble) diff.tv_usec) - 
usec_interflip) / usec_interflip) <= 0.005
(kms_flip:6823) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_flip:6823) CRITICAL: inter-flip ts jitter: 0s, 183415usec

The more mysterious seq_step==1 variant this time:
https://bugs.freedesktop.org/show_bug.cgi?id=94294

> Subgroup basic-plain-flip:
> dmesg-warn -> PASS   (hsw-gt2)
> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-b-frame-sequence:
> dmesg-warn -> PASS   (hsw-brixbox)
> Subgroup read-crc-pipe-a-frame-sequence:
> pass   -> DMESG-WARN (bdw-nuci7)

[  335.334105]  [] gen8_write32+0x26c/0x300 [i915]
[  335.334136]  [] _ilk_disable_lp_wm+0x98/0xd0 [i915]
[  335.334170]  [] ilk_program_watermarks+0x4bd/0x980 [i915]

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

> Subgroup read-crc-pipe-c-frame-sequence:
> pass   -> DMESG-WARN (hsw-gt2)

[  569.813901]  [] hsw_write32+0x21b/0x270 [i915]
[  569.813912]  [] _ilk_disable_lp_wm+0x98/0xd0 [i915]
[  569.813923]  [] ilk_program_watermarks+0x4bd/0x980 [i915]

same

> 
> bdw-nuci7total:193  pass:180  dwarn:1   dfail:0   fail:0   skip:12 
> bdw-ultratotal:193  pass:172  dwarn:0   dfail:0   fail:0   skip:21 
> byt-nuc  total:193  pass:157  dwarn:0   dfail:0   fail:1   skip:35 
> hsw-brixbox  total:193  pass:171  dwarn:0   dfail:0   fail:0   skip:22 
> hsw-gt2  total:193  pass:175  dwarn:1   dfail:0   fail:0   skip:17 
> ilk-hp8440p  total:193  pass:130  dwarn:0   dfail:0   fail:0   skip:63 
> skl-i5k-2total:193  pass:170  dwarn:0   dfail:0   fail:0   skip:23 
> skl-i7k-2total:193  pass:170  dwarn:0   dfail:0   fail:0   skip:23 
> snb-dellxps  total:193  pass:158  dwarn:1   dfail:0   fail:0   skip:34 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1554/
> 
> ab403b26610034afe0e0c97d960782bad98b97d0 drm-intel-nightly: 
> 2016y-03m-09d-09h-25m-31s UTC integration manifest
> 0434f7d5769d4ae80fde59476b129fcf8653d655 drm/i915: 
> s/crtc_state/old_crtc_state/ in intel_atomic_commit()
> 9265370d045306f483b6af65948ef8f5d17e5dc8 drm/i915: Wait for vblank after cxsr 
> disable in pre_plane_update
> cbd2f01aa943825becbe92fb126e3b3a67bf49a2 drm/i915: Fix watermarks for VLV/CHV
> a4713d57b76d75fb527f3b802ec88e950f3cbac6 drm/i915: Pass the correct crtc 
> state to .update_plane()
> fe2c89bbb4a7bffcf8f046c396b132075ab96693 Revert "drm/i915: Enable PSR by 
> default on Valleyview and Cherryview."

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: CHV regressions fixes

[Patchwork]

== Series Details ==

Series: drm/i915: CHV regressions fixes
URL   : https://patchwork.freedesktop.org/series/4283/
State : failure

== Summary ==

Series 4283v1 drm/i915: CHV regressions fixes
http://patchwork.freedesktop.org/api/1.0/series/4283/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (byt-nuc)
Subgroup basic-plain-flip:
dmesg-warn -> PASS   (hsw-gt2)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (bdw-nuci7)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> DMESG-WARN (hsw-gt2)

bdw-nuci7total:193  pass:180  dwarn:1   dfail:0   fail:0   skip:12 
bdw-ultratotal:193  pass:172  dwarn:0   dfail:0   fail:0   skip:21 
byt-nuc  total:193  pass:157  dwarn:0   dfail:0   fail:1   skip:35 
hsw-brixbox  total:193  pass:171  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:193  pass:175  dwarn:1   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:193  pass:130  dwarn:0   dfail:0   fail:0   skip:63 
skl-i5k-2total:193  pass:170  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:193  pass:170  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:193  pass:158  dwarn:1   dfail:0   fail:0   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1554/

ab403b26610034afe0e0c97d960782bad98b97d0 drm-intel-nightly: 
2016y-03m-09d-09h-25m-31s UTC integration manifest
0434f7d5769d4ae80fde59476b129fcf8653d655 drm/i915: s/crtc_state/old_crtc_state/ 
in intel_atomic_commit()
9265370d045306f483b6af65948ef8f5d17e5dc8 drm/i915: Wait for vblank after cxsr 
disable in pre_plane_update
cbd2f01aa943825becbe92fb126e3b3a67bf49a2 drm/i915: Fix watermarks for VLV/CHV
a4713d57b76d75fb527f3b802ec88e950f3cbac6 drm/i915: Pass the correct crtc state 
to .update_plane()
fe2c89bbb4a7bffcf8f046c396b132075ab96693 Revert "drm/i915: Enable PSR by 
default on Valleyview and Cherryview."

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

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Move load time display/audio callback init earlier

[kbuild test robot]

Hi Imre,

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20160309]
[cannot apply to v4.5-rc7]
[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/Imre-Deak/drm-i915-Move-some-load-time-init-steps-earlier/20160309-233629
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/drm/drm_crtc.h:2144: warning: No description found for parameter 
'allow_fb_modifiers'
   include/drm/drm_dp_helper.h:749: warning: No description found for parameter 
'i2c_nack_count'
   include/drm/drm_dp_helper.h:749: warning: No description found for parameter 
'i2c_defer_count'
   drivers/gpu/drm/drm_dp_mst_topology.c:2364: warning: No description found 
for parameter 'connector'
   include/drm/drm_dp_mst_helper.h:92: warning: No description found for 
parameter 'cached_edid'
   include/drm/drm_dp_mst_helper.h:92: warning: No description found for 
parameter 'has_audio'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'max_dpcd_transaction_bytes'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'sink_count'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'total_slots'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'avail_slots'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'total_pbn'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'qlock'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'tx_msg_downq'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'tx_down_in_progress'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'payload_lock'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'proposed_vcpis'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'payloads'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'payload_mask'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'vcpi_mask'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'tx_waitq'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'work'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'tx_work'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'destroy_connector_list'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'destroy_connector_lock'
   include/drm/drm_dp_mst_helper.h:466: warning: No description found for 
parameter 'destroy_connector_work'
   drivers/gpu/drm/drm_dp_mst_topology.c:2364: warning: No description found 
for parameter 'connector'
   drivers/gpu/drm/drm_irq.c:176: warning: No description found for parameter 
'flags'
   include/drm/drmP.h:168: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:184: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:202: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:247: warning: No description found for parameter 'dev'
   include/drm/drmP.h:247: warning: No description found for parameter 'data'
   include/drm/drmP.h:247: warning: No description found for parameter 
'file_priv'
   include/drm/drmP.h:280: warning: No description found for parameter 'ioctl'
   include/drm/drmP.h:280: warning: No description found for parameter '_func'
   include/drm/drmP.h:280: warning: No description found for parameter '_flags'
   include/drm/drmP.h:362: warning: cannot understand function prototype: 
'struct drm_lock_data '
   include/drm/drmP.h:415: warning: cannot understand function prototype: 
'struct drm_driver '
   include/drm/drmP.h:672: warning: cannot understand function prototype: 
'struct drm_info_list '
   include/drm/drmP.h:682: warning: cannot understand function prototype: 
'struct drm_info_node '
   include/drm/drmP.h:692: warning: cannot understand function prototype: 
'struct drm_minor '
   include/drm/drmP.h:740: warning: cannot understand function prototype: 
'struct drm_device '
   drivers/gpu/drm/i915/intel_runtime_pm.c:2269: warning: No description found 
for parameter 'resume'
   drivers/gpu/drm/i915/intel_runtime_pm.c:2269: warning: No description found 
for parameter 'resume'
   drivers/gpu/drm/i915/i915_irq.c:2665: warning: No description found for 
parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2665: warning: No description found for 
parameter 'fmt'
   drivers/gpu/drm/i915/i915_irq.c:2665: warning: No description found for 
parameter 'wedged'
   drivers/gpu/dr

Re: [Intel-gfx] [PATCH 1/5] Revert "drm/i915: Enable PSR by default on Valleyview and Cherryview."

[Vivi, Rodrigo]

Acked-by: Rodrigo Vivi 

I confirm this is hitting BAT hard on CHV.

I'm working here to handle this PSR exit on VBlanks on CHV already, but
the vblanks spinlocks are giving me headaches... 

So better to revert.

thanks for the finding, ideas and this revert...

On Wed, 2016-03-09 at 19:07 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> This reverts commit a38c274faad0ec6aba692e294ec751d04dbba803.
> 
> PSR causes all sorts of vblank wait timeouts and whanot on CHV.
> Disable
> it again.
> 
> Cc: Rodrigo Vivi 
> Fixes: a38c274faad0 ("drm/i915: Enable PSR by default on Valleyview
> and Cherryview.")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index b1413beb00d1..38e95185d9c6 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -781,8 +781,7 @@ void intel_psr_init(struct drm_device *dev)
>  
>   /* Per platform default */
>   if (i915.enable_psr == -1) {
> - if (IS_HASWELL(dev) || IS_BROADWELL(dev) ||
> - IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
> + if (IS_HASWELL(dev) || IS_BROADWELL(dev))
>   i915.enable_psr = 1;
>   else
>   i915.enable_psr = 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/5] drm/i915: s/crtc_state/old_crtc_state/ in intel_atomic_commit()

[ville . syrjala]

From: Ville Syrjälä 

Avoid some head spinning by renaming the crtc_state variable to
old_crtc_state.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a76ba22ee711..c68964243b99 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13705,7 +13705,7 @@ static int intel_atomic_commit(struct drm_device *dev,
 {
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_state *old_crtc_state;
struct drm_crtc *crtc;
struct intel_crtc_state *intel_cstate;
int ret = 0, i;
@@ -13731,7 +13731,7 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
}
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 
if (needs_modeset(crtc->state) ||
@@ -13746,10 +13746,10 @@ static int intel_atomic_commit(struct drm_device *dev,
if (!needs_modeset(crtc->state))
continue;
 
-   intel_pre_plane_update(to_intel_crtc_state(crtc_state));
+   intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
 
-   if (crtc_state->active) {
-   intel_crtc_disable_planes(crtc, crtc_state->plane_mask);
+   if (old_crtc_state->active) {
+   intel_crtc_disable_planes(crtc, 
old_crtc_state->plane_mask);
dev_priv->display.crtc_disable(crtc);
intel_crtc->active = false;
intel_fbc_disable(intel_crtc);
@@ -13782,7 +13782,7 @@ static int intel_atomic_commit(struct drm_device *dev,
}
 
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
struct intel_crtc_state *pipe_config =
@@ -13795,14 +13795,14 @@ static int intel_atomic_commit(struct drm_device *dev,
}
 
if (!modeset)
-   intel_pre_plane_update(to_intel_crtc_state(crtc_state));
+   
intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
 
if (crtc->state->active && intel_crtc->atomic.update_fbc)
intel_fbc_enable(intel_crtc);
 
if (crtc->state->active &&
(crtc->state->planes_changed || update_pipe))
-   drm_atomic_helper_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))
crtc_vblank_mask |= 1 << i;
@@ -13813,7 +13813,7 @@ static int intel_atomic_commit(struct drm_device *dev,
if (!state->legacy_cursor_update)
intel_atomic_wait_for_vblanks(dev, dev_priv, crtc_vblank_mask);
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
intel_post_plane_update(to_intel_crtc(crtc));
 
if (put_domains[i])
@@ -13830,7 +13830,7 @@ static int intel_atomic_commit(struct drm_device *dev,
 *
 * TODO: Move this (and other cleanup) to an async worker eventually.
 */
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
intel_cstate = to_intel_crtc_state(crtc->state);
 
if (dev_priv->display.optimize_watermarks)
-- 
2.4.10

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

[Intel-gfx] [PATCH 3/5] drm/i915: Fix watermarks for VLV/CHV

[ville . syrjala]

From: Ville Syrjälä 

commit 92826fcdfc14 ("drm/i915: Calculate watermark related members in the 
crtc_state, v4.")
broke thigns by removing the pre vs. post wm update distinction. We also
lost the pre plane wm update entirely for VLV/CHV from the crtc enable
path.

This caused underruns on modeset and plane enable/disable on CHV,
and often those can lead to a dead pipe.

So let's bring back the pre vs. post thing, and let's toss in an
explicit wm update to valleyview_crtc_enable() to avoid having to
put it into the common code.

This is more or less a partial revert of the offending commit.

Cc: Maarten Lankhorst 
Cc: drm-intel-fi...@lists.freedesktop.org
Fixes: 92826fcdfc14 ("drm/i915: Calculate watermark related members in the 
crtc_state, v4.")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic.c  |  3 ++-
 drivers/gpu/drm/i915/intel_display.c | 29 +++--
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 3 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 6a661e796328..79448f1c8b8d 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -96,7 +96,8 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state->update_pipe = false;
crtc_state->disable_lp_wm = false;
crtc_state->disable_cxsr = false;
-   crtc_state->wm_changed = false;
+   crtc_state->update_wm_pre = false;
+   crtc_state->update_wm_post = false;
crtc_state->fb_changed = false;
crtc_state->wm.need_postvbl_update = false;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 62d36a7b3398..8b44e0652740 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4919,7 +4919,7 @@ static void intel_post_plane_update(struct intel_crtc 
*crtc)
 
crtc->wm.cxsr_allowed = true;
 
-   if (pipe_config->wm_changed && pipe_config->base.active)
+   if (pipe_config->update_wm_post && pipe_config->base.active)
intel_update_watermarks(>base);
 
if (atomic->update_fbc)
@@ -5001,7 +5001,7 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state)
 */
if (dev_priv->display.initial_watermarks != NULL)
dev_priv->display.initial_watermarks(pipe_config);
-   else if (pipe_config->wm_changed)
+   else if (pipe_config->update_wm_pre)
intel_update_watermarks(>base);
 }
 
@@ -6372,6 +6372,7 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
 
intel_crtc_load_lut(crtc);
 
+   intel_update_watermarks(crtc);
intel_enable_pipe(intel_crtc);
 
assert_vblank_disabled(crtc);
@@ -11994,19 +11995,27 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
 plane->base.id, was_visible, visible,
 turn_off, turn_on, mode_changed);
 
-   if (turn_on || turn_off) {
-   pipe_config->wm_changed = true;
+   if (turn_on) {
+   pipe_config->update_wm_pre = true;
+
+   /* must disable cxsr around plane enable/disable */
+   if (plane->type != DRM_PLANE_TYPE_CURSOR)
+   pipe_config->disable_cxsr = true;
+   } else if (turn_off) {
+   pipe_config->update_wm_post = true;
 
/* must disable cxsr around plane enable/disable */
if (plane->type != DRM_PLANE_TYPE_CURSOR)
pipe_config->disable_cxsr = true;
} else if (intel_wm_need_update(plane, plane_state)) {
-   pipe_config->wm_changed = true;
+   /* FIXME bollocks */
+   pipe_config->update_wm_pre = true;
+   pipe_config->update_wm_post = true;
}
 
/* Pre-gen9 platforms need two-step watermark updates */
-   if (pipe_config->wm_changed && INTEL_INFO(dev)->gen < 9 &&
-   dev_priv->display.optimize_watermarks)
+   if ((pipe_config->update_wm_pre || pipe_config->update_wm_post) &&
+   INTEL_INFO(dev)->gen < 9 && dev_priv->display.optimize_watermarks)
to_intel_crtc_state(crtc_state)->wm.need_postvbl_update = true;
 
if (visible || was_visible)
@@ -12106,7 +12115,7 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
}
 
if (mode_changed && !crtc_state->active)
-   pipe_config->wm_changed = true;
+   pipe_config->update_wm_post = true;
 
if (mode_changed && crtc_state->enable &&
dev_priv->display.crtc_compute_clock &&
@@ -13645,12 +13654,12 @@ static bool needs_vblank_wait(struct intel_crtc_state 
*crtc_state)
return true;
 
/* wm changes, need vblank before final wm's */
-   if 

[Intel-gfx] [PATCH 2/5] drm/i915: Pass the correct crtc state to .update_plane()

[ville . syrjala]

From: Ville Syrjälä 

Pass the current crtc state, not the old crtc state, to the
.update_plane() hook.

Noticed on BSW when PRIMSIZE was getting programmed to a stale value
which produced utter garbage on screen eg. wwhen going from 1920x1080
to 1024x768.

Cc: Maarten Lankhorst 
Fixes: a758e6845825 ("drm/i915: Do not use commit_plane for sprite planes.")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index e0b851a0004a..7de7721f65bc 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -195,12 +195,10 @@ static void intel_plane_atomic_update(struct drm_plane 
*plane,
struct intel_plane_state *intel_state =
to_intel_plane_state(plane->state);
struct drm_crtc *crtc = plane->state->crtc ?: old_state->crtc;
-   struct drm_crtc_state *crtc_state =
-   drm_atomic_get_existing_crtc_state(old_state->state, crtc);
 
if (intel_state->visible)
intel_plane->update_plane(plane,
- to_intel_crtc_state(crtc_state),
+ to_intel_crtc_state(crtc->state),
  intel_state);
else
intel_plane->disable_plane(plane, crtc);
-- 
2.4.10

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

[Intel-gfx] [PATCH 1/5] Revert "drm/i915: Enable PSR by default on Valleyview and Cherryview."

[ville . syrjala]

From: Ville Syrjälä 

This reverts commit a38c274faad0ec6aba692e294ec751d04dbba803.

PSR causes all sorts of vblank wait timeouts and whanot on CHV. Disable
it again.

Cc: Rodrigo Vivi 
Fixes: a38c274faad0 ("drm/i915: Enable PSR by default on Valleyview and 
Cherryview.")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_psr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b1413beb00d1..38e95185d9c6 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -781,8 +781,7 @@ void intel_psr_init(struct drm_device *dev)
 
/* Per platform default */
if (i915.enable_psr == -1) {
-   if (IS_HASWELL(dev) || IS_BROADWELL(dev) ||
-   IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
+   if (IS_HASWELL(dev) || IS_BROADWELL(dev))
i915.enable_psr = 1;
else
i915.enable_psr = 0;
-- 
2.4.10

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

[Intel-gfx] [PATCH 4/5] drm/i915: Wait for vblank after cxsr disable in pre_plane_update

[ville . syrjala]

From: Ville Syrjälä 

We must wait for the hardware to exit cxsr before doing the plane
update, so add the missing vblank wait to pre_plane_update after
disabling cxsr.

We have the wait for vblank in the pre_disable_primary hook, but not in
the pre_plane_update hook. Just move the code from (and comment) from
pre_disable_primary into pre_plane_update. Well, we still have to keep
it in pre_disable_primary for these strange _noatomic codepaths, so
let's do another version of pre_disable_primary for those. Also toss
in some FIXMEs in the hope that someone will eventually clean up this
pre_disable_primary mess.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 59 ++--
 1 file changed, 37 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8b44e0652740..a76ba22ee711 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -116,7 +116,7 @@ static void skylake_pfit_enable(struct intel_crtc *crtc);
 static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force);
 static void ironlake_pfit_enable(struct intel_crtc *crtc);
 static void intel_modeset_setup_hw_state(struct drm_device *dev);
-static void intel_pre_disable_primary(struct drm_crtc *crtc);
+static void intel_pre_disable_primary_noatomic(struct drm_crtc *crtc);
 
 typedef struct {
int min, max;
@@ -2755,7 +2755,7 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
 */
to_intel_plane_state(plane_state)->visible = false;
crtc_state->plane_mask &= ~(1 << drm_plane_index(primary));
-   intel_pre_disable_primary(_crtc->base);
+   intel_pre_disable_primary_noatomic(_crtc->base);
intel_plane->disable_plane(primary, _crtc->base);
 
return;
@@ -4857,16 +4857,7 @@ intel_post_enable_primary(struct drm_crtc *crtc)
intel_check_pch_fifo_underruns(dev_priv);
 }
 
-/**
- * intel_pre_disable_primary - Perform operations before disabling primary 
plane
- * @crtc: the CRTC whose primary plane is to be disabled
- *
- * Performs potentially sleeping operations that must be done before the
- * primary plane is disabled, such as updating FBC and IPS.  Note that this may
- * be called due to an explicit primary plane update, or due to an implicit
- * disable that is caused when a sprite plane completely hides the primary
- * plane.
- */
+/* FIXME move all this to pre_plane_update() with proper state tracking */
 static void
 intel_pre_disable_primary(struct drm_crtc *crtc)
 {
@@ -4885,6 +4876,26 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
 
/*
+* FIXME IPS should be fine as long as one plane is
+* enabled, but in practice it seems to have problems
+* when going from primary only to sprite only and vice
+* versa.
+*/
+   hsw_disable_ips(intel_crtc);
+}
+
+/* FIXME get rid of this and use pre_plane_update */
+static void
+intel_pre_disable_primary_noatomic(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   int pipe = intel_crtc->pipe;
+
+   intel_pre_disable_primary(crtc);
+
+   /*
 * Vblank time updates from the shadow to live plane control register
 * are blocked if the memory self-refresh mode is active at that
 * moment. So to make sure the plane gets truly disabled, disable
@@ -4898,14 +4909,6 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
dev_priv->wm.vlv.cxsr = false;
intel_wait_for_vblank(dev, pipe);
}
-
-   /*
-* FIXME IPS should be fine as long as one plane is
-* enabled, but in practice it seems to have problems
-* when going from primary only to sprite only and vice
-* versa.
-*/
-   hsw_disable_ips(intel_crtc);
 }
 
 static void intel_post_plane_update(struct intel_crtc *crtc)
@@ -4962,8 +4965,20 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state)
if (pipe_config->disable_cxsr) {
crtc->wm.cxsr_allowed = false;
 
-   if (old_crtc_state->base.active)
+   /*
+* Vblank time updates from the shadow to live plane control 
register
+* are blocked if the memory self-refresh mode is active at that
+* moment. So to make sure the plane gets truly disabled, 
disable
+* first the self-refresh mode. The self-refresh enable bit in 
turn
+* will be checked/applied by the HW only at the next frame 
start
+* event which is after the vblank start event, so we need to 
have a
+* 

[Intel-gfx] [PATCH 0/5] drm/i915: CHV regressions fixes

[ville . syrjala]

From: Ville Syrjälä 

CHV display side got broken on multiple fronts. This series undoes the
damage a bit and I tossed in a few cleanupish things at the end for fun.

Ville Syrjälä (5):
  Revert "drm/i915: Enable PSR by default on Valleyview and Cherryview."
  drm/i915: Pass the correct crtc state to .update_plane()
  drm/i915: Fix watermarks for VLV/CHV
  drm/i915: Wait for vblank after cxsr disable in pre_plane_update
  drm/i915: s/crtc_state/old_crtc_state/ in intel_atomic_commit()

 drivers/gpu/drm/i915/intel_atomic.c   |   3 +-
 drivers/gpu/drm/i915/intel_atomic_plane.c |   4 +-
 drivers/gpu/drm/i915/intel_display.c  | 108 ++
 drivers/gpu/drm/i915/intel_drv.h  |   2 +-
 drivers/gpu/drm/i915/intel_psr.c  |   3 +-
 5 files changed, 71 insertions(+), 49 deletions(-)

-- 
2.4.10

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

Re: [Intel-gfx] [PATCH] drm/i915: implement WaClearTdlStateAckDirtyBits

[Arun Siluvery]

On 09/03/2016 16:46, tim.g...@intel.com wrote:

From: Tim Gore 

This is to fix a GPU hang seen with mid thread pre-emption
and pooled EUs.

Signed-off-by: Tim Gore 
---
  drivers/gpu/drm/i915/i915_reg.h  | 12 
  drivers/gpu/drm/i915/intel_lrc.c | 19 +++
  2 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc400..0600bc7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1777,6 +1777,18 @@ enum skl_disp_power_wells {
  #define   GEN9_IZ_HASHING_MASK(slice) (0x3 << ((slice) * 2))
  #define   GEN9_IZ_HASHING(slice, val) ((val) << ((slice) * 2))

+/* WaClearTdlStateAckDirtyBits */
+#define GEN8_STATE_ACK 0x20F0
+#define GEN9_STATE_ACK_SLICE1  0x20F8
+#define GEN9_STATE_ACK_SLICE2  0x2100


_MMIO(reg_addr)

regards
Arun


+#define   GEN9_STATE_ACK_TDL0 (1 << 12)
+#define   GEN9_STATE_ACK_TDL1 (1 << 13)
+#define   GEN9_STATE_ACK_TDL2 (1 << 14)
+#define   GEN9_STATE_ACK_TDL3 (1 << 15)
+#define   GEN9_SUBSLICE_TDL_ACK_BITS \
+   (GEN9_STATE_ACK_TDL3 | GEN9_STATE_ACK_TDL2 | \
+GEN9_STATE_ACK_TDL1 | GEN9_STATE_ACK_TDL0)
+
  #define GFX_MODE  _MMIO(0x2520)
  #define GFX_MODE_GEN7 _MMIO(0x229c)
  #define RING_MODE_GEN7(ring)  _MMIO((ring)->mmio_base+0x29c)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6fcbf6b..c36398d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1447,6 +1447,25 @@ static int gen9_init_perctx_bb(struct intel_engine_cs 
*ring,
wa_ctx_emit(batch, index, MI_NOOP);
}

+   /* WaClearTdlStateAckDirtyBits:bxt */
+   if (IS_BROXTON(dev) && (INTEL_REVID(dev) <= BXT_REVID_B0)) {
+   wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(4));
+
+   wa_ctx_emit(batch, index, GEN8_STATE_ACK);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit(batch, index, GEN9_STATE_ACK_SLICE1);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit(batch, index, GEN9_STATE_ACK_SLICE2);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit(batch, index, GEN7_ROW_CHICKEN2);
+   /* dummy write to CS, mask bits are 0 to ensure the register is 
not modified */
+   wa_ctx_emit(batch, index, 0x0);
+   wa_ctx_emit(batch, index, MI_NOOP);
+   }
+
/* WaDisableCtxRestoreArbitration:skl,bxt */
if (IS_SKL_REVID(dev, 0, SKL_REVID_D0) ||
IS_BXT_REVID(dev, 0, BXT_REVID_A1))



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

Re: [Intel-gfx] [PATCH] drm/i915: implement WaClearTdlStateAckDirtyBits

[kbuild test robot]

Hi Tim,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.5-rc7 next-20160309]
[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/tim-gore-intel-com/drm-i915-implement-WaClearTdlStateAckDirtyBits/20160310-004816
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x000-201610 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_lrc.c: In function 'gen9_init_perctx_bb':
>> drivers/gpu/drm/i915/intel_lrc.c:1216:18: error: incompatible types when 
>> assigning to type 'uint32_t {aka unsigned int}' from type 'i915_reg_t {aka 
>> const struct }'
  batch[__index] = (cmd); \
 ^
>> drivers/gpu/drm/i915/intel_lrc.c:1463:3: note: in expansion of macro 
>> 'wa_ctx_emit'
  wa_ctx_emit(batch, index, GEN7_ROW_CHICKEN2);
  ^

vim +1216 drivers/gpu/drm/i915/intel_lrc.c

83b8a982 Arun Siluvery 2015-07-08  1210  #define wa_ctx_emit(batch, index, cmd) 
\
17ee950d Arun Siluvery 2015-06-19  1211 do {
\
83b8a982 Arun Siluvery 2015-07-08  1212 int __index = 
(index)++;\
83b8a982 Arun Siluvery 2015-07-08  1213 if (WARN_ON(__index >= 
(PAGE_SIZE / sizeof(uint32_t { \
17ee950d Arun Siluvery 2015-06-19  1214 return -ENOSPC; 
\
17ee950d Arun Siluvery 2015-06-19  1215 }   
\
83b8a982 Arun Siluvery 2015-07-08 @1216 batch[__index] = (cmd); 
\
17ee950d Arun Siluvery 2015-06-19  1217 } while (0)
17ee950d Arun Siluvery 2015-06-19  1218  
8f40db77 Ville Syrjälä 2015-11-04  1219  #define wa_ctx_emit_reg(batch, index, 
reg) \

:: The code at line 1216 was first introduced by commit
:: 83b8a982b101c48fc025066a7b08beaf6fa756f0 drm/i915: Update wa_ctx_emit() 
macro as per kernel coding guidelines

:: TO: Arun Siluvery <arun.siluv...@linux.intel.com>
:: CC: Daniel Vetter <daniel.vet...@ffwll.ch>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: implement WaClearTdlStateAckDirtyBits

[Arun Siluvery]

On 09/03/2016 16:46, tim.g...@intel.com wrote:

From: Tim Gore 

This is to fix a GPU hang seen with mid thread pre-emption
and pooled EUs.

Signed-off-by: Tim Gore 
---
  drivers/gpu/drm/i915/i915_reg.h  | 12 
  drivers/gpu/drm/i915/intel_lrc.c | 19 +++
  2 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc400..0600bc7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1777,6 +1777,18 @@ enum skl_disp_power_wells {
  #define   GEN9_IZ_HASHING_MASK(slice) (0x3 << ((slice) * 2))
  #define   GEN9_IZ_HASHING(slice, val) ((val) << ((slice) * 2))

+/* WaClearTdlStateAckDirtyBits */
+#define GEN8_STATE_ACK 0x20F0
+#define GEN9_STATE_ACK_SLICE1  0x20F8
+#define GEN9_STATE_ACK_SLICE2  0x2100
+#define   GEN9_STATE_ACK_TDL0 (1 << 12)
+#define   GEN9_STATE_ACK_TDL1 (1 << 13)
+#define   GEN9_STATE_ACK_TDL2 (1 << 14)
+#define   GEN9_STATE_ACK_TDL3 (1 << 15)
+#define   GEN9_SUBSLICE_TDL_ACK_BITS \
+   (GEN9_STATE_ACK_TDL3 | GEN9_STATE_ACK_TDL2 | \
+GEN9_STATE_ACK_TDL1 | GEN9_STATE_ACK_TDL0)
+
  #define GFX_MODE  _MMIO(0x2520)
  #define GFX_MODE_GEN7 _MMIO(0x229c)
  #define RING_MODE_GEN7(ring)  _MMIO((ring)->mmio_base+0x29c)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6fcbf6b..c36398d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1447,6 +1447,25 @@ static int gen9_init_perctx_bb(struct intel_engine_cs 
*ring,
wa_ctx_emit(batch, index, MI_NOOP);
}

+   /* WaClearTdlStateAckDirtyBits:bxt */
+   if (IS_BROXTON(dev) && (INTEL_REVID(dev) <= BXT_REVID_B0)) {


this should be, IS_BXT_REVID(dev, 0, BXT_REVID_B0)

regards
Arun


+   wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(4));
+
+   wa_ctx_emit(batch, index, GEN8_STATE_ACK);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit(batch, index, GEN9_STATE_ACK_SLICE1);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit(batch, index, GEN9_STATE_ACK_SLICE2);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit(batch, index, GEN7_ROW_CHICKEN2);
+   /* dummy write to CS, mask bits are 0 to ensure the register is 
not modified */
+   wa_ctx_emit(batch, index, 0x0);
+   wa_ctx_emit(batch, index, MI_NOOP);
+   }
+
/* WaDisableCtxRestoreArbitration:skl,bxt */
if (IS_SKL_REVID(dev, 0, SKL_REVID_D0) ||
IS_BXT_REVID(dev, 0, BXT_REVID_A1))



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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: implement WaClearTdlStateAckDirtyBits

[Patchwork]

== Series Details ==

Series: drm/i915: implement WaClearTdlStateAckDirtyBits
URL   : https://patchwork.freedesktop.org/series/4282/
State : failure

== Summary ==

  CC [M]  drivers/net/ethernet/intel/igbvf/ethtool.o
  LD  drivers/usb/storage/built-in.o
  CC [M]  drivers/net/ethernet/intel/e1000e/mac.o
  CC [M]  drivers/net/ethernet/intel/igbvf/netdev.o
  CC [M]  drivers/net/ethernet/intel/e1000e/manage.o
  CC [M]  drivers/net/ethernet/intel/e1000e/nvm.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_82575.o
  CC [M]  drivers/net/ethernet/intel/e1000e/phy.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mac.o
  CC [M]  drivers/net/ethernet/intel/e1000e/param.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_nvm.o
  CC [M]  drivers/net/ethernet/intel/e1000e/ethtool.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_phy.o
  CC [M]  drivers/net/ethernet/intel/e1000e/netdev.o
  LD  drivers/usb/host/xhci-hcd.o
  CC [M]  drivers/net/ethernet/intel/e1000e/ptp.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD  drivers/usb/host/built-in.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_mbx.o
  CC [M]  drivers/net/ethernet/intel/igb/e1000_i210.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_ptp.o
  LD  drivers/usb/built-in.o
  CC [M]  drivers/net/ethernet/intel/igb/igb_hwmon.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:950: 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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gen9: add WaClearFlowControlGpgpuContextSave (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gen9: add WaClearFlowControlGpgpuContextSave (rev2)
URL   : https://patchwork.freedesktop.org/series/4272/
State : warning

== Summary ==

Series 4272v2 drm/i915/gen9: add WaClearFlowControlGpgpuContextSave
http://patchwork.freedesktop.org/api/1.0/series/4272/revisions/2/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (hsw-brixbox)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (hsw-gt2)
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (hsw-brixbox)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (hsw-brixbox)

bdw-nuci7total:193  pass:181  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:193  pass:172  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:193  pass:155  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:193  pass:158  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:193  pass:168  dwarn:2   dfail:0   fail:0   skip:23 
hsw-gt2  total:193  pass:174  dwarn:2   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:193  pass:130  dwarn:0   dfail:0   fail:0   skip:63 
skl-i5k-2total:193  pass:170  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:193  pass:170  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:193  pass:158  dwarn:1   dfail:0   fail:0   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1552/

ab403b26610034afe0e0c97d960782bad98b97d0 drm-intel-nightly: 
2016y-03m-09d-09h-25m-31s UTC integration manifest
b45861404ef31f09fbeedb2b0d28a5f34e307cf2 drm/i915/gen9: add 
WaClearFlowControlGpgpuContextSave

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

[Intel-gfx] [PATCH] drm/i915: implement WaClearTdlStateAckDirtyBits

[tim . gore]

From: Tim Gore 

This is to fix a GPU hang seen with mid thread pre-emption
and pooled EUs.

Signed-off-by: Tim Gore 
---
 drivers/gpu/drm/i915/i915_reg.h  | 12 
 drivers/gpu/drm/i915/intel_lrc.c | 19 +++
 2 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc400..0600bc7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1777,6 +1777,18 @@ enum skl_disp_power_wells {
 #define   GEN9_IZ_HASHING_MASK(slice)  (0x3 << ((slice) * 2))
 #define   GEN9_IZ_HASHING(slice, val)  ((val) << ((slice) * 2))
 
+/* WaClearTdlStateAckDirtyBits */
+#define GEN8_STATE_ACK 0x20F0
+#define GEN9_STATE_ACK_SLICE1  0x20F8
+#define GEN9_STATE_ACK_SLICE2  0x2100
+#define   GEN9_STATE_ACK_TDL0 (1 << 12)
+#define   GEN9_STATE_ACK_TDL1 (1 << 13)
+#define   GEN9_STATE_ACK_TDL2 (1 << 14)
+#define   GEN9_STATE_ACK_TDL3 (1 << 15)
+#define   GEN9_SUBSLICE_TDL_ACK_BITS \
+   (GEN9_STATE_ACK_TDL3 | GEN9_STATE_ACK_TDL2 | \
+GEN9_STATE_ACK_TDL1 | GEN9_STATE_ACK_TDL0)
+
 #define GFX_MODE   _MMIO(0x2520)
 #define GFX_MODE_GEN7  _MMIO(0x229c)
 #define RING_MODE_GEN7(ring)   _MMIO((ring)->mmio_base+0x29c)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6fcbf6b..c36398d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1447,6 +1447,25 @@ static int gen9_init_perctx_bb(struct intel_engine_cs 
*ring,
wa_ctx_emit(batch, index, MI_NOOP);
}
 
+   /* WaClearTdlStateAckDirtyBits:bxt */
+   if (IS_BROXTON(dev) && (INTEL_REVID(dev) <= BXT_REVID_B0)) {
+   wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(4));
+
+   wa_ctx_emit(batch, index, GEN8_STATE_ACK);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit(batch, index, GEN9_STATE_ACK_SLICE1);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit(batch, index, GEN9_STATE_ACK_SLICE2);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit(batch, index, GEN7_ROW_CHICKEN2);
+   /* dummy write to CS, mask bits are 0 to ensure the register is 
not modified */
+   wa_ctx_emit(batch, index, 0x0);
+   wa_ctx_emit(batch, index, MI_NOOP);
+   }
+
/* WaDisableCtxRestoreArbitration:skl,bxt */
if (IS_SKL_REVID(dev, 0, SKL_REVID_D0) ||
IS_BXT_REVID(dev, 0, BXT_REVID_A1))
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Support to enable TRTT on GEN9

[Goel, Akash]

On 3/9/2016 9:51 PM, Chris Wilson wrote:

On Wed, Mar 09, 2016 at 09:26:08PM +0530, Goel, Akash wrote:



On 3/9/2016 8:32 PM, Chris Wilson wrote:

On Wed, Mar 09, 2016 at 08:20:07PM +0530, Goel, Akash wrote:

What locks are we holding here?


+   else if (args->size < sizeof(trtt_params))
+   return -EINVAL;
+   else if (copy_from_user(_params,
+   to_user_ptr(args->value),
+   sizeof(trtt_params)))


Because whatever they are, we can't hold them here!


The struct_mutex lock was taken in the caller, ioctl function.
Ok, so need to release that before invoking copy_from_user.


(Imagine/write a test that passes in the trtt_params inside a GTT mmaping.)


This could cause a recursive locking of struct_mutex from the gem_fault() ?


Exactly. At the least lockdep should warn if we hit a fault along this
path (due to the illegal nesting of mmap_sem inside struct_mtuex).



I hope it won't look ungainly to unlock the struct_mutex before
copy_from_user and lock it back right after that.


It what's we have to do. However, we have to make sure that we do not
lose state, or the user doesn't interfere, across the unlock. i.e. make
sure we have a reference on the context, double check that the state is
still valid (so do the EEXISTS check after the copy) etc.



Thanks for the inputs, will keep them in mind.


In the new test case, will soft pin objects in TR-TT segment first.
Then later on enabling TR-TT, those objects should get evicted.


Yes. But make sure you have combinations of inactive, active, and
hanging objects inside the to-be-evicted segment. Those cover the most
frequent errors we have to handle (and easiest to reproduce).


Fine, will refer other tests logic to see how to ensure that
previously soft pinned object is still marked as active, when the
eviction happens on enabling TR-TT.

Sorry what is the hanging object type ?


Submit a recursive batch using the vma inside your trtt region.
See igt_hang_ctx() if you are free to select the trtt region using the
offset generated by igt_hang_ctx() (and for this test you are), then it
is very simple. See gem_softpin, test_evict_hang() and
test_evict_active().



Thanks for suggesting these tests, will refer them.


+static int gen9_init_context_trtt(struct drm_i915_gem_request *req)


Since TRTT is render only, call this gen9_init_rcs_context_trtt()


Thanks, will change.


  static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
  {
struct i915_hw_ppgtt *ppgtt = req->ctx->ppgtt;
@@ -1693,6 +1757,20 @@ static int gen8_emit_bb_start(struct 
drm_i915_gem_request *req,
req->ctx->ppgtt->pd_dirty_rings &= ~intel_ring_flag(req->ring);
}

+   /*
+* Emitting LRIs to update the TRTT registers is most reliable, instead
+* of directly updating the context image, as this will ensure that
+* update happens in a serialized manner for the context and also
+* lite-restore scenario will get handled.
+*/
+   if ((req->ring->id == RCS) && req->ctx->trtt_info.update_trtt_params) {
+   ret = gen9_emit_trtt_regs(req);
+   if (ret)
+   return ret;
+
+   req->ctx->trtt_info.update_trtt_params = false;


Bah. Since we can only update the params once (EEXIST otherwise),
we emit the change when the user sets the new params.


Sorry couldn't get this point. We can't emit the params right away
when User sets them (only once). We need to emit/apply the params
(onetime) in a deferred manner on the next submission.


Why can't we? We can construct and submit a request setting the
registers inside the right context image at that point, and they never
change after that point.


Ok yes a new request can be constructed & submitted for the Context,
emitting the LRIs to update the TRTT params in the Context image.
But won't that be relatively cumbersome considering that we are able
to easily defer & conflate that with next batch submission, through
an extra flag trtt_info.update_trtt_params.


A conditional on every batch vs a one-off ?

request = i915_gem_request_alloc(_priv->ring[RCS], ctx);
if (IS_ERR(request))
return ERR_PTR(request);

ret = gen9_emit_trtt_regs(request);
if (ret) {
i915_gem_request_cancel(request);
return ret;
}

i915_add_request(request);
return 0;

Complain to whoever sold you your kernel if it is not that simple. (And
that is quite byzantine compared to how it should be!)


Fine, thanks much for the required code snippet, will update the patch.

Sorry actually was bit skeptical about introducing a new non-execbuffer 
path, from the where the request allocation & submission happens.


Best regards
Akash


-Chris


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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Move some load time init steps earlier

[Patchwork]

== Series Details ==

Series: drm/i915: Move some load time init steps earlier
URL   : https://patchwork.freedesktop.org/series/4277/
State : warning

== Summary ==

Series 4277v1 drm/i915: Move some load time init steps earlier
http://patchwork.freedesktop.org/api/1.0/series/4277/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (hsw-brixbox)
dmesg-warn -> PASS   (bdw-ultra)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:193  pass:181  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:193  pass:172  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:193  pass:156  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:193  pass:158  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox  total:193  pass:170  dwarn:1   dfail:0   fail:0   skip:22 
hsw-gt2  total:193  pass:175  dwarn:1   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:193  pass:129  dwarn:1   dfail:0   fail:0   skip:63 
skl-i5k-2total:193  pass:170  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:193  pass:170  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:193  pass:158  dwarn:1   dfail:0   fail:0   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1551/

ab403b26610034afe0e0c97d960782bad98b97d0 drm-intel-nightly: 
2016y-03m-09d-09h-25m-31s UTC integration manifest
31a9f0eb7255e6db7d2c2ead85c82a7a563d613c drm/i915: Move load time runtime PM 
get later
12441e34328cb74efd2171173917a228533346af drm/i915: Move load time runtime 
device info init earlier
e6a2f41a605493e196ec653a083fe45e41acde2b drm/i915: Move load time clock gating 
callback init earlier
bb85943be0fc41628f90163831ac4e734e6a1516 drm/i915: Move load time display/audio 
callback init earlier
23740b43760949edca1146662b0651e53c6e0a6c drm/i915: Move load time IRQ SW init 
earlier
d66e1cc5ce11b04c995d6cf4ea3ea1611b977758 drm/i915: Move laod time PCH detect, 
DPIO, power domain SW init earlier
ee9ef87a8f4084ed39e0674cf770fee37dbd9bac drm/i915: Add comments marking the 
start of load time init phases

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Support to enable TRTT on GEN9

[Chris Wilson]

On Wed, Mar 09, 2016 at 09:26:08PM +0530, Goel, Akash wrote:
> 
> 
> On 3/9/2016 8:32 PM, Chris Wilson wrote:
> >On Wed, Mar 09, 2016 at 08:20:07PM +0530, Goel, Akash wrote:
> >>>What locks are we holding here?
> >>>
> + else if (args->size < sizeof(trtt_params))
> + return -EINVAL;
> + else if (copy_from_user(_params,
> + to_user_ptr(args->value),
> + sizeof(trtt_params)))
> >>>
> >>>Because whatever they are, we can't hold them here!
> >>>
> >>The struct_mutex lock was taken in the caller, ioctl function.
> >>Ok, so need to release that before invoking copy_from_user.
> >>
> >>>(Imagine/write a test that passes in the trtt_params inside a GTT mmaping.)
> >>
> >>This could cause a recursive locking of struct_mutex from the gem_fault() ?
> >
> >Exactly. At the least lockdep should warn if we hit a fault along this
> >path (due to the illegal nesting of mmap_sem inside struct_mtuex).
> >
> 
> I hope it won't look ungainly to unlock the struct_mutex before
> copy_from_user and lock it back right after that.

It what's we have to do. However, we have to make sure that we do not
lose state, or the user doesn't interfere, across the unlock. i.e. make
sure we have a reference on the context, double check that the state is
still valid (so do the EEXISTS check after the copy) etc.

> >>In the new test case, will soft pin objects in TR-TT segment first.
> >>Then later on enabling TR-TT, those objects should get evicted.
> >
> >Yes. But make sure you have combinations of inactive, active, and
> >hanging objects inside the to-be-evicted segment. Those cover the most
> >frequent errors we have to handle (and easiest to reproduce).
> >
> Fine, will refer other tests logic to see how to ensure that
> previously soft pinned object is still marked as active, when the
> eviction happens on enabling TR-TT.
> 
> Sorry what is the hanging object type ?

Submit a recursive batch using the vma inside your trtt region.
See igt_hang_ctx() if you are free to select the trtt region using the
offset generated by igt_hang_ctx() (and for this test you are), then it
is very simple. See gem_softpin, test_evict_hang() and
test_evict_active().

> +static int gen9_init_context_trtt(struct drm_i915_gem_request *req)
> >>>
> >>>Since TRTT is render only, call this gen9_init_rcs_context_trtt()
> >>>
> >>Thanks, will change.
> >>
>   static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request 
>  *req)
>   {
>   struct i915_hw_ppgtt *ppgtt = req->ctx->ppgtt;
> @@ -1693,6 +1757,20 @@ static int gen8_emit_bb_start(struct 
> drm_i915_gem_request *req,
>   req->ctx->ppgtt->pd_dirty_rings &= 
>  ~intel_ring_flag(req->ring);
>   }
> 
> + /*
> +  * Emitting LRIs to update the TRTT registers is most reliable, instead
> +  * of directly updating the context image, as this will ensure that
> +  * update happens in a serialized manner for the context and also
> +  * lite-restore scenario will get handled.
> +  */
> + if ((req->ring->id == RCS) && req->ctx->trtt_info.update_trtt_params) {
> + ret = gen9_emit_trtt_regs(req);
> + if (ret)
> + return ret;
> +
> + req->ctx->trtt_info.update_trtt_params = false;
> >>>
> >>>Bah. Since we can only update the params once (EEXIST otherwise),
> >>>we emit the change when the user sets the new params.
> >>
> >>Sorry couldn't get this point. We can't emit the params right away
> >>when User sets them (only once). We need to emit/apply the params
> >>(onetime) in a deferred manner on the next submission.
> >
> >Why can't we? We can construct and submit a request setting the
> >registers inside the right context image at that point, and they never
> >change after that point.
> 
> Ok yes a new request can be constructed & submitted for the Context,
> emitting the LRIs to update the TRTT params in the Context image.
> But won't that be relatively cumbersome considering that we are able
> to easily defer & conflate that with next batch submission, through
> an extra flag trtt_info.update_trtt_params.

A conditional on every batch vs a one-off ?

request = i915_gem_request_alloc(_priv->ring[RCS], ctx);
if (IS_ERR(request))
return ERR_PTR(request);

ret = gen9_emit_trtt_regs(request);
if (ret) {
i915_gem_request_cancel(request);
return ret;
}

i915_add_request(request);
return 0;

Complain to whoever sold you your kernel if it is not that simple. (And
that is quite byzantine compared to how it should be!)
-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 5/7] drm/i915: Move load time clock gating callback init earlier

[Chris Wilson]

On Wed, Mar 09, 2016 at 06:01:32PM +0200, Imre Deak wrote:
> > else
> > MISSING_CASE()
> > 
> > We definitely need a warning here in case we fall through and leave a
> > most unexpected NULL pointer.
> 
> Ok, can add that. At least SKL doesn't have a callback, but I can check
> for such platforms explicitly.

imo, set it to a nop_init_clock_gating as it is very much the exception
rather than the rule (and expect we'll find something to put in there
eventually!)
-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 i-g-t v7] lib/igt_kms: Add COMMIT_ATOMIC to igt_display_commit2()

[Lionel Landwerlin]

Thanks,

It seems the igt_atomic_prepare_plane_commit() function still needs to
reset the plane->rotation_changed field (it was at the bottom of my
previous email, sorry for that).

The way supported property ids are listed from the driver isn't
different in the atomic and non atomic cases.
The igt_atomic_fill_props and igt_atomic_fill_plane_props functions are
not atomic specific.
What I was suggesting is to have a unified way of listing the
properties regardless of whether we're committing things atomically or
not and just have the commit function do a special case for atomic.

That way it becomes easier to add new properties.


-
Lionel

On Wed, 2016-03-09 at 19:55 +0530, Mayuresh Gharpure wrote:
> Hi Lionel,
> 
> I've incorporated your comments using the diff patch submitted by
> Maarten and submitted the changes
> 
> https://patchwork.freedesktop.org/series/4274/ 
> 
> Also, please find my comments inline
> 
> Regards,
> Mayuresh
> 
> On 3/8/2016 9:41 PM, Lionel Landwerlin wrote:
> > Hi Maarten, 
> > 
> > Yeah that would be much simpler I think.
> > 
> > Damien also looked at this patch over my shoulder and had
> > additional comments.
> > So more or less proxying :
> > 
> > - Not sure why we're exposing the new enums and the
> > igt_atomic_popuplate_* macros in igt_kms.h.
> >   After all we're not using them anywhere outside igt_kms.c.
>  Macros are just to improve readability. In case some new feature
> needs to be added, we can just add an enum and use the macro to
> populate it in call to IOCTL.
> These were added in initial implementation by Marius. 
> 
> > 
> > - We have a couple of properties ids stored in igt_kms.h
> > (background_property & rotation_property), it would make sense to
> > get rid of those and use the new created arrays instead.
>  These are used by the COMMIT_LEGACY and COMMIT_UNIVERSAL style
> calls. So keeping it as is, as changing this may need a change in
> many existing tests
> > 
> > Cheers,
> > 
> > -
> > Lionel 
> > 
> > On 08/03/16 15:56, Maarten Lankhorst wrote:
> > > Op 07-03-16 om 13:50 schreef Lionel Landwerlin:
> > > > Hi Pratik,
> > > > 
> > > > I'm really looking forward to get this merged.
> > > > Just a few comments on the plane commit part below.
> > > Would the following diff to the patch satisfy you? It would clean
> > > up things a lot.
> > > 
> > > diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > > index 1f738e14f52f..454ff7552b4a 100644
> > > --- a/lib/igt_kms.c
> > > +++ b/lib/igt_kms.c
> > > @@ -1534,14 +1534,6 @@
> > > igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_output_t
> > > *output,
> > >  
> > >   igt_display_t *display = output->display;
> > >   uint32_t fb_id, crtc_id;
> > > - uint32_t src_x;
> > > - uint32_t src_y;
> > > - uint32_t src_w;
> > > - uint32_t src_h;
> > > - int32_t crtc_x;
> > > - int32_t crtc_y;
> > > - uint32_t crtc_w;
> > > - uint32_t crtc_h;
> > >  
> > >   igt_assert(plane->drm_plane);
> > >  
> > > @@ -1552,54 +1544,30 @@
> > > igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_output_t
> > > *output,
> > >   fb_id = igt_plane_get_fb_id(plane);
> > >   crtc_id = output->config.crtc->crtc_id;
> > >  
> > > - if ((plane->fb_changed || plane->size_changed) && fb_id
> > > == 0) {
> > > -
> > > - LOG(display,
> > > - "%s: populating plane data: pipe %s, plane
> > > %d, disabling\n",
> > > -  igt_output_name(output),
> > > -  kmstest_pipe_name(output->config.pipe),
> > > -  plane->index);
> > > -
> > > - /* populate plane req */
> > > - igt_atomic_populate_plane_req(req, plane,
> > > IGT_PLANE_CRTC_ID, 0);
> > > - igt_atomic_populate_plane_req(req, plane,
> > > IGT_PLANE_FB_ID, 0);
> > > -
> > > - igt_atomic_populate_plane_req(req, plane,
> > > IGT_PLANE_SRC_X, IGT_FIXED(0, 0));
> > > - igt_atomic_populate_plane_req(req, plane,
> > > IGT_PLANE_SRC_Y, IGT_FIXED(0, 0));
> > > - igt_atomic_populate_plane_req(req, plane,
> > > IGT_PLANE_SRC_W, IGT_FIXED(0, 0));
> > > - igt_atomic_populate_plane_req(req, plane,
> > > IGT_PLANE_SRC_H, IGT_FIXED(0, 0));
> > > -
> > > - igt_atomic_populate_plane_req(req, plane,
> > > IGT_PLANE_CRTC_X, 0);
> > > - igt_atomic_populate_plane_req(req, plane,
> > > IGT_PLANE_CRTC_Y, 0);
> > > - igt_atomic_populate_plane_req(req, plane,
> > > IGT_PLANE_CRTC_W, 0);
> > > - igt_atomic_populate_plane_req(req, plane,
> > > IGT_PLANE_CRTC_H, 0);
> > > -
> > > - } else if (plane->fb_changed || plane->position_changed
> > > ||
> > > - plane->size_changed) {
> > > -
> > > - src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x
> > > */
> > > - src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y
> > > */
> > > - src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w
> > > */
> > > - src_h = IGT_FIXED(plane->fb->src_h, 0); /* src_h
> > > */
> > > - crtc_x = plane->crtc_x;
> > > - crtc_y = plane->crtc_y;
> > > -  

[Intel-gfx] [PATCH v2] drm/i915/gen9: add WaClearFlowControlGpgpuContextSave

[tim . gore]

From: Tim Gore 

This allows writes to EU flow control registers. Together
with SIP code from the user-mode driver this resolves a
hang seen in some pre-emption scenarios. Note that this
patch is just the kernel mode part of this workaround.

v2. Oops, add FLOW_CONTROL_ENABLE macro to i915_reg.h.

Signed-off-by: Tim Gore 
---
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7dfc400..58dcf01 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7103,6 +7103,7 @@ enum skl_disp_power_wells {
 #define   GEN9_CCS_TLB_PREFETCH_ENABLE (1<<3)
 
 #define GEN8_ROW_CHICKEN   _MMIO(0xe4f0)
+#define   FLOW_CONTROL_ENABLE  (1<<15)
 #define   PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE(1<<8)
 #define   STALL_DOP_GATING_DISABLE (1<<5)
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 45ce45a..83ab25a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -920,8 +920,10 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*ring)
I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
   ECOCHK_DIS_TLB);
 
+   /* WaClearFlowControlGpgpuContextSave:skl,bxt */
/* WaDisablePartialInstShootdown:skl,bxt */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
+ FLOW_CONTROL_ENABLE |
  PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
 
/* Syncing dependencies between camera and graphics:skl,bxt */
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Move some load time init steps earlier

[Chris Wilson]

On Wed, Mar 09, 2016 at 05:31:39PM +0200, Imre Deak wrote:
> While working on the CDCLK init code I realized that the driver load time
> dependencies between the different init steps are rather difficult to follow
> and so it's not obvious where some new piece of initialization needs to be
> added.
> 
> Also because some things are initialized too late, other steps depending on
> these must be initialized in a non-logical place or even split into multiple
> parts. One example is the CDCLK initialization which needs the display
> callbacks to be set already, but those callbacks are setup only late, so the
> CDCLK initialization must be done in two parts.
> 
> As a generic solution, I suggest that we define the following load
> time init phases:
> - state init not requiring device access
>   (i.e SW only, like initializing locks, allocating system memory, setting
>up callbacks, device attributes)
> - minimal HW setup to enable MMIO access to the device
> - state init requiring device access w/o side effects
>   (i.e. read-only HW access, no interface registrations)
> - state init causing device-wide side effects
>   (i.e any HW access, no interface registration)
> - registering all interfaces

On paper sounds goods. The only complaint I have is that we have only
nomenclature for 2 phases: init and init_hw. To be compelling I want
consistent names for each init function so that we know at a glance what
phase we are in, and the expectations/limitations upon the function.

init_early() / setup()
init_mmio()
init_late()
init_hw()

> This patchset adds the corresponding comment markers for the first
> two phases above and one common phase for the rest of the current
> init steps. Later we could also add the last three init phases above
> and restructure the code accordingly.
> 
> For now I only moved earlier a few obvious init steps that fit these
> new phases.
> 
> I smoke tested this on GEN4, SNB, BXT.
> 
> Imre Deak (7):
>   drm/i915: Add comments marking the start of load time init phases
>   drm/i915: Move laod time PCH detect, DPIO, power domain SW init
> earlier
>   drm/i915: Move load time IRQ SW init earlier
>   drm/i915: Move load time display/audio callback init earlier
>   drm/i915: Move load time clock gating callback init earlier
>   drm/i915: Move load time runtime device info init earlier
>   drm/i915: Move load time runtime PM get later

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 5/7] drm/i915: Move load time clock gating callback init earlier

[Imre Deak]

On ke, 2016-03-09 at 15:57 +, Chris Wilson wrote:
> On Wed, Mar 09, 2016 at 05:31:44PM +0200, Imre Deak wrote:
> > Split out the part initing the clock gating callbacks and move it
> > earlier.
> > 
> > The rest of the callbacks in intel_init_pm() should be inited in
> > the
> > same way, but atm some of the callbacks are set only conditionally,
> > so
> > before doing this we need to make the setup unconditional and use
> > instead some flags.
> > 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_dma.c  |  1 +
> >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> >  drivers/gpu/drm/i915/intel_pm.c  | 65 --
> > --
> >  3 files changed, 34 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 55b0c62..8cbe9ef 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1030,6 +1030,7 @@ int i915_driver_load(struct drm_device *dev,
> > unsigned long flags)
> >     intel_power_domains_init(dev_priv);
> >     intel_irq_init(dev_priv);
> >     intel_init_display_callbacks(dev_priv);
> > +   intel_init_clock_gating_callbacks(dev_priv);
> >     intel_init_audio_callbacks(dev_priv);
> >  
> >     intel_runtime_pm_get(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 5264901..d3d31cc 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1596,6 +1596,7 @@ void intel_suspend_hw(struct drm_device
> > *dev);
> >  int ilk_wm_max_level(const struct drm_device *dev);
> >  void intel_update_watermarks(struct drm_crtc *crtc);
> >  void intel_init_pm(struct drm_device *dev);
> > +void intel_init_clock_gating_callbacks(struct drm_i915_private
> > *dev_priv);
> >  void intel_pm_setup(struct drm_device *dev);
> >  void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
> >  void intel_gpu_ips_teardown(void);
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index d7aef17..02d3598 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -7107,6 +7107,38 @@ void intel_suspend_hw(struct drm_device
> > *dev)
> >     lpt_suspend_hw(dev);
> >  }
> >  
> > +void intel_init_clock_gating_callbacks(struct drm_i915_private
> > *dev_priv)
> > +{
> > +   if (IS_BROXTON(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > bxt_init_clock_gating;
> > +   else if (IS_BROADWELL(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > broadwell_init_clock_gating;
> > +   else if (IS_CHERRYVIEW(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > cherryview_init_clock_gating;
> > +   else if (IS_HASWELL(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > haswell_init_clock_gating;
> > +   else if (IS_IVYBRIDGE(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > ivybridge_init_clock_gating;
> > +   else if (IS_VALLEYVIEW(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > valleyview_init_clock_gating;
> > +   else if (IS_GEN6(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > gen6_init_clock_gating;
> > +   else if (IS_GEN5(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > ironlake_init_clock_gating;
> > +   else if (IS_G4X(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > g4x_init_clock_gating;
> > +   else if (IS_CRESTLINE(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > crestline_init_clock_gating;
> > +   else if (IS_BROADWATER(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > broadwater_init_clock_gating;
> > +   else if (IS_GEN3(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > gen3_init_clock_gating;
> > +   else if (IS_I85X(dev_priv) || IS_I865G(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > i85x_init_clock_gating;
> > +   else if (IS_GEN2(dev_priv))
> > +   dev_priv->display.init_clock_gating =
> > i830_init_clock_gating;
> 
> else
> MISSING_CASE()
> 
> We definitely need a warning here in case we fall through and leave a
> most unexpected NULL pointer.

Ok, can add that. At least SKL doesn't have a callback, but I can check
for such platforms explicitly.

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

[Intel-gfx] [i-g-t PATCH v2 2/2] overlay: Remove crtc<->pipe mapping code from kms-overlay

[Tomeu Vizoso]

From: Micah Fedke 

the crtc id is now always equivalent to its index in the array of crtcs
returned by the kernel

Signed-off-by: Micah Fedke 
[tomeu: Fixed include path and removed some dead code]
Signed-off-by: Tomeu Vizoso 
---

Changes in v2:
- Fix include path as suggested by Thomas
- Remove some dead code

 overlay/Makefile.am   |  4 ++--
 overlay/kms/kms-overlay.c | 16 
 2 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/overlay/Makefile.am b/overlay/Makefile.am
index c648875d24a7..eed2f9293ce0 100644
--- a/overlay/Makefile.am
+++ b/overlay/Makefile.am
@@ -3,8 +3,8 @@ bin_PROGRAMS = intel-gpu-overlay
 endif
 
 AM_CPPFLAGS = -I.
-AM_CFLAGS = $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) $(CWARNFLAGS) $(CAIRO_CFLAGS) 
$(OVERLAY_CFLAGS)
-LDADD = $(DRM_LIBS) $(PCIACCESS_LIBS) $(CAIRO_LIBS) $(OVERLAY_LIBS)
+AM_CFLAGS = -I$(top_srcdir)/lib $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) 
$(CWARNFLAGS) $(CAIRO_CFLAGS) $(OVERLAY_CFLAGS)
+LDADD = $(top_builddir)/lib/libintel_tools.la $(LIBUNWIND_LIBS) $(DRM_LIBS) 
$(PCIACCESS_LIBS) $(CAIRO_LIBS) $(OVERLAY_LIBS)
 
 intel_gpu_overlay_SOURCES = \
i915_pciids.h \
diff --git a/overlay/kms/kms-overlay.c b/overlay/kms/kms-overlay.c
index cfb3d5ae1dd7..494d57eeeb6b 100644
--- a/overlay/kms/kms-overlay.c
+++ b/overlay/kms/kms-overlay.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include "../overlay.h"
+#include "igt_kms.h"
 //#include "rgb2yuv.h"
 
 #ifndef ALIGN
@@ -240,20 +241,11 @@ kms_overlay_create(struct config *config, int *width, int 
*height)
priv->crtc = 0;
 
for (i = 0; i < kmode->count_crtcs; i++) {
-   struct drm_i915_get_pipe_from_crtc_id get_pipe;
-
-   get_pipe.pipe = 0;
-   get_pipe.crtc_id = kmode->crtcs[i];
-   if (drmIoctl(priv->fd,
-DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID,
-_pipe)) {
-   continue;
-   }
-
-   if (get_pipe.pipe != pipe)
+   if (kmstest_get_pipe_from_crtc_id(priv->fd,
+ kmode->crtcs[i]) != pipe)
continue;
 
-   priv->crtc = get_pipe.crtc_id;
+   priv->crtc = kmode->crtcs[i];
}
 
if (priv->crtc == 0)
-- 
2.5.0

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

[Intel-gfx] [i-g-t PATCH v2 1/2] lib: update kmstest_get_pipe_from_crtc_id

[Tomeu Vizoso]

From: Micah Fedke 

This function uses an intel-specific ioctl to fetch a mapping between pipes and
crtc ids, but this technique is outdated as the crtc id is now always
equivalent to its index in the array of crtcs returned by the kernel.

Signed-off-by: Tomeu Vizoso 
---

Changes in v2: None

 lib/igt_kms.c | 33 -
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 9f18aef72ea0..1d9acce31676 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -261,20 +261,35 @@ void kmstest_dump_mode(drmModeModeInfo *mode)
  * @fd: DRM fd
  * @crtc_id: DRM CRTC id
  *
- * Returns: The pipe number for the given DRM CRTC @crtc_id. This maps directly
- * to an enum pipe value used in other helper functions.
+ * Returns: The crtc index for the given DRM CRTC ID @crtc_id. The crtc index
+ * is the equivalent of the pipe id.  This value maps directly to an enum pipe
+ * value used in other helper functions.  Returns 0 if the index could not be
+ * determined.
  */
+
 int kmstest_get_pipe_from_crtc_id(int fd, int crtc_id)
 {
-   struct drm_i915_get_pipe_from_crtc_id pfci;
-   int ret;
+   drmModeRes *res;
+   drmModeCrtc *crtc;
+   int i, cur_id;
+
+   res = drmModeGetResources(fd);
+   igt_assert(res);
+
+   for (i = 0; i < res->count_crtcs; i++) {
+   crtc = drmModeGetCrtc(fd, res->crtcs[i]);
+   igt_assert(crtc);
+   cur_id = crtc->crtc_id;
+   drmModeFreeCrtc(crtc);
+   if (cur_id == crtc_id)
+   break;
+   }
+
+   drmModeFreeResources(res);
 
-   memset(, 0, sizeof(pfci));
-   pfci.crtc_id = crtc_id;
-   ret = drmIoctl(fd, DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID, );
-   igt_assert(ret == 0);
+   igt_assert(i < res->count_crtcs);
 
-   return pfci.pipe;
+   return i;
 }
 
 /**
-- 
2.5.0

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

[Intel-gfx] [i-g-t PATCH v2 0/2] Avoid calling DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID

[Tomeu Vizoso]

Hi,

these two patches remove the two last uses of
DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID, with the intention of making the
tests runnable on !i915.

I have looked in the kernel and cannot find any point where the pipe ID
didn't match the index of the CRTC as returned by GETRESOURCES, so I'm
not increasing the required libdrm version for now.

I wasn't able to fully run intel-gpu-overlay with the kms backend, but I
have checked with gdb that the changed code keeps working correctly (on
my system the CRTC with ID 21 is chosen for the pipe 0).

Thanks,

Tomeu

Changes in v2:
- Fix include path as suggested by Thomas
- Remove some dead code

Micah Fedke (2):
  lib: update kmstest_get_pipe_from_crtc_id
  overlay: Remove crtc<->pipe mapping code from kms-overlay

 lib/igt_kms.c | 33 -
 overlay/Makefile.am   |  4 ++--
 overlay/kms/kms-overlay.c | 16 
 3 files changed, 30 insertions(+), 23 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 5/7] drm/i915: Move load time clock gating callback init earlier

[Chris Wilson]

On Wed, Mar 09, 2016 at 05:31:44PM +0200, Imre Deak wrote:
> Split out the part initing the clock gating callbacks and move it
> earlier.
> 
> The rest of the callbacks in intel_init_pm() should be inited in the
> same way, but atm some of the callbacks are set only conditionally, so
> before doing this we need to make the setup unconditional and use
> instead some flags.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_dma.c  |  1 +
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_pm.c  | 65 
> 
>  3 files changed, 34 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 55b0c62..8cbe9ef 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1030,6 +1030,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>   intel_power_domains_init(dev_priv);
>   intel_irq_init(dev_priv);
>   intel_init_display_callbacks(dev_priv);
> + intel_init_clock_gating_callbacks(dev_priv);
>   intel_init_audio_callbacks(dev_priv);
>  
>   intel_runtime_pm_get(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 5264901..d3d31cc 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1596,6 +1596,7 @@ void intel_suspend_hw(struct drm_device *dev);
>  int ilk_wm_max_level(const struct drm_device *dev);
>  void intel_update_watermarks(struct drm_crtc *crtc);
>  void intel_init_pm(struct drm_device *dev);
> +void intel_init_clock_gating_callbacks(struct drm_i915_private *dev_priv);
>  void intel_pm_setup(struct drm_device *dev);
>  void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
>  void intel_gpu_ips_teardown(void);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d7aef17..02d3598 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7107,6 +7107,38 @@ void intel_suspend_hw(struct drm_device *dev)
>   lpt_suspend_hw(dev);
>  }
>  
> +void intel_init_clock_gating_callbacks(struct drm_i915_private *dev_priv)
> +{
> + if (IS_BROXTON(dev_priv))
> + dev_priv->display.init_clock_gating = bxt_init_clock_gating;
> + else if (IS_BROADWELL(dev_priv))
> + dev_priv->display.init_clock_gating = 
> broadwell_init_clock_gating;
> + else if (IS_CHERRYVIEW(dev_priv))
> + dev_priv->display.init_clock_gating = 
> cherryview_init_clock_gating;
> + else if (IS_HASWELL(dev_priv))
> + dev_priv->display.init_clock_gating = haswell_init_clock_gating;
> + else if (IS_IVYBRIDGE(dev_priv))
> + dev_priv->display.init_clock_gating = 
> ivybridge_init_clock_gating;
> + else if (IS_VALLEYVIEW(dev_priv))
> + dev_priv->display.init_clock_gating = 
> valleyview_init_clock_gating;
> + else if (IS_GEN6(dev_priv))
> + dev_priv->display.init_clock_gating = gen6_init_clock_gating;
> + else if (IS_GEN5(dev_priv))
> + dev_priv->display.init_clock_gating = 
> ironlake_init_clock_gating;
> + else if (IS_G4X(dev_priv))
> + dev_priv->display.init_clock_gating = g4x_init_clock_gating;
> + else if (IS_CRESTLINE(dev_priv))
> + dev_priv->display.init_clock_gating = 
> crestline_init_clock_gating;
> + else if (IS_BROADWATER(dev_priv))
> + dev_priv->display.init_clock_gating = 
> broadwater_init_clock_gating;
> + else if (IS_GEN3(dev_priv))
> + dev_priv->display.init_clock_gating = gen3_init_clock_gating;
> + else if (IS_I85X(dev_priv) || IS_I865G(dev_priv))
> + dev_priv->display.init_clock_gating = i85x_init_clock_gating;
> + else if (IS_GEN2(dev_priv))
> + dev_priv->display.init_clock_gating = i830_init_clock_gating;

else
MISSING_CASE()

We definitely need a warning here in case we fall through and leave a
most unexpected NULL pointer.
-Chris

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Support to enable TRTT on GEN9

[Goel, Akash]

On 3/9/2016 8:32 PM, Chris Wilson wrote:

On Wed, Mar 09, 2016 at 08:20:07PM +0530, Goel, Akash wrote:

What locks are we holding here?


+   else if (args->size < sizeof(trtt_params))
+   return -EINVAL;
+   else if (copy_from_user(_params,
+   to_user_ptr(args->value),
+   sizeof(trtt_params)))


Because whatever they are, we can't hold them here!


The struct_mutex lock was taken in the caller, ioctl function.
Ok, so need to release that before invoking copy_from_user.


(Imagine/write a test that passes in the trtt_params inside a GTT mmaping.)


This could cause a recursive locking of struct_mutex from the gem_fault() ?


Exactly. At the least lockdep should warn if we hit a fault along this
path (due to the illegal nesting of mmap_sem inside struct_mtuex).



I hope it won't look ungainly to unlock the struct_mutex before 
copy_from_user and lock it back right after that.







@@ -923,7 +1015,6 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
return PTR_ERR(ctx);
}

-   args->size = 0;


Awooga. Does every path then set it?



It is being set only for the TRTT case. For the other existing
cases, should it be explicitly set to 0, is that really needed ?


Yes. All other paths need to report .size = 0 (as they don't write
through a pointer).



Fine will add the args->size = 0 for all the other cases.


+   /* Mark the vma as permanently pinned */
+   vma->pin_count = 1;
+
+   /* Reserve from the 48 bit PPGTT space */
+   vma->node.start = segment_base_addr;
+   vma->node.size = GEN9_TRTT_SEGMENT_SIZE;
+   ret = drm_mm_reserve_node(>mm, >node);
+   if (ret) {
+   ret = i915_gem_evict_for_vma(vma);


Given that this has a known GPF, you need a test case that tries to
evict an active/hanging object in order to make room for the trtt.


In the new test case, will soft pin objects in TR-TT segment first.
Then later on enabling TR-TT, those objects should get evicted.


Yes. But make sure you have combinations of inactive, active, and
hanging objects inside the to-be-evicted segment. Those cover the most
frequent errors we have to handle (and easiest to reproduce).

Fine, will refer other tests logic to see how to ensure that previously 
soft pinned object is still marked as active, when the eviction happens 
on enabling TR-TT.


Sorry what is the hanging object type ?


+static int gen9_init_context_trtt(struct drm_i915_gem_request *req)


Since TRTT is render only, call this gen9_init_rcs_context_trtt()


Thanks, will change.


  static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
  {
struct i915_hw_ppgtt *ppgtt = req->ctx->ppgtt;
@@ -1693,6 +1757,20 @@ static int gen8_emit_bb_start(struct 
drm_i915_gem_request *req,
req->ctx->ppgtt->pd_dirty_rings &= ~intel_ring_flag(req->ring);
}

+   /*
+* Emitting LRIs to update the TRTT registers is most reliable, instead
+* of directly updating the context image, as this will ensure that
+* update happens in a serialized manner for the context and also
+* lite-restore scenario will get handled.
+*/
+   if ((req->ring->id == RCS) && req->ctx->trtt_info.update_trtt_params) {
+   ret = gen9_emit_trtt_regs(req);
+   if (ret)
+   return ret;
+
+   req->ctx->trtt_info.update_trtt_params = false;


Bah. Since we can only update the params once (EEXIST otherwise),
we emit the change when the user sets the new params.


Sorry couldn't get this point. We can't emit the params right away
when User sets them (only once). We need to emit/apply the params
(onetime) in a deferred manner on the next submission.


Why can't we? We can construct and submit a request setting the
registers inside the right context image at that point, and they never
change after that point.


Ok yes a new request can be constructed & submitted for the Context, 
emitting the LRIs to update the TRTT params in the Context image.
But won't that be relatively cumbersome considering that we are able to 
easily defer & conflate that with next batch submission, through an 
extra flag trtt_info.update_trtt_params.


Best regards
Akash



-Chris


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

[Intel-gfx] [PATCH 0/7] drm/i915: Move some load time init steps earlier

[Imre Deak]

While working on the CDCLK init code I realized that the driver load time
dependencies between the different init steps are rather difficult to follow
and so it's not obvious where some new piece of initialization needs to be
added.

Also because some things are initialized too late, other steps depending on
these must be initialized in a non-logical place or even split into multiple
parts. One example is the CDCLK initialization which needs the display
callbacks to be set already, but those callbacks are setup only late, so the
CDCLK initialization must be done in two parts.

As a generic solution, I suggest that we define the following load
time init phases:
- state init not requiring device access
  (i.e SW only, like initializing locks, allocating system memory, setting
   up callbacks, device attributes)
- minimal HW setup to enable MMIO access to the device
- state init requiring device access w/o side effects
  (i.e. read-only HW access, no interface registrations)
- state init causing device-wide side effects
  (i.e any HW access, no interface registration)
- registering all interfaces

This patchset adds the corresponding comment markers for the first
two phases above and one common phase for the rest of the current
init steps. Later we could also add the last three init phases above
and restructure the code accordingly.

For now I only moved earlier a few obvious init steps that fit these
new phases.

I smoke tested this on GEN4, SNB, BXT.

Imre Deak (7):
  drm/i915: Add comments marking the start of load time init phases
  drm/i915: Move laod time PCH detect, DPIO, power domain SW init
earlier
  drm/i915: Move load time IRQ SW init earlier
  drm/i915: Move load time display/audio callback init earlier
  drm/i915: Move load time clock gating callback init earlier
  drm/i915: Move load time runtime device info init earlier
  drm/i915: Move load time runtime PM get later

 drivers/gpu/drm/i915/i915_dma.c  | 33 ++--
 drivers/gpu/drm/i915/i915_irq.c  |  2 -
 drivers/gpu/drm/i915/intel_audio.c   | 12 +++---
 drivers/gpu/drm/i915/intel_display.c | 77 
 drivers/gpu/drm/i915/intel_drv.h |  4 +-
 drivers/gpu/drm/i915/intel_pm.c  | 65 +++---
 6 files changed, 95 insertions(+), 98 deletions(-)

-- 
2.5.0

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

[Intel-gfx] [PATCH 7/7] drm/i915: Move load time runtime PM get later

[Imre Deak]

We require the device to be powered only before accessing it, so we can
move this call later.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 76e5c69..cbf42a9 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1032,9 +1032,6 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
intel_init_display_callbacks(dev_priv);
intel_init_clock_gating_callbacks(dev_priv);
intel_init_audio_callbacks(dev_priv);
-
-   intel_runtime_pm_get(dev_priv);
-
intel_display_crc_init(dev);
 
i915_dump_device_info(dev_priv);
@@ -1048,6 +1045,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
 "It may not be fully functional.\n");
 
/* Init phase: setup device MMIO */
+   intel_runtime_pm_get(dev_priv);
+
if (i915_get_bridge_dev(dev)) {
ret = -EIO;
goto out_runtime_pm_put;
-- 
2.5.0

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

[Intel-gfx] [PATCH 4/7] drm/i915: Move load time display/audio callback init earlier

[Imre Deak]

All of this is SW only initialization so we can move them earlier. Move
the mutex init where the rest of the locks are inited. While at it also
convert dev to dev_priv.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c  |  3 ++
 drivers/gpu/drm/i915/intel_audio.c   | 12 +++---
 drivers/gpu/drm/i915/intel_display.c | 77 
 drivers/gpu/drm/i915/intel_drv.h |  3 +-
 4 files changed, 45 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9b3ed00..55b0c62 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1016,6 +1016,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
mutex_init(_priv->modeset_restore_lock);
mutex_init(_priv->av_mutex);
mutex_init(_priv->wm.wm_mutex);
+   mutex_init(_priv->pps_mutex);
 
ret = i915_workqueues_init(dev_priv);
if (ret < 0)
@@ -1028,6 +1029,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
intel_init_dpio(dev_priv);
intel_power_domains_init(dev_priv);
intel_irq_init(dev_priv);
+   intel_init_display_callbacks(dev_priv);
+   intel_init_audio_callbacks(dev_priv);
 
intel_runtime_pm_get(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 30f9214..1936752 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -567,20 +567,18 @@ void intel_audio_codec_disable(struct intel_encoder 
*intel_encoder)
  * intel_init_audio - Set up chip specific audio functions
  * @dev: drm device
  */
-void intel_init_audio(struct drm_device *dev)
+void intel_init_audio_callbacks(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
-   if (IS_G4X(dev)) {
+   if (IS_G4X(dev_priv)) {
dev_priv->display.audio_codec_enable = g4x_audio_codec_enable;
dev_priv->display.audio_codec_disable = g4x_audio_codec_disable;
-   } else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
+   } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
dev_priv->display.audio_codec_enable = ilk_audio_codec_enable;
dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
-   } else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8) {
+   } else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8) {
dev_priv->display.audio_codec_enable = hsw_audio_codec_enable;
dev_priv->display.audio_codec_disable = hsw_audio_codec_disable;
-   } else if (HAS_PCH_SPLIT(dev)) {
+   } else if (HAS_PCH_SPLIT(dev_priv)) {
dev_priv->display.audio_codec_enable = ilk_audio_codec_enable;
dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 62d36a7..5170718 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15095,22 +15095,20 @@ static const struct drm_mode_config_funcs 
intel_mode_funcs = {
 };
 
 /* Set up chip specific display functions */
-static void intel_init_display(struct drm_device *dev)
+void intel_init_display_callbacks(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
-   if (HAS_PCH_SPLIT(dev) || IS_G4X(dev))
+   if (HAS_PCH_SPLIT(dev_priv) || IS_G4X(dev_priv))
dev_priv->display.find_dpll = g4x_find_best_dpll;
-   else if (IS_CHERRYVIEW(dev))
+   else if (IS_CHERRYVIEW(dev_priv))
dev_priv->display.find_dpll = chv_find_best_dpll;
-   else if (IS_VALLEYVIEW(dev))
+   else if (IS_VALLEYVIEW(dev_priv))
dev_priv->display.find_dpll = vlv_find_best_dpll;
-   else if (IS_PINEVIEW(dev))
+   else if (IS_PINEVIEW(dev_priv))
dev_priv->display.find_dpll = pnv_find_best_dpll;
else
dev_priv->display.find_dpll = i9xx_find_best_dpll;
 
-   if (INTEL_INFO(dev)->gen >= 9) {
+   if (INTEL_INFO(dev_priv)->gen >= 9) {
dev_priv->display.get_pipe_config = haswell_get_pipe_config;
dev_priv->display.get_initial_plane_config =
skylake_get_initial_plane_config;
@@ -15118,7 +15116,7 @@ static void intel_init_display(struct drm_device *dev)
haswell_crtc_compute_clock;
dev_priv->display.crtc_enable = haswell_crtc_enable;
dev_priv->display.crtc_disable = haswell_crtc_disable;
-   } else if (HAS_DDI(dev)) {
+   } else if (HAS_DDI(dev_priv)) {
dev_priv->display.get_pipe_config = haswell_get_pipe_config;
dev_priv->display.get_initial_plane_config =

[Intel-gfx] [PATCH 1/7] drm/i915: Add comments marking the start of load time init phases

[Imre Deak]

To make it easier to get init time dependencies right during driver
loading, define the following init phases:
- state init not requiring device access
- minimal HW setup to enable MMIO access to the device
- state init requiring device access

In the future the 3rd phase could be fine-grained further for example:
- state init requiring device access w/o side effects
  (i.e. read-only HW access, no interface registrations)
- state init causing device side effects
  (i.e any HW access, no interface registration)
- registering all interfaces

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4aa3db6..d3dc4d4 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -991,6 +991,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long 
flags)
int ret = 0;
uint32_t aperture_size;
 
+   /* Init phase: setup state not requiring accessing the device. */
info = (struct intel_device_info *) flags;
 
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
@@ -1036,6 +1037,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
DRM_INFO("This is an early pre-production Haswell machine. "
 "It may not be fully functional.\n");
 
+   /* Init phase: setup device MMIO */
if (i915_get_bridge_dev(dev)) {
ret = -EIO;
goto out_runtime_pm_put;
@@ -1050,6 +1052,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
 
intel_uncore_init(dev);
 
+   /* Init phase: setup state requiring accessing the device. */
ret = i915_gem_gtt_init(dev);
if (ret)
goto out_uncore_fini;
-- 
2.5.0

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

[Intel-gfx] [PATCH 3/7] drm/i915: Move load time IRQ SW init earlier

[Imre Deak]

Most of the IRQ init is setting up callbacks so move that part earlier.
Leave the pm_qos_add_request() call in place.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c | 5 -
 drivers/gpu/drm/i915/i915_irq.c | 2 --
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9269f1c..9b3ed00 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1027,6 +1027,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
intel_pm_setup(dev);
intel_init_dpio(dev_priv);
intel_power_domains_init(dev_priv);
+   intel_irq_init(dev_priv);
 
intel_runtime_pm_get(dev_priv);
 
@@ -1103,7 +1104,9 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
dev_priv->gtt.mtrr = arch_phys_wc_add(dev_priv->gtt.mappable_base,
  aperture_size);
 
-   intel_irq_init(dev_priv);
+   pm_qos_add_request(_priv->pm_qos, PM_QOS_CPU_DMA_LATENCY,
+  PM_QOS_DEFAULT_VALUE);
+
intel_uncore_sanitize(dev);
 
intel_opregion_setup(dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 53e5104..8c7f730 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4564,8 +4564,6 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
INIT_DELAYED_WORK(_priv->gpu_error.hangcheck_work,
  i915_hangcheck_elapsed);
 
-   pm_qos_add_request(_priv->pm_qos, PM_QOS_CPU_DMA_LATENCY, 
PM_QOS_DEFAULT_VALUE);
-
if (IS_GEN2(dev_priv)) {
dev->max_vblank_count = 0;
dev->driver->get_vblank_counter = i8xx_get_vblank_counter;
-- 
2.5.0

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

[Intel-gfx] [PATCH 5/7] drm/i915: Move load time clock gating callback init earlier

[Imre Deak]

Split out the part initing the clock gating callbacks and move it
earlier.

The rest of the callbacks in intel_init_pm() should be inited in the
same way, but atm some of the callbacks are set only conditionally, so
before doing this we need to make the setup unconditional and use
instead some flags.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c  |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 65 
 3 files changed, 34 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 55b0c62..8cbe9ef 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1030,6 +1030,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
intel_power_domains_init(dev_priv);
intel_irq_init(dev_priv);
intel_init_display_callbacks(dev_priv);
+   intel_init_clock_gating_callbacks(dev_priv);
intel_init_audio_callbacks(dev_priv);
 
intel_runtime_pm_get(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5264901..d3d31cc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1596,6 +1596,7 @@ void intel_suspend_hw(struct drm_device *dev);
 int ilk_wm_max_level(const struct drm_device *dev);
 void intel_update_watermarks(struct drm_crtc *crtc);
 void intel_init_pm(struct drm_device *dev);
+void intel_init_clock_gating_callbacks(struct drm_i915_private *dev_priv);
 void intel_pm_setup(struct drm_device *dev);
 void intel_gpu_ips_init(struct drm_i915_private *dev_priv);
 void intel_gpu_ips_teardown(void);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d7aef17..02d3598 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7107,6 +7107,38 @@ void intel_suspend_hw(struct drm_device *dev)
lpt_suspend_hw(dev);
 }
 
+void intel_init_clock_gating_callbacks(struct drm_i915_private *dev_priv)
+{
+   if (IS_BROXTON(dev_priv))
+   dev_priv->display.init_clock_gating = bxt_init_clock_gating;
+   else if (IS_BROADWELL(dev_priv))
+   dev_priv->display.init_clock_gating = 
broadwell_init_clock_gating;
+   else if (IS_CHERRYVIEW(dev_priv))
+   dev_priv->display.init_clock_gating = 
cherryview_init_clock_gating;
+   else if (IS_HASWELL(dev_priv))
+   dev_priv->display.init_clock_gating = haswell_init_clock_gating;
+   else if (IS_IVYBRIDGE(dev_priv))
+   dev_priv->display.init_clock_gating = 
ivybridge_init_clock_gating;
+   else if (IS_VALLEYVIEW(dev_priv))
+   dev_priv->display.init_clock_gating = 
valleyview_init_clock_gating;
+   else if (IS_GEN6(dev_priv))
+   dev_priv->display.init_clock_gating = gen6_init_clock_gating;
+   else if (IS_GEN5(dev_priv))
+   dev_priv->display.init_clock_gating = 
ironlake_init_clock_gating;
+   else if (IS_G4X(dev_priv))
+   dev_priv->display.init_clock_gating = g4x_init_clock_gating;
+   else if (IS_CRESTLINE(dev_priv))
+   dev_priv->display.init_clock_gating = 
crestline_init_clock_gating;
+   else if (IS_BROADWATER(dev_priv))
+   dev_priv->display.init_clock_gating = 
broadwater_init_clock_gating;
+   else if (IS_GEN3(dev_priv))
+   dev_priv->display.init_clock_gating = gen3_init_clock_gating;
+   else if (IS_I85X(dev_priv) || IS_I865G(dev_priv))
+   dev_priv->display.init_clock_gating = i85x_init_clock_gating;
+   else if (IS_GEN2(dev_priv))
+   dev_priv->display.init_clock_gating = i830_init_clock_gating;
+}
+
 /* Set up chip specific power management-related functions */
 void intel_init_pm(struct drm_device *dev)
 {
@@ -7123,10 +7155,6 @@ void intel_init_pm(struct drm_device *dev)
/* For FIFO watermark updates */
if (INTEL_INFO(dev)->gen >= 9) {
skl_setup_wm_latency(dev);
-
-   if (IS_BROXTON(dev))
-   dev_priv->display.init_clock_gating =
-   bxt_init_clock_gating;
dev_priv->display.update_wm = skl_update_wm;
} else if (HAS_PCH_SPLIT(dev)) {
ilk_setup_wm_latency(dev);
@@ -7146,29 +7174,12 @@ void intel_init_pm(struct drm_device *dev)
DRM_DEBUG_KMS("Failed to read display plane latency. "
  "Disable CxSR\n");
}
-
-   if (IS_GEN5(dev))
-   dev_priv->display.init_clock_gating = 
ironlake_init_clock_gating;
-   else if (IS_GEN6(dev))
-   dev_priv->display.init_clock_gating = 
gen6_init_clock_gating;
-   else if (IS_IVYBRIDGE(dev))
-   dev_priv->display.init_clock_gating = 

[Intel-gfx] [PATCH 6/7] drm/i915: Move load time runtime device info init earlier

[Imre Deak]

This init step accesses the device, but doesn't have any device
specific side effect. It also sets up some platform specific
attributes that may be required early, so move it earlier.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 8cbe9ef..76e5c69 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1060,6 +1060,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
intel_uncore_init(dev);
 
/* Init phase: setup state requiring accessing the device. */
+   intel_device_info_runtime_init(dev);
+
ret = i915_gem_gtt_init(dev);
if (ret)
goto out_uncore_fini;
@@ -1134,8 +1136,6 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
DRM_DEBUG_DRIVER("can't enable MSI");
}
 
-   intel_device_info_runtime_init(dev);
-
if (INTEL_INFO(dev)->num_pipes) {
ret = drm_vblank_init(dev, INTEL_INFO(dev)->num_pipes);
if (ret)
-- 
2.5.0

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

[Intel-gfx] [PATCH 2/7] drm/i915: Move laod time PCH detect, DPIO, power domain SW init earlier

[Imre Deak]

These are all SW only init steps, so we can move them earlier.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index d3dc4d4..9269f1c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1021,7 +1021,12 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
if (ret < 0)
goto out_free_priv;
 
+   /* This must be called before any calls to HAS_PCH_* */
+   intel_detect_pch(dev);
+
intel_pm_setup(dev);
+   intel_init_dpio(dev_priv);
+   intel_power_domains_init(dev_priv);
 
intel_runtime_pm_get(dev_priv);
 
@@ -1047,9 +1052,6 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
if (ret < 0)
goto put_bridge;
 
-   /* This must be called before any calls to HAS_PCH_* */
-   intel_detect_pch(dev);
-
intel_uncore_init(dev);
 
/* Init phase: setup state requiring accessing the device. */
@@ -1127,16 +1129,12 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
 
intel_device_info_runtime_init(dev);
 
-   intel_init_dpio(dev_priv);
-
if (INTEL_INFO(dev)->num_pipes) {
ret = drm_vblank_init(dev, INTEL_INFO(dev)->num_pipes);
if (ret)
goto out_gem_unload;
}
 
-   intel_power_domains_init(dev_priv);
-
ret = i915_load_modeset_init(dev);
if (ret < 0) {
DRM_ERROR("failed to init modeset\n");
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: exercise invalid rotations

[Ville Syrjälä]

On Wed, Mar 09, 2016 at 03:05:24PM +, Matthew Auld wrote:
> Add expect-to-fail tests for invalid rotations on each of the plane types.
> 
> Cc: Joonas Lahtinen 
> Signed-off-by: Matthew Auld 
> ---
>  tests/kms_rotation_crc.c | 96 
> 
>  1 file changed, 96 insertions(+)
> 
> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
> index f94f8f1..a0a5a0f 100644
> --- a/tests/kms_rotation_crc.c
> +++ b/tests/kms_rotation_crc.c
> @@ -479,6 +479,68 @@ err_commit:
>   igt_assert(ret == 0);
>  }
>  
> +static void test_plane_rotation_invalid(data_t *data, enum igt_plane 
> plane_type)
> +{
> + igt_display_t *display = >display;
> + uint64_t tiling = LOCAL_DRM_FORMAT_MOD_NONE;
> + uint32_t format = DRM_FORMAT_XRGB;
> + int bpp = igt_drm_format_to_bpp(format);
> + enum igt_commit_style commit = COMMIT_LEGACY;
> + int fd = data->gfx_fd;
> + igt_output_t *output = >outputs[0];
> + igt_plane_t *plane;
> + drmModeModeInfo *mode;
> + unsigned int stride, size, w, h;
> + uint32_t gem_handle;
> + int ret;
> +
> + igt_require(output != NULL && output->valid == true);
> +
> + plane = igt_output_get_plane(output, plane_type);
> + igt_require(igt_plane_supports_rotation(plane));
> +
> + if (plane_type == IGT_PLANE_PRIMARY || plane_type == IGT_PLANE_CURSOR) {
> + igt_require(data->display.has_universal_planes);
> + commit = COMMIT_UNIVERSAL;
> + }
> +
> + mode = igt_output_get_mode(output);
> + w = mode->hdisplay;
> + h = mode->vdisplay;
> +
> + for (stride = 512; stride < (w * bpp / 8); stride *= 2)
> + ;
> + for (size = 1024*1024; size < stride * h; size *= 2)
> + ;
> +
> + gem_handle = gem_create(fd, size);
> + ret = __gem_set_tiling(fd, gem_handle, I915_TILING_Y, stride);

Y tiled fb will be rejected for gen < 9, should use X/linear for those.
Actually using X/linear for gen >= 9 would also be interesting to make
sure we reject 90/270 for those even when they are otherwise listead as
supported rotations.

Also why hand roll the fb creation instead of using the igt_fb stuff?

> + igt_assert(ret == 0);
> +
> + do_or_die(__kms_addfb(fd, gem_handle, w, h, stride,
> +   format, tiling, LOCAL_DRM_MODE_FB_MODIFIERS,
> +   >fb.fb_id));
> + data->fb.width = w;
> + data->fb.height = h;
> + data->fb.gem_handle = gem_handle;
> +
> + igt_plane_set_fb(plane, NULL);
> + igt_display_commit(display);
> +
> + igt_plane_set_rotation(plane, data->rotation);
> + igt_plane_set_fb(plane, >fb);
> +
> + drmModeObjectSetProperty(fd, plane->drm_plane->plane_id,
> +  DRM_MODE_OBJECT_PLANE,
> +  plane->rotation_property,
> +  plane->rotation);

What's this doing here?

> + ret = igt_display_try_commit2(display, commit);
> +
> + kmstest_restore_vt_mode();
> + igt_remove_fb(fd, >fb);
> + igt_assert_eq(ret, -EINVAL);
> +}
> +
>  igt_main
>  {
>   data_t data = {};
> @@ -579,6 +641,40 @@ igt_main
>   test_plane_rotation_exhaust_fences(, IGT_PLANE_PRIMARY);
>   }
>  
> + igt_subtest_f("primary-rotation-90-invalid") {
> + igt_require(gen < 9);
> + data.rotation = IGT_ROTATION_90;
> + test_plane_rotation_invalid(, IGT_PLANE_PRIMARY);
> + }
> +
> + igt_subtest_f("primary-rotation-270-invalid") {
> + igt_require(gen < 9);
> + data.rotation = IGT_ROTATION_270;
> + test_plane_rotation_invalid(, IGT_PLANE_PRIMARY);
> + }
> +
> + igt_subtest_f("sprite-rotation-90-invalid") {
> + igt_require(gen < 9);
> + data.rotation = IGT_ROTATION_90;
> + test_plane_rotation_invalid(, IGT_PLANE_2);
> + }
> +
> + igt_subtest_f("sprite-rotation-270-invalid") {
> + igt_require(gen < 9);
> + data.rotation = IGT_ROTATION_270;
> + test_plane_rotation_invalid(, IGT_PLANE_2);
> + }
> +
> + igt_subtest_f("cursor-rotation-90-invalid") {
> + data.rotation = IGT_ROTATION_90;
> + test_plane_rotation_invalid(, IGT_PLANE_CURSOR);
> + }
> +
> + igt_subtest_f("cursor-rotation-270-invalid") {
> + data.rotation = IGT_ROTATION_270;
> + test_plane_rotation_invalid(, IGT_PLANE_CURSOR);
> + }

These seem rather needlessly hardcody. I would suggest looking at the
supported rotations for each plane and picking some invalid ones based
on that.

> +
>   igt_fixture {
>   igt_display_fini();
>   }
> -- 
> 2.4.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: GMBUS fixes and whatnot

[Ville Syrjälä]

On Tue, Mar 08, 2016 at 07:25:05AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: GMBUS fixes and whatnot
> URL   : https://patchwork.freedesktop.org/series/4178/
> State : warning
> 
> == Summary ==
> 
> Series 4178v1 drm/i915: GMBUS fixes and whatnot
> http://patchwork.freedesktop.org/api/1.0/series/4178/revisions/1/mbox/
> 
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> fail   -> PASS   (hsw-gt2)
> fail   -> PASS   (hsw-brixbox)
> Subgroup basic-plain-flip:
> dmesg-warn -> PASS   (hsw-gt2)
> pass   -> DMESG-WARN (hsw-brixbox)

[  276.675359]  [] hsw_write32+0x1dc/0x270 [i915]
[  276.675387]  [] _ilk_disable_lp_wm+0x98/0xd0 [i915]

> Test kms_frontbuffer_tracking:
> Subgroup basic:
> pass   -> DMESG-WARN (snb-x220t)

[  209.900547]  [] gen6_write32+0x1dc/0x270 [i915]
[  209.900584]  [] _ilk_disable_lp_wm+0x98/0xd0 [i915]

> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-b:
> pass   -> DMESG-WARN (hsw-brixbox)

[  301.672605]  [] hsw_write32+0x21b/0x270 [i915]
[  301.672614]  [] _ilk_disable_lp_wm+0x98/0xd0 [i915]

> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> dmesg-fail -> FAIL   (snb-x220t)

dmesg ping pong
[   89.058704]  [] gen6_write32+0x1dc/0x270 [i915]
[   89.058777]  [] _ilk_disable_lp_wm+0x98/0xd0 [i915]

So all are
https://bugs.freedesktop.org/show_bug.cgi?id=94349

> Subgroup basic-rte:
> dmesg-warn -> PASS   (snb-x220t)
> 
> bdw-nuci7total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:11 
> bsw-nuc-2total:183  pass:149  dwarn:0   dfail:0   fail:0   skip:34 
> byt-nuc  total:183  pass:152  dwarn:0   dfail:0   fail:0   skip:31 
> hsw-brixbox  total:183  pass:162  dwarn:2   dfail:0   fail:0   skip:19 
> hsw-gt2  total:183  pass:169  dwarn:0   dfail:0   fail:0   skip:14 
> ivb-t430stotal:183  pass:162  dwarn:0   dfail:0   fail:0   skip:21 
> skl-i5k-2total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20 
> snb-dellxps  total:183  pass:153  dwarn:1   dfail:0   fail:0   skip:29 
> snb-x220ttotal:183  pass:153  dwarn:1   dfail:0   fail:1   skip:28 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1537/
> 
> dd7b01270c8b2048c35b3c336431c50c05a07718 drm-intel-nightly: 
> 2016y-03m-07d-18h-03m-57s UTC integration manifest
> 52f3fbed204983eeefcfd2e6bcdfd95bcfd6a324 drm/i915: Make GMBUS timeout message 
> DRM_DEBUG_KMS
> 3a2a906288c099bc6a8ddf81092da3423b6065c9 drm/i915: Restore GMBUS operation 
> after a failed bit-banging fallback
> 770fe6a15dbf7330b964ddd3db44c6068b607669 drm/i915: Protect force_bit with 
> gmbus_mutex
> 4aa7bf0b8885ef5bd55280c51bd0d48822d02c2e drm/i915: Actually retry with 
> bit-banging after GMBUS timeout

-- 
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/4] drm/i915: Actually retry with bit-banging after GMBUS timeout

[Ville Syrjälä]

On Mon, Mar 07, 2016 at 07:06:37PM +0200, Jani Nikula wrote:
> On Mon, 07 Mar 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > After the GMBUS transfer times out, we set force_bit=1 and
> > return -EAGAIN expecting the i2c core to call the .master_xfer
> > hook again so that we will retry the same transfer via bit-banging.
> > This is in case the gmbus hardware is somehow faulty.
> >
> > Unfortunately we left adapter->retries to 0, meaning the i2c core
> > didn't actually do the retry. Let's tell the core we want one retry
> > when we return -EAGAIN.
> >
> > Note that i2c-algo-bit also uses this retry count for some internal
> > retries, so we'll end up increasing those a bit as well.
> 
> I think I must have confused this with the dp aux i2c adapter retries
> which does get initialized to 3. Meh.
> 
> Reviewed-by: Jani Nikula 

Patch pushed to dinq. Thanks for the review.

> 
> >
> > Cc: Jani Nikula 
> > Cc: drm-intel-fi...@lists.freedesktop.org
> > Fixes: bffce907d640 ("drm/i915: abstract i2c bit banging fallback in gmbus 
> > xfer")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_i2c.c | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> > b/drivers/gpu/drm/i915/intel_i2c.c
> > index deb8282c26d8..52fbe530fc9e 100644
> > --- a/drivers/gpu/drm/i915/intel_i2c.c
> > +++ b/drivers/gpu/drm/i915/intel_i2c.c
> > @@ -664,6 +664,12 @@ int intel_setup_gmbus(struct drm_device *dev)
> >  
> > bus->adapter.algo = _algorithm;
> >  
> > +   /*
> > +* We wish to retry with bit banging
> > +* after a timed out GMBUS attempt.
> > +*/
> > +   bus->adapter.retries = 1;
> > +
> > /* By default use a conservative clock rate */
> > bus->reg0 = pin | GMBUS_RATE_100KHZ;
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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

[Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: exercise invalid rotations

[Matthew Auld]

Add expect-to-fail tests for invalid rotations on each of the plane types.

Cc: Joonas Lahtinen 
Signed-off-by: Matthew Auld 
---
 tests/kms_rotation_crc.c | 96 
 1 file changed, 96 insertions(+)

diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index f94f8f1..a0a5a0f 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -479,6 +479,68 @@ err_commit:
igt_assert(ret == 0);
 }
 
+static void test_plane_rotation_invalid(data_t *data, enum igt_plane 
plane_type)
+{
+   igt_display_t *display = >display;
+   uint64_t tiling = LOCAL_DRM_FORMAT_MOD_NONE;
+   uint32_t format = DRM_FORMAT_XRGB;
+   int bpp = igt_drm_format_to_bpp(format);
+   enum igt_commit_style commit = COMMIT_LEGACY;
+   int fd = data->gfx_fd;
+   igt_output_t *output = >outputs[0];
+   igt_plane_t *plane;
+   drmModeModeInfo *mode;
+   unsigned int stride, size, w, h;
+   uint32_t gem_handle;
+   int ret;
+
+   igt_require(output != NULL && output->valid == true);
+
+   plane = igt_output_get_plane(output, plane_type);
+   igt_require(igt_plane_supports_rotation(plane));
+
+   if (plane_type == IGT_PLANE_PRIMARY || plane_type == IGT_PLANE_CURSOR) {
+   igt_require(data->display.has_universal_planes);
+   commit = COMMIT_UNIVERSAL;
+   }
+
+   mode = igt_output_get_mode(output);
+   w = mode->hdisplay;
+   h = mode->vdisplay;
+
+   for (stride = 512; stride < (w * bpp / 8); stride *= 2)
+   ;
+   for (size = 1024*1024; size < stride * h; size *= 2)
+   ;
+
+   gem_handle = gem_create(fd, size);
+   ret = __gem_set_tiling(fd, gem_handle, I915_TILING_Y, stride);
+   igt_assert(ret == 0);
+
+   do_or_die(__kms_addfb(fd, gem_handle, w, h, stride,
+ format, tiling, LOCAL_DRM_MODE_FB_MODIFIERS,
+ >fb.fb_id));
+   data->fb.width = w;
+   data->fb.height = h;
+   data->fb.gem_handle = gem_handle;
+
+   igt_plane_set_fb(plane, NULL);
+   igt_display_commit(display);
+
+   igt_plane_set_rotation(plane, data->rotation);
+   igt_plane_set_fb(plane, >fb);
+
+   drmModeObjectSetProperty(fd, plane->drm_plane->plane_id,
+DRM_MODE_OBJECT_PLANE,
+plane->rotation_property,
+plane->rotation);
+   ret = igt_display_try_commit2(display, commit);
+
+   kmstest_restore_vt_mode();
+   igt_remove_fb(fd, >fb);
+   igt_assert_eq(ret, -EINVAL);
+}
+
 igt_main
 {
data_t data = {};
@@ -579,6 +641,40 @@ igt_main
test_plane_rotation_exhaust_fences(, IGT_PLANE_PRIMARY);
}
 
+   igt_subtest_f("primary-rotation-90-invalid") {
+   igt_require(gen < 9);
+   data.rotation = IGT_ROTATION_90;
+   test_plane_rotation_invalid(, IGT_PLANE_PRIMARY);
+   }
+
+   igt_subtest_f("primary-rotation-270-invalid") {
+   igt_require(gen < 9);
+   data.rotation = IGT_ROTATION_270;
+   test_plane_rotation_invalid(, IGT_PLANE_PRIMARY);
+   }
+
+   igt_subtest_f("sprite-rotation-90-invalid") {
+   igt_require(gen < 9);
+   data.rotation = IGT_ROTATION_90;
+   test_plane_rotation_invalid(, IGT_PLANE_2);
+   }
+
+   igt_subtest_f("sprite-rotation-270-invalid") {
+   igt_require(gen < 9);
+   data.rotation = IGT_ROTATION_270;
+   test_plane_rotation_invalid(, IGT_PLANE_2);
+   }
+
+   igt_subtest_f("cursor-rotation-90-invalid") {
+   data.rotation = IGT_ROTATION_90;
+   test_plane_rotation_invalid(, IGT_PLANE_CURSOR);
+   }
+
+   igt_subtest_f("cursor-rotation-270-invalid") {
+   data.rotation = IGT_ROTATION_270;
+   test_plane_rotation_invalid(, IGT_PLANE_CURSOR);
+   }
+
igt_fixture {
igt_display_fini();
}
-- 
2.4.3

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Support to enable TRTT on GEN9

[Chris Wilson]

On Wed, Mar 09, 2016 at 08:20:07PM +0530, Goel, Akash wrote:
> >What locks are we holding here?
> >
> >>+   else if (args->size < sizeof(trtt_params))
> >>+   return -EINVAL;
> >>+   else if (copy_from_user(_params,
> >>+   to_user_ptr(args->value),
> >>+   sizeof(trtt_params)))
> >
> >Because whatever they are, we can't hold them here!
> >
> The struct_mutex lock was taken in the caller, ioctl function.
> Ok, so need to release that before invoking copy_from_user.
> 
> >(Imagine/write a test that passes in the trtt_params inside a GTT mmaping.)
> 
> This could cause a recursive locking of struct_mutex from the gem_fault() ?

Exactly. At the least lockdep should warn if we hit a fault along this
path (due to the illegal nesting of mmap_sem inside struct_mtuex).

> 
> >
> >>@@ -923,7 +1015,6 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
> >>*dev, void *data,
> >>return PTR_ERR(ctx);
> >>}
> >>
> >>-   args->size = 0;
> >
> >Awooga. Does every path then set it?
> >
> 
> It is being set only for the TRTT case. For the other existing
> cases, should it be explicitly set to 0, is that really needed ?

Yes. All other paths need to report .size = 0 (as they don't write
through a pointer).

> >>+struct i915_vma *
> >>+intel_trtt_context_allocate_vma(struct i915_address_space *vm,
> >>+   uint64_t segment_base_addr)
> >>+{
> >>+   struct i915_vma *vma;
> >>+   int ret;
> >>+
> >>+   vma = kmem_cache_zalloc(to_i915(vm->dev)->vmas, GFP_KERNEL);
> >>+   if (!vma)
> >>+   return ERR_PTR(-ENOMEM);
> >>+
> >>+   INIT_LIST_HEAD(>obj_link);
> >>+   INIT_LIST_HEAD(>vm_link);
> >>+   INIT_LIST_HEAD(>exec_list);
> >>+   vma->vm = vm;
> >>+   i915_ppgtt_get(i915_vm_to_ppgtt(vm));
> >>+
> >>+   /* Mark the vma as permanently pinned */
> >>+   vma->pin_count = 1;
> >>+
> >>+   /* Reserve from the 48 bit PPGTT space */
> >>+   vma->node.start = segment_base_addr;
> >>+   vma->node.size = GEN9_TRTT_SEGMENT_SIZE;
> >>+   ret = drm_mm_reserve_node(>mm, >node);
> >>+   if (ret) {
> >>+   ret = i915_gem_evict_for_vma(vma);
> >
> >Given that this has a known GPF, you need a test case that tries to
> >evict an active/hanging object in order to make room for the trtt.
> >
> In the new test case, will soft pin objects in TR-TT segment first.
> Then later on enabling TR-TT, those objects should get evicted.

Yes. But make sure you have combinations of inactive, active, and
hanging objects inside the to-be-evicted segment. Those cover the most
frequent errors we have to handle (and easiest to reproduce).
 
> >>+static int gen9_init_context_trtt(struct drm_i915_gem_request *req)
> >
> >Since TRTT is render only, call this gen9_init_rcs_context_trtt()
> >
> Thanks, will change.
> 
> >>  static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
> >>  {
> >>struct i915_hw_ppgtt *ppgtt = req->ctx->ppgtt;
> >>@@ -1693,6 +1757,20 @@ static int gen8_emit_bb_start(struct 
> >>drm_i915_gem_request *req,
> >>req->ctx->ppgtt->pd_dirty_rings &= ~intel_ring_flag(req->ring);
> >>}
> >>
> >>+   /*
> >>+* Emitting LRIs to update the TRTT registers is most reliable, instead
> >>+* of directly updating the context image, as this will ensure that
> >>+* update happens in a serialized manner for the context and also
> >>+* lite-restore scenario will get handled.
> >>+*/
> >>+   if ((req->ring->id == RCS) && req->ctx->trtt_info.update_trtt_params) {
> >>+   ret = gen9_emit_trtt_regs(req);
> >>+   if (ret)
> >>+   return ret;
> >>+
> >>+   req->ctx->trtt_info.update_trtt_params = false;
> >
> >Bah. Since we can only update the params once (EEXIST otherwise),
> >we emit the change when the user sets the new params.
> 
> Sorry couldn't get this point. We can't emit the params right away
> when User sets them (only once). We need to emit/apply the params
> (onetime) in a deferred manner on the next submission.

Why can't we? We can construct and submit a request setting the
registers inside the right context image at that point, and they never
change after that point.
-Chris

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Support to enable TRTT on GEN9

[Goel, Akash]

On 3/9/2016 5:34 PM, Chris Wilson wrote:

On Wed, Mar 09, 2016 at 05:00:24PM +0530, akash.g...@intel.com wrote:

+static int
+intel_context_get_trtt(struct intel_context *ctx,
+  struct drm_i915_gem_context_param *args)
+{
+   struct drm_i915_gem_context_trtt_param trtt_params;
+   struct drm_device *dev = ctx->i915->dev;
+
+   if (!HAS_TRTT(dev) || !USES_FULL_48BIT_PPGTT(dev)) {


Both of these actually inspect dev_priv (and magically convert dev into
dev_priv).


Sorry, my bad. Missed the __I915__ macro.



+   return -ENODEV;
+   } else if (args->size < sizeof(trtt_params)) {
+   args->size = sizeof(trtt_params);
+   } else {
+   trtt_params.segment_base_addr =
+   ctx->trtt_info.segment_base_addr;
+   trtt_params.l3_table_address =
+   ctx->trtt_info.l3_table_address;
+   trtt_params.null_tile_val =
+   ctx->trtt_info.null_tile_val;
+   trtt_params.invd_tile_val =
+   ctx->trtt_info.invd_tile_val;
+
+   if (__copy_to_user(to_user_ptr(args->value),
+  _params,
+  sizeof(trtt_params)))
+   return -EFAULT;


args->size = sizeof(trtt_params);

in case the use passed in size > sizeof(trtt_params) we want to report
how many bytes we wrote.


fine will add this.



+   }
+
+   return 0;
+}
+
+static int
+intel_context_set_trtt(struct intel_context *ctx,
+  struct drm_i915_gem_context_param *args)
+{
+   struct drm_i915_gem_context_trtt_param trtt_params;
+   struct drm_device *dev = ctx->i915->dev;
+
+   if (!HAS_TRTT(dev) || !USES_FULL_48BIT_PPGTT(dev))


Ditto (dev_priv)


+   return -ENODEV;
+   else if (ctx->flags & CONTEXT_USE_TRTT)
+   return -EEXIST;


What locks are we holding here?


+   else if (args->size < sizeof(trtt_params))
+   return -EINVAL;
+   else if (copy_from_user(_params,
+   to_user_ptr(args->value),
+   sizeof(trtt_params)))


Because whatever they are, we can't hold them here!


The struct_mutex lock was taken in the caller, ioctl function.
Ok, so need to release that before invoking copy_from_user.


(Imagine/write a test that passes in the trtt_params inside a GTT mmaping.)


This could cause a recursive locking of struct_mutex from the gem_fault() ?




@@ -923,7 +1015,6 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
return PTR_ERR(ctx);
}

-   args->size = 0;


Awooga. Does every path then set it?



It is being set only for the TRTT case. For the other existing cases, 
should it be explicitly set to 0, is that really needed ?



diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7b8de85..8de0319 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2169,6 +2169,17 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
  {
gtt_write_workarounds(dev);

+   if (HAS_TRTT(dev) && USES_FULL_48BIT_PPGTT(dev)) {
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   /*
+* Globally enable TR-TT support in Hw.
+* Still TR-TT enabling on per context basis is required.
+* Non-trtt contexts are not affected by this setting.
+*/
+   I915_WRITE(GEN9_TR_CHICKEN_BIT_VECTOR,
+  GEN9_TRTT_BYPASS_DISABLE);
+   }
+
/* In the case of execlists, PPGTT is enabled by the context descriptor
 * and the PDPs are contained within the context itself.  We don't
 * need to do anything here. */
@@ -3368,6 +3379,57 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct 
drm_i915_gem_object *obj,

  }

+void intel_trtt_context_destroy_vma(struct i915_vma *vma)
+{
+   struct i915_address_space *vm = vma->vm;
+
+   WARN_ON(!list_empty(>obj_link));
+   WARN_ON(!list_empty(>vm_link));
+   WARN_ON(!list_empty(>exec_list));


WARN_ON(!vma->pin_count);


Thanks, will add.




+
+   drm_mm_remove_node(>node);
+   i915_ppgtt_put(i915_vm_to_ppgtt(vm));
+   kmem_cache_free(to_i915(vm->dev)->vmas, vma);
+}
+
+struct i915_vma *
+intel_trtt_context_allocate_vma(struct i915_address_space *vm,
+   uint64_t segment_base_addr)
+{
+   struct i915_vma *vma;
+   int ret;
+
+   vma = kmem_cache_zalloc(to_i915(vm->dev)->vmas, GFP_KERNEL);
+   if (!vma)
+   return ERR_PTR(-ENOMEM);
+
+   INIT_LIST_HEAD(>obj_link);
+   INIT_LIST_HEAD(>vm_link);
+   INIT_LIST_HEAD(>exec_list);
+   vma->vm = vm;
+   i915_ppgtt_get(i915_vm_to_ppgtt(vm));
+
+   /* Mark the vma as permanently pinned */
+   vma->pin_count = 1;

Re: [Intel-gfx] [PATCH i-g-t v7] lib/igt_kms: Add COMMIT_ATOMIC to igt_display_commit2()

[Mayuresh Gharpure]

Hi Lionel,

I've incorporated your comments using the diff patch submitted by 
Maarten and submitted the changes


https://patchwork.freedesktop.org/series/4274/

Also, please find my comments inline

Regards,
Mayuresh

On 3/8/2016 9:41 PM, Lionel Landwerlin wrote:

Hi Maarten,

Yeah that would be much simpler I think.

Damien also looked at this patch over my shoulder and had additional 
comments.

So more or less proxying :

- Not sure why we're exposing the new enums and the 
igt_atomic_popuplate_* macros in igt_kms.h.

  After all we're not using them anywhere outside igt_kms.c.
Macros are just to improve readability. In case some new feature needs 
to be added, we can just add an enum and use the macro to populate it in 
call to IOCTL.


These were added in initial implementation by Marius.



- We have a couple of properties ids stored in igt_kms.h 
(background_property & rotation_property), it would make sense to get 
rid of those and use the new created arrays instead.
These are used by the COMMIT_LEGACY and COMMIT_UNIVERSAL style calls. So 
keeping it as is, as changing this may need a change in many existing tests


Cheers,

-
Lionel

On 08/03/16 15:56, Maarten Lankhorst wrote:

Op 07-03-16 om 13:50 schreef Lionel Landwerlin:

Hi Pratik,

I'm really looking forward to get this merged.
Just a few comments on the plane commit part below.

Would the following diff to the patch satisfy you? It would clean up things a 
lot.

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 1f738e14f52f..454ff7552b4a 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1534,14 +1534,6 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
igt_output_t *output,
  
  	igt_display_t *display = output->display;

uint32_t fb_id, crtc_id;
-   uint32_t src_x;
-   uint32_t src_y;
-   uint32_t src_w;
-   uint32_t src_h;
-   int32_t crtc_x;
-   int32_t crtc_y;
-   uint32_t crtc_w;
-   uint32_t crtc_h;
  
  	igt_assert(plane->drm_plane);
  
@@ -1552,54 +1544,30 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_output_t *output,

fb_id = igt_plane_get_fb_id(plane);
crtc_id = output->config.crtc->crtc_id;
  
-	if ((plane->fb_changed || plane->size_changed) && fb_id == 0) {

-
-   LOG(display,
-   "%s: populating plane data: pipe %s, plane %d, disabling\n",
-igt_output_name(output),
-kmstest_pipe_name(output->config.pipe),
-plane->index);
-
-   /* populate plane req */
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID, 0);
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID, 0);
-
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_SRC_X, 
IGT_FIXED(0, 0));
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_SRC_Y, 
IGT_FIXED(0, 0));
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_SRC_W, 
IGT_FIXED(0, 0));
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_SRC_H, 
IGT_FIXED(0, 0));
-
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_X, 0);
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_Y, 0);
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_W, 0);
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_H, 0);
-
-   } else if (plane->fb_changed || plane->position_changed ||
-   plane->size_changed) {
-
-   src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
-   src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
-   src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */
-   src_h = IGT_FIXED(plane->fb->src_h, 0); /* src_h */
-   crtc_x = plane->crtc_x;
-   crtc_y = plane->crtc_y;
-   crtc_w = plane->crtc_w;
-   crtc_h = plane->crtc_h;
-
-   LOG(display,
-   "%s: populating plane data: %s.%d, fb %u, src = (%d, %d) "
-   "%ux%u dst = (%u, %u) %ux%u\n",
-   igt_output_name(output),
-   kmstest_pipe_name(output->config.pipe),
-   plane->index,
-   fb_id,
-   src_x >> 16, src_y >> 16, src_w >> 16, src_h >> 16,
-   crtc_x, crtc_y, crtc_w, crtc_h);
-
-
-   /* populate plane req */
-   igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID, 
crtc_id);
+   LOG(display,
+   "%s: populating plane data: %s.%d, fb %u, src = (%d, %d) "
+   "%ux%u dst = (%u, %u) %ux%u\n",
+   igt_output_name(output),
+   kmstest_pipe_name(output->config.pipe),
+   plane->index,
+   fb_id,
+   src_x >> 16, src_y >> 16, src_w >> 16, src_h >> 16,
+   crtc_x, crtc_y, crtc_w, crtc_h);
+
+   if (plane->fb_changed) {
+   

Re: [Intel-gfx] [PATCH v4] drm/i915: Support to enable TRTT on GEN9

[kbuild test robot]

Hi Akash,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160309]
[cannot apply to v4.5-rc7]
[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/akash-goel-intel-com/drm-i915-Support-to-enable-TRTT-on-GEN9/20160309-192019
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_gem_context.c: In function 
'intel_context_set_trtt':
>> drivers/gpu/drm/i915/i915_gem_context.c:570:3: error: implicit declaration 
>> of function 'i915_dbg' [-Werror=implicit-function-declaration]
  i915_dbg(dev, "segment base address not correctly aligned\n");
  ^
   cc1: some warnings being treated as errors

vim +/i915_dbg +570 drivers/gpu/drm/i915/i915_gem_context.c

   564  to_user_ptr(args->value),
   565  sizeof(trtt_params)))
   566  return -EFAULT;
   567  
   568  /* basic sanity checks for the segment location & l3 table 
pointer */
   569  if (trtt_params.segment_base_addr & (GEN9_TRTT_SEGMENT_SIZE - 
1)) {
 > 570  i915_dbg(dev, "segment base address not correctly 
 > aligned\n");
   571  return -EINVAL;
   572  }
   573  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] lib/igt_kms: Add COMMIT_ATOMIC to igt_display_commit2()

[Mayuresh Gharpure]

Co-Author : Marius Vlad 
Co-Author : Pratik Vishwakarma 

So far we have had only two commit styles, COMMIT_LEGACY
and COMMIT_UNIVERSAL. This patch adds another commit style
COMMIT_ATOMIC which makes use of drmModeAtomicCommit()

v2: (Marius)
i)Set CRTC_ID to zero while disabling plane
ii)Modified the log message in igt_atomic_prepare_plane_commit
https://patchwork.freedesktop.org/patch/71945/

v3: (Marius)Set FB_ID to zero while disabling plane
https://patchwork.freedesktop.org/patch/72179/

v4: (Maarten) Corrected the typo in commit message
https://patchwork.freedesktop.org/patch/72598/

v5: Added check for DRM_CLIENT_CAP_ATOMIC in igt_display_init
(Marius)
i)Removed unused props from igt_display_init
ii)Removed unused ret. Changed function to void
iii)Declare the variable before checking if we have
DRM_CLIENT_CAP_ATOMIC.
https://patchwork.freedesktop.org/patch/73505/

v6: (Jani) Corrected typo in commit message

v7: Added is_atomic check for DRM_CLIENT_CAP_ATOMIC in
igt_display_init and igt_atomic_commit

v8: (Matthew Auld) Replaced for loops by for_each_connected_output and
for_each_plane_on_pipe
(Lionel) Populate properties only if the value has changed
Remove the resetting of values in disable case
Note : I've used Maarten's diff patch

Signed-off-by: Mayuresh Gharpure 
Signed-off-by: Pratik Vishwakarma 
Signed-off-by: Mayuresh Gharpure 
---
Incorporated Comments Matthew and Lionel
 lib/igt_kms.c | 289 +-
 lib/igt_kms.h |  72 ++-
 2 files changed, 359 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 9f18aef..5b6c324 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -145,6 +145,120 @@ const unsigned char* igt_kms_get_base_edid(void)
  *
  * Returns: an alternate edid block
  */
+static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
+   "SRC_X",
+   "SRC_Y",
+   "SRC_W",
+   "SRC_H",
+   "CRTC_X",
+   "CRTC_Y",
+   "CRTC_W",
+   "CRTC_H",
+   "FB_ID",
+   "CRTC_ID",
+   "type",
+   "rotation"
+};
+
+static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
+   "background_color"
+};
+
+static const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
+   "scaling mode",
+   "DPMS"
+};
+
+/*
+ * Retrieve all the properies specified in props_name and store them into
+ * plane->atomic_props_plane.
+ */
+static void
+igt_atomic_fill_plane_props(igt_display_t *display, igt_plane_t *plane,
+   int num_props, const char **prop_names)
+{
+   drmModeObjectPropertiesPtr props;
+   int i, j, fd;
+
+   fd = display->drm_fd;
+
+   props = drmModeObjectGetProperties(fd, plane->drm_plane->plane_id, 
DRM_MODE_OBJECT_PLANE);
+   igt_assert(props);
+
+   for (i = 0; i < props->count_props; i++) {
+   drmModePropertyPtr prop =
+   drmModeGetProperty(fd, props->props[i]);
+
+   for (j = 0; j < num_props; j++) {
+   if (strcmp(prop->name, prop_names[j]) != 0)
+   continue;
+
+   plane->atomic_props_plane[j] = props->props[i];
+   break;
+   }
+
+   drmModeFreeProperty(prop);
+   }
+
+   drmModeFreeObjectProperties(props);
+}
+
+/*
+ * Retrieve all the properies specified in props_name and store them into
+ * config->atomic_props_crtc and config->atomic_props_connector.
+ */
+static void
+igt_atomic_fill_props(igt_display_t *display, igt_output_t *output,
+   int num_crtc_props, const char **crtc_prop_names,
+   int num_connector_props, const char **conn_prop_names)
+{
+   drmModeObjectPropertiesPtr props;
+   int i, j, fd;
+
+   fd = display->drm_fd;
+
+   props = drmModeObjectGetProperties(fd, output->config.crtc->crtc_id, 
DRM_MODE_OBJECT_CRTC);
+   igt_assert(props);
+
+   for (i = 0; i < props->count_props; i++) {
+   drmModePropertyPtr prop =
+   drmModeGetProperty(fd, props->props[i]);
+
+   for (j = 0; j < num_crtc_props; j++) {
+   if (strcmp(prop->name, crtc_prop_names[j]) != 0)
+   continue;
+
+   output->config.atomic_props_crtc[j] = props->props[i];
+   break;
+   }
+
+   drmModeFreeProperty(prop);
+   }
+
+   drmModeFreeObjectProperties(props);
+   props = NULL;
+   props = drmModeObjectGetProperties(fd, 
output->config.connector->connector_id, DRM_MODE_OBJECT_CONNECTOR);
+   igt_assert(props);
+
+   for (i = 0; i < 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen9: add WaClearFlowControlGpgpuContextSave

[Patchwork]

== Series Details ==

Series: drm/i915/gen9: add WaClearFlowControlGpgpuContextSave
URL   : https://patchwork.freedesktop.org/series/4272/
State : failure

== Summary ==

  CC [M]  drivers/net/ethernet/smsc/smsc9420.o
  CC [M]  drivers/net/usb/smsc95xx.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD  drivers/net/ethernet/synopsys/built-in.o
  CC  drivers/video/fbdev/efifb.o
  CC  drivers/usb/host/ohci-hcd.o
  LD [M]  drivers/usb/serial/usbserial.o
  CC  drivers/usb/host/ohci-pci.o
  CC [M]  drivers/net/usb/mcs7830.o
  CC  drivers/usb/host/uhci-hcd.o
  CC [M]  drivers/net/usb/usbnet.o
  CC  drivers/usb/host/xhci.o
  CC [M]  drivers/net/usb/cdc_ncm.o
  CC  drivers/usb/host/xhci-mem.o
  CC  drivers/usb/host/xhci-ring.o
  CC  drivers/usb/host/xhci-hub.o
  CC  drivers/usb/host/xhci-dbg.o
  CC  drivers/usb/host/xhci-trace.o
  CC  drivers/usb/host/xhci-pci.o
  LD  drivers/video/fbdev/built-in.o
  LD  drivers/video/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
Makefile:950: 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/gen9: add WaClearFlowControlGpgpuContextSave

[kbuild test robot]

Hi Tim,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.5-rc7 next-20160309]
[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/tim-gore-intel-com/drm-i915-gen9-add-WaClearFlowControlGpgpuContextSave/20160309-213806
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x000-201610 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_ringbuffer.c: In function 'gen9_init_workarounds':
>> drivers/gpu/drm/i915/intel_ringbuffer.c:926:6: error: 'FLOW_CONTROL_ENABLE' 
>> undeclared (first use in this function)
 FLOW_CONTROL_ENABLE |
 ^
   drivers/gpu/drm/i915/intel_ringbuffer.c:773:43: note: in definition of macro 
'WA_REG'
  const int r = wa_add(dev_priv, (addr), (mask), (val)); \
  ^
>> drivers/gpu/drm/i915/intel_ringbuffer.c:925:2: note: in expansion of macro 
>> 'WA_SET_BIT_MASKED'
 WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
 ^
   drivers/gpu/drm/i915/intel_ringbuffer.c:926:6: note: each undeclared 
identifier is reported only once for each function it appears in
 FLOW_CONTROL_ENABLE |
 ^
   drivers/gpu/drm/i915/intel_ringbuffer.c:773:43: note: in definition of macro 
'WA_REG'
  const int r = wa_add(dev_priv, (addr), (mask), (val)); \
  ^
>> drivers/gpu/drm/i915/intel_ringbuffer.c:925:2: note: in expansion of macro 
>> 'WA_SET_BIT_MASKED'
 WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
 ^

vim +/FLOW_CONTROL_ENABLE +926 drivers/gpu/drm/i915/intel_ringbuffer.c

   919  /* WaDisableKillLogic:bxt,skl */
   920  I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
   921 ECOCHK_DIS_TLB);
   922  
   923  /* WaClearFlowControlGpgpuContextSave:skl,bxt */
   924  /* WaDisablePartialInstShootdown:skl,bxt */
 > 925  WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
 > 926FLOW_CONTROL_ENABLE |
   927PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
   928  
   929  /* Syncing dependencies between camera and graphics:skl,bxt */

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] drm_read: Remove use of DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID

[Tomeu Vizoso]

Instead of checking that there's a CRTC in pipe 0 with a valid mode,
check that we can get a vblank in the primary display controller.

This should be equivalent, but also works with drivers other than i915.

Signed-off-by: Tomeu Vizoso 
---
 tests/drm_read.c | 39 +--
 1 file changed, 5 insertions(+), 34 deletions(-)

diff --git a/tests/drm_read.c b/tests/drm_read.c
index faa3df862ea6..52dfa8ab8781 100644
--- a/tests/drm_read.c
+++ b/tests/drm_read.c
@@ -189,46 +189,17 @@ static void test_short_buffer(int in, int nonblock)
teardown(fd);
 }
 
-static int pipe0_enabled(int fd)
+static bool pipe0_enabled(int fd)
 {
-   struct drm_mode_card_res res;
-   uint32_t crtcs[32];
-   int i;
+   union drm_wait_vblank vbl;
 
/* We assume we can generate events on pipe 0. So we have better
 * make sure that is running!
 */
 
-   memset(, 0, sizeof(res));
-   res.count_crtcs = 32;
-   res.crtc_id_ptr = (uintptr_t)crtcs;
-
-   if (drmIoctl(fd, DRM_IOCTL_MODE_GETRESOURCES, ))
-   return 0;
-
-   if (res.count_crtcs > 32)
-   return 0;
-
-   for (i = 0; i < res.count_crtcs; i++) {
-   struct drm_i915_get_pipe_from_crtc_id get_pipe;
-   struct drm_mode_crtc mode;
-
-   memset(_pipe, 0, sizeof(get_pipe));
-   memset(, 0, sizeof(mode));
-
-   mode.crtc_id = crtcs[i];
-
-   get_pipe.pipe = -1;
-   get_pipe.crtc_id = mode.crtc_id;
-   drmIoctl(fd, DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID, _pipe);
-   if (get_pipe.pipe)
-   continue;
-
-   drmIoctl(fd, DRM_IOCTL_MODE_GETCRTC, );
-   return mode.mode_valid && mode.mode.clock;
-   }
-
-   return 0;
+   memset(, 0, sizeof(vbl));
+   vbl.request.type = DRM_VBLANK_RELATIVE;
+   return drmIoctl(fd, DRM_IOCTL_WAIT_VBLANK, ) == 0;
 }
 
 igt_main
-- 
2.5.0

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

[Intel-gfx] [PATCH] drm/i915/gen9: add WaClearFlowControlGpgpuContextSave

[tim . gore]

From: Tim Gore 

This allows writes to EU flow control registers. Together
with SIP code from the user-mode driver this resolves a
hang seen in some pre-emption scenarios. Note that this
patch is just the kernel mode part of this workaround.

Signed-off-by: Tim Gore 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 45ce45a..83ab25a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -920,8 +920,10 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*ring)
I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
   ECOCHK_DIS_TLB);
 
+   /* WaClearFlowControlGpgpuContextSave:skl,bxt */
/* WaDisablePartialInstShootdown:skl,bxt */
WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN,
+ FLOW_CONTROL_ENABLE |
  PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
 
/* Syncing dependencies between camera and graphics:skl,bxt */
-- 
1.9.1

___
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 [1/2] drm/i915: make device info bitfield flags bools

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: make device info bitfield flags 
bools
URL   : https://patchwork.freedesktop.org/series/4270/
State : warning

== Summary ==

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

Test gem_ringfill:
Subgroup basic-default-s3:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (hsw-brixbox)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (snb-dellxps)

bdw-nuci7total:186  pass:174  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:186  pass:167  dwarn:0   dfail:0   fail:0   skip:19 
bsw-nuc-2total:186  pass:150  dwarn:1   dfail:0   fail:0   skip:35 
byt-nuc  total:186  pass:154  dwarn:0   dfail:0   fail:0   skip:32 
hsw-brixbox  total:186  pass:165  dwarn:1   dfail:0   fail:0   skip:20 
ilk-hp8440p  total:186  pass:126  dwarn:1   dfail:0   fail:0   skip:59 
skl-i5k-2total:186  pass:165  dwarn:0   dfail:0   fail:0   skip:21 
skl-i7k-2total:186  pass:165  dwarn:0   dfail:0   fail:0   skip:21 
snb-dellxps  total:186  pass:154  dwarn:2   dfail:0   fail:0   skip:30 

Results at /archive/results/CI_IGT_test/Patchwork_1549/

ab403b26610034afe0e0c97d960782bad98b97d0 drm-intel-nightly: 
2016y-03m-09d-09h-25m-31s UTC integration manifest
8a922e5b2f7636902305978ecafacdaa164d3dc4 drm/i915: don't mix bitwise and 
logical operations for has_snoop
4f18aa47bf932a32d62486bcd88a56811d1eff58 drm/i915: make device info bitfield 
flags bools

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

[Intel-gfx] [PATCH 2/2] drm/i915: don't mix bitwise and logical operations for has_snoop

[Jani Nikula]

Also make the code more readable.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_dma.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4aa3db61a535..809d3783b033 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -853,9 +853,11 @@ static void intel_device_info_runtime_init(struct 
drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 9)
gen9_sseu_info_init(dev);
 
-   /* Snooping is broken on BXT A stepping. */
info->has_snoop = !info->has_llc;
-   info->has_snoop &= !IS_BXT_REVID(dev, 0, BXT_REVID_A1);
+
+   /* Snooping is broken on BXT A stepping. */
+   if (IS_BXT_REVID(dev, 0, BXT_REVID_A1))
+   info->has_snoop = false;
 
DRM_DEBUG_DRIVER("slice total: %u\n", info->slice_total);
DRM_DEBUG_DRIVER("subslice total: %u\n", info->subslice_total);
-- 
2.1.4

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

[Intel-gfx] [PATCH 1/2] drm/i915: make device info bitfield flags bools

[Jani Nikula]

This is more robust for assignments and comparisons.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f37ac120a29d..0f5db53501be 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -789,7 +789,7 @@ struct intel_csr {
func(has_ddi) sep \
func(has_fpga_dbg)
 
-#define DEFINE_FLAG(name) u8 name:1
+#define DEFINE_FLAG(name) bool name:1
 #define SEP_SEMICOLON ;
 
 struct intel_device_info {
-- 
2.1.4

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

Re: [Intel-gfx] [maintainer-tools PATCH] drm-intel: Add note about patches that move code between files

[Dave Gordon]

On 09/03/16 11:46, Ander Conselvan de Oliveira wrote:

Patches that move big chunks of code between files can cause some
complicated conflicts. Add a note to coordinate with maintainers before
merging such patches.

Signed-off-by: Ander Conselvan de Oliveira 

---
  drm-intel.rst | 4 
  1 file changed, 4 insertions(+)

diff --git a/drm-intel.rst b/drm-intel.rst
index c0c2f20..89df24b 100644
--- a/drm-intel.rst
+++ b/drm-intel.rst
@@ -350,6 +350,10 @@ An inexhaustive list of details to check:
http://developercertificate.org/. dim apply-branch should do this
automatically for you.

+* For patches that move around lots of code (file rename or extraction) please
+  coordinate with maintainers to avoid unnecessary pain with conflicts. Usually
+  some explicit merges are needed to avoid git getting lost.
+
  On Confidence, Complexity, and Transparency
  ---


Perhaps also add a note about "git blame -C", as recently discussed here 
by Tvrtko & Arun in the thread "[PATCH 044/190] drm/i915: Move GEM 
request routines to i915_gem_request.c"?


.Dave.

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix races on fbdev (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix races on fbdev (rev2)
URL   : https://patchwork.freedesktop.org/series/4068/
State : failure

== Summary ==

Series 4068v2 drm/i915: Fix races on fbdev
http://patchwork.freedesktop.org/api/1.0/series/4068/revisions/2/mbox/

Test gem_ringfill:
Subgroup basic-default-s3:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (bdw-ultra)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:186  pass:174  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:186  pass:167  dwarn:0   dfail:0   fail:0   skip:19 
bsw-nuc-2total:186  pass:150  dwarn:1   dfail:0   fail:0   skip:35 
byt-nuc  total:186  pass:154  dwarn:0   dfail:0   fail:0   skip:32 
skl-i5k-2total:186  pass:165  dwarn:0   dfail:0   fail:0   skip:21 
skl-i7k-2total:186  pass:165  dwarn:0   dfail:0   fail:0   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1548/

ab403b26610034afe0e0c97d960782bad98b97d0 drm-intel-nightly: 
2016y-03m-09d-09h-25m-31s UTC integration manifest
a06328bd06f956c0b41202589175e68665c09ab1 drm/i915: Fix races on fbdev

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

Re: [Intel-gfx] [PATCH v4] drm/i915: Support to enable TRTT on GEN9

[Chris Wilson]

On Wed, Mar 09, 2016 at 05:00:24PM +0530, akash.g...@intel.com wrote:
> +static int
> +intel_context_get_trtt(struct intel_context *ctx,
> +struct drm_i915_gem_context_param *args)
> +{
> + struct drm_i915_gem_context_trtt_param trtt_params;
> + struct drm_device *dev = ctx->i915->dev;
> +
> + if (!HAS_TRTT(dev) || !USES_FULL_48BIT_PPGTT(dev)) {

Both of these actually inspect dev_priv (and magically convert dev into
dev_priv).

> + return -ENODEV;
> + } else if (args->size < sizeof(trtt_params)) {
> + args->size = sizeof(trtt_params);
> + } else {
> + trtt_params.segment_base_addr =
> + ctx->trtt_info.segment_base_addr;
> + trtt_params.l3_table_address =
> + ctx->trtt_info.l3_table_address;
> + trtt_params.null_tile_val =
> + ctx->trtt_info.null_tile_val;
> + trtt_params.invd_tile_val =
> + ctx->trtt_info.invd_tile_val;
> +
> + if (__copy_to_user(to_user_ptr(args->value),
> +_params,
> +sizeof(trtt_params)))
> + return -EFAULT;

args->size = sizeof(trtt_params);

in case the use passed in size > sizeof(trtt_params) we want to report
how many bytes we wrote.

> + }
> +
> + return 0;
> +}
> +
> +static int
> +intel_context_set_trtt(struct intel_context *ctx,
> +struct drm_i915_gem_context_param *args)
> +{
> + struct drm_i915_gem_context_trtt_param trtt_params;
> + struct drm_device *dev = ctx->i915->dev;
> +
> + if (!HAS_TRTT(dev) || !USES_FULL_48BIT_PPGTT(dev))

Ditto (dev_priv)

> + return -ENODEV;
> + else if (ctx->flags & CONTEXT_USE_TRTT)
> + return -EEXIST;

What locks are we holding here?

> + else if (args->size < sizeof(trtt_params))
> + return -EINVAL;
> + else if (copy_from_user(_params,
> + to_user_ptr(args->value),
> + sizeof(trtt_params)))

Because whatever they are, we can't hold them here!

(Imagine/write a test that passes in the trtt_params inside a GTT mmaping.)

> @@ -923,7 +1015,6 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
> *dev, void *data,
>   return PTR_ERR(ctx);
>   }
>  
> - args->size = 0;

Awooga. Does every path then set it?

> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 7b8de85..8de0319 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2169,6 +2169,17 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
>  {
>   gtt_write_workarounds(dev);
>  
> + if (HAS_TRTT(dev) && USES_FULL_48BIT_PPGTT(dev)) {
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + /*
> +  * Globally enable TR-TT support in Hw.
> +  * Still TR-TT enabling on per context basis is required.
> +  * Non-trtt contexts are not affected by this setting.
> +  */
> + I915_WRITE(GEN9_TR_CHICKEN_BIT_VECTOR,
> +GEN9_TRTT_BYPASS_DISABLE);
> + }
> +
>   /* In the case of execlists, PPGTT is enabled by the context descriptor
>* and the PDPs are contained within the context itself.  We don't
>* need to do anything here. */
> @@ -3368,6 +3379,57 @@ i915_gem_obj_lookup_or_create_ggtt_vma(struct 
> drm_i915_gem_object *obj,
>  
>  }
>  
> +void intel_trtt_context_destroy_vma(struct i915_vma *vma)
> +{
> + struct i915_address_space *vm = vma->vm;
> +
> + WARN_ON(!list_empty(>obj_link));
> + WARN_ON(!list_empty(>vm_link));
> + WARN_ON(!list_empty(>exec_list));

WARN_ON(!vma->pin_count);

> +
> + drm_mm_remove_node(>node);
> + i915_ppgtt_put(i915_vm_to_ppgtt(vm));
> + kmem_cache_free(to_i915(vm->dev)->vmas, vma);
> +}
> +
> +struct i915_vma *
> +intel_trtt_context_allocate_vma(struct i915_address_space *vm,
> + uint64_t segment_base_addr)
> +{
> + struct i915_vma *vma;
> + int ret;
> +
> + vma = kmem_cache_zalloc(to_i915(vm->dev)->vmas, GFP_KERNEL);
> + if (!vma)
> + return ERR_PTR(-ENOMEM);
> +
> + INIT_LIST_HEAD(>obj_link);
> + INIT_LIST_HEAD(>vm_link);
> + INIT_LIST_HEAD(>exec_list);
> + vma->vm = vm;
> + i915_ppgtt_get(i915_vm_to_ppgtt(vm));
> +
> + /* Mark the vma as permanently pinned */
> + vma->pin_count = 1;
> +
> + /* Reserve from the 48 bit PPGTT space */
> + vma->node.start = segment_base_addr;
> + vma->node.size = GEN9_TRTT_SEGMENT_SIZE;
> + ret = drm_mm_reserve_node(>mm, >node);
> + if (ret) {
> + ret = i915_gem_evict_for_vma(vma);

Given that this has a known GPF, you need a test case that tries to
evict an active/hanging object in order to make room for the trtt.

> 

[Intel-gfx] [PATCH v2] drm/i915: Fix races on fbdev

[Lukas Wunner]

The ->lastclose callback invokes intel_fbdev_restore_mode() and has
been witnessed to run before intel_fbdev_initial_config_async()
has finished.

We might likewise receive hotplug events before we've had a chance to
fully set up the fbdev.

Fix by waiting for the asynchronous thread to finish.

v2:
An async_synchronize_full() was also added to intel_fbdev_set_suspend()
in v1 which turned out to be entirely gratuitous. It caused a deadlock
on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela
for CI support) and was unnecessary since a device is never suspended
until its ->probe callback (and all asynchronous tasks it scheduled)
have finished. See dpm_prepare(), which calls wait_for_device_probe(),
which calls async_synchronize_full().

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
Reported-by: Gustav Fägerlind 
Reported-by: "Li, Weinan Z" 
Cc: Chris Wilson 
Cc: sta...@vger.kernel.org
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/i915/i915_dma.c| 8 +++-
 drivers/gpu/drm/i915/intel_fbdev.c | 3 +++
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4aa3db6..9d76dfb 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -430,11 +430,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
 * Some ports require correctly set-up hpd registers for detection to
 * work properly (leading to ghost connected connector status), e.g. VGA
 * on gm45.  Hence we can only set up the initial fbdev config after hpd
-* irqs are fully enabled. Now we should scan for the initial config
-* only once hotplug handling is enabled, but due to screwed-up locking
-* around kms/fbdev init we can't protect the fdbev initial config
-* scanning against hotplug events. Hence do this first and ignore the
-* tiny window where we will loose hotplug notifactions.
+* irqs are fully enabled. We protect the fbdev initial config scanning
+* against hotplug events by waiting in intel_fbdev_output_poll_changed
+* until the asynchronous thread has finished.
 */
intel_fbdev_initial_config_async(dev);
 
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index ae9cf6f..7e73acc 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -800,6 +800,8 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int 
state, bool synchronous
 void intel_fbdev_output_poll_changed(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
+
+   async_synchronize_full();
if (dev_priv->fbdev)
drm_fb_helper_hotplug_event(_priv->fbdev->helper);
 }
@@ -811,6 +813,7 @@ void intel_fbdev_restore_mode(struct drm_device *dev)
struct intel_fbdev *ifbdev = dev_priv->fbdev;
struct drm_fb_helper *fb_helper;
 
+   async_synchronize_full();
if (!ifbdev)
return;
 
-- 
1.8.5.2 (Apple Git-48)

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

[Intel-gfx] [maintainer-tools PATCH] drm-intel: Add note about patches that move code between files

[Ander Conselvan de Oliveira]

Patches that move big chunks of code between files can cause some
complicated conflicts. Add a note to coordinate with maintainers before
merging such patches.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drm-intel.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/drm-intel.rst b/drm-intel.rst
index c0c2f20..89df24b 100644
--- a/drm-intel.rst
+++ b/drm-intel.rst
@@ -350,6 +350,10 @@ An inexhaustive list of details to check:
   http://developercertificate.org/. dim apply-branch should do this
   automatically for you.
 
+* For patches that move around lots of code (file rename or extraction) please
+  coordinate with maintainers to avoid unnecessary pain with conflicts. Usually
+  some explicit merges are needed to avoid git getting lost.
+
 On Confidence, Complexity, and Transparency
 ---
 
-- 
2.4.3

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Support to enable TRTT on GEN9 (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Support to enable TRTT on GEN9 (rev4)
URL   : https://patchwork.freedesktop.org/series/2321/
State : failure

== Summary ==

  CC  drivers/usb/host/xhci-hub.o
  CC [M]  drivers/net/phy/bcm-phy-lib.o
  LD  drivers/tty/serial/8250/8250_base.o
  CC [M]  drivers/net/phy/broadcom.o
  LD  drivers/tty/serial/8250/built-in.o
  CC [M]  drivers/net/usb/cdc_eem.o
  LD  drivers/tty/serial/built-in.o
  CC  drivers/usb/host/xhci-dbg.o
  LD  drivers/tty/built-in.o
  CC [M]  drivers/net/usb/smsc75xx.o
  CC  drivers/usb/host/xhci-trace.o
  CC [M]  drivers/net/phy/bcm7xxx.o
  CC  drivers/usb/host/xhci-pci.o
  CC [M]  drivers/net/usb/smsc95xx.o
  CC [M]  drivers/net/phy/bcm87xx.o
  CC [M]  drivers/net/phy/realtek.o
  CC [M]  drivers/net/phy/fixed_phy.o
  LD  drivers/net/phy/libphy.o
  LD  drivers/net/phy/built-in.o
  CC [M]  drivers/net/usb/mcs7830.o
  CC [M]  drivers/net/usb/usbnet.o
  CC [M]  drivers/net/usb/cdc_ncm.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD  drivers/net/built-in.o
Makefile:950: 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

[Intel-gfx] [PATCH v4] igt/gem_trtt: Exercise the TRTT hardware

[akash . goel]

From: Akash Goel 

This patch provides the testcase to exercise the TRTT hardware.

Some platforms have an additional address translation hardware support in
form of Tiled Resource Translation Table (TR-TT) which provides an extra level
of abstraction over PPGTT.
This is useful for mapping Sparse/Tiled texture resources.

TR-TT is tightly coupled with PPGTT, a new instance of TR-TT will be required
for a new PPGTT instance, but TR-TT may not enabled for every context.
1/16th of the 48bit PPGTT space is earmarked for the translation by TR-TT,
which such chunk to use is conveyed to HW through a register.
Any GFX address, which lies in that reserved 44 bit range will be translated
through TR-TT first and then through PPGTT to get the actual physical address.

TRTT is constructed as a 3 level tile Table. Each tile is 64KB is size which
leaves behind 44-16=28 address bits. 28bits are partitioned as 9+9+10, and
each level is contained within a 4KB page hence L3 and L2 is composed of
512 64b entries and L1 is composed of 1024 32b entries.

There is a provision to keep TR-TT Tables in virtual space, where the pages of
TRTT tables will be mapped to PPGTT. This is the adopted mode, as in this mode
UMD will have a full control on TR-TT management, with bare minimum support
from KMD.
So the entries of L3 table will contain the PPGTT offset of L2 Table pages,
similarly entries of L2 table will contain the PPGTT offset of L1 Table pages.
The entries of L1 table will contain the PPGTT offset of BOs actually backing
the Sparse resources.

I915_GEM_CONTEXT_SETPARAM ioctl is used to request KMD to enable TRTT for a
certain context, a new I915_CONTEXT_PARAM_ENABLE_TRTT param has been
added to the CONTEXT_SETPARAM ioctl for that purpose.

v2:
 - Add new wrapper function __gem_context_require_param and used that
   to detect the TR-TT support
 - Use igt_main macro, rename certain function, remove extra white space,
   cleanup the code (Chris)
 - Enhance the basic subtest to exercise all possible TR-TT segment start
   locations (i.e. 16 of them) & for every iteration create a new context.

v3:
 - Get rid of some superfluous local variables (Chris)
 - Add asserts to validate whether the GFX address used in MI_STORE_DATA_IMM
   command is in canonical form & is correctly aligned or not (Chris)
 - Remove clearing of errno in has_trtt_support function (Chris)
 - Use the 48B_ADDRESS flag for batch buffer BO also (Chris)
 - Rebased.

v4:
 - Add new subtest for invalid settings.
 - Add new local function query_trtt to check the Driver state (Chris)
 - Add new helper function gem_uses_64b_ppgtt to detect 64bit PPGTT support
 - Remove local functions uses_full_ppgtt & has_softpin_support, instead use
   existing wrappers gem_has_softpin & gem_uses_64b_ppgtt (Chris).
 - Remove redundant bit masking in emit_store_xxx functions (Chris).

Cc: Chris Wilson 
Cc: Michel Thierry 
Signed-off-by: Akash Goel 
---
 lib/ioctl_wrappers.c   |  39 +++-
 lib/ioctl_wrappers.h   |   3 +
 tests/Makefile.sources |   1 +
 tests/gem_trtt.c   | 498 +
 4 files changed, 533 insertions(+), 8 deletions(-)
 create mode 100644 tests/gem_trtt.c

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 4071260..fb5de07 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -882,6 +882,22 @@ void gem_context_set_param(int fd, struct 
local_i915_gem_context_param *p)
igt_assert(__gem_context_set_param(fd, p) == 0);
 }
 
+int __gem_context_require_param(int fd, uint64_t param)
+{
+   struct local_i915_gem_context_param p;
+   int ret;
+
+   p.context = 0;
+   p.param = param;
+   p.value = 0;
+   p.size = 0;
+
+   ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CONTEXT_GETPARAM, );
+   if (ret)
+   return -errno;
+   return 0;
+}
+
 /**
  * gem_context_require_param:
  * @fd: open i915 drm file descriptor
@@ -892,14 +908,7 @@ void gem_context_set_param(int fd, struct 
local_i915_gem_context_param *p)
  */
 void gem_context_require_param(int fd, uint64_t param)
 {
-   struct local_i915_gem_context_param p;
-
-   p.context = 0;
-   p.param = param;
-   p.value = 0;
-   p.size = 0;
-
-   igt_require(drmIoctl(fd, LOCAL_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 
0);
+   igt_require(__gem_context_require_param(fd, param) == 0);
 }
 
 void gem_context_require_ban_period(int fd)
@@ -1063,6 +1072,20 @@ bool gem_uses_full_ppgtt(int fd)
 }
 
 /**
+ * gem_uses_64b_ppgtt:
+ * @fd: open i915 drm file descriptor
+ *
+ * Feature test macro to check whether the kernel internally uses full
+ * 64b per-process gtt to execute batches.
+ *
+ * Returns: Whether batches are run through full 64b ppgtt.
+ */
+bool gem_uses_64b_ppgtt(int fd)
+{
+   return gem_gtt_type(fd) > 2;
+}
+
+/**
  * gem_available_fences:
  * @fd: open i915 drm file descriptor
  *
diff 

[Intel-gfx] [PATCH v4] drm/i915: Support to enable TRTT on GEN9

[akash . goel]

From: Akash Goel 

Gen9 has an additional address translation hardware support in form of
Tiled Resource Translation Table (TR-TT) which provides an extra level
of abstraction over PPGTT.
This is useful for mapping Sparse/Tiled texture resources.
Sparse resources are created as virtual-only allocations. Regions of the
resource that the application intends to use is bound to the physical memory
on the fly and can be re-bound to different memory allocations over the
lifetime of the resource.

TR-TT is tightly coupled with PPGTT, a new instance of TR-TT will be required
for a new PPGTT instance, but TR-TT may not enabled for every context.
1/16th of the 48bit PPGTT space is earmarked for the translation by TR-TT,
which such chunk to use is conveyed to HW through a register.
Any GFX address, which lies in that reserved 44 bit range will be translated
through TR-TT first and then through PPGTT to get the actual physical address,
so the output of translation from TR-TT will be a PPGTT offset.

TRTT is constructed as a 3 level tile Table. Each tile is 64KB is size which
leaves behind 44-16=28 address bits. 28bits are partitioned as 9+9+10, and
each level is contained within a 4KB page hence L3 and L2 is composed of
512 64b entries and L1 is composed of 1024 32b entries.

There is a provision to keep TR-TT Tables in virtual space, where the pages of
TRTT tables will be mapped to PPGTT.
Currently this is the supported mode, in this mode UMD will have a full control
on TR-TT management, with bare minimum support from KMD.
So the entries of L3 table will contain the PPGTT offset of L2 Table pages,
similarly entries of L2 table will contain the PPGTT offset of L1 Table pages.
The entries of L1 table will contain the PPGTT offset of BOs actually backing
the Sparse resources.
UMD will have to allocate the L3/L2/L1 table pages as a regular BO only &
assign them a PPGTT address through the Soft Pin API (for example, use soft pin
to assign l3_table_address to the L3 table BO, when used).
UMD will also program the entries in the TR-TT page tables using regular batch
commands (MI_STORE_DATA_IMM), or via mmapping of the page table BOs.
UMD may do the complete PPGTT address space management, on the pretext that it
could help minimize the conflicts.

Any space in TR-TT segment not bound to any Sparse texture, will be handled
through Invalid tile, User is expected to initialize the entries of a new
L3/L2/L1 table page with the Invalid tile pattern. The entries corresponding to
the holes in the Sparse texture resource will be set with the Null tile pattern
The improper programming of TRTT should only lead to a recoverable GPU hang,
eventually leading to banning of the culprit context without victimizing others.

The association of any Sparse resource with the BOs will be known only to UMD,
and only the Sparse resources shall be assigned an offset from the TR-TT segment
by UMD. The use of TR-TT segment or mapping of Sparse resources will be
transparent to the KMD, UMD will do the address assignment from TR-TT segment
autonomously and KMD will be oblivious of it.
Any object must not be assigned an address from TR-TT segment, they will be
mapped to PPGTT in a regular way by KMD.

This patch provides an interface through which UMD can convey KMD to enable
TR-TT for a given context. A new I915_CONTEXT_PARAM_TRTT param has been
added to I915_GEM_CONTEXT_SETPARAM ioctl for that purpose.
UMD will have to pass the GFX address of L3 table page, start location of TR-TT
segment alongwith the pattern value for the Null & invalid Tile registers.

v2:
 - Support context_getparam for TRTT also and dispense with a separate
   GETPARAM case for TRTT (Chris).
 - Use i915_dbg to log errors for the invalid TRTT ABI parameters passed
   from user space (Chris).
 - Move all the argument checking for TRTT in context_setparam to the
   set_trtt function (Chris).
 - Change the type of 'flags' field inside 'intel_context' to unsigned (Chris)
 - Rename certain functions to rightly reflect their purpose, rename
   the new param for TRTT in gem_context_param to I915_CONTEXT_PARAM_TRTT,
   rephrase few lines in the commit message body, add more comments (Chris).
 - Extend ABI to allow User specify TRTT segment location also.
 - Fix for selective enabling of TRTT on per context basis, explicitly
   disable TR-TT at the start of a new context.

v3:
 - Check the return value of gen9_emit_trtt_regs (Chris)
 - Update the kernel doc for intel_context structure.
 - Rebased.

v4:
 - Fix the warnings reported by 'checkpatch.pl --strict' (Michel)
 - Fix the context_getparam implementation avoiding the reset of size field,
   affecting the TRTT case.

Testcase: igt/gem_trtt

Cc: Chris Wilson 
Cc: Michel Thierry 
Signed-off-by: Akash Goel 
---
 drivers/gpu/drm/i915/i915_drv.h |  17 -
 drivers/gpu/drm/i915/i915_gem_context.c |  99 -
 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Remove some post-commit members from intel_crtc->atomic, v3.

[Maarten Lankhorst]

Op 09-03-16 om 10:59 schreef Patchwork:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Remove some post-commit members 
> from intel_crtc->atomic, v3.
> URL   : https://patchwork.freedesktop.org/series/4261/
> State : warning
>
> == Summary ==
>
> Series 4261v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/4261/revisions/1/mbox/
>
> Test gem_ringfill:
> Subgroup basic-default-s3:
> pass   -> DMESG-WARN (bsw-nuc-2)
circular locking with cpu_hotplug.lock again. :(
> Test kms_flip:
> Subgroup basic-flip-vs-modeset:
> dmesg-warn -> PASS   (bdw-ultra)
> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-b:
> dmesg-warn -> PASS   (snb-x220t)
> Subgroup nonblocking-crc-pipe-b-frame-sequence:
> dmesg-warn -> PASS   (hsw-brixbox)
> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS   (bsw-nuc-2)
Flaky.
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> fail   -> DMESG-FAIL (snb-x220t)
> pass   -> DMESG-WARN (snb-dellxps)
> Subgroup basic-rte:
> dmesg-warn -> PASS   (snb-dellxps)
>
Seems the failures were already pre existing and intermittent.
___
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 [1/2] drm/i915: Remove some post-commit members from intel_crtc->atomic, v3.

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Remove some post-commit members 
from intel_crtc->atomic, v3.
URL   : https://patchwork.freedesktop.org/series/4261/
State : warning

== Summary ==

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

Test gem_ringfill:
Subgroup basic-default-s3:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (bdw-ultra)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
dmesg-warn -> PASS   (snb-x220t)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail   -> DMESG-FAIL (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
Subgroup basic-rte:
dmesg-warn -> PASS   (snb-dellxps)

bdw-nuci7total:186  pass:174  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:186  pass:167  dwarn:0   dfail:0   fail:0   skip:19 
bsw-nuc-2total:186  pass:150  dwarn:1   dfail:0   fail:0   skip:35 
byt-nuc  total:186  pass:154  dwarn:0   dfail:0   fail:0   skip:32 
hsw-brixbox  total:186  pass:166  dwarn:0   dfail:0   fail:0   skip:20 
hsw-gt2  total:186  pass:170  dwarn:1   dfail:0   fail:0   skip:15 
ivb-t430stotal:186  pass:164  dwarn:0   dfail:0   fail:0   skip:22 
skl-i5k-2total:186  pass:165  dwarn:0   dfail:0   fail:0   skip:21 
skl-i7k-2total:186  pass:165  dwarn:0   dfail:0   fail:0   skip:21 
snb-dellxps  total:186  pass:155  dwarn:1   dfail:0   fail:0   skip:30 
snb-x220ttotal:186  pass:155  dwarn:1   dfail:1   fail:0   skip:29 

Results at /archive/results/CI_IGT_test/Patchwork_1546/

ab403b26610034afe0e0c97d960782bad98b97d0 drm-intel-nightly: 
2016y-03m-09d-09h-25m-31s UTC integration manifest
57b84d83e0ac568bb896e2d91d4055e9398f2c36 drm/i915: Nuke fbc members from 
intel_crtc->atomic, v4.
6c0ccc5c9c7541ea90a17fbc1d71c017266edf7f drm/i915: Remove some post-commit 
members from intel_crtc->atomic, v3.

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

Re: [Intel-gfx] [PATCH 13/13] drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll code

[Ander Conselvan De Oliveira]

On Wed, 2016-03-09 at 09:36 +0100, Maarten Lankhorst wrote:
> Op 08-03-16 om 16:46 schreef Ander Conselvan de Oliveira:
> > Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept
> > enabled because of it driving CDCLK, it is better to special case that
> > inside the DPLL code than in the higher level.
> > 
> > v2: Use INTEL_DPLL_ALWAYS_ON flag. (Ander)
> > 
> > v3: Remove extremely paranoid WARN_ONs. (Maarten)
> > Handle DPLL0 in skylake_get_ddi_pll() properly. (Ander)
> > 
> > Signed-off-by: Ander Conselvan de Oliveira <
> > ander.conselvan.de.olive...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  |  21 --
> >  drivers/gpu/drm/i915/intel_display.c  |  12 +---
> >  drivers/gpu/drm/i915/intel_dp.c   |  52 +-
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 124 ++-
> > ---
> >  drivers/gpu/drm/i915/intel_dpll_mgr.h |   7 +-
> >  5 files changed, 105 insertions(+), 111 deletions(-)
> Excellent, glad you managed to test it. :)
> > @@ -1176,6 +1221,19 @@ skl_get_dpll(struct intel_crtc *crtc, struct
> > intel_crtc_state *crtc_state,
> > case 27:
> > ctrl1 |=
> > DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2700, 0);
> > break;
> > +   /* eDP 1.4 rates */
> > +   case 162000:
> > +   ctrl1 |=
> > DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1620, 0);
> > +   break;
> > +   /* TBD: For DP link rates 2.16 GHz and 4.32 GHz, VCO is
> > 8640 which
> > +   results in CDCLK change. Need to handle the change of CDCLK
> > by
> > +   disabling pipes and re-enabling them */
> > +   case 108000:
> > +   ctrl1 |=
> > DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1080, 0);
> > +   break;
> > +   case 216000:
> > +   ctrl1 |=
> > DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2160, 0);
> > +   break;
> > }
> >  
> > cfgcr1 = cfgcr2 = 0;
> > 
> Seems there's already a patch to address this on the mailing list, so for 12
> and 13:
> 
> Reviewed-by: Maarten Lankhorst 

Whole series merged. Thanks for reviewing.

Ander

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

[Intel-gfx] [PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

I expect this to be the final drm-misc pull for 4.6:
- color manager core patch from Lionel - i915 side is ready too, but will
  only land in 4.7, but I figured it's better to land this earlier for
  better coordination with other plane stuff (like alpha/blending) going
  on.
- more mode_fixup dummy func removal from Carlos (I think that's all now).
- atomic connector stealing fixes Maarten (maybe this time around, Maarten
  added testcases for it to igt too).

Cheers, Daniel


The following changes since commit 44ab4042178bd596275927ea050980aa4257581b:

  Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into 
drm-next (2016-02-26 13:02:57 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-03-09

for you to fetch changes up to 5488dc16fde74595a40c5d20ae52d978313f0b4e:

  drm: introduce pipe color correction properties (2016-03-08 13:57:32 +0100)


Carlos Palminha (15):
  drm/cirrus: removed optional dummy crtc mode_fixup function.
  drm/mgag200: removed optional dummy crtc mode_fixup function.
  drm/udl: removed optional dummy crtc mode_fixup function.
  drm/gma: removed optional dummy crtc mode_fixup function.
  drm/rcar-du: removed optional dummy crtc mode_fixup function.
  drm/omapdrm: removed optional dummy crtc mode_fixup function.
  drm/msm/mdp: removed optional dummy crtc mode_fixup function.
  drm/shmobile: removed optional dummy crtc mode_fixup function.
  drm/sti: removed optional dummy crtc mode_fixup function.
  drm/atmel-hlcdc: remove optional dummy crtc mode_fixup function.
  drm/nouveau/dispnv04: removed optional dummy crtc mode_fixup function.
  drm/virtio: removed optional dummy crtc mode_fixup function.
  drm/fsl-dcu: removed optional dummy crtc mode_fixup function.
  drm/bochs: removed optional dummy crtc mode_fixup function.
  drm/ast: removed optional dummy crtc mode_fixup function.

Lionel Landwerlin (1):
  drm: introduce pipe color correction properties

Liu Ying (1):
  drm/crtc: Use drm_mode_object_put() in __drm_framebuffer_unregister()

Maarten Lankhorst (7):
  drm/atomic: Clean up update_output_state.
  drm/atomic: Pass connector and state to update_connector_routing.
  drm/atomic: Always call steal_encoder, v2.
  drm/atomic: Handle encoder stealing from set_config better.
  drm/atomic: Handle encoder assignment conflicts in a separate check, v3.
  drm/atomic: Clean up steal_encoder, v2.
  drm/atomic: Clean up update_connector_routing.

 Documentation/DocBook/gpu.tmpl |  59 +++-
 drivers/gpu/drm/ast/ast_mode.c |   8 -
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |   9 -
 drivers/gpu/drm/bochs/bochs_kms.c  |   8 -
 drivers/gpu/drm/cirrus/cirrus_mode.c   |  13 -
 drivers/gpu/drm/drm_atomic.c   |  88 +-
 drivers/gpu/drm/drm_atomic_helper.c| 361 -
 drivers/gpu/drm/drm_crtc.c |  39 ++-
 drivers/gpu/drm/drm_crtc_helper.c  |  33 +++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c |   8 -
 drivers/gpu/drm/gma500/cdv_intel_display.c |  13 +-
 drivers/gpu/drm/gma500/gma_display.c   |   7 -
 drivers/gpu/drm/gma500/gma_display.h   |   3 -
 drivers/gpu/drm/gma500/mdfld_intel_display.c   |   2 -
 drivers/gpu/drm/gma500/oaktrail_crtc.c |   1 -
 drivers/gpu/drm/gma500/psb_intel_display.c |   1 -
 drivers/gpu/drm/mgag200/mgag200_mode.c |  13 -
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c   |   8 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c   |   8 -
 drivers/gpu/drm/nouveau/dispnv04/crtc.c|   8 -
 drivers/gpu/drm/omapdrm/omap_crtc.c|   8 -
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |   9 -
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |   8 -
 drivers/gpu/drm/sti/sti_crtc.c |   9 -
 drivers/gpu/drm/udl/udl_modeset.c  |   9 -
 drivers/gpu/drm/virtio/virtgpu_display.c   |   8 -
 include/drm/drm_atomic_helper.h|   3 +
 include/drm/drm_crtc.h |  48 +++-
 include/drm/drm_crtc_helper.h  |   3 +
 include/uapi/drm/drm_mode.h|  15 +
 30 files changed, 524 insertions(+), 286 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Remove some post-commit members from intel_crtc->atomic, v3.

[Maarten Lankhorst]

fb_bits is useful to have in the crtc_state for cs flips when
the code is updated to use intel_frontbuffer_flip_prepare/complete.
So calculate it in advance and move it to crtc_state. The other stuff
can be calculated in post_plane_update, and aren't useful elsewhere.

Changes since v1:
- Changing wording, remove comment about loop.
Changes since v2:
- Rebase.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ander Conselvan de Oliveira 
---
 drivers/gpu/drm/i915/intel_atomic.c  |  1 +
 drivers/gpu/drm/i915/intel_display.c | 29 +
 drivers/gpu/drm/i915/intel_drv.h |  5 +
 3 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 6a661e796328..e23e1ec6df89 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -99,6 +99,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state->wm_changed = false;
crtc_state->fb_changed = false;
crtc_state->wm.need_postvbl_update = false;
+   crtc_state->fb_bits = 0;
 
return _state->base;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 62d36a7b3398..2d31755608ce 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4908,14 +4908,20 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
hsw_disable_ips(intel_crtc);
 }
 
-static void intel_post_plane_update(struct intel_crtc *crtc)
+static void intel_post_plane_update(struct intel_crtc_state *old_crtc_state)
 {
+   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
+   struct drm_atomic_state *old_state = old_crtc_state->base.state;
struct intel_crtc_atomic_commit *atomic = >atomic;
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->base.state);
struct drm_device *dev = crtc->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_plane *primary = crtc->base.primary;
+   struct drm_plane_state *old_pri_state =
+   drm_atomic_get_existing_plane_state(old_state, primary);
 
-   intel_frontbuffer_flip(dev, atomic->fb_bits);
+   intel_frontbuffer_flip(dev, pipe_config->fb_bits);
 
crtc->wm.cxsr_allowed = true;
 
@@ -4925,8 +4931,17 @@ static void intel_post_plane_update(struct intel_crtc 
*crtc)
if (atomic->update_fbc)
intel_fbc_post_update(crtc);
 
-   if (atomic->post_enable_primary)
-   intel_post_enable_primary(>base);
+   if (old_pri_state) {
+   struct intel_plane_state *primary_state =
+   to_intel_plane_state(primary->state);
+   struct intel_plane_state *old_primary_state =
+   to_intel_plane_state(old_pri_state);
+
+   if (primary_state->visible &&
+   (needs_modeset(_config->base) ||
+!old_primary_state->visible))
+   intel_post_enable_primary(>base);
+   }
 
memset(atomic, 0, sizeof(*atomic));
 }
@@ -12010,12 +12025,10 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
to_intel_crtc_state(crtc_state)->wm.need_postvbl_update = true;
 
if (visible || was_visible)
-   intel_crtc->atomic.fb_bits |=
-   to_intel_plane(plane)->frontbuffer_bit;
+   pipe_config->fb_bits |= to_intel_plane(plane)->frontbuffer_bit;
 
switch (plane->type) {
case DRM_PLANE_TYPE_PRIMARY:
-   intel_crtc->atomic.post_enable_primary = turn_on;
intel_crtc->atomic.update_fbc = true;
 
break;
@@ -13790,7 +13803,7 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_atomic_wait_for_vblanks(dev, dev_priv, crtc_vblank_mask);
 
for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   intel_post_plane_update(to_intel_crtc(crtc));
+   intel_post_plane_update(to_intel_crtc_state(crtc_state));
 
if (put_domains[i])
modeset_put_power_domains(dev_priv, put_domains[i]);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7b2d66d8dd7f..6385dbb01ace 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -418,6 +418,7 @@ struct intel_crtc_state {
 #define PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS  (1<<0) /* unreliable sync 
mode.flags */
unsigned long quirks;
 
+   unsigned fb_bits; /* framebuffers to flip */
bool update_pipe; /* can a fast modeset be performed? */
bool disable_cxsr;
bool wm_changed; /* watermarks are updated */
@@ -605,10 +606,6 @@ struct intel_crtc_atomic_commit {
/* Sleepable operations to perform before commit */

[Intel-gfx] [PATCH 2/2] drm/i915: Nuke fbc members from intel_crtc->atomic, v4.

[Maarten Lankhorst]

Whenever there's an update to the primary plane,
fbc_pre_update and fbc_post_update are called. Kill off
intel_crtc->atomic.update_fbc and now that intel_crtc->atomic
is empty, kill it off too.

Changes since v1:
- Add a intel_fbc_supports_rotation helper.
Changes since v2:
- Remove intel_fbc_supports_rotation_helper.
- Remove unrelated changes.
Changes since v3:
- Rebase

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 51 +++-
 drivers/gpu/drm/i915/intel_drv.h | 15 ---
 2 files changed, 16 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2d31755608ce..6e6d8b342517 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4912,11 +4912,9 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_atomic_state *old_state = old_crtc_state->base.state;
-   struct intel_crtc_atomic_commit *atomic = >atomic;
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->base.state);
struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_plane *primary = crtc->base.primary;
struct drm_plane_state *old_pri_state =
drm_atomic_get_existing_plane_state(old_state, primary);
@@ -4928,22 +4926,19 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
if (pipe_config->wm_changed && pipe_config->base.active)
intel_update_watermarks(>base);
 
-   if (atomic->update_fbc)
-   intel_fbc_post_update(crtc);
-
if (old_pri_state) {
struct intel_plane_state *primary_state =
to_intel_plane_state(primary->state);
struct intel_plane_state *old_primary_state =
to_intel_plane_state(old_pri_state);
 
+   intel_fbc_post_update(crtc);
+
if (primary_state->visible &&
(needs_modeset(_config->base) ||
 !old_primary_state->visible))
intel_post_enable_primary(>base);
}
-
-   memset(atomic, 0, sizeof(*atomic));
 }
 
 static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state)
@@ -4951,7 +4946,6 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state)
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc_atomic_commit *atomic = >atomic;
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->base.state);
struct drm_atomic_state *old_state = old_crtc_state->base.state;
@@ -4960,15 +4954,14 @@ static void intel_pre_plane_update(struct 
intel_crtc_state *old_crtc_state)
drm_atomic_get_existing_plane_state(old_state, primary);
bool modeset = needs_modeset(_config->base);
 
-   if (atomic->update_fbc)
-   intel_fbc_pre_update(crtc);
-
if (old_pri_state) {
struct intel_plane_state *primary_state =
to_intel_plane_state(primary->state);
struct intel_plane_state *old_primary_state =
to_intel_plane_state(old_pri_state);
 
+   intel_fbc_pre_update(crtc);
+
if (old_primary_state->visible &&
(modeset || !primary_state->visible))
intel_pre_disable_primary(>base);
@@ -12027,27 +12020,17 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
if (visible || was_visible)
pipe_config->fb_bits |= to_intel_plane(plane)->frontbuffer_bit;
 
-   switch (plane->type) {
-   case DRM_PLANE_TYPE_PRIMARY:
-   intel_crtc->atomic.update_fbc = true;
-
-   break;
-   case DRM_PLANE_TYPE_CURSOR:
-   break;
-   case DRM_PLANE_TYPE_OVERLAY:
-   /*
-* WaCxSRDisabledForSpriteScaling:ivb
-*
-* cstate->update_wm was already set above, so this flag will
-* take effect when we commit and program watermarks.
-*/
-   if (IS_IVYBRIDGE(dev) &&
-   needs_scaling(to_intel_plane_state(plane_state)) &&
-   !needs_scaling(old_plane_state))
-   pipe_config->disable_lp_wm = true;
+   /*
+* WaCxSRDisabledForSpriteScaling:ivb
+*
+* cstate->update_wm was already set above, so this flag will
+* take effect when we commit and program watermarks.
+*/
+   if 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Shared pll improvements (rev4)

[Conselvan De Oliveira, Ander]

On Tue, 2016-03-08 at 16:01 +, Patchwork wrote:
> == Series Details ==
> 
> Series: Shared pll improvements (rev4)
> URL   : https://patchwork.freedesktop.org/series/3850/
> State : warning
> 
> == Summary ==
> 
> Series 3850v4 Shared pll improvements
> http://patchwork.freedesktop.org/api/1.0/series/3850/revisions/4/mbox/
> 
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> dmesg-warn -> PASS   (bdw-ultra)
> Test kms_frontbuffer_tracking:
> Subgroup basic:
> pass   -> DMESG-WARN (snb-x220t)

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

> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-b:
> dmesg-warn -> PASS   (hsw-gt2)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> dmesg-fail -> FAIL   (snb-x220t)

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

> pass   -> DMESG-WARN (snb-dellxps)

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

> Subgroup basic-rte:
> dmesg-warn -> PASS   (snb-x220t)
> dmesg-warn -> PASS   (snb-dellxps)
> dmesg-warn -> PASS   (bsw-nuc-2)
> 
> bdw-nuci7total:186  pass:174  dwarn:0   dfail:0   fail:0   skip:12 
> bdw-ultratotal:186  pass:167  dwarn:0   dfail:0   fail:0   skip:19 
> bsw-nuc-2total:186  pass:151  dwarn:0   dfail:0   fail:0   skip:35 
> byt-nuc  total:186  pass:154  dwarn:0   dfail:0   fail:0   skip:32 
> hsw-brixbox  total:186  pass:166  dwarn:0   dfail:0   fail:0   skip:20 
> hsw-gt2  total:186  pass:170  dwarn:1   dfail:0   fail:0   skip:15 
> ilk-hp8440p  total:186  pass:127  dwarn:0   dfail:0   fail:0   skip:59 
> ivb-t430stotal:186  pass:164  dwarn:0   dfail:0   fail:0   skip:22 
> skl-i5k-2total:186  pass:165  dwarn:0   dfail:0   fail:0   skip:21 
> skl-i7k-2total:186  pass:165  dwarn:0   dfail:0   fail:0   skip:21 
> snb-dellxps  total:186  pass:155  dwarn:1   dfail:0   fail:0   skip:30 
> snb-x220ttotal:186  pass:155  dwarn:1   dfail:0   fail:1   skip:29 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1542/
> 
> b519bbd9633eca6bc8e8e80588b48bcee447c330 drm-intel-nightly: 2016y-03m-08d-13h
> -00m-35s UTC integration manifest
> f8848e64f47e4200ca993ab5bb868bd6c68767a3 drm/i915: Make SKL/KBL DPLL0 managed
> by the shared dpll code
> 4ebc277121e7ac78ec5b276285036adc7fd0378c drm/i915: Manage HSW/BDW LCPLLs with
> the shared dpll interface
> 3a4e1a242b5bcfd9f13dd396148496cd5023e148 drm/i915: Move BXT pll configuration
> logic to intel_dpll_mgr.c
> 7c5af214173d1b70d5700182ac13c1426b420101 drm/i915: Move SKL/KLB pll selection
> logic to intel_dpll_mgr.c
> bbd624df74bdedbbdd6aeed20dff43e8cc2c1bf2 drm/i915: Move HSW/BDW pll selection
> logic to intel_dpll_mgr.c
> 7dfc6d5ac9dbca040722b3f8160d701303224e23 drm/i915: Refactor platform specifics
> out of intel_get_shared_dpll()
> 0e6c3ed940919ec78fcd17fe817854463239c949 drm/i915: Use a table to initilize
> shared dplls
> 2a434bf66a3a5db28cee6fdcb302007554cbac5e drm/i915: Move shared dpll function
> prototypes to intel_dpll_mgr.h
> 4654f45012aa9cce7a906a11f3ef6833826f0c2a drm/i915: Move shared dpll struct
> definitions to separate header file
> 29d479929a350c2623dae07f400623f33ece8f1a drm/i915: Store a direct pointer to
> shared dpll in intel_crtc_state
> 12b8330b15a5feb3e6a3cf41216a2f2f803ee755 drm/i915: Split
> intel_get_shared_dpll() into smaller functions
> dfa9c8044c69fb361e7482c5c58b997618eb163d drm/i915: Move ddi shared dpll code
> to intel_dpll_mgr.c
> 8584a2d3faa95cfe6094391d7a20d1a1f3a790c7 drm/i915: Move shared dpll code to a
> new file
> 
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v5] intel: New libdrm interface to create unbound wc user mappings for objects

[akash . goel]

From: Akash Goel 

A new libdrm interface 'drm_intel_gem_bo_map_wc' is provided by this
patch. Through this interface Gfx clients can create write combining
virtual mappings of the Gem object. It will provide the same funtionality
of 'mmap_gtt' interface without the constraints of limited aperture space,
but provided clients handles the linear to tile conversion on their own.
This patch is intended for improving the CPU write operation performance,
as with such mapping, writes are almost 50% faster than with mmap_gtt.
Also it avoids the Cache flush after update from CPU side, when object is
passed on to GPU, which will be the case if regular mmap interface is used.
This type of mapping is specially useful in case of sub-region
update, i.e. when only a portion of the object is to be updated.
Also there is a support for the unsynchronized version of this interface
named 'drm_intel_gem_bo_map_wc_unsynchronized', through which wc virtual
mappings, but unsynchronized one, can be created of the Gem object.
To ensure the cache coherency, before using this mapping, the GTT domain has
been reused here. This provides the required Cache flush if the object is in
CPU domain or synchronization against the concurrent rendering

The drm_i915_gem_mmap structure (for the DRM_I915_GEM_MMAP_IOCTL) has been
extended with a new flags field (defaulting to 0 for existent users). In
order for userspace to detect the extended ioctl, a new parameter
I915_PARAM_HAS_EXT_MMAP has been added for versioning the ioctl interface.

v2: Aligned with the v2 of the corresponding kernel patch (Chris)
v3: Added the unmap calls for the wc mapping (Damien)
Added the param feature check before creating the wc mapping & reduced
the vma limit (Chris)
v4: Removed the extraneous unlock call from map_wc function (Damien)
v5: Rebased.

Signed-off-by: Akash Goel 
Signed-off-by: Chris Wilson 
Reviewed-by: Damien Lespiau 
---
 intel/intel_bufmgr.h |   3 +
 intel/intel_bufmgr_gem.c | 147 +++
 2 files changed, 150 insertions(+)

diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index a1abbcd..061b500 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -183,6 +183,9 @@ void 
drm_intel_bufmgr_gem_set_vma_cache_size(drm_intel_bufmgr *bufmgr,
 int drm_intel_gem_bo_map_unsynchronized(drm_intel_bo *bo);
 int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo);
 int drm_intel_gem_bo_unmap_gtt(drm_intel_bo *bo);
+int drm_intel_gem_bo_map_wc_unsynchronized(drm_intel_bo *bo);
+int drm_intel_gem_bo_map_wc(drm_intel_bo *bo);
+int drm_intel_gem_bo_unmap_wc(drm_intel_bo *bo);
 
 int drm_intel_gem_bo_get_reloc_count(drm_intel_bo *bo);
 void drm_intel_gem_bo_clear_relocs(drm_intel_bo *bo, int start);
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index dc28200..ca2f9ed 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -146,6 +146,7 @@ typedef struct _drm_intel_bufmgr_gem {
unsigned int bo_reuse : 1;
unsigned int no_exec : 1;
unsigned int has_vebox : 1;
+   unsigned int has_ext_mmap : 1;
bool fenced_relocs;
 
struct {
@@ -209,6 +210,8 @@ struct _drm_intel_bo_gem {
 
/** Mapped address for the buffer, saved across map/unmap cycles */
void *mem_virtual;
+   /** Uncached Mapped address for the buffer, saved across map/unmap 
cycles */
+   void *mem_wc_virtual;
/** GTT virtual address for the buffer, saved across map/unmap cycles */
void *gtt_virtual;
/**
@@ -1192,6 +1195,10 @@ drm_intel_gem_bo_free(drm_intel_bo *bo)
drm_munmap(bo_gem->gtt_virtual, bo_gem->bo.size);
bufmgr_gem->vma_count--;
}
+   if (bo_gem->mem_wc_virtual) {
+   drm_munmap(bo_gem->mem_wc_virtual, bo_gem->bo.size);
+   bufmgr_gem->vma_count--;
+   }
 
/* Close this object */
memclear(close);
@@ -1215,6 +1222,9 @@ drm_intel_gem_bo_mark_mmaps_incoherent(drm_intel_bo *bo)
 
if (bo_gem->gtt_virtual)
VALGRIND_MAKE_MEM_NOACCESS(bo_gem->gtt_virtual, bo->size);
+
+   if (bo_gem->mem_wc_virtual)
+   VALGRIND_MAKE_MEM_NOACCESS(bo_gem->mem_wc_virtual, bo->size);
 #endif
 }
 
@@ -1260,6 +1270,8 @@ static void 
drm_intel_gem_bo_purge_vma_cache(drm_intel_bufmgr_gem *bufmgr_gem)
 
/* We may need to evict a few entries in order to create new mmaps */
limit = bufmgr_gem->vma_max - 2*bufmgr_gem->vma_open;
+   if (bufmgr_gem->has_ext_mmap)
+   limit -= bufmgr_gem->vma_open;
if (limit < 0)
limit = 0;
 
@@ -1282,6 +1294,11 @@ static void 
drm_intel_gem_bo_purge_vma_cache(drm_intel_bufmgr_gem *bufmgr_gem)
bo_gem->gtt_virtual = NULL;
bufmgr_gem->vma_count--;
}
+   if 

Re: [Intel-gfx] [PATCH i-g-t] [Intel-gfx, v2] tests/gem_buffered_svm: Buffered SVM tests

[Chris Wilson]

On Tue, Mar 08, 2016 at 09:58:13AM -0800, Vinay Belgaumkar wrote:
> These tests were initially reviewed/merged under the gem_softpin title.
> They use softpinning and userptr mechanism to share buffers between
> CPU and GPU.
> 
> The userptr part was decoupled from them recently. Adding these tests
> under a different name to ensure buffered SVM usage testing.
> 
> The only change made was to instantiate the drm fd in the main instead
> of every subtest.
> 
> v2: Addressed all comments, removed duplicate tests/functions as suggested

You still haven't fixed the bugs. Hint, try writing a test for
concurrent read-read access between the client and the GPU. Or try
writing a swap test.
-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 13/13] drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll code

[Maarten Lankhorst]

Op 08-03-16 om 16:46 schreef Ander Conselvan de Oliveira:
> Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept
> enabled because of it driving CDCLK, it is better to special case that
> inside the DPLL code than in the higher level.
>
> v2: Use INTEL_DPLL_ALWAYS_ON flag. (Ander)
>
> v3: Remove extremely paranoid WARN_ONs. (Maarten)
> Handle DPLL0 in skylake_get_ddi_pll() properly. (Ander)
>
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  |  21 --
>  drivers/gpu/drm/i915/intel_display.c  |  12 +---
>  drivers/gpu/drm/i915/intel_dp.c   |  52 +-
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 124 
> ++
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |   7 +-
>  5 files changed, 105 insertions(+), 111 deletions(-)
Excellent, glad you managed to test it. :)
> @@ -1176,6 +1221,19 @@ skl_get_dpll(struct intel_crtc *crtc, struct 
> intel_crtc_state *crtc_state,
>   case 27:
>   ctrl1 |= 
> DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2700, 0);
>   break;
> + /* eDP 1.4 rates */
> + case 162000:
> + ctrl1 |= 
> DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1620, 0);
> + break;
> + /* TBD: For DP link rates 2.16 GHz and 4.32 GHz, VCO is 8640 
> which
> + results in CDCLK change. Need to handle the change of CDCLK by
> + disabling pipes and re-enabling them */
> + case 108000:
> + ctrl1 |= 
> DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_1080, 0);
> + break;
> + case 216000:
> + ctrl1 |= 
> DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_2160, 0);
> + break;
>   }
>  
>   cfgcr1 = cfgcr2 = 0;
>
Seems there's already a patch to address this on the mailing list, so for 12 
and 13:

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add support for GuC-based SLPC (rev2)

[Patchwork]

== Series Details ==

Series: Add support for GuC-based SLPC (rev2)
URL   : https://patchwork.freedesktop.org/series/2691/
State : failure

== Summary ==

Series 2691v2 Add support for GuC-based SLPC
http://patchwork.freedesktop.org/api/1.0/series/2691/revisions/2/mbox/

Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup basic-subslice-total:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> SKIP   (skl-i5k-2)
pass   -> DMESG-WARN (hsw-gt2)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> SKIP   (skl-i7k-2)
pass   -> DMESG-WARN (ivb-t430s)
pass   -> DMESG-WARN (byt-nuc)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (bdw-nuci7)
Test drv_module_reload_basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-FAIL (skl-i5k-2)
pass   -> DMESG-WARN (hsw-gt2)
pass   -> DMESG-WARN (bdw-ultra)
pass   -> DMESG-FAIL (skl-i7k-2)
pass   -> DMESG-WARN (ivb-t430s)
pass   -> DMESG-WARN (byt-nuc)
pass   -> DMESG-WARN (snb-x220t)
pass   -> DMESG-WARN (snb-dellxps)
pass   -> DMESG-WARN (hsw-brixbox)
pass   -> DMESG-WARN (bdw-nuci7)
Test gem_basic:
Subgroup bad-close:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup create-close:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup create-fd-close:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> DMESG-FAIL (skl-i5k-2)
pass   -> DMESG-FAIL (skl-i7k-2)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> SKIP   (skl-i5k-2)
pass   -> DMESG-WARN (snb-x220t)
pass   -> SKIP   (skl-i7k-2)
Test gem_ctx_basic:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Test gem_ctx_create:
Subgroup basic:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Test gem_ctx_exec:
Subgroup basic:
pass   -> DMESG-FAIL (skl-i5k-2)
pass   -> DMESG-FAIL (skl-i7k-2)
Test gem_ctx_param_basic:
Subgroup basic:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup basic-default:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup invalid-ctx-get:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup invalid-ctx-set:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup invalid-param-get:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup invalid-param-set:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup invalid-size-get:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup invalid-size-set:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup non-root-set:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup non-root-set-no-zeromap:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup root-set:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup root-set-no-zeromap-disabled:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Subgroup root-set-no-zeromap-enabled:
pass   -> DMESG-WARN (skl-i5k-2)
pass   -> DMESG-WARN (skl-i7k-2)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> DMESG-FAIL 

Re: [Intel-gfx] [PATCH] drm/i915/bxt: add missing DSI power domain to power well 1

[Jani Nikula]

On Tue, 08 Mar 2016, Ville Syrjälä  wrote:
> On Tue, Mar 08, 2016 at 09:00:56PM +0200, Jani Nikula wrote:
>> The DSI power domain was missing from BXT power well 1 definitions,
>> failing to get the power well for DSI transcoders. As pipe A is in the
>> same power well as DSI transcoders, the problem should only occur with
>> pipes B and C.
>> 
>> Cc: Ramalingam C 
>> Cc: Deepak M 
>> Signed-off-by: Jani Nikula 
>> 
>> ---
>> 
>> This should superseed [1], but a change will be required in
>> haswell_get_pipe_config() or [2] to check the DSI power domain.
>> 
>> [1] 
>> http://patchwork.freedesktop.org/patch/msgid/1456239619-14808-1-git-send-email-ramalinga...@intel.com
>> [2] 
>> http://patchwork.freedesktop.org/patch/msgid/1456771760-18823-1-git-send-email-ramalinga...@intel.com
>> ---
>>  drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
>> b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index 5adf4b337de3..2e88a5e06884 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -421,6 +421,7 @@ static void hsw_set_power_well(struct drm_i915_private 
>> *dev_priv,
>>  BIT(POWER_DOMAIN_TRANSCODER_EDP) |  \
>>  BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER) | \
>>  BIT(POWER_DOMAIN_PORT_DDI_A_LANES) |\
>> +BIT(POWER_DOMAIN_PORT_DSI) |\
>
> This is basically a nop since pw1 is under dmc control. But given that
> we still have this stuff defined here, it's clearly correct to include
> DSI here.
>
> Reviewed-by: Ville Syrjälä 

Pushed to drm-intel-next-queued, thanks for the review.

None of the CI fails have anything to do with this.

BR,
Jani.


>
>>  BIT(POWER_DOMAIN_AUX_A) |   \
>>  BIT(POWER_DOMAIN_PLLS) |\
>>  BIT(POWER_DOMAIN_INIT))
>> -- 
>> 2.1.4

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