Re: [Intel-gfx] snd-hda-intel runtime PM fail after module reload

[Takashi Iwai]

On Thu, 25 Feb 2016 22:57:34 +0100,
Ville Syrjälä wrote:
> 
> On Thu, Feb 25, 2016 at 09:28:59PM +0100, Takashi Iwai wrote:
> > On Thu, 25 Feb 2016 20:19:08 +0100,
> > Ville Syrjälä wrote:
> > > 
> > > Hi,
> > > 
> > > My investigation into some sporadic i915 runtime PM failures seem to
> > > point the finger at snd-hda-intel.
> > > 
> > > I just tried to play around unloding and reloading snd-hda-intel and
> > > sometimes I get snd-hda-intel loaded with runtime PM supposedly enabled,
> > > but actually the device won't runtime suspend. At which point frobbing
> > > with power/control is enough to kick it back into submission.
> > 
> > Which platform are you testing?  If it's SKL, BSW or later, multiple
> > codecs are on a single HD-audio bus.  In general, you have to adjust
> > the runtime PM of all these codecs in addition to the runtime PM of
> > the controller.  Some of them are immediately runtime PM enabled but
> > some of them aren't, left the default as is.
> 
> This was on a HSW.

OK, then the HDMI/DP has its own controller.

> I also have CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1 which I presume should
> enable codec power saving by deafault?

Yes, unless something overwrites it.  Often there are udev rules to
override something for that.

> > It might be that your desktop environment adjusts the runtime PM of
> > HD-audio stuff, often depending on the power state.  But when you
> > reload, this adjustment is also lost, so you'd have to adjust
> > manually.
> 
> There's no desktop environment. Well, unless you count systemd as such.
> As you can see from the log I included at least the pci device power/control
> file stayed at 'auto' the whole time until I flipped it to 'on' and then
> back to 'auto' to fix the problem.

It implies that the problem is the PM layer itself...

> Also the problem didn't happen on every reload AFAICS, so there's
> something rather non-deterministic happening.

In anyway, please check the runtime PM status in the codec devices,
i.e. /sys/bus/hdaudio/devices/*.   The controller runtime PM is
activated only when the codec is power-saved.

If the codec is in runtime-suspended but the controller still doesn't,
put some debug codes in azx_runtime_idle() in
sound/pci/hda/hda_intel.c, whether any EBUSY condition there hits.


Takashi
___
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: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)

[Patchwork]

== Series Details ==

Series: drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)
URL   : https://patchwork.freedesktop.org/series/3827/
State : failure

== Summary ==

Series 3827v1 drm/i915: Balance assert_rpm_wakelock_held() for 
!IS_ENABLED(CONFIG_PM)
http://patchwork.freedesktop.org/api/1.0/series/3827/revisions/1/mbox/

Test drv_hangman:
Subgroup error-state-basic:
pass   -> INCOMPLETE (snb-dellxps)
Test gem_sync:
Subgroup basic-bsd:
pass   -> DMESG-FAIL (hsw-brixbox)
pass   -> DMESG-FAIL (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (snb-x220t)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (byt-nuc)
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)
fail   -> PASS   (bdw-nuci7)
fail   -> PASS   (bdw-ultra)

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:136  dwarn:1   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:143  dwarn:0   dfail:0   fail:0   skip:25 
hsw-brixbox  total:168  pass:153  dwarn:0   dfail:1   fail:0   skip:14 
hsw-gt2  total:168  pass:157  dwarn:0   dfail:1   fail:0   skip:10 
ilk-hp8440p  total:168  pass:117  dwarn:0   dfail:2   fail:0   skip:49 
ivb-t430stotal:168  pass:153  dwarn:0   dfail:0   fail:1   skip:14 
skl-i7k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:154  pass:132  dwarn:0   dfail:0   fail:1   skip:20 
snb-x220ttotal:168  pass:144  dwarn:0   dfail:0   fail:3   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1479/

38f0cd5314ecb02d15d019631e388d3642275600 drm-intel-nightly: 
2016y-02m-25d-15h-33m-53s UTC integration manifest
f7a63002de7ec2829aeae48527217bc4d1d9b106 drm/i915: Balance 
assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)

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

[Intel-gfx] High power use from Xorg on skylake dual graphics with intel

[Marc MERLIN]

Can you help me find out why my laptop uses about 6W extra when X is
running with the intel graphics running?
Are there special kernel options I can give to the i915 driver to use less 
power,
or include in xorg.conf to do the same?

Is there also a way to make sure my nvidia chip I'm not using, is truly
off and not using power?

Details:
Laptop: Thinkpad skylake based P70 with dual graphics
legolas:~# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Device 191b (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M] 
(rev a2)
Kernel: 4.4.2

Bios is setup for hybrid graphics instead of discrete since I'd like to
try not to use the nvidia chip.
I've disabled the nouveau kernel module and the nouveau X driver
(otherwise they load and talk to the nvidia card even if it doesn't
drive the display).
I did note that battery use wasn't good with them loaded either, but
maybe I need to do something special to make sure they're really off,
not sure.

When X wasn't running, in a text console, I was able to get this from
powertop:
LCD Off: 8.8W
LCD On:  13W

Sadly, when running X, and switch back to text terminal, I then get:
LCD Off: 14.2
LCD On:  17W

And inside X, I get:
The battery reports a discharge rate of 17.7 W
The estimated remaining time is 3 hours, 22 minutes

Summary: 113.6 wakeups/second,  0.0 GPU ops/seconds, 0.0 VFS ops/sec and 11.8% 
CPU use

Power est.  Usage   Events/sCategory   Description
  5.57 W 10.0%  Device Display backlight
  216 mW  2.8 ms/s  17.1Process/usr/bin/enlightenment
  172 mW363.3 µs/s  13.8Timer  tick_sched_timer
  164 mW135.6 µs/s  13.2Process[rcu_sched]
  131 mW101.7 ms/s   2.8Processpowertop


If I let the LCD turn off:
The battery reports a discharge rate of 14.5 W
The estimated remaining time is 4 hours, 2 minutes

Summary: 108.9 wakeups/second,  0.0 GPU ops/seconds, 0.0 VFS ops/sec and 11.5% 
CPU use

Power est.  Usage   Events/sCategory   Description
  168 mW337.7 µs/s  13.8Timer  tick_sched_timer
  152 mW  1.8 ms/s  12.3Process/usr/bin/enlightenment
  134 mW 99.8 µs/s  11.0Process[rcu_sched]
  108 mW 97.9 ms/s   1.1Processpowertop

In other words, whether I'm in X or on a text console, apparently having X run
causes a fairly high battery draw (4-6W extra).

Currently, I'm booting with:
[0.00] Kernel command line: 
BOOT_IMAGE=/vmlinuz-4.4.2-amd64-i915-volpreempt-20160214bc2  
usbcore.autosuspend=1 acpi_backlight=vendor pci=noaer
[1.721963] [drm] Initialized i915 1.6.0 20151010 for :00:02.0 on minor 0
[2.908854] i915 :00:02.0: fb0: inteldrmfb frame buffer device

i915 is built in the kernel.
xserver-xorg-video-intel 2:2.99.917+git20151217-1~exp1
xorg 1:7.7+12

Xorg log says:
[  1109.972] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1109.975] (--) PCI:*(0:0:2:0) 8086:191b:17aa:222d rev 6, Mem @ 
0xd200/16777216, 0x6000/536870912, I/O @ 0x6000/64
[  1109.975] (--) PCI: (0:1:0:0) 10de:13b2:17aa:222d rev 162, Mem @ 
0xd300/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 
0x5000/128, BIOS @ 0x/524288
[  1109.975] (II) LoadModule: "glx"
[  1109.975] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  1109.976] (II) Module glx: vendor="X.Org Foundation"
[  1109.976]compiled for 1.17.3, module version = 1.0.0
[  1109.976]ABI class: X.Org Server Extension, version 9.0
[  1109.976] (**) AIGLX enabled
[  1109.976] (==) Matched intel as autoconfigured driver 0
[  1109.976] (==) Matched intel as autoconfigured driver 1
[  1109.976] (==) Matched modesetting as autoconfigured driver 2
[  1109.976] (==) Matched fbdev as autoconfigured driver 3
[  1109.976] (==) Matched vesa as autoconfigured driver 4
[  1109.976] (==) Assigned the driver to the xf86ConfigLayout
[  1109.976] (II) LoadModule: "intel"
[  1109.976] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[  1109.976] (II) Module intel: vendor="X.Org Foundation"
[  1109.976]compiled for 1.17.3, module version = 2.99.917
[  1109.976]Module class: X.Org Video Driver
[  1109.976]ABI class: X.Org Video Driver, version 19.0
[  1109.976] (II) LoadModule: "modesetting"
[  1109.976] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[  1109.977] (II) Module modesetting: vendor="X.Org Foundation"
[  1109.977]compiled for 1.17.3, module version = 1.17.3
[  1109.977]Module class: X.Org Video Driver
[  1109.977]ABI class: X.Org Video Driver, version 19.0
[  1109.977] (II) LoadModule: "fbdev"
[  1109.977] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[  1109.977] (II) Module fbdev: vendor="X.Org Foundation"
[  1109.977]compiled for 1.17.1, module version = 0.4.4
[  1109.977]Module class: 

Re: [Intel-gfx] [4.4-rc1][Regression] drm/i915: Check live status before reading edid

[Jindal, Sonika]

On 2/26/2016 12:11 AM, Joseph Salisbury wrote:

On 02/24/2016 10:53 PM, Jindal, Sonika wrote:

Hi Joe,

Yes, first thing to try is to increase the tries.

We testing with 300 retries, but the second monitor still did not show
up.  However, it did show up in lspci.



Can you please point me to the bug and provide more details like platform, 
monitor, cable.

The bug is at: http://pad.lv/1543683 .  All the hardware details should
be in the bug report.  The cable is a single link dvi-d cable.
Unfortunately the bug reporter does not have a dual link cable to test.
If you need any additional info, we can ask the bug reporter.

If this is with single link cable, the issue could be the same.
As Ville suggested for the other issue to use video=HDMI-A-1:e as 
command line argument, can you please give it a try?
The logs shared in the bug doesn't have drm logs enabled, so couldnt get 
much out of it.

Which platform is this?

Alternatively you can add something like following in intel_hdmi_detect 
to make it ignore the live status checks.


@@ -1419,7 +1419,7 @@ intel_hdmi_detect(struct drm_connector *connector, 
bool force)


intel_hdmi_unset_edid(connector);
-
+   live_status = live_status | force;
if (intel_hdmi_set_edid(connector, live_status)) {
struct intel_hdmi *intel_hdmi = 
intel_attached_hdmi(connector);



Regards,
Sonika

Are you referring to the same issue as Oleksandr reported where a single link 
dvi/hdmi cable didn’t work and dual link worked?

I'm not sure if this is the exact issue or not.  I'll review the other
thread and compare.


Regards,
Sonika

-Original Message-
From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com]
Sent: Thursday, February 25, 2016 3:09 AM
To: Jindal, Sonika 
Cc: Sharma, Shashank ; Vivi, Rodrigo ; Daniel Vetter 
; Jani Nikula ; David Airlie ; 
intel-gfx ; dri-devel ; LKML 

Subject: [4.4-rc1][Regression] drm/i915: Check live status before reading edid

Hi Sonika,

A kernel bug report was opened against Ubuntu [0].  After a kernel bisect, it 
was found that reverting the following commit resolved this bug:

commit 237ed86c693d8a8e4db476976aeb30df4deac74b
Author: Sonika Jindal 
Date:   Tue Sep 15 09:44:20 2015 +0530

 drm/i915: Check live status before reading edid



The regression was introduced as of v4.4-rc1.

I was hoping to get your feedback, since you are the patch author.  Do think 
increasing the number of tries in intel_hdmi_detect() is worth trying?  Do you 
think gathering any additional data will help diagnose this issue, or would it 
be best to submit a revert request?
 


Thanks,
 
Joe


[0] http://pad.lv/lp1543683





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

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

[Zhi Wang]

Hi Joonas:

Thanks for you time and comments. :) See my replies below.

On 02/23/16 20:42, Joonas Lahtinen wrote:

Hi,

Code is looking a lot better.

A general question still; why you seem to be preferring multi-stage
alloc and destroy?

Are there going to be scenarios when things will be allocated but not
initialized? I don't see a such use scenario.

I wouldn't split the init functions down as much as you currently do
because that'll require a lot of boilerplate code to propagate the
errors up, which is currently not done. The boilerplate for propagation
becomes necessary when the teardown function is complex, but currently
the teardown itself is less lines of code than the function
boilerplate.

So just squash those into gvt_device_create() and gvt_device_destroy()
where _create() will propagate any lower level errors up and tear down
a partially initialized struct. _destroy() can then expect to just tear
the whole struct down with no ifs.


OK. Sure no problem.

Regards, Joonas

On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote:

This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.

v2:
- Introduce i915_gvt.c.
It's necessary to introduce the stubs between i915 driver and GVT-g host,
as GVT-g components is configurable in kernel config. When disabled, the
stubs here do nothing.

Take Joonas's comments:
- Replace boolean return value with int.
- Replace customized info/warn/debug macros with DRM macros.
- Document all non-static functions like i915.
- Remove empty and unused functions.
- Replace magic number with marcos.
- Set GVT-g in kernel config to "n" by default.

Signed-off-by: Zhi Wang 
---
  drivers/gpu/drm/i915/Kconfig |  15 ++
  drivers/gpu/drm/i915/Makefile|   2 +
  drivers/gpu/drm/i915/gvt/Makefile|   5 +
  drivers/gpu/drm/i915/gvt/debug.h |  57 +
  drivers/gpu/drm/i915/gvt/gvt.c   | 393 +++
  drivers/gpu/drm/i915/gvt/gvt.h   | 100 +
  drivers/gpu/drm/i915/gvt/hypercall.h |  30 +++
  drivers/gpu/drm/i915/gvt/mpt.h   |  34 +++
  drivers/gpu/drm/i915/gvt/params.c|  32 +++
  drivers/gpu/drm/i915/gvt/params.h|  34 +++
  drivers/gpu/drm/i915/gvt/reg.h   |  34 +++
  drivers/gpu/drm/i915/i915_dma.c  |  14 ++
  drivers/gpu/drm/i915/i915_drv.h  |  12 ++
  drivers/gpu/drm/i915/i915_gvt.c  |  93 +
  drivers/gpu/drm/i915/i915_gvt.h  |  49 +
  15 files changed, 904 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
  create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
  create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
  create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
  create mode 100644 drivers/gpu/drm/i915/gvt/params.c
  create mode 100644 drivers/gpu/drm/i915/gvt/params.h
  create mode 100644 drivers/gpu/drm/i915/gvt/reg.h
  create mode 100644 drivers/gpu/drm/i915/i915_gvt.c
  create mode 100644 drivers/gpu/drm/i915/i915_gvt.h

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 4c59793..082e77d 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -45,3 +45,18 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
  option changes the default for that module option.

  If in doubt, say "N".
+
+config DRM_I915_GVT
+tristate "GVT-g host driver"
+depends on DRM_I915
+default n
+help
+  Enabling GVT-g mediated graphics passthrough technique for Intel i915
+  based integrated graphics card. With GVT-g, it's possible to have one
+  integrated i915 device shared by multiple VMs. Performance critical
+  opterations such as apperture accesses and ring buffer operations
+  are pass-throughed to VM, with a minimal set of conflicting resources
+  (e.g. display settings) mediated by vGT driver. The benefit of vGT
+  is on both the performance, given that each VM could directly operate
+  its aperture space and submit commands like running on native, and
+  the feature completeness, given that a true GEN hardware is exposed.
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07..c65026c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -91,6 +91,8 @@ i915-y += dvo_ch7017.o \
  intel_sdvo.o \
  intel_tv.o

+obj-$(CONFIG_DRM_I915_GVT)  += i915_gvt.o gvt/
+
  # virtual gpu code
  i915-y += i915_vgpu.o

diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
new file mode 100644
index 000..959305f
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -0,0 +1,5 @@
+GVT_SOURCE := gvt.o params.o
+
+ccflags-y  += -I$(src) -I$(src)/.. -Wall -Werror 
-Wno-unused-function
+i915_gvt-y 

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

[Zhi Wang]

On 02/24/16 16:08, Tian, Kevin wrote:

From: Wang, Zhi A
Sent: Thursday, February 18, 2016 7:42 PM
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
new file mode 100644
index 000..52cfa32
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/gvt.c

[...]

+
+#include 
+#include 


would this inclusion lead to a dependency on Xen?


+#include 
+
+#include "gvt.h"
+
+struct gvt_host gvt_host;
+
+static const char * const supported_hypervisors[] = {
+   [GVT_HYPERVISOR_TYPE_XEN] = "Xen Hypervisor",
+   [GVT_HYPERVISOR_TYPE_KVM] = "KVM",
+};
+
+static int gvt_init_host(void)
+{
+   struct gvt_host *host = _host;
+
+   if (!gvt.enable) {
+   gvt_dbg_core("GVT-g has been disabled by kernel parameter");
+   return -EINVAL;
+   }
+
+   if (host->initialized) {
+   gvt_err("GVT-g has already been initialized!");
+   return -EINVAL;
+   }
+
+   /* Xen DOM U */
+   if (xen_domain() && !xen_initial_domain())
+   return -ENODEV;
+
+   if (xen_initial_domain()) {
+   /* Xen Dom0 */
+   host->kdm = try_then_request_module(
+   symbol_get(xengt_kdm), "xengt");
+   host->hypervisor_type = GVT_HYPERVISOR_TYPE_XEN;
+   } else {
+   /* not in Xen. Try KVMGT */
+   host->kdm = try_then_request_module(
+   symbol_get(kvmgt_kdm), "kvm");
+   host->hypervisor_type = GVT_HYPERVISOR_TYPE_KVM;
+   }


It'd be clearer to add a comment here that above is only a short-term
solution. It's supposed to have a general registration framework in
the future so any hypervisor (Xen or KVM) can register their callbacks
at run-time, then we'll not need such direct Xen/KVM references or
hard assumption in driver code. That framework is now still under
discussion with Xen/KVM community. It doesn't prevent reviewing of
other bits, but better to document it clear here.

I'm keeping thinking if we should split this patch into much smaller 
patches and just push some basic definitions and functions for GVT 
context patch review here before MPT framework is finally figured out 
with RH guys?



+static int init_device_info(struct pgt_device *pdev)
+{
+   struct gvt_device_info *info = >device_info;
+
+   if (!IS_BROADWELL(pdev->dev_priv)) {
+   DRM_DEBUG_DRIVER("Unsupported GEN device");
+   return -ENODEV;
+   }
+
+   if (IS_BROADWELL(pdev->dev_priv)) {
+   info->max_gtt_gm_sz = (1ULL << 32); /* 4GB */
+   /*
+* The layout of BAR0 in BDW:
+* |< - MMIO 2MB ->|<- Reserved 6MB ->|<- MAX GTT 8MB->|
+*
+* GTT offset in BAR0 starts from 8MB to 16MB, and
+* Whatever GTT size is configured in BIOS,
+* the size of BAR0 is always 16MB. The actual configured
+* GTT size can be found in GMCH_CTRL.
+*/
+   info->gtt_start_offset = (1UL << 23); /* 8MB */
+   info->max_gtt_size = (1UL << 23); /* 8MB */
+   info->gtt_entry_size = 8;
+   info->gtt_entry_size_shift = 3;
+   info->gmadr_bytes_in_cmd = 8;
+   info->mmio_size = 2 * 1024 * 1024; /* 2MB */


Above are pure device info. Joonas, do you think whether it makes
sense to make them to drm_i915_private, though gvt is the only
user today?


+   }
+
+   return 0;
+}
+
+static void init_initial_cfg_space_state(struct pgt_device *pdev)


'init' -> 'setup'


+{
+   struct pci_dev *pci_dev = pdev->dev_priv->dev->pdev;
+   int i;
+
+   gvt_dbg_core("init initial cfg space, id %d", pdev->id);
+
+   for (i = 0; i < GVT_CFG_SPACE_SZ; i += 4)
+   pci_read_config_dword(pci_dev, i,
+   (u32 *)>initial_cfg_space[i]);
+
+   for (i = 0; i < GVT_BAR_NUM; i++) {
+   pdev->bar_size[i] = pci_resource_len(pci_dev, i * 2);
+   gvt_dbg_core("bar %d size: %llx", i, pdev->bar_size[i]);
+   }
+}
+
+static void clean_initial_mmio_state(struct pgt_device *pdev)
+{
+   if (pdev->gttmmio_va) {
+   iounmap(pdev->gttmmio_va);
+   pdev->gttmmio_va = NULL;
+   }
+
+   if (pdev->gmadr_va) {
+   iounmap(pdev->gmadr_va);
+   pdev->gmadr_va = NULL;
+   }


Can we reuse existing mapping in i915?

Yes, but we have to flush the tlb stuffs like i915, as i915 maps GTT 
MMIOs as WC...



+}
+
+static int init_initial_mmio_state(struct pgt_device *pdev)
+{


'init' -> 'setup'


+   struct gvt_device_info *info = >device_info;
+
+   u64 bar0, bar1;
+   int rc;
+
+   gvt_dbg_core("init initial mmio state, id %d", pdev->id);
+
+   bar0 = *(u64 *)>initial_cfg_space[GVT_REG_CFG_SPACE_BAR0];
+   bar1 = *(u64 *)>initial_cfg_space[GVT_REG_CFG_SPACE_BAR1];
+
+   

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

[Zhi Wang]

On 02/24/16 16:22, Tian, Kevin wrote:

From: Wang, Zhi A
Sent: Thursday, February 18, 2016 7:42 PM
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 52cfa32..2099b7e 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -348,6 +348,10 @@ void *gvt_create_pgt_device(struct drm_i915_private
*dev_priv)
goto err;
}

+   dev_priv->gvt.host_fence_sz = gvt.host_fence_sz;
+   dev_priv->gvt.host_low_gm_sz_in_mb = gvt.host_low_gm_sz;
+   dev_priv->gvt.host_high_gm_sz_in_mb = gvt.host_high_gm_sz;


Do we need hard limiting fence number for host usage here? There is no
continuity requirement as seen for graphics memory, since we do translate
fence# between guest view and host view. So we could make it flexible
as an on-demand allocation when creating a vGPU. Daniel even mentioned
, iirc, that today i915 can dynamically grab a fence register away from
an application, which could be useful even when host fence usage is high
(not a typical case in server virtualization which runs few applications in 
host).

Yes. They steal fence in aperture mapping fault handler. We could steal 
the fence registers from i915 as well. Let me see the effort here. :)



diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9127f8f..de09dd4 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2734,7 +2734,7 @@ static int i915_gem_setup_global_gtt(struct drm_device 
*dev,
i915_address_space_init(ggtt_vm, dev_priv);
ggtt_vm->total += PAGE_SIZE;

-   if (intel_vgpu_active(dev)) {
+   if (intel_vgpu_active(dev) || intel_gvt_active(dev)) {


above two conditions are bit confusing for others not familiar with
this technology. vgpu_active is for driver running in a VM, while
gvt_active is for driver running in host. Could we introduce a better
name, or at least wrap them into a more meaningful macro like
intel_ballooning_required?


ret = intel_vgt_balloon(dev);


I saw several comments whether ballooning is a right term here,
since we only do static reservation so far. How about renaming it
to intel_reserve_gm_resource to be more clear? In the future even
when we want to add true dynamic ballooning feature, it will be
largely refactored anyway. :-)


Sure, will do that.

Thanks
Kevin


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

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

[Zhi Wang]

On 02/24/16 15:42, Tian, Kevin wrote:

From: Wang, Zhi A
Sent: Tuesday, February 23, 2016 9:23 PM

--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -348,6 +348,10 @@ void *gvt_create_pgt_device(struct drm_i915_private

*dev_priv)

goto err;
}

+   dev_priv->gvt.host_fence_sz = gvt.host_fence_sz;
+   dev_priv->gvt.host_low_gm_sz_in_mb = gvt.host_low_gm_sz;
+   dev_priv->gvt.host_high_gm_sz_in_mb = gvt.host_high_gm_sz;


I'm thinking, could we expose the pgt_device struct (at least
partially, and then have a PIMPL pattern), to avoid this kind of
duplication of declarations and unnecessary copies between i915 and
i915_gvt modules?

It's little rough that the gvt driver writes to i915_private struct.
I'd rather see that gvt.host_fence_sz and other variables get sanitized
and then written to pgt_device (maybe the public part would be
i915_pgt_device) and used by gvt and i915 code.

Was this ever considered?


The previous version do something similar like that, both i915 and gvt
reads GVT module kernel parameter but considered that GVT modules could
be configured as "n" in kernel configuration, probably we should let
i915 to store this information and GVT to configure it if GVT is active?


Agree with Joonas. We don't need another gvt wrap. Let's just expose
pgt_device directly. I believe all other information can be encapsulated
under pgt_device.


How about this scheme:

1. Move GVT kernel parameter into intel_gvt.{h, c}
2. Sanitize the partition configuration for host in intel_gvt.c
3. If CONFIG_DRM_I915_GVT = y, write the configuration into pgt_device 
to inform GVT resource allocator ranges owned by host



btw to match other description in the code, is it clear to rename pgt_device
to gvt_device?



For the name of GVT physical device, if we use "gvt_device", it looks a 
bit weird when both "gvt_device" and "vgt_device"(vGPU instance) 
appeared in our code? :( And "pgpu" and "vgpu" also looks weird...



Another minor thing needs Joonas' feedback. Is it usual to capture
all module parameters belonging to one feature structurized together
(like 'gvt' in this patch), or just to leave them directly exposed?





Thanks
Kevin


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

Re: [Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

[Matt Roper]

On Fri, Feb 26, 2016 at 12:36:12AM +, Emil Velikov wrote:
...
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1554,6 +1554,41 @@ static int 
> > drm_mode_create_standard_properties(struct drm_device *dev)
> > return -ENOMEM;
> > dev->mode_config.prop_mode_id = prop;
> >
> > +   prop = drm_property_create(dev,
> > +   DRM_MODE_PROP_BLOB,
> > +   "DEGAMMA_LUT", 0);
> 
> Just wondering -  don't we want this and the remaining properties to
> be atomic only ? I doubt we have userspace that [will be updated to]
> handle these, yet lacks atomic.

I asked this on a previous version of the series as well since I thought
I remembered Daniel Vetter indicating that the goal was to have new
capabilities going forward should require atomic (even if the properties
could still technically work okay via the legacy property interface).
Daniel Stone felt it was probably fine to still allow it via legacy
though:

  https://lists.freedesktop.org/archives/intel-gfx/2016-January/086120.html

I personally don't have a strong feeling either way, but we should
probably just make sure everyone is on the same page.  If we decide as a
community that we *do* want the atomic requirement going forward, maybe
we can add a note about that to the kerneldoc or something so we
remember in the future.


Matt

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement color management on chv

[Matt Roper]

On Thu, Feb 25, 2016 at 03:33:43PM +, Lionel Landwerlin wrote:
> Patch based on a previous series by Shashank Sharma.
> 
> v2: Update contributors
> 
> v3: Refactor degamma/gamma LUTs load into a single function
> 
> v4: Remove unused variable
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Kumar, Kiran S 
> Signed-off-by: Kausal Malladi 

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/i915_drv.c|   3 +
>  drivers/gpu/drm/i915/i915_reg.h|  31 +
>  drivers/gpu/drm/i915/intel_color.c | 133 
> +++--
>  3 files changed, 161 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3807b73..8a2aaa7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -68,6 +68,8 @@ static struct drm_driver driver;
>  
>  #define BDW_COLORS \
>   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
> +#define CHV_COLORS \
> + .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
>  
>  static const struct intel_device_info intel_i830_info = {
>   .gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
> @@ -325,6 +327,7 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>   .display_mmio_offset = VLV_DISPLAY_BASE,
>   GEN_CHV_PIPEOFFSETS,
>   CURSOR_OFFSETS,
> + CHV_COLORS,
>  };
>  
>  static const struct intel_device_info intel_skylake_info = {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 76a9e49..ea599a9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7673,6 +7673,37 @@ enum skl_disp_power_wells {
>  #define PREC_PAL_GC_MAX(pipe, i) _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A, 
> _PAL_PREC_GC_MAX_B) + (i) * 4)
>  #define PREC_PAL_EXT_GC_MAX(pipe, i) _MMIO(_PIPE(pipe, 
> _PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4)
>  
> +/* pipe CSC & degamma/gamma LUTs on CHV */
> +#define _CGM_PIPE_A_CSC_COEFF01  (VLV_DISPLAY_BASE + 0x67900)
> +#define _CGM_PIPE_A_CSC_COEFF23  (VLV_DISPLAY_BASE + 0x67904)
> +#define _CGM_PIPE_A_CSC_COEFF45  (VLV_DISPLAY_BASE + 0x67908)
> +#define _CGM_PIPE_A_CSC_COEFF67  (VLV_DISPLAY_BASE + 0x6790C)
> +#define _CGM_PIPE_A_CSC_COEFF8   (VLV_DISPLAY_BASE + 0x67910)
> +#define _CGM_PIPE_A_DEGAMMA  (VLV_DISPLAY_BASE + 0x66000)
> +#define _CGM_PIPE_A_GAMMA(VLV_DISPLAY_BASE + 0x67000)
> +#define _CGM_PIPE_A_MODE (VLV_DISPLAY_BASE + 0x67A00)
> +#define   CGM_PIPE_MODE_GAMMA(1 << 2)
> +#define   CGM_PIPE_MODE_CSC  (1 << 1)
> +#define   CGM_PIPE_MODE_DEGAMMA  (1 << 0)
> +
> +#define _CGM_PIPE_B_CSC_COEFF01  (VLV_DISPLAY_BASE + 0x69900)
> +#define _CGM_PIPE_B_CSC_COEFF23  (VLV_DISPLAY_BASE + 0x69904)
> +#define _CGM_PIPE_B_CSC_COEFF45  (VLV_DISPLAY_BASE + 0x69908)
> +#define _CGM_PIPE_B_CSC_COEFF67  (VLV_DISPLAY_BASE + 0x6990C)
> +#define _CGM_PIPE_B_CSC_COEFF8   (VLV_DISPLAY_BASE + 0x69910)
> +#define _CGM_PIPE_B_DEGAMMA  (VLV_DISPLAY_BASE + 0x68000)
> +#define _CGM_PIPE_B_GAMMA(VLV_DISPLAY_BASE + 0x69000)
> +#define _CGM_PIPE_B_MODE (VLV_DISPLAY_BASE + 0x69A00)
> +
> +#define CGM_PIPE_CSC_COEFF01(pipe)   _MMIO_PIPE(pipe, 
> _CGM_PIPE_A_CSC_COEFF01, _CGM_PIPE_B_CSC_COEFF01)
> +#define CGM_PIPE_CSC_COEFF23(pipe)   _MMIO_PIPE(pipe, 
> _CGM_PIPE_A_CSC_COEFF23, _CGM_PIPE_B_CSC_COEFF23)
> +#define CGM_PIPE_CSC_COEFF45(pipe)   _MMIO_PIPE(pipe, 
> _CGM_PIPE_A_CSC_COEFF45, _CGM_PIPE_B_CSC_COEFF45)
> +#define CGM_PIPE_CSC_COEFF67(pipe)   _MMIO_PIPE(pipe, 
> _CGM_PIPE_A_CSC_COEFF67, _CGM_PIPE_B_CSC_COEFF67)
> +#define CGM_PIPE_CSC_COEFF8(pipe)_MMIO_PIPE(pipe, 
> _CGM_PIPE_A_CSC_COEFF8, _CGM_PIPE_B_CSC_COEFF8)
> +#define CGM_PIPE_DEGAMMA(pipe, i, w) _MMIO(_PIPE(pipe, _CGM_PIPE_A_DEGAMMA, 
> _CGM_PIPE_B_DEGAMMA) + (i) * 8 + (w) * 4)
> +#define CGM_PIPE_GAMMA(pipe, i, w)   _MMIO(_PIPE(pipe, _CGM_PIPE_A_GAMMA, 
> _CGM_PIPE_B_GAMMA) + (i) * 8 + (w) * 4)
> +#define CGM_PIPE_MODE(pipe)  _MMIO_PIPE(pipe, _CGM_PIPE_A_MODE, 
> _CGM_PIPE_B_MODE)
> +
>  /* MIPI DSI registers */
>  
>  #define _MIPI_PORT(port, a, c)   _PORT3(port, a, 0, c)   /* ports A and 
> C only */
> diff --git a/drivers/gpu/drm/i915/intel_color.c 
> b/drivers/gpu/drm/i915/intel_color.c
> index a6dc2af..9ad37e5 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -29,6 +29,7 @@
>  #define CTM_COEFF_1_0(1ULL << 32)
>  #define CTM_COEFF_2_0(CTM_COEFF_1_0 << 1)
>  #define CTM_COEFF_4_0(CTM_COEFF_2_0 << 1)
> +#define CTM_COEFF_8_0(CTM_COEFF_4_0 << 1)
>  #define CTM_COEFF_0_5(CTM_COEFF_1_0 >> 1)
>  #define CTM_COEFF_0_25   (CTM_COEFF_0_5 >> 1)
>  #define CTM_COEFF_0_125  (CTM_COEFF_0_25 >> 1)
> 

Re: [Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

[Emil Velikov]

Hi Lionel,

A bunch of suggestions - feel free to take or ignore them :-)

On 25 February 2016 at 10:58, Lionel Landwerlin
 wrote:
> Patch based on a previous series by Shashank Sharma.
>
> This introduces optional properties to enable color correction at the
> pipe level. It relies on 3 transformations applied to every pixels
> displayed. First a lookup into a degamma table, then a multiplication
> of the rgb components by a 3x3 matrix and finally another lookup into
> a gamma table.
>
> The following properties can be added to a pipe :
>   - DEGAMMA_LUT : blob containing degamma LUT
>   - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT
>   - CTM : transformation matrix applied after the degamma LUT
>   - GAMMA_LUT : blob containing gamma LUT
>   - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT
>
> DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by
> the driver to tell userspace applications what sizes should be the
> lookup tables in DEGAMMA_LUT and GAMMA_LUT.
>
> A helper is also provided so legacy gamma correction is redirected
> through these new properties.
>
> v2: Register LUT size properties as range
>
> v3: Fix round in drm_color_lut_get_value() helper
> More docs on how degamma/gamma properties are used
>
> v4: Update contributors
>
> v5: Rename CTM_MATRIX property to CTM (Doh!)
> Add legacy gamma_set atomic helper
> Describe CTM/LUT acronyms in the kernel doc
>
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Kumar, Kiran S 
> Signed-off-by: Kausal Malladi 
The above should be kept in the order of which people worked on them.

> Reviewed-by: Matt Roper 

> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c

> @@ -376,6 +377,57 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>  EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
>
>  /**
> + * drm_atomic_replace_property_blob - replace a blob property
> + * @blob: a pointer to the member blob to be replaced
> + * @new_blob: the new blob to replace with
> + * @expected_size: the expected size of the new blob
> + * @replaced: whether the blob has been replaced
> + *
> + * RETURNS:
> + * Zero on success, error code on failure
> + */
> +static int
> +drm_atomic_replace_property_blob(struct drm_property_blob **blob,
> +struct drm_property_blob *new_blob,
> +bool *replaced)
"Replaced" here and though the rest of the patch is used as "changed".
Worth naming it that way ?

> +{
> +   struct drm_property_blob *old_blob = *blob;
> +
> +   if (old_blob == new_blob)
> +   return 0;
> +
> +   if (old_blob)
> +   drm_property_unreference_blob(old_blob);
> +   if (new_blob)
> +   drm_property_reference_blob(new_blob);
> +   *blob = new_blob;
> +   *replaced = true;
> +
> +   return 0;
The function always succeeds - drop the return value ?

> +}
> +
> +static int
> +drm_atomic_replace_property_blob_from_id(struct drm_crtc *crtc,
> +struct drm_property_blob **blob,
> +uint64_t blob_id,
> +ssize_t expected_size,
> +bool *replaced)
> +{
> +   struct drm_device *dev = crtc->dev;
> +   struct drm_property_blob *new_blob = NULL;
> +
> +   if (blob_id != 0) {
> +   new_blob = drm_property_lookup_blob(dev, blob_id);
> +   if (new_blob == NULL)
> +   return -EINVAL;
> +   if (expected_size > 0 && expected_size != new_blob->length)
> +   return -EINVAL;
> +   }
> +
Having a look at drm_atomic_set_mode_prop_for_crtc() I think I can
spot a bug - it shouldn't drop/unref the old blob in case of an error.
A case you handle nicely here. Perhaps it's worth using the
drm_atomic_replace_property_blob() in there ?


> @@ -397,6 +449,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>  {
> struct drm_device *dev = crtc->dev;
> struct drm_mode_config *config = >mode_config;
> +   bool replaced = false;
> int ret;
>
> if (property == config->prop_active)
> @@ -407,8 +460,31 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
> drm_property_unreference_blob(mode);
> return ret;
> -   }
> -   else if (crtc->funcs->atomic_set_property)
> +   } else if (property == config->degamma_lut_property) {
> +   ret = drm_atomic_replace_property_blob_from_id(crtc,
> +   >degamma_lut,
> +   val,

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Adding missing IS_KABYLAKE checks.

[Rodrigo Vivi]

Hi Jani and Daniel,

I believe I forgot to cc:stable on this one and this is missing on
most branches out there including Linus 4.5-r5.
Is there any chance to get this patch in for 4.5? without this i915 is
not working on KBL.
Good thing is that this platform is still protected by preliminary_hw_support.

Thanks,
Rodrigo.

On Thu, Jan 7, 2016 at 4:49 PM, Rodrigo Vivi  wrote:
> When adding IS_KABYLAKE definition I didn't included the
> DC states related because I was planing to include them
> with the patch that fixes DMC firmware loading, but I
> forgot them.
>
> Meanwhile this runtime pm code changed a lot for
> Skylake.
>
> Well, I didn't expect that this would crash the machine
> and I just noticed now that Sarah warned me our driver
> wasn't working. Thanks Sarah.
>
> Michel had found the main error first and his
> fix had better details on the history and got
> merged already:
>
> commit 16fbc291cb87c7defcd13ad715d3e4af0d523e43
> Author: Michel Thierry 
> Date:   Wed Jan 6 12:08:36 2016 +
>
> drm/i915/kbl: Enable PW1 and Misc I/O power wells
>
> This one is a follow-up adding the other remaining
> missing pieces.
>
> v2: Rebased on top of Michel's patch as explained above.
>
> Cc: Sarah Sharp 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: Michel Thierry 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_csr.c|  5 +++--
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 15 ++-
>  2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index 9bb63a8..3f69829 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -278,7 +278,8 @@ static uint32_t *parse_csr_fw(struct drm_i915_private 
> *dev_priv,
>
> csr->version = css_header->version;
>
> -   if (IS_SKYLAKE(dev) && csr->version < SKL_CSR_VERSION_REQUIRED) {
> +   if ((IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) &&
> +csr->version < SKL_CSR_VERSION_REQUIRED) {
> DRM_INFO("Refusing to load old Skylake DMC firmware v%u.%u,"
>  " please upgrade to v%u.%u or later"
>  " 
> [https://01.org/linuxgraphics/intel-linux-graphics-firmwares].\n;,
> @@ -421,7 +422,7 @@ void intel_csr_ucode_init(struct drm_i915_private 
> *dev_priv)
> if (!HAS_CSR(dev_priv))
> return;
>
> -   if (IS_SKYLAKE(dev_priv))
> +   if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv))
> csr->fw_path = I915_CSR_SKL;
> else if (IS_BROXTON(dev_priv))
> csr->fw_path = I915_CSR_BXT;
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 4b44e68..89a7dd8 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -532,7 +532,8 @@ static void assert_can_enable_dc5(struct drm_i915_private 
> *dev_priv)
> bool pg2_enabled = intel_display_power_well_is_enabled(dev_priv,
> SKL_DISP_PW_2);
>
> -   WARN_ONCE(!IS_SKYLAKE(dev), "Platform doesn't support DC5.\n");
> +   WARN_ONCE(!IS_SKYLAKE(dev) && !IS_KABYLAKE(dev),
> + "Platform doesn't support DC5.\n");
> WARN_ONCE(!HAS_RUNTIME_PM(dev), "Runtime PM not enabled.\n");
> WARN_ONCE(pg2_enabled, "PG2 not disabled to enable DC5.\n");
>
> @@ -568,7 +569,8 @@ static void assert_can_enable_dc6(struct drm_i915_private 
> *dev_priv)
>  {
> struct drm_device *dev = dev_priv->dev;
>
> -   WARN_ONCE(!IS_SKYLAKE(dev), "Platform doesn't support DC6.\n");
> +   WARN_ONCE(!IS_SKYLAKE(dev) && !IS_KABYLAKE(dev),
> + "Platform doesn't support DC6.\n");
> WARN_ONCE(!HAS_RUNTIME_PM(dev), "Runtime PM not enabled.\n");
> WARN_ONCE(I915_READ(UTIL_PIN_CTL) & UTIL_PIN_ENABLE,
>   "Backlight is not disabled.\n");
> @@ -595,7 +597,8 @@ static void gen9_disable_dc5_dc6(struct drm_i915_private 
> *dev_priv)
>  {
> assert_can_disable_dc5(dev_priv);
>
> -   if (IS_SKYLAKE(dev_priv) && i915.enable_dc != 0 && i915.enable_dc != 
> 1)
> +   if ((IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) &&
> +   i915.enable_dc != 0 && i915.enable_dc != 1)
> assert_can_disable_dc6(dev_priv);
>
> gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> @@ -783,7 +786,8 @@ static void gen9_dc_off_power_well_enable(struct 
> drm_i915_private *dev_priv,
>  static void gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv,
>struct i915_power_well *power_well)
>  {
> -   if (IS_SKYLAKE(dev_priv) && i915.enable_dc != 0 && i915.enable_dc != 
> 1)
> +   if ((IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) &&

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

[Matt Roper]

On Thu, Feb 25, 2016 at 03:33:42PM +, Lionel Landwerlin wrote:
> Patch based on a previous series by Shashank Sharma.
> 
> v2: Do not read GAMMA_MODE register to figure what mode we're in
> 
> v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0
> 
> Add documentation on how the Broadcast RGB property is affected by CTM
> 
> v4: Update contributors
> 
> v5: Refactor degamma/gamma LUTs load into a single function
> 
> v6: Fix missing intel_crtc variable (bisect issue)
> 
> v7: Fix & simplify limited range matrix multiplication
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Kumar, Kiran S 
> Signed-off-by: Kausal Malladi 

There are two trivial typo/style items that I call out farther down, but
aside from those, you've addressed everything I saw in earlier versions
of this patch.  It's a pretty large/complicated patch overall, so there
may be things I missed, but I think it's in good enough shape to merge.

Acknowledged-by: Matt Roper 


> ---
>  Documentation/DocBook/gpu.tmpl   |   6 +-
>  drivers/gpu/drm/i915/i915_drv.c  |  24 ++-
>  drivers/gpu/drm/i915/i915_drv.h  |   6 +
>  drivers/gpu/drm/i915/i915_reg.h  |  22 +++
>  drivers/gpu/drm/i915/intel_color.c   | 341 
> ++-
>  drivers/gpu/drm/i915/intel_display.c |  22 ++-
>  drivers/gpu/drm/i915/intel_drv.h |   3 +-
>  drivers/gpu/drm/i915/intel_fbdev.c   |   8 +
>  8 files changed, 369 insertions(+), 63 deletions(-)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 1692c4d..430e99b 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -2153,7 +2153,11 @@ void intel_crt_init(struct drm_device *dev)
>   ENUM
>   { "Automatic", "Full", "Limited 16:235" }
>   Connector
> - TBD
> + When this property is set to Limited 16:235
> + and CTM is set, the hardware will be programmed with the
> + result of the multiplication of CTM by the limited range
> + matrix to ensure the pixels normaly in the range 0..1.0 are
> + remapped to the range 16/255..235/255.
>   
>   
>   “audio”
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 20e8200..3807b73 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -66,6 +66,9 @@ static struct drm_driver driver;
>  #define IVB_CURSOR_OFFSETS \
>   .cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET, 
> IVB_CURSOR_C_OFFSET }
>  
> +#define BDW_COLORS \
> + .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
> +
>  static const struct intel_device_info intel_i830_info = {
>   .gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
>   .has_overlay = 1, .overlay_needs_physical = 1,
> @@ -288,24 +291,28 @@ static const struct intel_device_info 
> intel_haswell_m_info = {
>   .is_mobile = 1,
>  };
>  
> +#define BDW_FEATURES \
> + HSW_FEATURES, \
> + BDW_COLORS
> +
>  static const struct intel_device_info intel_broadwell_d_info = {
> - HSW_FEATURES,
> + BDW_FEATURES,
>   .gen = 8,
>  };
>  
>  static const struct intel_device_info intel_broadwell_m_info = {
> - HSW_FEATURES,
> + BDW_FEATURES,
>   .gen = 8, .is_mobile = 1,
>  };
>  
>  static const struct intel_device_info intel_broadwell_gt3d_info = {
> - HSW_FEATURES,
> + BDW_FEATURES,
>   .gen = 8,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
>  
>  static const struct intel_device_info intel_broadwell_gt3m_info = {
> - HSW_FEATURES,
> + BDW_FEATURES,
>   .gen = 8, .is_mobile = 1,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
>  };
> @@ -321,13 +328,13 @@ static const struct intel_device_info 
> intel_cherryview_info = {
>  };
>  
>  static const struct intel_device_info intel_skylake_info = {
> - HSW_FEATURES,
> + BDW_FEATURES,
>   .is_skylake = 1,
>   .gen = 9,
>  };
>  
>  static const struct intel_device_info intel_skylake_gt3_info = {
> - HSW_FEATURES,
> + BDW_FEATURES,
>   .is_skylake = 1,
>   .gen = 9,
>   .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
> @@ -345,17 +352,18 @@ static const struct intel_device_info 
> intel_broxton_info = {
>   .has_fbc = 1,
>   GEN_DEFAULT_PIPEOFFSETS,
>   IVB_CURSOR_OFFSETS,
> + BDW_COLORS,
>  };
>  
>  static const struct intel_device_info intel_kabylake_info = {
> - HSW_FEATURES,
> + BDW_FEATURES,
>   .is_preliminary = 1,
>   .is_kabylake = 1,
>   .gen = 9,
>  };
>  
>  static const struct intel_device_info intel_kabylake_gt3_info = {
> - HSW_FEATURES,
> + BDW_FEATURES,
>   .is_preliminary = 1,
>   

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

[Clint Taylor]

On 02/25/2016 05:49 AM, Ville Syrjälä wrote:

On Tue, Feb 16, 2016 at 09:44:55AM -0800, clinton.a.tay...@intel.com wrote:

From: Clint Taylor 

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.

Signed-off-by: Clint Taylor 
Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= 


I finally got around to actually trying this out myself, and I
noticed a few remaining problems:

- skl_modeset_calc_cdclk() should calculate dev_cdclk as well
   dev_cdclk will be the same as cdclk, except when all pipes are
   inactive, at which point dev_cdclk should be the minimum cdclk


That explains the relationship between dev_cdclk and cdclk.


- skl_modeset_commit_cdclk() should commit dev_cdclk, not cdclk


correct, based on the above statement. New version on its way.


- modeset_update_crtc_power_domains() should check of the current
   vco is different from the requested vco in addition to checking
   the dev_cdclk vs. current cdclk, just like intel_modeset_checks()
   does
modeset_update_crtc_power_domains() no longer exists. However it appears 
the functionality has been moved to intel_atomic_commit(). I will add 
the vco check into intel_atomic_commit()




So the current thing works, but it fails to drop the cdclk to minimum
when all pipes are inactive, and it also reprograms the cdclk every
time, I assume since it forgot to compute dev_cdclk and so that one
is probably left at 0 and so it never matches the current cdclk.


---
  drivers/gpu/drm/i915/i915_drv.h  |2 +-
  drivers/gpu/drm/i915/intel_ddi.c |2 +-
  drivers/gpu/drm/i915/intel_display.c |  102 +-
  drivers/gpu/drm/i915/intel_dp.c  |6 +-
  drivers/gpu/drm/i915/intel_drv.h |4 ++
  5 files changed, 99 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8216665..f65dd1a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1822,7 +1822,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 hpll_freq;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 6d5b09f..285adab 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2958,7 +2958,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 9e2273b..e118ce0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5663,7 +5663,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;

@@ -5821,17 +5821,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 == 

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

[Matt Roper]

On Thu, Feb 25, 2016 at 10:58:46AM +, Lionel Landwerlin wrote:
> Implement Daniel Stone's recommendation to not read registers to infer
> the hardware's state.
> 
> v2: Read GAMMA_MODE register value at init (Matt Roper's comment)
> 
> v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along
> with other registers (Matt Roper's comment).
> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/intel_color.c   | 12 
>  drivers/gpu/drm/i915/intel_display.c |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h |  3 +++
>  3 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_color.c 
> b/drivers/gpu/drm/i915/intel_color.c
> index 5e0b997..16657eb 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -121,6 +121,8 @@ static void haswell_load_luts(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);
> + struct intel_crtc_state *intel_crtc_state =
> + to_intel_crtc_state(crtc->state);
>   bool reenable_ips = false;
>  
>   /*
> @@ -128,11 +130,12 @@ static void haswell_load_luts(struct drm_crtc *crtc)
>* GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
>*/
>   if (IS_HASWELL(dev) && intel_crtc->config->ips_enabled &&
> - ((I915_READ(GAMMA_MODE(intel_crtc->pipe)) & GAMMA_MODE_MODE_MASK) ==
> -  GAMMA_MODE_MODE_SPLIT)) {
> + (intel_crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
>   hsw_disable_ips(intel_crtc);
>   reenable_ips = true;
>   }
> +
> + intel_crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
>   I915_WRITE(GAMMA_MODE(intel_crtc->pipe), GAMMA_MODE_MODE_8BIT);
>  
>   i9xx_load_luts(crtc);
> @@ -183,8 +186,9 @@ void intel_color_init(struct drm_crtc *crtc)
>   }
>  
>   if (IS_HASWELL(dev) ||
> - (INTEL_INFO(dev)->gen >= 8 && !IS_CHERRYVIEW(dev)))
> + (INTEL_INFO(dev)->gen >= 8 && !IS_CHERRYVIEW(dev))) {
>   dev_priv->display.load_luts = haswell_load_luts;
> - else
> + } else {
>   dev_priv->display.load_luts = i9xx_load_luts;
> + }
>  }
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index acbb1d9..19f8284 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9891,6 +9891,8 @@ static bool haswell_get_pipe_config(struct intel_crtc 
> *crtc,
>  
>   intel_get_pipe_timings(crtc, pipe_config);
>  
> + pipe_config->gamma_mode = I915_READ(GAMMA_MODE(crtc->pipe));

I think you want to mask this with GAMMA_MODE_MODE_MASK since there may
be stuff in the higher bits.

With that change made, you can consider this patch

Reviewed-by: Matt Roper 


> +
>   if (INTEL_INFO(dev)->gen >= 9) {
>   skl_init_scalers(dev, crtc, pipe_config);
>   }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 7532f61..8c48131 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -517,6 +517,9 @@ struct intel_crtc_state {
>   struct skl_pipe_wm skl;
>   } optimal;
>   } wm;
> +
> + /* Gamma mode programmed on the pipe */
> + uint32_t gamma_mode;
>  };
>  
>  struct vlv_wm_state {
> -- 
> 2.7.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH] drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)

[Imre Deak]

On Thu, 2016-02-25 at 21:10 +, Chris Wilson wrote:
> commit 09731280028ce03e6a27e1998137f1775a2839f3
> Author: Imre Deak 
> Date:   Wed Feb 17 14:17:42 2016 +0200
> 
> drm/i915: Add helper to get a display power ref if it was already
> enabled
> 
> left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled
> as
> intel_runtime_pm_get_if_in_use() would return true without
> incrementing
> the local bookkeeping required for the assertions.
> 
> Signed-off-by: Chris Wilson 
> CC: Mika Kuoppala 
> CC: Joonas Lahtinen 
> CC: Ville Syrjälä 
> Cc: Imre Deak 

Arg, I broke this in v3. Thanks for catching it:
Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 26 ---
> ---
>  1 file changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index e2329768902c..4172e73212cd 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2365,22 +2365,20 @@ bool intel_runtime_pm_get_if_in_use(struct
> drm_i915_private *dev_priv)
>  {
>   struct drm_device *dev = dev_priv->dev;
>   struct device *device = >pdev->dev;
> - int ret;
>  
> - if (!IS_ENABLED(CONFIG_PM))
> - return true;
> + if (IS_ENABLED(CONFIG_PM)) {
> + int ret = pm_runtime_get_if_in_use(device);
>  
> - ret = pm_runtime_get_if_in_use(device);
> -
> - /*
> -  * In cases runtime PM is disabled by the RPM core and we
> get an
> -  * -EINVAL return value we are not supposed to call this
> function,
> -  * since the power state is undefined. This applies atm to
> the
> -  * late/early system suspend/resume handlers.
> -  */
> - WARN_ON_ONCE(ret < 0);
> - if (ret <= 0)
> - return false;
> + /*
> +  * In cases runtime PM is disabled by the RPM core
> and we get
> +  * an -EINVAL return value we are not supposed to
> call this
> +  * function, since the power state is undefined.
> This applies
> +  * atm to the late/early system suspend/resume
> handlers.
> +  */
> + WARN_ON_ONCE(ret < 0);
> + if (ret <= 0)
> + return false;
> + }
>  
>   atomic_inc(_priv->pm.wakeref_count);
>   assert_rpm_wakelock_held(dev_priv);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] snd-hda-intel runtime PM fail after module reload

[Ville Syrjälä]

On Thu, Feb 25, 2016 at 09:28:59PM +0100, Takashi Iwai wrote:
> On Thu, 25 Feb 2016 20:19:08 +0100,
> Ville Syrjälä wrote:
> > 
> > Hi,
> > 
> > My investigation into some sporadic i915 runtime PM failures seem to
> > point the finger at snd-hda-intel.
> > 
> > I just tried to play around unloding and reloading snd-hda-intel and
> > sometimes I get snd-hda-intel loaded with runtime PM supposedly enabled,
> > but actually the device won't runtime suspend. At which point frobbing
> > with power/control is enough to kick it back into submission.
> 
> Which platform are you testing?  If it's SKL, BSW or later, multiple
> codecs are on a single HD-audio bus.  In general, you have to adjust
> the runtime PM of all these codecs in addition to the runtime PM of
> the controller.  Some of them are immediately runtime PM enabled but
> some of them aren't, left the default as is.

This was on a HSW.

I also have CONFIG_SND_HDA_POWER_SAVE_DEFAULT=1 which I presume should
enable codec power saving by deafault?

> It might be that your desktop environment adjusts the runtime PM of
> HD-audio stuff, often depending on the power state.  But when you
> reload, this adjustment is also lost, so you'd have to adjust
> manually.

There's no desktop environment. Well, unless you count systemd as such.
As you can see from the log I included at least the pci device power/control
file stayed at 'auto' the whole time until I flipped it to 'on' and then
back to 'auto' to fix the problem.

Also the problem didn't happen on every reload AFAICS, so there's
something rather non-deterministic happening.

-- 
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] drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)

[Chris Wilson]

commit 09731280028ce03e6a27e1998137f1775a2839f3
Author: Imre Deak 
Date:   Wed Feb 17 14:17:42 2016 +0200

drm/i915: Add helper to get a display power ref if it was already enabled

left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as
intel_runtime_pm_get_if_in_use() would return true without incrementing
the local bookkeeping required for the assertions.

Signed-off-by: Chris Wilson 
CC: Mika Kuoppala 
CC: Joonas Lahtinen 
CC: Ville Syrjälä 
Cc: Imre Deak 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index e2329768902c..4172e73212cd 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2365,22 +2365,20 @@ bool intel_runtime_pm_get_if_in_use(struct 
drm_i915_private *dev_priv)
 {
struct drm_device *dev = dev_priv->dev;
struct device *device = >pdev->dev;
-   int ret;
 
-   if (!IS_ENABLED(CONFIG_PM))
-   return true;
+   if (IS_ENABLED(CONFIG_PM)) {
+   int ret = pm_runtime_get_if_in_use(device);
 
-   ret = pm_runtime_get_if_in_use(device);
-
-   /*
-* In cases runtime PM is disabled by the RPM core and we get an
-* -EINVAL return value we are not supposed to call this function,
-* since the power state is undefined. This applies atm to the
-* late/early system suspend/resume handlers.
-*/
-   WARN_ON_ONCE(ret < 0);
-   if (ret <= 0)
-   return false;
+   /*
+* In cases runtime PM is disabled by the RPM core and we get
+* an -EINVAL return value we are not supposed to call this
+* function, since the power state is undefined. This applies
+* atm to the late/early system suspend/resume handlers.
+*/
+   WARN_ON_ONCE(ret < 0);
+   if (ret <= 0)
+   return false;
+   }
 
atomic_inc(_priv->pm.wakeref_count);
assert_rpm_wakelock_held(dev_priv);
-- 
2.7.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Rob Clark]

On Tue, Feb 23, 2016 at 9:33 PM, Thulasimani, Sivakumar
 wrote:
>
>
> On 2/24/2016 3:41 AM, Lyude wrote:
>>
>> As it turns out, resuming DP MST is racey since we don't make sure MST
>> is ready before we start modesetting, it just usually happens to be
>> ready in time. This isn't the case on all systems, particularly a
>> ThinkPad T560 with displays connected through the dock. On these
>> systems, resuming the laptop while connected to the dock usually results
>> in blank monitors. Making sure MST is ready before doing any kind of
>> modesetting fixes this issue.
>
> basic question since i haven't worked on MST much. MST should work like any
> other digital panel on resume. i.e detect followed by modeset. in the
> modified
> commit mentioned below is it failing to detect the panel or failing at the
> modeset ?
> if we are depending on the intel_display_resume, how about moving the
> intel_dp_mst_resume just above intel_display_resume?
>

so I think the issue is there needs to be communication with (for
example) hubs that sit downstream..  we probably do need enough clks
and irq's going so that dpcd xfer's work, but then I think we should
do mst_resume() first and then display_resume()

BR,
-R

>
> Generic question to others in mail list on i915_drm_resume
> we are doing a modeset and then doing the detect/hpd init.
> shouldn't this be the other way round ? almost all displays
> will pass a modeset even if display is not connected so we
> are spending time on modeset even for displays that were
> removed during the suspend state. if this is to simply
> drm_state being saved and restored,
>>
>> We originally changed the resume order in
>>
>> commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw
>> state")
>>
>> to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
>> issue now anyhow.
>>
>> CC: sta...@vger.kernel.org
>> Signed-off-by: Lyude 
>> ---
>>   drivers/gpu/drm/i915/i915_drv.c | 10 --
>>   1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index f357058..4dcf3dd 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -733,6 +733,14 @@ static int i915_drm_resume(struct drm_device *dev)
>> intel_opregion_setup(dev);
>> intel_init_pch_refclk(dev);
>> +
>> +   /*
>> +* We need to make sure that we resume MST before doing anything
>> +* display related, otherwise we risk trying to bring up a display
>> on
>> +* MST before the hub is actually ready
>> +*/
>> +   intel_dp_mst_resume(dev);
>> +
>
> This does not look proper. if the CD clock is turned off during suspend
> our dpcd read itself might fail till we enable CD Clock.
>
> regards,
> Sivakumar
>>
>> drm_mode_config_reset(dev);
>> /*
>> @@ -765,8 +773,6 @@ static int i915_drm_resume(struct drm_device *dev)
>> intel_display_resume(dev);
>> drm_modeset_unlock_all(dev);
>>   - intel_dp_mst_resume(dev);
>> -
>> /*
>>  * ... but also need to make sure that hotplug processing
>>  * doesn't cause havoc. Like in the driver load code we don't
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] snd-hda-intel runtime PM fail after module reload

[Takashi Iwai]

On Thu, 25 Feb 2016 20:19:08 +0100,
Ville Syrjälä wrote:
> 
> Hi,
> 
> My investigation into some sporadic i915 runtime PM failures seem to
> point the finger at snd-hda-intel.
> 
> I just tried to play around unloding and reloading snd-hda-intel and
> sometimes I get snd-hda-intel loaded with runtime PM supposedly enabled,
> but actually the device won't runtime suspend. At which point frobbing
> with power/control is enough to kick it back into submission.

Which platform are you testing?  If it's SKL, BSW or later, multiple
codecs are on a single HD-audio bus.  In general, you have to adjust
the runtime PM of all these codecs in addition to the runtime PM of
the controller.  Some of them are immediately runtime PM enabled but
some of them aren't, left the default as is.

It might be that your desktop environment adjusts the runtime PM of
HD-audio stuff, often depending on the power state.  But when you
reload, this adjustment is also lost, so you'd have to adjust
manually.


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

[Intel-gfx] snd-hda-intel runtime PM fail after module reload

[Ville Syrjälä]

Hi,

My investigation into some sporadic i915 runtime PM failures seem to
point the finger at snd-hda-intel.

I just tried to play around unloding and reloading snd-hda-intel and
sometimes I get snd-hda-intel loaded with runtime PM supposedly enabled,
but actually the device won't runtime suspend. At which point frobbing
with power/control is enough to kick it back into submission.

# for i in `seq 1 3`; do sleep 1 ; grep . 
/sys/bus/pci/devices/\:00\:03.0/power/*  ; done
/sys/bus/pci/devices/:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/:00:03.0/power/autosuspend_delay_ms: 
Input/output error
/sys/bus/pci/devices/:00:03.0/power/control:auto
/sys/bus/pci/devices/:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/:00:03.0/power/runtime_active_time:117045
/sys/bus/pci/devices/:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/:00:03.0/power/runtime_status:suspended
/sys/bus/pci/devices/:00:03.0/power/runtime_suspended_time:222657
/sys/bus/pci/devices/:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/:00:03.0/power/autosuspend_delay_ms: 
Input/output error
/sys/bus/pci/devices/:00:03.0/power/control:auto
/sys/bus/pci/devices/:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/:00:03.0/power/runtime_active_time:117045
/sys/bus/pci/devices/:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/:00:03.0/power/runtime_status:suspended
/sys/bus/pci/devices/:00:03.0/power/runtime_suspended_time:223666
/sys/bus/pci/devices/:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/:00:03.0/power/autosuspend_delay_ms: 
Input/output error
/sys/bus/pci/devices/:00:03.0/power/control:auto
/sys/bus/pci/devices/:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/:00:03.0/power/runtime_active_time:117045
/sys/bus/pci/devices/:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/:00:03.0/power/runtime_status:suspended
/sys/bus/pci/devices/:00:03.0/power/runtime_suspended_time:224674
/sys/bus/pci/devices/:00:03.0/power/runtime_usage:0
# rmmod snd-hda-intel
# modprobe snd-hda-intel
# for i in `seq 1 3`; do sleep 1 ; grep . 
/sys/bus/pci/devices/\:00\:03.0/power/*  ; done
/sys/bus/pci/devices/:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/:00:03.0/power/autosuspend_delay_ms: 
Input/output error
/sys/bus/pci/devices/:00:03.0/power/control:auto
/sys/bus/pci/devices/:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/:00:03.0/power/runtime_active_time:121454
/sys/bus/pci/devices/:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/:00:03.0/power/runtime_status:active
/sys/bus/pci/devices/:00:03.0/power/runtime_suspended_time:228560
/sys/bus/pci/devices/:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/:00:03.0/power/autosuspend_delay_ms: 
Input/output error
/sys/bus/pci/devices/:00:03.0/power/control:auto
/sys/bus/pci/devices/:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/:00:03.0/power/runtime_active_time:122463
/sys/bus/pci/devices/:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/:00:03.0/power/runtime_status:active
/sys/bus/pci/devices/:00:03.0/power/runtime_suspended_time:228560
/sys/bus/pci/devices/:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/:00:03.0/power/autosuspend_delay_ms: 
Input/output error
/sys/bus/pci/devices/:00:03.0/power/control:auto
/sys/bus/pci/devices/:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/:00:03.0/power/runtime_active_time:123472
/sys/bus/pci/devices/:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/:00:03.0/power/runtime_status:active
/sys/bus/pci/devices/:00:03.0/power/runtime_suspended_time:228560
/sys/bus/pci/devices/:00:03.0/power/runtime_usage:0
# echo on > /sys/bus/pci/devices/:00:03.0/power/control
# echo auto > /sys/bus/pci/devices/:00:03.0/power/control
# for i in `seq 1 3`; do sleep 1 ; grep . 
/sys/bus/pci/devices/\:00\:03.0/power/*  ; done
/sys/bus/pci/devices/:00:03.0/power/async:enabled
grep: /sys/bus/pci/devices/:00:03.0/power/autosuspend_delay_ms: 
Input/output error
/sys/bus/pci/devices/:00:03.0/power/control:auto
/sys/bus/pci/devices/:00:03.0/power/runtime_active_kids:0
/sys/bus/pci/devices/:00:03.0/power/runtime_active_time:141459
/sys/bus/pci/devices/:00:03.0/power/runtime_enabled:enabled
/sys/bus/pci/devices/:00:03.0/power/runtime_status:suspended
/sys/bus/pci/devices/:00:03.0/power/runtime_suspended_time:231699
/sys/bus/pci/devices/:00:03.0/power/runtime_usage:0
/sys/bus/pci/devices/:00:03.0/power/async:enabled
grep: 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Some FDI related dotclock stuff

[Ville Syrjälä]

On Fri, Feb 19, 2016 at 01:45:03PM -, Patchwork wrote:
> == Summary ==
> 
> Series 3541v1 drm/i915: Some FDI related dotclock stuff
> http://patchwork.freedesktop.org/api/1.0/series/3541/revisions/1/mbox/
> 
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> FAIL   (snb-x220t)

(kms_flip:6443) DEBUG: name = vblank
last_ts = 594.687318 usec
last_received_ts = 594.687142 usec
last_seq = 24682
current_ts = 594.870400 usec
current_received_ts = 594.870267 usec
current_seq = 24692
count = 44
seq_step = 10
(kms_flip:6443) CRITICAL: Test assertion failure function check_state, file 
kms_flip.c:692:
(kms_flip:6443) CRITICAL: Failed assertion: fabsdouble) diff.tv_usec) - 
usec_interflip) / usec_interflip) <= 0.005
(kms_flip:6443) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_flip:6443) CRITICAL: inter-vblank ts jitter: 0s, 183082usec

Hmm. So here it looks like the seq number says 10, but the timestamp
difference says 11. I found a few more of the same in the CI results.
This could be due to the race with even numbered vblank seq increments
that could be fixed by:
https://lists.freedesktop.org/archives/dri-devel/2015-September/090288.html

Filed a bug:
https://bugs.freedesktop.org/show_bug.cgi?id=94294

> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-b:
> pass   -> INCOMPLETE (ilk-hp8440p)
> Subgroup suspend-read-crc-pipe-a:
> dmesg-warn -> PASS   (skl-i5k-2) UNSTABLE
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (skl-i5k-2) UNSTABLE
> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS   (bsw-nuc-2)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> dmesg-warn -> PASS   (bsw-nuc-2)
> pass   -> DMESG-WARN (byt-nuc)

[  126.296996] [drm:intel_runtime_suspend [i915]] *ERROR* Unclaimed access 
detected prior to suspending
https://bugs.freedesktop.org/show_bug.cgi?id=94164

> Subgroup basic-rte:
> pass   -> DMESG-WARN (bsw-nuc-2)
> pass   -> FAIL   (bdw-ultra)

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

> dmesg-warn -> PASS   (byt-nuc) UNSTABLE
> 
> bdw-nuci7total:164  pass:153  dwarn:0   dfail:0   fail:0   skip:11 
> bdw-ultratotal:167  pass:152  dwarn:0   dfail:0   fail:1   skip:14 
> bsw-nuc-2total:167  pass:136  dwarn:1   dfail:0   fail:0   skip:30 
> byt-nuc  total:167  pass:141  dwarn:1   dfail:0   fail:0   skip:25 
> hsw-gt2  total:167  pass:156  dwarn:0   dfail:0   fail:1   skip:10 
> ilk-hp8440p  total:163  pass:114  dwarn:0   dfail:0   fail:1   skip:47 
> ivb-t430stotal:167  pass:152  dwarn:0   dfail:0   fail:1   skip:14 
> skl-i5k-2total:167  pass:150  dwarn:1   dfail:0   fail:0   skip:16 
> snb-dellxps  total:167  pass:144  dwarn:0   dfail:0   fail:1   skip:22 
> snb-x220ttotal:167  pass:143  dwarn:0   dfail:0   fail:3   skip:21 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1429/
> 
> 631053ba117c294f0cdfe704718a040b4406a240 drm-intel-nightly: 
> 2016y-02m-17d-21h-05m-38s UTC integration manifest
> beb6d5046d6b0eafd0aa4bc15a87e534e3e0aa8e drm/i915: Try to fix CRT port clock 
> limits
> c7f53fb3c57d5a91216c037d757876e3a692ae0e drm/i915: Read out VGA dotclock 
> properly on LPT
> 3c2e8606fb856686e2fa84b10f1c22ef2d209e17 drm/i915: Make the LPT iclkip 20MHz 
> case more generic
> 6bb0fff788112afbb60391b5a77e4f62745ba0f7 drm/i915: Remove the SPLL==270Mhz 
> assumption from intel_fdi_link_freq()
> f8260170eff5e4763d1c99e1baa3246f19c294d5 drm/i915: Move the encoder vs. FDI 
> dotclock check out from encoder .get_config()
> 865134f99bff4ba3a91d2703282aa16c83d8ce52 drm/i915: Dump ddi_pll_sel in hex 
> instead of decimal on HSW/BDW

-- 
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: warning for drm/i915: add enable_guc_loading parameter (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: add enable_guc_loading parameter (rev2)
URL   : https://patchwork.freedesktop.org/series/3045/
State : warning

== Summary ==

Series 3045v2 drm/i915: add enable_guc_loading parameter
http://patchwork.freedesktop.org/api/1.0/series/3045/revisions/2/mbox/

Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-load-detect:
fail   -> DMESG-FAIL (snb-x220t)
dmesg-fail -> FAIL   (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (hsw-gt2)
pass   -> DMESG-WARN (ivb-t430s)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (byt-nuc)
Subgroup basic-rte:
fail   -> PASS   (bdw-ultra)

bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:137  dwarn:0   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:143  dwarn:0   dfail:0   fail:0   skip:25 
hsw-brixbox  total:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
hsw-gt2  total:168  pass:156  dwarn:0   dfail:1   fail:0   skip:11 
ilk-hp8440p  total:168  pass:117  dwarn:1   dfail:0   fail:1   skip:49 
ivb-t430stotal:168  pass:152  dwarn:1   dfail:0   fail:1   skip:14 
skl-i7k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:1   fail:1   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1478/

38f0cd5314ecb02d15d019631e388d3642275600 drm-intel-nightly: 
2016y-02m-25d-15h-33m-53s UTC integration manifest
7cd8e5dc284499930311e7b005f8d5b42607ab73 drm/i915: add enable_guc_loading 
parameter

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

Re: [Intel-gfx] [PATCH 044/190] drm/i915: Move GEM request routines to i915_gem_request.c

[Arun Siluvery]

On 11/01/2016 09:16, Chris Wilson wrote:

Migrate the request operations out of the main body of i915_gem.c and
into their own C file for easier expansion.

v2: Move __i915_add_request() across as well

Signed-off-by: Chris Wilson 
---


don't we lose the history in git blame when moved to a new file? is this 
ok? especially for files like i915_gem.c.


regards
Arun


  drivers/gpu/drm/i915/Makefile   |   1 +
  drivers/gpu/drm/i915/i915_drv.h | 205 +-
  drivers/gpu/drm/i915/i915_gem.c | 652 +--
  drivers/gpu/drm/i915/i915_gem_request.c | 659 
  drivers/gpu/drm/i915/i915_gem_request.h | 223 +++
  5 files changed, 895 insertions(+), 845 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/i915_gem_request.c
  create mode 100644 drivers/gpu/drm/i915/i915_gem_request.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 99ce591c8574..b0a83215db80 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -31,6 +31,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_gtt.o \
  i915_gem.o \
  i915_gem_render_state.o \
+ i915_gem_request.o \
  i915_gem_shrinker.o \
  i915_gem_stolen.o \
  i915_gem_tiling.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 57e450e25ad6..ee146ce02412 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -41,6 +41,7 @@
  #include "intel_lrc.h"
  #include "i915_gem_gtt.h"
  #include "i915_gem_render_state.h"
+#include "i915_gem_request.h"
  #include 
  #include 
  #include 
@@ -2162,179 +2163,15 @@ struct drm_i915_gem_object {
  };
  #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)

-void i915_gem_track_fb(struct drm_i915_gem_object *old,
-  struct drm_i915_gem_object *new,
-  unsigned frontbuffer_bits);
-
-/**
- * Request queue structure.
- *
- * The request queue allows us to note sequence numbers that have been emitted
- * and may be associated with active buffers to be retired.
- *
- * By keeping this list, we can avoid having to do questionable sequence
- * number comparisons on buffer last_read|write_seqno. It also allows an
- * emission time to be associated with the request for tracking how far ahead
- * of the GPU the submission is.
- *
- * The requests are reference counted, so upon creation they should have an
- * initial reference taken using kref_init
- */
-struct drm_i915_gem_request {
-   struct kref ref;
-
-   /** On Which ring this request was generated */
-   struct drm_i915_private *i915;
-   struct intel_engine_cs *ring;
-   unsigned reset_counter;
-
-/** GEM sequence number associated with the previous request,
- * when the HWS breadcrumb is equal to this the GPU is processing
- * this request.
- */
-   u32 previous_seqno;
-
-/** GEM sequence number associated with this request,
- * when the HWS breadcrumb is equal or greater than this the GPU
- * has finished processing this request.
- */
-   u32 seqno;
-
-   /** Position in the ringbuffer of the start of the request */
-   u32 head;
-
-   /**
-* Position in the ringbuffer of the start of the postfix.
-* This is required to calculate the maximum available ringbuffer
-* space without overwriting the postfix.
-*/
-u32 postfix;
-
-   /** Position in the ringbuffer of the end of the whole request */
-   u32 tail;
-
-   /**
-* Context and ring buffer related to this request
-* Contexts are refcounted, so when this request is associated with a
-* context, we must increment the context's refcount, to guarantee that
-* it persists while any request is linked to it. Requests themselves
-* are also refcounted, so the request will only be freed when the last
-* reference to it is dismissed, and the code in
-* i915_gem_request_free() will then decrement the refcount on the
-* context.
-*/
-   struct intel_context *ctx;
-   struct intel_ringbuffer *ringbuf;
-
-   /** Batch buffer related to this request if any (used for
-   error state dump only) */
-   struct drm_i915_gem_object *batch_obj;
-
-   /** Time at which this request was emitted, in jiffies. */
-   unsigned long emitted_jiffies;
-
-   /** global list entry for this request */
-   struct list_head list;
-
-   struct drm_i915_file_private *file_priv;
-   /** file_priv list entry for this request */
-   struct list_head client_list;
-
-   /** process identifier submitting this request */
-   struct pid *pid;
-
-   /**
-* The ELSP only accepts two elements at a time, so we queue
-* context/tail pairs on a 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v3)

[Ville Syrjälä]

On Tue, Feb 16, 2016 at 11:28:05AM -, Patchwork wrote:
> == Summary ==
> 
> Series 3455v1 drm/i915: Handle fb->offsets[] and rewrite fb rotation handling 
> to be more generic (v3)
> http://patchwork.freedesktop.org/api/1.0/series/3455/revisions/1/mbox/
> 
> Test gem_ringfill:
> Subgroup basic-default-hang:
> incomplete -> PASS   (snb-dellxps)
> Test gem_sync:
> Subgroup basic-bsd:
> dmesg-fail -> PASS   (ilk-hp8440p)
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
> Subgroup basic-flip-vs-wf_vblank:
> pass   -> FAIL   (snb-x220t)

(kms_flip:5932) DEBUG: name = flip
last_ts = 229.786169 usec
last_received_ts = 229.785609 usec
last_seq = 9555
current_ts = 229.970103 usec
current_received_ts = 229.983336 usec
current_seq = 9566
count = 30
seq_step = 1
(kms_flip:5932) CRITICAL: Test assertion failure function check_state, file 
kms_flip.c:692:
(kms_flip:5932) CRITICAL: Failed assertion: fabsdouble) diff.tv_usec) - 
usec_interflip) / usec_interflip) <= 0.005
(kms_flip:5932) CRITICAL: Last errno: 25, Inappropriate ioctl for device
(kms_flip:5932) CRITICAL: inter-flip ts jitter: 0s, 183934usec

Kinda looks like we were supposed to wait for 1 vblank and instead we
did 11. Not sure what happended.

> Test kms_force_connector_basic:
> Subgroup force-load-detect:
> fail   -> SKIP   (ivb-t430s)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> pass   -> FAIL   (bdw-nuci7)

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

> 
> bdw-nuci7total:162  pass:151  dwarn:0   dfail:0   fail:1   skip:10 
> bdw-ultratotal:165  pass:152  dwarn:0   dfail:0   fail:0   skip:13 
> bsw-nuc-2total:165  pass:135  dwarn:1   dfail:0   fail:0   skip:29 
> byt-nuc  total:165  pass:140  dwarn:1   dfail:0   fail:0   skip:24 
> hsw-brixbox  total:165  pass:151  dwarn:0   dfail:0   fail:0   skip:14 
> hsw-gt2  total:165  pass:154  dwarn:0   dfail:0   fail:1   skip:10 
> ilk-hp8440p  total:165  pass:116  dwarn:0   dfail:0   fail:1   skip:48 
> ivb-t430stotal:165  pass:150  dwarn:0   dfail:0   fail:0   skip:15 
> skl-i5k-2total:165  pass:150  dwarn:0   dfail:0   fail:0   skip:15 
> snb-dellxps  total:165  pass:142  dwarn:0   dfail:0   fail:1   skip:22 
> snb-x220ttotal:165  pass:141  dwarn:0   dfail:0   fail:3   skip:21 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_1410/
> 
> 63cbdd1816fd78d404ed004b0f931c497625e0df drm-intel-nightly: 
> 2016y-02m-16d-09h-41m-02s UTC integration manifest
> b84ef2badea15712a81923b7df4706b24bc169ca drm/i915: Make sure fb offset is 
> (macro)pixel aligned
> ca71915fbb9c4c8ba57604ce6c8845fe03a43d7a drm/i915: Deal with NV12 CbCr plane 
> AUX surface on SKL+
> d7f9294ecc8efdc5ee8ab82f507fbdfa908c85aa drm/i915: Compute display surface 
> offset in the plane check hook for SKL+
> 8bef0691c82442ec596fdc70567f8c5e2811ae05 drm/i915: Make 
> intel_adjust_tile_offset() work for linear buffers
> 1a99c9e2231d7e6f09606019ffe5adf7f0a80357 drm/i915: Allow calling 
> intel_adjust_tile_offset() multiple times
> c49b5375a08ed884e8606ef7d31a6715cbb25f0c drm/i915: Limit fb x offset due to 
> fences
> 7491f5ca5dab46dd1a76cf29aafdfc0d4e98bb1e drm/i915: Adjust obj tiling vs. fb 
> modifier rules
> 185515a0d9c827dc1cac159fcadd73b9fb90b679 drm/i915: Use fb modifiers for 
> display tiling decisions
> 803c4b6df97ec77ea9d03f9c08df0937227533fb drm/i915: Pass around plane_state 
> instead of fb+rotation
> 6b6b376594dcb603d281ec732e1e5059d6619384 drm/i915: Move SKL hw stride 
> calculation into a helper
> b06dc2a2512b136c01ff44537e003cfe83d7a819 drm/i915: Don't pass pitch to 
> intel_compute_page_offset()
> defd01e2e7134e7a4885520c20e957d3be3e1447 drm/i915: Rewrite fb rotation GTT 
> handling
> b160930772ba5b6c5288721316a1691f466b3359 drm/i915: Embed rotation_info under 
> intel_framebuffer
> 5cac19f82e3eec58a3f5d804f4c1f381480193e4 drm/i915: Move the NULL sg handling 
> out from rotate_pages()
> 2a89ffc5be0aee76cb70415a04f9df031b2f6f68 drm/i915: Reorganize 
> intel_rotation_info
> 69bc06403bc4d1218a6b58ac5286e8fe7d68d1a4 drm/i915: Pass drm_frambuffer to 
> intel_compute_page_offset()
> 1cf4455801c0ac86ea4c3634f96c725834244d09 drm/i915: Don't pass 
> plane+plane_state to intel_pin_and_fence_fb_obj()
> e83c7b76fb678f07f688db4b3e7aa7a0e057d742 drm/i915: Support for extra 
> alignment for tiled surfaces
> e685ff00fa6cb9d4a9511247cc272897f59ea71e drm/i915: Pass 90/270 vs. 0/180 
> rotation info for intel_gen4_compute_page_offset()
> 27fd3a6e846364496becb6cdada752ec905d6f1b drm/i915: 
> s/tile_width/tile_width_bytes/
> 59b7e88935861c72c8f0ca8c3fcbe2cfe14a4d46 drm/i915: Account for the size of 
> the chroma plane for the rotated gtt view

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 042/190] drm/i915: Clean up GPU hang message

[Arun Siluvery]

On 11/01/2016 09:16, Chris Wilson wrote:

Remove some redundant kernel messages as we deduce a hung GPU and
capture the error state.

v2: Fix "hang" vs "no progress" message whilst I was there

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_irq.c | 21 +++--
  1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d9757d227c86..ce52d7d9ad91 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3031,8 +3031,7 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
struct drm_device *dev = dev_priv->dev;
struct intel_engine_cs *ring;
int i;
-   int busy_count = 0, rings_hung = 0;
-   bool stuck[I915_NUM_RINGS] = { 0 };
+   int busy_count = 0;
  #define BUSY 1
  #define KICK 5
  #define HUNG 20
@@ -3108,7 +3107,6 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
break;
case HANGCHECK_HUNG:
ring->hangcheck.score += HUNG;
-   stuck[i] = true;
break;
}
}
@@ -3134,17 +3132,12 @@ static void i915_hangcheck_elapsed(struct work_struct 
*work)
busy_count += busy;
}

-   for_each_ring(ring, dev_priv, i) {
-   if (ring->hangcheck.score >= HANGCHECK_SCORE_RING_HUNG) {
-   DRM_INFO("%s on %s\n",
-stuck[i] ? "stuck" : "no progress",
-ring->name);
-   rings_hung++;


this is required when engine resets are supported. I am converting this 
to an engine_mask and send it directly to i915_handle_error().


regards
Arun


-   }
-   }
-
-   if (rings_hung)
-   return i915_handle_error(dev, true, "Ring hung");
+   for_each_ring(ring, dev_priv, i)
+   if (ring->hangcheck.score >= HANGCHECK_SCORE_RING_HUNG)
+   return i915_handle_error(dev, true,
+"%s on %s",
+ring->hangcheck.action == HANGCHECK_HUNG ? 
"Hang" : "No progress" ,
+ring->name);

/* Reset timer in case GPU hangs without another request being added */
if (busy_count)



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

Re: [Intel-gfx] [PATCH 039/190] drm/i915: Remove stop-rings debugfs interface

[Arun Siluvery]

On 11/01/2016 09:16, Chris Wilson wrote:

Now that we have (near) universal GPU recovery code, we can inject a
real hang from userspace and not need any fakery. Not only does this
mean that the testing is far more realistic, but we can simplify the
kernel in the process.

v2: Replace the i915_stop_rings with a dummy implementation as igt
encodified its existence until we can release an update.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 19 +--
  drivers/gpu/drm/i915/i915_drv.c | 17 ++---
  drivers/gpu/drm/i915/i915_drv.h | 19 ---
  drivers/gpu/drm/i915/i915_gem.c | 13 +++--
  drivers/gpu/drm/i915/intel_lrc.c|  5 -
  drivers/gpu/drm/i915/intel_ringbuffer.c |  8 
  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
  7 files changed, 6 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 567f8db4c70a..6172649b7e56 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4752,30 +4752,13 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_wedged_fops,
  static int
  i915_ring_stop_get(void *data, u64 *val)
  {
-   struct drm_device *dev = data;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
-   *val = dev_priv->gpu_error.stop_rings;
-
+   *val = 0;
return 0;
  }

  static int
  i915_ring_stop_set(void *data, u64 val)
  {
-   struct drm_device *dev = data;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   int ret;
-
-   DRM_DEBUG_DRIVER("Stopping rings 0x%08llx\n", val);
-
-   ret = mutex_lock_interruptible(>struct_mutex);
-   if (ret)
-   return ret;
-
-   dev_priv->gpu_error.stop_rings = val;
-   mutex_unlock(>struct_mutex);
-
return 0;
  }

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 442e1217e442..e9f85fd0542f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -891,24 +891,11 @@ int i915_reset(struct drm_device *dev)
goto error;
}

+   pr_notice("drm/i915: Resetting chip after gpu hang\n");
+
i915_gem_reset(dev);

ret = intel_gpu_reset(dev);
-
-   /* Also reset the gpu hangman. */
-   if (error->stop_rings != 0) {
-   DRM_INFO("Simulated gpu hang, resetting stop_rings\n");
-   error->stop_rings = 0;
-   if (ret == -ENODEV) {
-   DRM_INFO("Reset not implemented, but ignoring "
-"error for simulated gpu hangs\n");
-   ret = 0;
-   }
-   }
-
-   if (i915_stop_ring_allow_warn(dev_priv))
-   pr_notice("drm/i915: Resetting chip after gpu hang\n");
-
if (ret) {
if (ret != -ENODEV)
DRM_ERROR("Failed to reset chip: %i\n", ret);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9ec6f3e9e74d..c3b795f1566b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1371,13 +1371,6 @@ struct i915_gpu_error {
 */
wait_queue_head_t reset_queue;

-   /* Userspace knobs for gpu hang simulation;
-* combines both a ring mask, and extra flags
-*/
-   u32 stop_rings;
-#define I915_STOP_RING_ALLOW_BAN   (1 << 31)
-#define I915_STOP_RING_ALLOW_WARN  (1 << 30)
-
/* For missed irq/seqno simulation. */
unsigned long test_irq_rings;
  };
@@ -3030,18 +3023,6 @@ static inline u32 i915_reset_count(struct i915_gpu_error 
*error)
return ((i915_reset_counter(error) & ~I915_WEDGED) + 1) / 2;
  }

-static inline bool i915_stop_ring_allow_ban(struct drm_i915_private *dev_priv)
-{
-   return dev_priv->gpu_error.stop_rings == 0 ||
-   dev_priv->gpu_error.stop_rings & I915_STOP_RING_ALLOW_BAN;
-}
-
-static inline bool i915_stop_ring_allow_warn(struct drm_i915_private *dev_priv)
-{
-   return dev_priv->gpu_error.stop_rings == 0 ||
-   dev_priv->gpu_error.stop_rings & I915_STOP_RING_ALLOW_WARN;
-}
-
  void i915_gem_reset(struct drm_device *dev);
  bool i915_gem_clflush_object(struct drm_i915_gem_object *obj, bool force);
  int __must_check i915_gem_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3948e85eaa48..ea9344503bf6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2633,21 +2633,14 @@ static bool i915_context_is_banned(struct 
drm_i915_private *dev_priv,
  {
unsigned long elapsed;

-   elapsed = get_seconds() - ctx->hang_stats.guilty_ts;
-
if (ctx->hang_stats.banned)
return true;

+   elapsed = get_seconds() - ctx->hang_stats.guilty_ts;
if (ctx->hang_stats.ban_period_seconds &&
   

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RFC,1/2] drm/i915: opt-out CPU and WC mmaps from FBC

[Patchwork]

== Series Details ==

Series: series starting with [RFC,1/2] drm/i915: opt-out CPU and WC mmaps from 
FBC
URL   : https://patchwork.freedesktop.org/series/3817/
State : failure

== Summary ==

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

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ivb-t430s)
Test kms_force_connector_basic:
Subgroup force-load-detect:
fail   -> DMESG-FAIL (snb-x220t)
fail   -> DMESG-FAIL (snb-dellxps)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (ivb-t430s)
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (hsw-brixbox)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (byt-nuc)
Subgroup basic-rte:
pass   -> FAIL   (hsw-gt2)
fail   -> PASS   (bdw-nuci7)
fail   -> PASS   (bdw-ultra)

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:137  dwarn:0   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:143  dwarn:0   dfail:0   fail:0   skip:25 
hsw-brixbox  total:168  pass:153  dwarn:0   dfail:0   fail:0   skip:15 
hsw-gt2  total:168  pass:156  dwarn:0   dfail:1   fail:1   skip:10 
ilk-hp8440p  total:168  pass:118  dwarn:0   dfail:1   fail:0   skip:49 
ivb-t430stotal:168  pass:151  dwarn:1   dfail:0   fail:2   skip:14 
skl-i7k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:1   fail:0   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:1   fail:1   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1477/

38f0cd5314ecb02d15d019631e388d3642275600 drm-intel-nightly: 
2016y-02m-25d-15h-33m-53s UTC integration manifest
ab6500ca2d5c9bce9fd7598053adc228c88d066a drm/i915/fbc: enable FBC on SKL too
680684b20c4eec08db4ba230df68a72c67865b95 drm/i915: opt-out CPU and WC mmaps 
from FBC

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

[Intel-gfx] [PATCH i-g-t 3/5] lib: fb: add igt_paint_color_gradient_range

[Lionel Landwerlin]

This is a helper to draw a gradient between 2 colors.

Signed-off-by: Lionel Landwerlin 
---
 lib/igt_fb.c  | 34 ++
 lib/igt_fb.h  |  3 +++
 lib/igt_kms.c |  2 +-
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 5f23136..bbafcd9 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -277,6 +277,40 @@ igt_paint_color_gradient(cairo_t *cr, int x, int y, int w, 
int h,
cairo_pattern_destroy(pat);
 }
 
+/**
+ * igt_paint_color_gradient_range:
+ * @cr: cairo drawing context
+ * @x: pixel x-coordination of the fill rectangle
+ * @y: pixel y-coordination of the fill rectangle
+ * @w: width of the fill rectangle
+ * @h: height of the fill rectangle
+ * @sr: red value to use as start gradient color
+ * @sg: green value to use as start gradient color
+ * @sb: blue value to use as start gradient color
+ * @er: red value to use as end gradient color
+ * @eg: green value to use as end gradient color
+ * @eb: blue value to use as end gradient color
+ *
+ * This functions draws a gradient into the rectangle which fades in
+ * from one color to the other using the drawing context @cr.
+ */
+void
+igt_paint_color_gradient_range(cairo_t *cr, int x, int y, int w, int h,
+  double sr, double sg, double sb,
+  double er, double eg, double eb)
+{
+   cairo_pattern_t *pat;
+
+   pat = cairo_pattern_create_linear(x, y, x + w, y + h);
+   cairo_pattern_add_color_stop_rgba(pat, 1, sr, sg, sb, 1);
+   cairo_pattern_add_color_stop_rgba(pat, 0, er, eg, eb, 1);
+
+   cairo_rectangle(cr, x, y, w, h);
+   cairo_set_source(cr, pat);
+   cairo_fill(cr);
+   cairo_pattern_destroy(pat);
+}
+
 static void
 paint_test_patterns(cairo_t *cr, int width, int height)
 {
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 4e6a769..469fbbc 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -105,6 +105,9 @@ void igt_paint_color_alpha(cairo_t *cr, int x, int y, int 
w, int h,
   double r, double g, double b, double a);
 void igt_paint_color_gradient(cairo_t *cr, int x, int y, int w, int h,
  int r, int g, int b);
+void igt_paint_color_gradient_range(cairo_t *cr, int x, int y, int w, int h,
+   double sr, double sg, double sb,
+   double er, double eg, double eb);
 void igt_paint_test_pattern(cairo_t *cr, int width, int height);
 void igt_paint_image(cairo_t *cr, const char *filename,
 int dst_x, int dst_y, int dst_width, int dst_height);
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 22996d5..97ee156 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1185,7 +1185,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
  NULL,
  NULL);
get_crtc_property(display->drm_fd, 
output->config.crtc->crtc_id,
- "CTM_MATRIX",
+ "CTM",
  >ctm_property,
  NULL,
  NULL);
-- 
2.7.0

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

[Intel-gfx] [PATCH i-g-t 5/5] tests/kms_color: New test for pipe level color management

[Lionel Landwerlin]

This test enables testing of :

 * degamma LUTs
 * csc matrix
 * gamma LUTs
 * legacy gamma LUTs

v2: turn assert into require to skip on platform not supporting color
management

v3: add invalid blob ids tests

v4: Try to match CRC results against several values around the
expected result for platforms with odd LUT items

v5: Fix running tests with multiple screens

Signed-off-by: Lionel Landwerlin 
---
 tests/Makefile.sources |1 +
 tests/kms_pipe_color.c | 1045 
 2 files changed, 1046 insertions(+)
 create mode 100644 tests/kms_pipe_color.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index f8b18b0..eb5e79a 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -89,6 +89,7 @@ TESTS_progs_M = \
kms_legacy_colorkey \
kms_mmio_vs_cs_flip \
kms_pipe_b_c_ivb \
+   kms_pipe_color \
kms_pipe_crc_basic \
kms_plane \
kms_psr_sink_crc \
diff --git a/tests/kms_pipe_color.c b/tests/kms_pipe_color.c
new file mode 100644
index 000..8d664ac
--- /dev/null
+++ b/tests/kms_pipe_color.c
@@ -0,0 +1,1045 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+  * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+
+#include "drm.h"
+#include "drmtest.h"
+#include "igt.h"
+
+IGT_TEST_DESCRIPTION("Test Color Features at Pipe level");
+
+/* Data structures for gamma/degamma ramps & ctm matrix. */
+struct _drm_color_ctm {
+   /* Transformation matrix in S31.32 format. */
+   __s64 matrix[9];
+};
+
+struct _drm_color_lut {
+   /*
+* Data is U0.16 fixed point format.
+*/
+   __u16 red;
+   __u16 green;
+   __u16 blue;
+   __u16 reserved;
+};
+
+/* Internal */
+typedef struct {
+   double r, g, b;
+} color_t;
+
+typedef struct {
+   int drm_fd;
+   uint32_t devid;
+   igt_display_t display;
+   igt_pipe_crc_t *pipe_crc;
+
+   uint32_t color_depth;
+   uint64_t degamma_lut_size;
+   uint64_t gamma_lut_size;
+} data_t;
+
+
+static void paint_gradient_rectangles(data_t *data,
+ drmModeModeInfo *mode,
+ color_t *colors,
+ struct igt_fb *fb)
+{
+   cairo_t *cr = igt_get_cairo_ctx(data->drm_fd, fb);
+   int i, l = mode->hdisplay / 3;
+
+   /* Paint 3 gradient rectangles with red/green/blue between 1.0 and
+* 0.5. We want to avoid 0 so each max LUTs only affect their own
+* rectangle.
+*/
+   for (i = 0 ; i < 3; i++) {
+   igt_paint_color_gradient_range(cr, i * l, 0, l, mode->vdisplay,
+  colors[i].r != 0 ? 0.2 : 0,
+  colors[i].g != 0 ? 0.2 : 0,
+  colors[i].b != 0 ? 0.2 : 0,
+  colors[i].r,
+  colors[i].g,
+  colors[i].b);
+   }
+
+   cairo_destroy(cr);
+}
+
+static void paint_rectangles(data_t *data,
+drmModeModeInfo *mode,
+color_t *colors,
+struct igt_fb *fb)
+{
+   cairo_t *cr = igt_get_cairo_ctx(data->drm_fd, fb);
+   int i, l = mode->hdisplay / 3;
+
+   /* Paint 3 solid rectangles. */
+   for (i = 0 ; i < 3; i++) {
+   igt_paint_color(cr, i * l, 0, l, mode->vdisplay,
+   colors[i].r, colors[i].g, colors[i].b);
+   }
+
+   cairo_destroy(cr);
+}
+
+static double *generate_table(uint32_t lut_size, double exp)
+{
+   double *coeffs = malloc(sizeof(double) * lut_size);
+   uint32_t i;
+
+   for (i = 0; i < 

[Intel-gfx] [PATCH i-g-t 4/5] lib: add crc comparison function without an assert

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 lib/igt_debugfs.c | 17 +
 lib/igt_debugfs.h |  1 +
 2 files changed, 18 insertions(+)

diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index c291ef3..a32ed78 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -252,6 +252,23 @@ bool igt_debugfs_search(const char *filename, const char 
*substring)
  * @a: first pipe CRC value
  * @b: second pipe CRC value
  *
+ * Compares two CRC values.
+ */
+bool igt_crc_equal(igt_crc_t *a, igt_crc_t *b)
+{
+   int i;
+
+   for (i = 0; i < a->n_words; i++)
+   if (a->crc[i] != b->crc[i])
+   return false;
+   return true;
+}
+
+/**
+ * igt_assert_crc_equal:
+ * @a: first pipe CRC value
+ * @b: second pipe CRC value
+ *
  * Compares two CRC values and fails the testcase if they don't match with
  * igt_fail(). Note that due to CRC collisions CRC based testcase can only
  * assert that CRCs match, never that they are different. Otherwise there might
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index dac8413..d08fc23 100644
--- a/lib/igt_debugfs.h
+++ b/lib/igt_debugfs.h
@@ -124,6 +124,7 @@ __attribute__((warn_unused_result))
 int igt_pipe_crc_get_crcs(igt_pipe_crc_t *pipe_crc, int n_crcs,
  igt_crc_t **out_crcs);
 void igt_pipe_crc_collect_crc(igt_pipe_crc_t *pipe_crc, igt_crc_t *out_crc);
+bool igt_crc_equal(igt_crc_t *a, igt_crc_t *b);
 
 /*
  * Drop caches
-- 
2.7.0

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

[Intel-gfx] [PATCH i-g-t 2/5] lib: kms: add helpers for color management properties on pipes

[Lionel Landwerlin]

v2: Rename CTM_MATRIX property to CTM

Signed-off-by: Lionel Landwerlin 
---
 lib/igt_kms.c | 74 +++
 lib/igt_kms.h | 17 +-
 2 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index dd4ca45..22996d5 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1179,6 +1179,21 @@ void igt_display_init(igt_display_t *display, int drm_fd)
   _value,
   NULL);
pipe->background = (uint32_t)prop_value;
+   get_crtc_property(display->drm_fd, 
output->config.crtc->crtc_id,
+ "DEGAMMA_LUT",
+ >degamma_property,
+ NULL,
+ NULL);
+   get_crtc_property(display->drm_fd, 
output->config.crtc->crtc_id,
+ "CTM_MATRIX",
+ >ctm_property,
+ NULL,
+ NULL);
+   get_crtc_property(display->drm_fd, 
output->config.crtc->crtc_id,
+ "GAMMA_LUT",
+ >gamma_property,
+ NULL,
+ NULL);
}
}
}
@@ -1328,6 +1343,16 @@ static igt_plane_t *igt_pipe_get_plane(igt_pipe_t *pipe, 
enum igt_plane plane)
return >planes[idx];
 }
 
+bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name,
+  uint32_t *prop_id, uint64_t *value,
+  drmModePropertyPtr *prop)
+{
+   return get_crtc_property(pipe->display->drm_fd,
+pipe->crtc_id,
+name,
+prop_id, value, prop);
+}
+
 static uint32_t igt_plane_get_fb_id(igt_plane_t *plane)
 {
if (plane->fb)
@@ -1635,6 +1660,17 @@ static int igt_output_commit(igt_output_t *output,
pipe->background_changed = false;
}
 
+   if (pipe->color_mgmt_changed) {
+   igt_crtc_set_property(output, pipe->degamma_property,
+ pipe->degamma_blob);
+   igt_crtc_set_property(output, pipe->ctm_property,
+ pipe->ctm_blob);
+   igt_crtc_set_property(output, pipe->gamma_property,
+ pipe->gamma_blob);
+
+   pipe->color_mgmt_changed = false;
+   }
+
for (i = 0; i < pipe->n_planes; i++) {
igt_plane_t *plane = >planes[i];
 
@@ -1967,6 +2003,44 @@ void igt_plane_set_rotation(igt_plane_t *plane, 
igt_rotation_t rotation)
plane->rotation_changed = true;
 }
 
+static void
+igt_pipe_replace_blob(igt_pipe_t *pipe, uint64_t *blob, void *ptr, size_t 
length)
+{
+   igt_display_t *display = pipe->display;
+   uint32_t blob_id = 0;
+
+   if (*blob != 0)
+   igt_assert(drmModeDestroyPropertyBlob(display->drm_fd,
+ *blob) == 0);
+
+   if (length > 0)
+   igt_assert(drmModeCreatePropertyBlob(display->drm_fd,
+ptr, length, _id) == 
0);
+
+   *blob = blob_id;
+}
+
+void
+igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length)
+{
+   igt_pipe_replace_blob(pipe, >degamma_blob, ptr, length);
+   pipe->color_mgmt_changed = 1;
+}
+
+void
+igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length)
+{
+   igt_pipe_replace_blob(pipe, >ctm_blob, ptr, length);
+   pipe->color_mgmt_changed = 1;
+}
+
+void
+igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length)
+{
+   igt_pipe_replace_blob(pipe, >gamma_blob, ptr, length);
+   pipe->color_mgmt_changed = 1;
+}
+
 /**
  * igt_crtc_set_background:
  * @pipe: pipe pointer to which background color to be set
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 77327c2..11a37d5 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -215,6 +215,15 @@ struct igt_pipe {
uint64_t background; /* Background color MSB BGR 16bpc LSB */
uint32_t background_changed : 1;
uint32_t background_property;
+
+   uint64_t degamma_blob;
+   uint32_t degamma_property;
+   uint64_t ctm_blob;
+   uint32_t ctm_property;
+   uint64_t gamma_blob;
+   uint32_t gamma_property;
+   uint32_t color_mgmt_changed : 1;
+
uint32_t crtc_id;
 };
 
@@ -253,12 +262,19 @@ drmModeModeInfo 

[Intel-gfx] [PATCH i-g-t 0/5] New pipe level color management tests V5

[Lionel Landwerlin]

Hi,

This series enables testing pipe level color management using kernel patches
from this serie :

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

Most of the tests use pipe CRCs to check the results by comparing the output
with the expected output drawn using cairo.

Cheers,

Lionel

Lionel Landwerlin (5):
  lib: kms: add crtc_id to igt_pipe_t
  lib: kms: add helpers for color management properties on pipes
  lib: fb: add igt_paint_color_gradient_range
  lib: add crc comparison function without an assert
  tests/kms_color: New test for pipe level color management

 lib/igt_debugfs.c  |   17 +
 lib/igt_debugfs.h  |1 +
 lib/igt_fb.c   |   34 ++
 lib/igt_fb.h   |3 +
 lib/igt_kms.c  |   75 
 lib/igt_kms.h  |   18 +-
 tests/Makefile.sources |1 +
 tests/kms_pipe_color.c | 1045 
 8 files changed, 1193 insertions(+), 1 deletion(-)
 create mode 100644 tests/kms_pipe_color.c

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

[Intel-gfx] [PATCH i-g-t 1/5] lib: kms: add crtc_id to igt_pipe_t

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 lib/igt_kms.c | 1 +
 lib/igt_kms.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 90c8da7..dd4ca45 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1047,6 +1047,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
int p = IGT_PLANE_2;
int j, type;
 
+   pipe->crtc_id = resources->crtcs[i];
pipe->display = display;
pipe->pipe = i;
 
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 3f7add5..77327c2 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -215,6 +215,7 @@ struct igt_pipe {
uint64_t background; /* Background color MSB BGR 16bpc LSB */
uint32_t background_changed : 1;
uint32_t background_property;
+   uint32_t crtc_id;
 };
 
 typedef struct {
-- 
2.7.0

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Pipe level color management (rev9)

[Patchwork]

== Series Details ==

Series: Pipe level color management (rev9)
URL   : https://patchwork.freedesktop.org/series/2720/
State : failure

== Summary ==

Series 2720v9 Pipe level color management
http://patchwork.freedesktop.org/api/1.0/series/2720/revisions/9/mbox/

Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-load-detect:
dmesg-fail -> FAIL   (hsw-gt2)
dmesg-fail -> FAIL   (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (skl-i7k-2) UNSTABLE
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (bsw-nuc-2)
dmesg-warn -> PASS   (skl-i7k-2) UNSTABLE
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> FAIL   (bdw-ultra)
dmesg-warn -> PASS   (byt-nuc)
Subgroup basic-rte:
fail   -> PASS   (bdw-ultra)

bdw-ultratotal:168  pass:153  dwarn:0   dfail:0   fail:1   skip:14 
bsw-nuc-2total:168  pass:136  dwarn:1   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:143  dwarn:0   dfail:0   fail:0   skip:25 
hsw-brixbox  total:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
hsw-gt2  total:168  pass:157  dwarn:0   dfail:0   fail:1   skip:10 
ilk-hp8440p  total:168  pass:117  dwarn:1   dfail:0   fail:1   skip:49 
ivb-t430stotal:168  pass:153  dwarn:0   dfail:0   fail:1   skip:14 
skl-i7k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1476/

38f0cd5314ecb02d15d019631e388d3642275600 drm-intel-nightly: 
2016y-02m-25d-15h-33m-53s UTC integration manifest
798167372b5f100f1f925da0c662d8ec38383ba1 drm/i915: Implement color management 
on chv
9ed2b832f837247690d3dd9c2d0dd75d8842ea5b drm/i915: Implement color management 
on bdw/skl/bxt/kbl
767405c0e581b9a54521c46b9df8d482bacaeff7 drm: introduce pipe color correction 
properties
1b9f0482150dd9e66956b8e649a9119b3f16 drm/i915: Do not read GAMMA_MODE 
register
a0b95e87badb761305105bc87c520546da504a50 drm/i915: Extract out gamma table and 
CSC to their own file

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

[Intel-gfx] [PATCH] drm/i915: add enable_guc_loading parameter

[Dave Gordon]

Split the function of "enable_guc_submission" into two separate options.
The new one "enable_guc_loading" controls only the *fetching and loading*
of the GuC firmware image. The existing one is redefined to control only
the *use* of the GuC for batch submission once the firmware is loaded.

In addition, the degree of control has been refined from a simple bool
to an integer key, allowing several options:
 -1  (default)whatever the platform default is
  0  DISABLE  don't load/use the GuC
  1  BEST EFFORT  try to load/use the GuC, fallback if not available
  2  REQUIRE  must load/use the GuC, else leave the GPU wedged

The new platform default (as coded here) will be to attempt to load
the GuC iff the device has a GuC that requires firmware, to attempt to
use it iff the device has a GuC that supports the submission protocol
(with or without firmware), and to fall back to execlist mode if any
required firmware cannot be found or fails to load.

Signed-off-by: Dave Gordon 
Reviewed-by: Alex Dai 
---
 drivers/gpu/drm/i915/i915_gem.c |  1 -
 drivers/gpu/drm/i915/i915_params.c  | 14 -
 drivers/gpu/drm/i915/i915_params.h  |  3 +-
 drivers/gpu/drm/i915/intel_guc_loader.c | 99 ++---
 4 files changed, 68 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f68f346..3d9397d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4891,7 +4891,6 @@ int i915_gem_init_rings(struct drm_device *dev)
ret = intel_guc_ucode_load(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
-   ret = -EIO;
goto out;
}
}
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 278c9c4..a57e16b 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -54,7 +54,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_submission = false,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = -1,
.guc_log_level = -1,
 };
 
@@ -195,8 +196,15 @@ struct i915_params i915 __read_mostly = {
 "(0=use value from vbt [default], 1=low power swing(200mV),"
 "2=default swing(400mV))");
 
-module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
bool, 0400);
-MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission 
(default:false)");
+module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
+MODULE_PARM_DESC(enable_guc_submission,
+   "Enable GuC firmware loading "
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
+
+module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
+MODULE_PARM_DESC(enable_guc_submission,
+   "Enable GuC submission "
+   "(-1=auto [default], 0=never, 1=if available, 2=required)");
 
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index bd5026b..8eafbce 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,6 +45,8 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
+   int enable_guc_loading;
+   int enable_guc_submission;
int guc_log_level;
int use_mmio_flip;
int mmio_debug;
@@ -56,7 +58,6 @@ struct i915_params {
bool load_detect_test;
bool reset;
bool disable_display;
-   bool enable_guc_submission;
bool verbose_state_checks;
bool nuclear_pageflip;
 };
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 82a3c03..e0093a9 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -369,49 +369,37 @@ int intel_guc_ucode_load(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   const char *fw_path = guc_fw->guc_fw_path;
int err = 0;
 
-   if (!i915.enable_guc_submission)
-   return 0;
-
-   DRM_DEBUG_DRIVER("GuC fw status: fetch %s, load %s\n",
+   DRM_DEBUG_DRIVER("GuC fw status: path %s, fetch %s, load %s\n",
+   fw_path,
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
 
-   direct_interrupts_to_host(dev_priv);
+   /* Loading forbidden, or no firmware to load? */
+   if 

[Intel-gfx] [PATCH igt 4/4] kms_frontbuffer_tracking: be aware of the new FBC Kernel workaround

[Paulo Zanoni]

We recently implemented a Kernel workaround that deactivates FBC in
case the FBC frontbuffer was ever CPU or WC mmapped. Change the test
suite to take this into account, otherwise we'll fail many tests with
!fbc_enabled assertions.

Also notice that if your Kernel doesn't have the workaround, then this
commit is going to break a lot of tests. The Kernel commit you need
is:
drm/i915: opt-out CPU and WC mmaps from FBC

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index aa124d3..671b0dd 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -1900,6 +1900,23 @@ static void update_wanted_crc(const struct test_mode *t, 
struct both_crcs *crc)
wanted_crc = crc;
 }
 
+/*
+ * The recent Kernel versions have a workaround that will refuse to activate 
FBC
+ * if the FBC frontbuffer has ever been CPU or WC mmapped.
+ */
+static bool op_disables_fbc(const struct test_mode *t,
+   enum igt_draw_method method)
+{
+   if (method != IGT_DRAW_MMAP_CPU && method != IGT_DRAW_MMAP_WC)
+   return false;
+   if (t->plane != PLANE_PRI)
+   return false;
+   if (t->screen == SCREEN_PRIM || t->fbs == FBS_SHARED)
+   return true;
+
+   return false;
+}
+
 static bool op_disables_psr(const struct test_mode *t,
enum igt_draw_method method)
 {
@@ -1969,6 +1986,8 @@ static void draw_subtest(const struct test_mode *t)
igt_assert(false);
}
 
+   if (op_disables_fbc(t, t->method))
+   assertions |= ASSERT_FBC_DISABLED;
if (op_disables_psr(t, t->method))
assertions |= ASSERT_PSR_DISABLED;
 
@@ -2027,7 +2046,12 @@ static void multidraw_subtest(const struct test_mode *t)
target = pick_target(t, params);
 
for (m1 = 0; m1 < IGT_DRAW_METHOD_COUNT; m1++) {
+   if (op_disables_fbc(t, m1))
+   continue;
+
for (m2 = m1 + 1; m2 < IGT_DRAW_METHOD_COUNT; m2++) {
+   if (op_disables_fbc(t, m2))
+   continue;
 
igt_debug("Methods %s and %s\n",
  igt_draw_get_method_name(m1),
-- 
2.7.0

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

[Intel-gfx] [PATCH igt 3/4] kms_frontbuffer_tracking: recreate the FBs at every subtest

[Paulo Zanoni]

We're studying the possibility to implement a Kernel FBC workaround
that will deactivate FBC every time the FBC frontbuffer was ever
CPU/WC mmapped. Due to this, we can't just reuse our FBs between
tests: the test suite will eventually CPU mmap every buffer, so FBC
will be disabled forever. In order to avoid this, keep it simple and
just recreate the FBs at every subtest.

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 363fe23..aa124d3 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -662,12 +662,31 @@ static void create_shared_fb(enum pixel_format format)
  PLANE_PRI, >big);
 }
 
+static void destroy_fbs(enum pixel_format format)
+{
+   struct screen_fbs *s = [format];
+
+   if (!s->initialized)
+   return;
+
+   if (scnd_mode_params.connector_id) {
+   igt_remove_fb(drm.fd, >scnd_pri);
+   igt_remove_fb(drm.fd, >scnd_cur);
+   igt_remove_fb(drm.fd, >scnd_spr);
+   }
+   igt_remove_fb(drm.fd, >prim_pri);
+   igt_remove_fb(drm.fd, >prim_cur);
+   igt_remove_fb(drm.fd, >prim_spr);
+   igt_remove_fb(drm.fd, >offscreen);
+   igt_remove_fb(drm.fd, >big);
+}
+
 static void create_fbs(enum pixel_format format)
 {
struct screen_fbs *s = [format];
 
if (s->initialized)
-   return;
+   destroy_fbs(format);
 
s->initialized = true;
 
@@ -698,25 +717,6 @@ static void create_fbs(enum pixel_format format)
  LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_SPR, >scnd_spr);
 }
 
-static void destroy_fbs(enum pixel_format format)
-{
-   struct screen_fbs *s = [format];
-
-   if (!s->initialized)
-   return;
-
-   if (scnd_mode_params.connector_id) {
-   igt_remove_fb(drm.fd, >scnd_pri);
-   igt_remove_fb(drm.fd, >scnd_cur);
-   igt_remove_fb(drm.fd, >scnd_spr);
-   }
-   igt_remove_fb(drm.fd, >prim_pri);
-   igt_remove_fb(drm.fd, >prim_cur);
-   igt_remove_fb(drm.fd, >prim_spr);
-   igt_remove_fb(drm.fd, >offscreen);
-   igt_remove_fb(drm.fd, >big);
-}
-
 static bool set_mode_for_params(struct modeset_params *params)
 {
int rc;
-- 
2.7.0

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

[Intel-gfx] [PATCH igt 1/4] kms_frontbuffer_tracking: add missing igt_remove_fb calls

[Paulo Zanoni]

Let's be good citizens and properly handle our garbage.

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 26e12d0..0ea1dde 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -3070,6 +3070,8 @@ static void tilingchange_subtest(const struct test_mode 
*t)
page_flip_for_params(params, flip_type);
do_assertions(0);
}
+
+   igt_remove_fb(drm.fd, _fb);
 }
 
 /*
@@ -3128,6 +3130,8 @@ static void basic_subtest(const struct test_mode *t)
update_wanted_crc(t, >crcs[t->format][r]);
do_assertions(assertions);
}
+
+   igt_remove_fb(drm.fd, );
 }
 
 static int opt_handler(int option, int option_index, void *data)
-- 
2.7.0

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

[Intel-gfx] [PATCH igt 2/4] kms_frontbuffer_tracking: prefer the BLT drawing method

[Paulo Zanoni]

While PSR has problems with GTT mmaps, we're studying the possibility
of implementing a workaround for FBC that affects CPU and WC mmaps. So
prefer the BLT method since it behaves the same with both features.

Signed-off-by: Paulo Zanoni 
---
 tests/kms_frontbuffer_tracking.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 0ea1dde..363fe23 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -1081,7 +1081,7 @@ static void fill_fb_region(struct fb_region *region, enum 
color ecolor)
 {
uint32_t color = pick_color(region->fb, ecolor);
 
-   igt_draw_rect_fb(drm.fd, NULL, NULL, region->fb, IGT_DRAW_MMAP_CPU,
+   igt_draw_rect_fb(drm.fd, drm.bufmgr, NULL, region->fb, IGT_DRAW_BLT,
 region->x, region->y, region->w, region->h,
 color);
 }
@@ -3498,7 +3498,7 @@ int main(int argc, char *argv[])
if (t.pipes != PIPE_SINGLE ||
t.screen != SCREEN_PRIM ||
t.plane != PLANE_PRI ||
-   t.method != IGT_DRAW_MMAP_CPU)
+   t.method != IGT_DRAW_BLT)
continue;
igt_subtest_f("%s-%s-scaledprimary",
  feature_str(t.feature),
@@ -3511,7 +3511,7 @@ int main(int argc, char *argv[])
t.screen != SCREEN_PRIM ||
t.plane != PLANE_PRI ||
t.fbs != FBS_INDIVIDUAL ||
-   t.method != IGT_DRAW_MMAP_CPU)
+   t.method != IGT_DRAW_BLT)
continue;
 
igt_subtest_f("%s-modesetfrombusy", feature_str(t.feature))
-- 
2.7.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Add two-stage ILK-style watermark programming (v11)

[Matt Roper]

I never got a CI email for this (probably because fdo was down for a while),
but I can see the results below in patchwork

>  Test gem_cs_prefetch:
>  Subgroup basic-default:
>  incomplete -> PASS   (ilk-hp8440p)
>  Test kms_flip:
>  Subgroup basic-flip-vs-dpms:
>  pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE

Pre-existing watermark bug here:
https://bugs.freedesktop.org/show_bug.cgi?id=93787

I had hoped this patch might also fix that problem, but I guess further
investigation will be needed; it seems to be something very
ILK-specific, not seen on SNB, IVB, etc.


>  Test kms_force_connector_basic:
>  Subgroup force-edid:
>  skip   -> PASS   (snb-x220t)
>  pass   -> SKIP   (ivb-t430s)

Pre-existing:
https://bugs.freedesktop.org/show_bug.cgi?id=93769

>  Subgroup force-load-detect:
>  dmesg-fail -> FAIL   (snb-x220t)
>  dmesg-fail -> FAIL   (hsw-gt2)

The dmesg warning is gone now (a locking warning that I don't think my
patch should have affected); the remaining test failure is identical to
what it was before (temp->connection != DRM_MODE_UNKNOWNCONNECTION) and
unrelated.

I don't see a bugzilla for this, which seems strange since it's a
pre-existing defect.  Am I overlooking it or do I need to file a new
one?

>  fail   -> SKIP   (ilk-hp8440p)

Not sure what is actually plugged into the CI machine, so the skip may
be legitimate/expected?  Doesn't seem related to anything in my patch
anyway.

>  Test kms_pipe_crc_basic:
>  Subgroup suspend-read-crc-pipe-c:
>  pass   -> DMESG-WARN (bsw-nuc-2)

This one was happening sporadically before my patch; I think it's the
same bug filed here:

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

I'll update the bugzilla to indicate it also happens on this test.

>  Test pm_rpm:
>  Subgroup basic-rte:
>  pass   -> DMESG-WARN (bsw-nuc-2)
>  fail   -> PASS   (hsw-brixbox)

Same bug mentioned above (94164)



Matt


On Tue, Feb 23, 2016 at 05:20:13PM -0800, Matt Roper wrote:
> In addition to calculating final watermarks, let's also pre-calculate a
> set of intermediate watermark values at atomic check time.  These
> intermediate watermarks are a combination of the watermarks for the old
> state and the new state; they should satisfy the requirements of both
> states which means they can be programmed immediately when we commit the
> atomic state (without waiting for a vblank).  Once the vblank does
> happen, we can then re-program watermarks to the more optimal final
> value.
> 
> v2: Significant rebasing/rewriting.
> 
> v3:
>  - Move 'need_postvbl_update' flag to CRTC state (Daniel)
>  - Don't forget to check intermediate watermark values for validity
>(Maarten)
>  - Don't due async watermark optimization; just do it at the end of the
>atomic transaction, after waiting for vblanks.  We do want it to be
>async eventually, but adding that now will cause more trouble for
>Maarten's in-progress work.  (Maarten)
>  - Don't allocate space in crtc_state for intermediate watermarks on
>platforms that don't need it (gen9+).
>  - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
>now that ilk_update_wm is gone.
> 
> v4:
>  - Add a wm_mutex to cover updates to intel_crtc->active and the
>need_postvbl_update flag.  Since we don't have async yet it isn't
>terribly important yet, but might as well add it now.
>  - Change interface to program watermarks.  Platforms will now expose
>.initial_watermarks() and .optimize_watermarks() functions to do
>watermark programming.  These should lock wm_mutex, copy the
>appropriate state values into intel_crtc->active, and then call
>the internal program watermarks function.
> 
> v5:
>  - Skip intermediate watermark calculation/check during initial hardware
>readout since we don't trust the existing HW values (and don't have
>valid values of our own yet).
>  - Don't try to call .optimize_watermarks() on platforms that don't have
>atomic watermarks yet.  (Maarten)
> 
> v6:
>  - Rebase
> 
> v7:
>  - Further rebase
> 
> v8:
>  - A few minor indentation and line length fixes
> 
> v9:
>  - Yet another rebase since Maarten's patches reworked a bunch of the
>code (wm_pre, wm_post, etc.) that this was previously based on.
> 
> v10:
>  - Move wm_mutex to dev_priv to protect against racing commits against
>disjoint CRTC sets. (Maarten)
>  - Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten)
> 
> v11:
>  - Now that we've moved to atomic watermark updates, make sure we call
>the proper function to program watermarks in
>{ironlake,haswell}_crtc_enable(); the failure to do so on the
>previous patch iteration led to us not actually programming the
>watermarks before 

[Intel-gfx] [PATCH 2/2] drm/i915/fbc: enable FBC on SKL too

[Paulo Zanoni]

Now that we're more protected against user space doing frontbuffer
mmap rendering, the last - how many times did I say this before? -
SKL problem seems to be solved. So let's give it a try.

If you reached this commit through git bisect or if you just want more
information about FBC, please see:
commit a98ee79317b4091cafb502b4ffdbbbe1335e298c
Author: Paulo Zanoni 
Date:   Tue Feb 16 18:47:21 2016 -0200
drm/i915/fbc: enable FBC by default on HSW and BDW

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index a3fd699..6a53e4f 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -835,7 +835,8 @@ static bool intel_fbc_can_choose(struct intel_crtc *crtc)
struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
struct intel_fbc *fbc = _priv->fbc;
bool enable_by_default = IS_HASWELL(dev_priv) ||
-IS_BROADWELL(dev_priv);
+IS_BROADWELL(dev_priv) ||
+IS_SKYLAKE(dev_priv);
 
if (intel_vgpu_active(dev_priv->dev)) {
fbc->no_fbc_reason = "VGPU is active";
-- 
2.7.0

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: GPIO for CHT generic MIPI

[Ville Syrjälä]

On Wed, Feb 24, 2016 at 07:13:46PM +0530, Deepak M wrote:
> From: Yogesh Mohan Marimuthu 
> 
> The GPIO configuration and register offsets are different from
> baytrail for cherrytrail. Port the gpio programming accordingly
> for cherrytrail in this patch.
> 
> v2: Removing the duplication of parsing
> 
> v3: Moved the macro def to panel_vbt.c file
> 
> Cc: Ville Syrjälä 
> Cc: Jani Nikula 
> Signed-off-by: Yogesh Mohan Marimuthu 
> Signed-off-by: Deepak M 
> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 123 
> +++--
>  1 file changed, 98 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 794bd1f..6b9a1f7 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -58,6 +58,28 @@ static inline struct vbt_panel *to_vbt_panel(struct 
> drm_panel *panel)
>  
>  #define NS_KHZ_RATIO 100
>  
> +#define CHV_IOSF_PORT_GPIO_N 0x13
> +#define CHV_IOSF_PORT_GPIO_SE0x48
> +#define CHV_IOSF_PORT_GPIO_SW0xB2
> +#define CHV_IOSF_PORT_GPIO_E 0xA8

These should have remained where the other ports were defined.

> +#define CHV_MAX_GPIO_NUM_N   72
> +#define CHV_MAX_GPIO_NUM_SE  99
> +#define CHV_MAX_GPIO_NUM_SW  197
> +#define CHV_MIN_GPIO_NUM_SE  73
> +#define CHV_MIN_GPIO_NUM_SW  100
> +#define CHV_MIN_GPIO_NUM_E   198

I never got any explanation where the block sizes came from on VLV.
IIRC when I checked them against configdb they didn't match the actual
number of pins in the hardware block. And the same story continues here.
Eg. if I check configfb the number of pins in each block is:
N 59, SE 55, SW 56, E 24.

So I can't review this until someone explains where this stuff comes
from. And there should probably be a comment next to the defines to
remind the next guy who gets totally confused by this.

Also I don't like the fact that VLV and CHV are now implemented in two
totally different ways. Can you eliminate the massive gpio table from
the VLV code to make it more similar to this?

> +
> +#define CHV_PAD_FMLY_BASE0x4400
> +#define CHV_PAD_FMLY_SIZE0x400
> +#define CHV_PAD_CFG_0_1_REG_SIZE 0x8
> +#define CHV_PAD_CFG_REG_SIZE 0x4
> +#define CHV_VBT_MAX_PINS_PER_FMLY15

I take it this magic 15 must be specified in some VBT spec or something? 

> +
> +#define CHV_GPIO_CFG_UNLOCK0x
> +#define CHV_GPIO_CFG_HIZ   0x8100

That's not really hi-z is it? It's GPO mode actually w/ txstate=0.
I would suggest adding separate defines for each bit so it's
easier to see what is really set and what isn't.

> +#define CHV_GPIO_CFG_TX_STATE_SHIFT1

Could be something like
#define CHV_GPIO_CFG0_TX_STATE(state) ((state) << 1)

> +
> +
>  #define VLV_HV_DDI0_HPD_GPIONC_0_PCONF0 0x4130
>  #define VLV_HV_DDI0_HPD_GPIONC_0_PAD0x4138
>  #define VLV_HV_DDI0_DDC_SDA_GPIONC_1_PCONF0 0x4120
> @@ -685,34 +707,13 @@ static const u8 *mipi_exec_delay(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   return data;
>  }
>  
> -static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
> +void vlv_program_gpio(struct intel_dsi *intel_dsi, u8 gpio, u8 action)
>  {
> - u8 gpio, action;
> + struct drm_device *dev = intel_dsi->base.base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
>   u16 function, pad;
>   u32 val;
>   u8 port;
> - struct drm_device *dev = intel_dsi->base.base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
> - DRM_DEBUG_DRIVER("MIPI: executing gpio element\n");
> -
> - if (dev_priv->vbt.dsi.seq_version >= 3)
> - data++;
> -
> - gpio = *data++;
> -
> - /* pull up/down */
> - action = *data++ & 1;
> -
> - if (gpio >= ARRAY_SIZE(gtable)) {
> - DRM_DEBUG_KMS("unknown gpio %u\n", gpio);
> - goto out;
> - }
> -
> - if (!IS_VALLEYVIEW(dev_priv)) {
> - DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
> - goto out;
> - }
>  
>   if (dev_priv->vbt.dsi.seq_version >= 3) {
>   if (gpio <= IOSF_MAX_GPIO_NUM_NC) {
> @@ -728,7 +729,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
> *intel_dsi, const u8 *data)
>   port = IOSF_PORT_GPIO_SUS;
>   } else {
>   DRM_ERROR("GPIO number is not present in the table\n");
> - goto out;
> + return;
>   }
>   } else {
>   

[Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

[Lionel Landwerlin]

Implement Daniel Stone's recommendation to not read registers to infer
the hardware's state.

v2: Read GAMMA_MODE register value at init (Matt Roper's comment)

v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along
with other registers (Matt Roper's comment).

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/intel_color.c   | 12 
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 5e0b997..16657eb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -121,6 +121,8 @@ static void haswell_load_luts(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);
+   struct intel_crtc_state *intel_crtc_state =
+   to_intel_crtc_state(crtc->state);
bool reenable_ips = false;
 
/*
@@ -128,11 +130,12 @@ static void haswell_load_luts(struct drm_crtc *crtc)
 * GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
 */
if (IS_HASWELL(dev) && intel_crtc->config->ips_enabled &&
-   ((I915_READ(GAMMA_MODE(intel_crtc->pipe)) & GAMMA_MODE_MODE_MASK) ==
-GAMMA_MODE_MODE_SPLIT)) {
+   (intel_crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
hsw_disable_ips(intel_crtc);
reenable_ips = true;
}
+
+   intel_crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
I915_WRITE(GAMMA_MODE(intel_crtc->pipe), GAMMA_MODE_MODE_8BIT);
 
i9xx_load_luts(crtc);
@@ -183,8 +186,9 @@ void intel_color_init(struct drm_crtc *crtc)
}
 
if (IS_HASWELL(dev) ||
-   (INTEL_INFO(dev)->gen >= 8 && !IS_CHERRYVIEW(dev)))
+   (INTEL_INFO(dev)->gen >= 8 && !IS_CHERRYVIEW(dev))) {
dev_priv->display.load_luts = haswell_load_luts;
-   else
+   } else {
dev_priv->display.load_luts = i9xx_load_luts;
+   }
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index cd47f5b..154ac87 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9873,6 +9873,8 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,
 
intel_get_pipe_timings(crtc, pipe_config);
 
+   pipe_config->gamma_mode = I915_READ(GAMMA_MODE(crtc->pipe));
+
if (INTEL_INFO(dev)->gen >= 9) {
skl_init_scalers(dev, crtc, pipe_config);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7532f61..8c48131 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -517,6 +517,9 @@ struct intel_crtc_state {
struct skl_pipe_wm skl;
} optimal;
} wm;
+
+   /* Gamma mode programmed on the pipe */
+   uint32_t gamma_mode;
 };
 
 struct vlv_wm_state {
-- 
2.7.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: Implement color management on chv

[Lionel Landwerlin]

Patch based on a previous series by Shashank Sharma.

v2: Update contributors

v3: Refactor degamma/gamma LUTs load into a single function

v4: Remove unused variable

Signed-off-by: Shashank Sharma 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c|   3 +
 drivers/gpu/drm/i915/i915_reg.h|  31 +
 drivers/gpu/drm/i915/intel_color.c | 133 +++--
 3 files changed, 161 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3807b73..8a2aaa7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -68,6 +68,8 @@ static struct drm_driver driver;
 
 #define BDW_COLORS \
.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+#define CHV_COLORS \
+   .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
 
 static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
@@ -325,6 +327,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
+   CHV_COLORS,
 };
 
 static const struct intel_device_info intel_skylake_info = {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 76a9e49..ea599a9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7673,6 +7673,37 @@ enum skl_disp_power_wells {
 #define PREC_PAL_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A, 
_PAL_PREC_GC_MAX_B) + (i) * 4)
 #define PREC_PAL_EXT_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, 
_PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4)
 
+/* pipe CSC & degamma/gamma LUTs on CHV */
+#define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
+#define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
+#define _CGM_PIPE_A_CSC_COEFF45(VLV_DISPLAY_BASE + 0x67908)
+#define _CGM_PIPE_A_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6790C)
+#define _CGM_PIPE_A_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x67910)
+#define _CGM_PIPE_A_DEGAMMA(VLV_DISPLAY_BASE + 0x66000)
+#define _CGM_PIPE_A_GAMMA  (VLV_DISPLAY_BASE + 0x67000)
+#define _CGM_PIPE_A_MODE   (VLV_DISPLAY_BASE + 0x67A00)
+#define   CGM_PIPE_MODE_GAMMA  (1 << 2)
+#define   CGM_PIPE_MODE_CSC(1 << 1)
+#define   CGM_PIPE_MODE_DEGAMMA(1 << 0)
+
+#define _CGM_PIPE_B_CSC_COEFF01(VLV_DISPLAY_BASE + 0x69900)
+#define _CGM_PIPE_B_CSC_COEFF23(VLV_DISPLAY_BASE + 0x69904)
+#define _CGM_PIPE_B_CSC_COEFF45(VLV_DISPLAY_BASE + 0x69908)
+#define _CGM_PIPE_B_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6990C)
+#define _CGM_PIPE_B_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x69910)
+#define _CGM_PIPE_B_DEGAMMA(VLV_DISPLAY_BASE + 0x68000)
+#define _CGM_PIPE_B_GAMMA  (VLV_DISPLAY_BASE + 0x69000)
+#define _CGM_PIPE_B_MODE   (VLV_DISPLAY_BASE + 0x69A00)
+
+#define CGM_PIPE_CSC_COEFF01(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF01, _CGM_PIPE_B_CSC_COEFF01)
+#define CGM_PIPE_CSC_COEFF23(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF23, _CGM_PIPE_B_CSC_COEFF23)
+#define CGM_PIPE_CSC_COEFF45(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF45, _CGM_PIPE_B_CSC_COEFF45)
+#define CGM_PIPE_CSC_COEFF67(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF67, _CGM_PIPE_B_CSC_COEFF67)
+#define CGM_PIPE_CSC_COEFF8(pipe)  _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF8, _CGM_PIPE_B_CSC_COEFF8)
+#define CGM_PIPE_DEGAMMA(pipe, i, w)   _MMIO(_PIPE(pipe, _CGM_PIPE_A_DEGAMMA, 
_CGM_PIPE_B_DEGAMMA) + (i) * 8 + (w) * 4)
+#define CGM_PIPE_GAMMA(pipe, i, w) _MMIO(_PIPE(pipe, _CGM_PIPE_A_GAMMA, 
_CGM_PIPE_B_GAMMA) + (i) * 8 + (w) * 4)
+#define CGM_PIPE_MODE(pipe)_MMIO_PIPE(pipe, _CGM_PIPE_A_MODE, 
_CGM_PIPE_B_MODE)
+
 /* MIPI DSI registers */
 
 #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c)   /* ports A and C only */
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index a6dc2af..9ad37e5 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -29,6 +29,7 @@
 #define CTM_COEFF_1_0  (1ULL << 32)
 #define CTM_COEFF_2_0  (CTM_COEFF_1_0 << 1)
 #define CTM_COEFF_4_0  (CTM_COEFF_2_0 << 1)
+#define CTM_COEFF_8_0  (CTM_COEFF_4_0 << 1)
 #define CTM_COEFF_0_5  (CTM_COEFF_1_0 >> 1)
 #define CTM_COEFF_0_25 (CTM_COEFF_0_5 >> 1)
 #define CTM_COEFF_0_125(CTM_COEFF_0_25 >> 1)
@@ -199,6 +200,58 @@ static void i9xx_load_csc_matrix(struct drm_crtc *crtc)
}
 }
 
+/*
+ * Set up the pipe CSC unit on CherryView.
+ */
+static void cherryview_load_csc_matrix(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_crtc_state *state = crtc->state;
+   struct 

[Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

[Lionel Landwerlin]

Patch based on a previous series by Shashank Sharma.

This introduces optional properties to enable color correction at the
pipe level. It relies on 3 transformations applied to every pixels
displayed. First a lookup into a degamma table, then a multiplication
of the rgb components by a 3x3 matrix and finally another lookup into
a gamma table.

The following properties can be added to a pipe :
  - DEGAMMA_LUT : blob containing degamma LUT
  - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT
  - CTM : transformation matrix applied after the degamma LUT
  - GAMMA_LUT : blob containing gamma LUT
  - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT

DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by
the driver to tell userspace applications what sizes should be the
lookup tables in DEGAMMA_LUT and GAMMA_LUT.

A helper is also provided so legacy gamma correction is redirected
through these new properties.

v2: Register LUT size properties as range

v3: Fix round in drm_color_lut_get_value() helper
More docs on how degamma/gamma properties are used

v4: Update contributors

v5: Rename CTM_MATRIX property to CTM (Doh!)
Add legacy gamma_set atomic helper
Describe CTM/LUT acronyms in the kernel doc

Signed-off-by: Shashank Sharma 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
Reviewed-by: Matt Roper 
---
 Documentation/DocBook/gpu.tmpl  |  59 -
 drivers/gpu/drm/drm_atomic.c|  86 +-
 drivers/gpu/drm/drm_atomic_helper.c | 103 
 drivers/gpu/drm/drm_crtc.c  |  35 
 drivers/gpu/drm/drm_crtc_helper.c   |  33 
 include/drm/drm_atomic_helper.h |   3 ++
 include/drm/drm_crtc.h  |  46 +++-
 include/drm/drm_crtc_helper.h   |   3 ++
 include/uapi/drm/drm_mode.h |  15 ++
 9 files changed, 378 insertions(+), 5 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index fe6b36a..1692c4d 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions


-   DRM
+   DRM
Generic
“rotation”
BITMASK
@@ -2068,7 +2068,7 @@ void intel_crt_init(struct drm_device *dev)
property to suggest an Y offset for a connector


-   Optional
+   Optional
“scaling mode”
ENUM
{ "None", "Full", "Center", "Full aspect" }
@@ -2092,6 +2092,61 @@ void intel_crt_init(struct drm_device *dev)
TBD


+   “DEGAMMA_LUT”
+   BLOB
+   0
+   CRTC
+   DRM property to set the degamma lookup table
+   (LUT) mapping pixel data from the framebuffer before it is
+   given to the transformation matrix. The data is an interpreted
+   as an array of struct drm_color_lut elements. Hardware might
+   choose not to use the full precision of the LUT elements nor
+   use all the elements of the LUT (for example the hardware
+   might choose to interpolate between LUT[0] and LUT[4]). 
+   
+   
+   “DEGAMMA_LUT_SIZE”
+   RANGE | IMMUTABLE
+   Min=0, Max=UINT_MAX
+   CRTC
+   DRM property to gives the size of the lookup
+   table to be set on the DEGAMMA_LUT property (the size depends
+   on the underlying hardware).
+   
+   
+   “CTM”
+   BLOB
+   0
+   CRTC
+   DRM property to set the current
+   transformation matrix (CTM) apply to pixel data after the
+   lookup through the degamma LUT and before the lookup through
+   the gamma LUT. The data is an interpreted as a struct
+   drm_color_ctm.
+   
+   
+   “GAMMA_LUT”
+   BLOB
+   0
+   CRTC
+   DRM property to set the gamma lookup table
+   (LUT) mapping pixel data after to the transformation matrix to
+   data sent to the connector. The data is an interpreted as an
+   array of struct drm_color_lut elements. Hardware might choose
+   not to use the full precision of the LUT elements nor use all
+   the elements of the LUT (for example the hardware might choose
+   to interpolate between LUT[0] and LUT[4]).
+   
+   
+   “GAMMA_LUT_SIZE”
+   RANGE | IMMUTABLE
+   Min=0, Max=UINT_MAX
+   CRTC
+   DRM property to gives the size of the lookup
+   table to be set on the GAMMA_LUT property (the size depends on
+   the underlying hardware).
+   
+   
i915
Generic
"Broadcast RGB"

[Intel-gfx] [PATCH 0/5] Pipe level color management V9

[Lionel Landwerlin]

This series introduces pipe level color management through a set of properties
attached to the CRTC. It also provides an implementation for some Intel
platforms.

This series is based of a previous set of patches by Shashank Sharma.

Cheers,

Lionel

v9: Rebase on nightly

Lionel Landwerlin (5):
  drm/i915: Extract out gamma table and CSC to their own file
  drm/i915: Do not read GAMMA_MODE register
  drm: introduce pipe color correction properties
  drm/i915: Implement color management on bdw/skl/bxt/kbl
  drm/i915: Implement color management on chv

 Documentation/DocBook/gpu.tmpl   |  65 +++-
 drivers/gpu/drm/drm_atomic.c |  86 +-
 drivers/gpu/drm/drm_atomic_helper.c  | 103 +++
 drivers/gpu/drm/drm_crtc.c   |  35 +++
 drivers/gpu/drm/drm_crtc_helper.c|  33 +++
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.c  |  27 +-
 drivers/gpu/drm/i915/i915_drv.h  |   8 +
 drivers/gpu/drm/i915/i915_reg.h  |  53 
 drivers/gpu/drm/i915/intel_color.c   | 556 +++
 drivers/gpu/drm/i915/intel_display.c | 183 ++--
 drivers/gpu/drm/i915/intel_drv.h |  12 +
 drivers/gpu/drm/i915/intel_fbdev.c   |   8 +
 include/drm/drm_atomic_helper.h  |   3 +
 include/drm/drm_crtc.h   |  46 ++-
 include/drm/drm_crtc_helper.h|   3 +
 include/uapi/drm/drm_mode.h  |  15 +
 17 files changed, 1072 insertions(+), 165 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color.c

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

[Intel-gfx] [PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

[Lionel Landwerlin]

Patch based on a previous series by Shashank Sharma.

v2: Do not read GAMMA_MODE register to figure what mode we're in

v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0

Add documentation on how the Broadcast RGB property is affected by CTM

v4: Update contributors

v5: Refactor degamma/gamma LUTs load into a single function

v6: Fix missing intel_crtc variable (bisect issue)

v7: Fix & simplify limited range matrix multiplication

Signed-off-by: Shashank Sharma 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
---
 Documentation/DocBook/gpu.tmpl   |   6 +-
 drivers/gpu/drm/i915/i915_drv.c  |  24 ++-
 drivers/gpu/drm/i915/i915_drv.h  |   6 +
 drivers/gpu/drm/i915/i915_reg.h  |  22 +++
 drivers/gpu/drm/i915/intel_color.c   | 341 ++-
 drivers/gpu/drm/i915/intel_display.c |  22 ++-
 drivers/gpu/drm/i915/intel_drv.h |   3 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |   8 +
 8 files changed, 369 insertions(+), 63 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 1692c4d..430e99b 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2153,7 +2153,11 @@ void intel_crt_init(struct drm_device *dev)
ENUM
{ "Automatic", "Full", "Limited 16:235" }
Connector
-   TBD
+   When this property is set to Limited 16:235
+   and CTM is set, the hardware will be programmed with the
+   result of the multiplication of CTM by the limited range
+   matrix to ensure the pixels normaly in the range 0..1.0 are
+   remapped to the range 16/255..235/255.


“audio”
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 20e8200..3807b73 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -66,6 +66,9 @@ static struct drm_driver driver;
 #define IVB_CURSOR_OFFSETS \
.cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET, 
IVB_CURSOR_C_OFFSET }
 
+#define BDW_COLORS \
+   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+
 static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
.has_overlay = 1, .overlay_needs_physical = 1,
@@ -288,24 +291,28 @@ static const struct intel_device_info 
intel_haswell_m_info = {
.is_mobile = 1,
 };
 
+#define BDW_FEATURES \
+   HSW_FEATURES, \
+   BDW_COLORS
+
 static const struct intel_device_info intel_broadwell_d_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8,
 };
 
 static const struct intel_device_info intel_broadwell_m_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8, .is_mobile = 1,
 };
 
 static const struct intel_device_info intel_broadwell_gt3d_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
 static const struct intel_device_info intel_broadwell_gt3m_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8, .is_mobile = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
@@ -321,13 +328,13 @@ static const struct intel_device_info 
intel_cherryview_info = {
 };
 
 static const struct intel_device_info intel_skylake_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
 };
 
 static const struct intel_device_info intel_skylake_gt3_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
@@ -345,17 +352,18 @@ static const struct intel_device_info intel_broxton_info 
= {
.has_fbc = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
+   BDW_COLORS,
 };
 
 static const struct intel_device_info intel_kabylake_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_preliminary = 1,
.is_kabylake = 1,
.gen = 9,
 };
 
 static const struct intel_device_info intel_kabylake_gt3_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_preliminary = 1,
.is_kabylake = 1,
.gen = 9,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8cb4418..e71dc9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -663,6 +663,7 @@ struct drm_i915_display_funcs {
/* display clock increase/decrease */
/* pll clock increase/decrease */
 
+   void (*load_csc_matrix)(struct drm_crtc *crtc);
void (*load_luts)(struct drm_crtc *crtc);
 };
 
@@ -812,6 +813,11 @@ struct intel_device_info {
u8 has_slice_pg:1;
u8 

[Intel-gfx] [PATCH 1/5] drm/i915: Extract out gamma table and CSC to their own file

[Lionel Landwerlin]

The moves a couple of functions programming the gamma LUT and CSC
units into their own file.

On generations prior to Haswell there is only a gamma LUT. From
haswell on there is also a new enhanced color correction unit that
isn't used yet. This is why we need to set the GAMMA_MODE register,
either we're using the legacy 8bits LUT or enhanced LUTs (of 10 or
12bits).

The CSC unit is only available from Haswell on.

We also need to make a special case for CherryView which is recognized
as a gen 8 but doesn't have the same enhanced color correction unit
from Haswell on.

v2: Fix access to GAMMA_MODE register on older generations than
Haswell (from Matt Roper's comments)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/intel_color.c   | 190 +++
 drivers/gpu/drm/i915/intel_display.c | 163 +++---
 drivers/gpu/drm/i915/intel_drv.h |  10 ++
 5 files changed, 215 insertions(+), 151 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07..0516300 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -55,6 +55,7 @@ i915-y += intel_audio.o \
  intel_atomic.o \
  intel_atomic_plane.o \
  intel_bios.o \
+ intel_color.o \
  intel_display.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9e76bfc..8cb4418 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -662,6 +662,8 @@ struct drm_i915_display_funcs {
/* render clock increase/decrease */
/* display clock increase/decrease */
/* pll clock increase/decrease */
+
+   void (*load_luts)(struct drm_crtc *crtc);
 };
 
 enum forcewake_domain_id {
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
new file mode 100644
index 000..5e0b997
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_drv.h"
+
+/*
+ * Set up the pipe CSC unit.
+ *
+ * Currently only full range RGB to limited range RGB conversion
+ * is supported, but eventually this should handle various
+ * RGB<->YCbCr scenarios as well.
+ */
+static void i9xx_load_csc_matrix(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;
+   uint16_t coeff = 0x7800; /* 1.0 */
+
+   /*
+* TODO: Check what kind of values actually come out of the pipe
+* with these coeff/postoff values and adjust to get the best
+* accuracy. Perhaps we even need to take the bpc value into
+* consideration.
+*/
+
+   if (intel_crtc->config->limited_color_range)
+   coeff = ((235 - 16) * (1 << 12) / 255) & 0xff8; /* 0.xxx... */
+
+   I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), coeff << 16);
+   I915_WRITE(PIPE_CSC_COEFF_BY(pipe), 0);
+
+   I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), coeff);
+   I915_WRITE(PIPE_CSC_COEFF_BU(pipe), 0);
+
+   I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), 0);
+   I915_WRITE(PIPE_CSC_COEFF_BV(pipe), coeff << 16);
+
+   I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+   if (INTEL_INFO(dev)->gen > 6) {
+   uint16_t postoff = 0;
+
+   if 

[Intel-gfx] [PATCH i-g-t v3] tests/drv_hangman: test for acthd increasing through invalid VM space

[daniele . ceraolospurio]

From: Daniele Ceraolo Spurio 

The hangcheck logic will not flag an hang if acthd keeps increasing.
However, if a malformed batch jumps to an invalid offset in the ppgtt it
can potentially continue executing through the whole address space
without triggering the hangcheck mechanism.

This patch adds a test to simulate the issue. I've kept the test running
for more than 10 minutes before killing it on a BDW and no hang occurred.
I've sampled i915_hangcheck_info a few times during the run and got the
following:

Hangcheck active, fires in 468ms
render ring:
seqno = f55e [current f55e]
ACTHD = 0x47df685ecc [current 0x4926b81d90]
max ACTHD = 0x47df685ecc
score = 0
action = 2
instdone read = 0xffd7 0x 0x 0x
instdone accu = 0x 0x 0x 0x

Hangcheck active, fires in 424ms
render ring:
seqno = f55e [current f55e]
ACTHD = 0x6c953d3a34 [current 0x6de5e76fa4]
max ACTHD = 0x6c953d3a34
score = 0
action = 2
instdone read = 0xffd7 0x 0x 0x
instdone accu = 0x 0x 0x 0x

Hangcheck active, fires in 1692ms
render ring:
seqno = f55e [current f55e]
ACTHD = 0x1f49b0366dc [current 0x1f4dcbd88ec]
max ACTHD = 0x1f49b0366dc
score = 0
action = 2
instdone read = 0xffd7 0x 0x 0x
instdone accu = 0x 0x 0x 0x

v2: use the new gem_wait() function (Chris)

v3: switch to unterminated batch and rename test, remove redundant
check, update test requirements (Chris), update top comment

Cc: Mika Kuoppala 
Cc: Arun Siluvery 
Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
---
 tests/drv_hangman.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
index 8a465cf..2360f26 100644
--- a/tests/drv_hangman.c
+++ b/tests/drv_hangman.c
@@ -288,6 +288,42 @@ static void test_error_state_capture(unsigned ring_id,
check_error_state(gen, cmd_parser, ring_name, offset);
 }
 
+/* This test covers the case where we end up in an uninitialised area of the
+ * ppgtt and keep executing through it. This is particularly relevant if 48b
+ * ppgtt is enabled because the ppgtt is massively bigger compared to the 32b
+ * case and it takes a lot more time to wrap, so the acthd can potentially keep
+ * increasing for a long time
+ */
+#define NSEC_PER_SEC   10L
+static void hangcheck_unterminated(void)
+{
+   int fd;
+   /* timeout needs to be greater than ~5*hangcheck */
+   int64_t timeout_ns = 100 * NSEC_PER_SEC; /* 100 seconds */
+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct drm_i915_gem_exec_object2 gem_exec;
+   uint32_t handle;
+
+   fd = drm_open_driver(DRIVER_INTEL);
+   igt_require(gem_uses_full_ppgtt(fd));
+   igt_require_hang_ring(fd, 0);
+
+   handle = gem_create(fd, 4096);
+
+   memset(_exec, 0, sizeof(gem_exec));
+   gem_exec.handle = handle;
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = (uintptr_t)_exec;
+   execbuf.buffer_count = 1;
+   execbuf.batch_len = 8;
+
+   gem_execbuf(fd, );
+   igt_assert_eq(gem_wait(fd, handle, _ns), 0);
+
+   close(fd);
+}
+
 igt_main
 {
const struct intel_execution_engine *e;
@@ -314,4 +350,7 @@ igt_main
test_error_state_capture(e->exec_id | e->flags,
 e->full_name);
}
+
+   igt_subtest("hangcheck-unterminated")
+   hangcheck_unterminated();
 }
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Lyude Paul]

Unfortunately MST is a wild beast, and doesn't work at all like other
connectors. This being said, putting it above intel_display_resume() was the
first thing I tried but that didn't work. Originally I had thought putting it
this high up was required because I had assumed drm_mode_config_reset() was
doing modesetting as well but doing some investigation, it doesn't look like
that call actually does anything. It looks like the real culprit here is
intel_runtime_pm_enable_interrupts(), so long as the call to
intel_dp_mst_resume() is above that everything works. So now I'm a little unsure
why this is working like it is, although I can definitely see the patch fixes
the issue. I'm going to edit the patch to reflect this, and see if I can get any
more insight as to why this fixes it.


On Wed, 2016-02-24 at 08:03 +0530, Thulasimani, Sivakumar wrote:
> 
> On 2/24/2016 3:41 AM, Lyude wrote:
> > As it turns out, resuming DP MST is racey since we don't make sure MST
> > is ready before we start modesetting, it just usually happens to be
> > ready in time. This isn't the case on all systems, particularly a
> > ThinkPad T560 with displays connected through the dock. On these
> > systems, resuming the laptop while connected to the dock usually results
> > in blank monitors. Making sure MST is ready before doing any kind of
> > modesetting fixes this issue.
> basic question since i haven't worked on MST much. MST should work like any
> other digital panel on resume. i.e detect followed by modeset. in the 
> modified
> commit mentioned below is it failing to detect the panel or failing at 
> the modeset ?
> if we are depending on the intel_display_resume, how about moving the
> intel_dp_mst_resume just above intel_display_resume?
> 
> 
> Generic question to others in mail list on i915_drm_resume
> we are doing a modeset and then doing the detect/hpd init.
> shouldn't this be the other way round ? almost all displays
> will pass a modeset even if display is not connected so we
> are spending time on modeset even for displays that were
> removed during the suspend state. if this is to simply
> drm_state being saved and restored,
> > We originally changed the resume order in
> > 
> > commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")
> > 
> > to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
> > issue now anyhow.
> > 
> > CC: sta...@vger.kernel.org
> > Signed-off-by: Lyude 
> > ---
> >   drivers/gpu/drm/i915/i915_drv.c | 10 --
> >   1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index f357058..4dcf3dd 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -733,6 +733,14 @@ static int i915_drm_resume(struct drm_device *dev)
> >     intel_opregion_setup(dev);
> >   
> >     intel_init_pch_refclk(dev);
> > +
> > +   /*
> > +    * We need to make sure that we resume MST before doing anything
> > +    * display related, otherwise we risk trying to bring up a display
> > on
> > +    * MST before the hub is actually ready
> > +    */
> > +   intel_dp_mst_resume(dev);
> > +
> This does not look proper. if the CD clock is turned off during suspend
> our dpcd read itself might fail till we enable CD Clock.
> 
> regards,
> Sivakumar
> >     drm_mode_config_reset(dev);
> >   
> >     /*
> > @@ -765,8 +773,6 @@ static int i915_drm_resume(struct drm_device *dev)
> >     intel_display_resume(dev);
> >     drm_modeset_unlock_all(dev);
> >   
> > -   intel_dp_mst_resume(dev);
> > -
> >     /*
> >      * ... but also need to make sure that hotplug processing
> >      * doesn't cause havoc. Like in the driver load code we don't
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFCv2 10/14] drm/i915: update PDPs by condition when submit the LRC context

[Wang, Zhi A]

-Original Message-
From: Tian, Kevin 
Sent: Wednesday, February 24, 2016 4:50 PM
To: Wang, Zhi A; intel-gfx@lists.freedesktop.org; igv...@lists.01.org
Cc: Lv, Zhiyuan; Niu, Bing; Song, Jike; daniel.vet...@ffwll.ch; Cowperthwaite, 
David J; ch...@chris-wilson.co.uk; joonas.lahti...@linux.intel.com
Subject: RE: [RFCv2 10/14] drm/i915: update PDPs by condition when submit the 
LRC context

> From: Wang, Zhi A
> Sent: Thursday, February 18, 2016 7:42 PM
> 
> Previously the PDPs inside the ring context are updated at:
> 
> - When populate a LRC context
> - Before submitting a LRC context (only for 32 bit PPGTT, as the amount
> of used PDPs may change)
> 
> This patch postpones the PDPs upgrade to submission time, and will update
> it by condition if the PPGTT is 48b. Under GVT-g, one GVT context will be
> used by different guest, the PPGTT instance related to the context might
> be changed before the submission time. And this patch gives GVT context
> a chance to load the new PPGTT instance into an initialized context.

Could you elaborate why we share one GVT context across different guest?
A natural thought is that we'll create one GVT context per every guest
context...

[Zhi] We don't have context creation/destroy notification in guest i915 driver.
Because in our implementation we need an unique context id to anchor the
relationship between shadow context and guest context, while i915 uses GGTT
address as context id. In each context pin/unpin, the context id may be changes.

So it's not necessary to allocate multiple GVT context here. 

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Support GuC SKL v6.1

[Dave Gordon]

On 24/02/16 16:49, yu@intel.com wrote:

From: Alex Dai 

This version of GuC firmware fixes the engine reset issue where golden
context LRC address is treated as page index by mistake. It also fixes
the problem that scheduler stops submiting to one engine when the other
engine work queue is full.

Signed-off-by: Alex Dai 


Hi Alex,

I heard a rumour that GuC 6.1 required a change to the driver interface?
If you can confirm that this is not so, then I'm happy with this, so:

Reviewed-by: Dave Gordon 

Also: GuC 6.1 has no known outstanding bugs to be fixed, so this would 
be a really good time to enable GuC submission by default on machines 
with this firmware installed. So I'm also going to repost the enabling 
patch (which you already R-B'ed) as a reply to this, so they should be 
taken together :)


.Dave.


---
  drivers/gpu/drm/i915/intel_guc_loader.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index e0093a9..e329a8a 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -59,7 +59,7 @@
   *
   */

-#define I915_SKL_GUC_UCODE "i915/skl_guc_ver4.bin"
+#define I915_SKL_GUC_UCODE "i915/skl_guc_ver6.bin"
  MODULE_FIRMWARE(I915_SKL_GUC_UCODE);

  /* User-friendly representation of an enum */
@@ -611,8 +611,8 @@ void intel_guc_ucode_init(struct drm_device *dev)
fw_path = NULL;
} else if (IS_SKYLAKE(dev)) {
fw_path = I915_SKL_GUC_UCODE;
-   guc_fw->guc_fw_major_wanted = 4;
-   guc_fw->guc_fw_minor_wanted = 3;
+   guc_fw->guc_fw_major_wanted = 6;
+   guc_fw->guc_fw_minor_wanted = 1;
} else {
fw_path = ""; /* unknown device */
}



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

[Intel-gfx] Graphical Corruption on Series 4 Chipset using xf86-video-intel

[Benjamin Hodgetts]

Hello all,

I recently updated the graphics drivers on a large amount of office machines
and noticed that some of the machines are now showing graphical corruption
on icons and other parts of the XFCE4 interface (e.g. the clock or icons on
the panel) when you mouse over them (when the icon should raise slightly).
Moving the mouse back and forth over icons results in differing degrees of
corruption varying from very slight to completely destroyed. I doubt this is
specific to XFCE4, that's just the desktop environment that these machines
are using (and unfortunately I don't have any way of testing another).

The version we updated to was xf86-video-intel 1:2.99.917+552+ge41040f-1
(Arch Linux) although unfortunately I don't know what the old version we
were using was, but it was several months old.

The only machines experiencing corruption show under "lspci" as "Intel
Corporation 4 Series Chipset" as the VGA adapter. It's not all Intel GPU
machines as there are other machines with Intel onboard graphics which are
fine (either newer or older chipsets).

Switching to UXA rather than SNA fixes the graphical corruption, but this in
itself causes problems as it no-longer automatically uses the correct screen
resolution by default for monitors greater than 1280x1024 in multi-monitor
setups (e.g. monitor 1 will show 1600x900 just fine, monitor 2 despite being
a 1080p monitor will just show 1280x1024 for unknown reasons, this only
happens under UXA, not SNA). I'm not keen on switching back to UXA and
manually setting the monitor resolutions isn't viable as any machine may be
connected to any monitor at any time, so hard-coding it is a no-no.

TL;DR: Latest xf86-video-intel causes graphical corruption on "4 Series
Chipset" machines.

Thanks all.

___
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/lrc: Only set RS ctx enable in ctx control reg if there is a RS (rev2)

[Michel Thierry]

On Thu, Feb 25, 2016 at 11:10 AM, Patchwork 
 wrote:

== Series Details ==

Series: drm/i915/lrc: Only set RS ctx enable in ctx control reg if there
is a RS (rev2)
URL   : https://patchwork.freedesktop.org/series/3725/
State : failure

== Summary ==

Series 3725v2 drm/i915/lrc: Only set RS ctx enable in ctx control reg if
there is a RS
http://patchwork.freedesktop.org/api/1.0/series/3725/revisions/2/mbox/

Test drv_hangman:
 Subgroup error-state-basic:
 pass   -> FAIL   (ilk-hp8440p)


(drv_hangman:6411) DEBUG: dfs entry i915_error_state read 'no error 
state collected'


So hangman wasn't able to hang the ring?



Test gem_sync:
 Subgroup basic-default:
 pass   -> DMESG-FAIL (hsw-brixbox)


[  406.005039] [drm:i915_hangcheck_elapsed [i915]] *ERROR* Hangcheck 
timer elapsed... render ring idle


This looks like a real regression (but unrelated to this patch, hsw 
doesn't use execlists). I opened 
https://bugs.freedesktop.org/show_bug.cgi?id=94289

Unfortunately I don't have a hsw to do a bisect.



Test kms_flip:
 Subgroup basic-flip-vs-modeset:
 pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE


The usual
[  196.712245] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* 
CPU pipe A FIFO underrun




Test kms_force_connector_basic:
 Subgroup force-load-detect:
 fail   -> DMESG-FAIL (ilk-hp8440p)

Again, unrelated to this patch, snd and ilk don't have execlists.

Looks like it has been like this for a while: 
/archive/results/CI_IGT_test/igt@kms_force_connector_ba...@force-load-detect.html


Also, this subtest is quite recent, 
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/?id=7670e286f5043d04af0cd1e6df1f092b5bcaf09e



Test kms_pipe_crc_basic:
 Subgroup nonblocking-crc-pipe-a-frame-sequence:
 pass   -> DMESG-WARN (ilk-hp8440p)


Again,
[  682.562490] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* 
CPU pipe A FIFO underrun



 Subgroup suspend-read-crc-pipe-b:
 pass   -> DMESG-WARN (skl-i7k-2) UNSTABLE


Same as: https://bugs.freedesktop.org/show_bug.cgi?id=93294 (cpu_hotplug 
lockdep fail).



 Subgroup suspend-read-crc-pipe-c:
 pass   -> SKIP   (bsw-nuc-2)
 pass   -> SKIP   (hsw-brixbox)
 dmesg-warn -> PASS   (skl-i7k-2) UNSTABLE
Test pm_rpm:
 Subgroup basic-pci-d3-state:
 dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14
bsw-nuc-2total:168  pass:136  dwarn:0   dfail:0   fail:1   skip:31
byt-nuc  total:168  pass:143  dwarn:0   dfail:0   fail:0   skip:25
hsw-brixbox  total:168  pass:152  dwarn:0   dfail:1   fail:0   skip:15
hsw-gt2  total:168  pass:157  dwarn:0   dfail:1   fail:0   skip:10
ilk-hp8440p  total:168  pass:115  dwarn:2   dfail:1   fail:1   skip:49
ivb-t430stotal:168  pass:153  dwarn:0   dfail:0   fail:1   skip:14
skl-i7k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16
snb-dellxps  total:168  pass:145  dwarn:0   dfail:0   fail:1   skip:22
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21

Results at /archive/results/CI_IGT_test/Patchwork_1473/

eb8b161ee8760105238ce372afa47b4565590125 drm-intel-nightly:
2016y-02m-25d-08h-16m-19s UTC integration manifest
b593d5b2bb8f88797651fda8e988794699da8eba drm/i915/lrc: Only set RS ctx
enable in ctx control reg if there is a RS

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


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

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

[Ville Syrjälä]

On Tue, Feb 16, 2016 at 09:44:55AM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor 
> 
> 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.
> 
> Signed-off-by: Clint Taylor 
> Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= 

I finally got around to actually trying this out myself, and I
noticed a few remaining problems:

- skl_modeset_calc_cdclk() should calculate dev_cdclk as well
  dev_cdclk will be the same as cdclk, except when all pipes are
  inactive, at which point dev_cdclk should be the minimum cdclk
- skl_modeset_commit_cdclk() should commit dev_cdclk, not cdclk
- modeset_update_crtc_power_domains() should check of the current
  vco is different from the requested vco in addition to checking
  the dev_cdclk vs. current cdclk, just like intel_modeset_checks()
  does

So the current thing works, but it fails to drop the cdclk to minimum
when all pipes are inactive, and it also reprograms the cdclk every
time, I assume since it forgot to compute dev_cdclk and so that one
is probably left at 0 and so it never matches the current cdclk.

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |2 +-
>  drivers/gpu/drm/i915/intel_ddi.c |2 +-
>  drivers/gpu/drm/i915/intel_display.c |  102 
> +-
>  drivers/gpu/drm/i915/intel_dp.c  |6 +-
>  drivers/gpu/drm/i915/intel_drv.h |4 ++
>  5 files changed, 99 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8216665..f65dd1a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1822,7 +1822,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 hpll_freq;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6d5b09f..285adab 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2958,7 +2958,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 9e2273b..e118ce0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5663,7 +5663,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;
>  
> @@ -5821,17 +5821,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 

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

[Joonas Lahtinen]

On ke, 2016-02-24 at 07:42 +, Tian, Kevin wrote:
> > From: Wang, Zhi A
> > Sent: Tuesday, February 23, 2016 9:23 PM
> > > > --- a/drivers/gpu/drm/i915/gvt/gvt.c
> > > > +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> > > > @@ -348,6 +348,10 @@ void *gvt_create_pgt_device(struct drm_i915_private
> > *dev_priv)
> > > >     goto err;
> > > >     }
> > > > 
> > > > +   dev_priv->gvt.host_fence_sz = gvt.host_fence_sz;
> > > > +   dev_priv->gvt.host_low_gm_sz_in_mb = gvt.host_low_gm_sz;
> > > > +   dev_priv->gvt.host_high_gm_sz_in_mb = gvt.host_high_gm_sz;
> > > 
> > > I'm thinking, could we expose the pgt_device struct (at least
> > > partially, and then have a PIMPL pattern), to avoid this kind of
> > > duplication of declarations and unnecessary copies between i915 and
> > > i915_gvt modules?
> > > 
> > > It's little rough that the gvt driver writes to i915_private struct.
> > > I'd rather see that gvt.host_fence_sz and other variables get sanitized
> > > and then written to pgt_device (maybe the public part would be
> > > i915_pgt_device) and used by gvt and i915 code.
> > > 
> > > Was this ever considered?
> > > 
> > The previous version do something similar like that, both i915 and gvt
> > reads GVT module kernel parameter but considered that GVT modules could
> > be configured as "n" in kernel configuration, probably we should let
> > i915 to store this information and GVT to configure it if GVT is active?
> 
> Agree with Joonas. We don't need another gvt wrap. Let's just expose
> pgt_device directly. I believe all other information can be encapsulated
> under pgt_device.
> 
> btw to match other description in the code, is it clear to rename pgt_device
> to gvt_device?
> 
> Another minor thing needs Joonas' feedback. Is it usual to capture
> all module parameters belonging to one feature structurized together
> (like 'gvt' in this patch), or just to leave them directly exposed?
> 

I think it's a good idea to group them as they're currently grouped.

Regards, Joonas

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

[Intel-gfx] [PATCH v2 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

[ville . syrjala]

From: Ville Syrjälä 

To save a bit of power, let's try to turn off the TMDS output buffers
in DP++ adaptors when we're not driving the port.

v2: Let's not forget DDI, toss in a debug message while at it

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ddi.c  | 12 
 drivers/gpu/drm/i915/intel_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 31 +--
 3 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 21a9b83f3bfc..458c41788b80 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2301,6 +2301,12 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
 
+   if (type == INTEL_OUTPUT_HDMI) {
+   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+
+   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
+   }
+
intel_prepare_ddi_buffer(intel_encoder);
 
if (type == INTEL_OUTPUT_EDP) {
@@ -2367,6 +2373,12 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder)
DPLL_CTRL2_DDI_CLK_OFF(port)));
else if (INTEL_INFO(dev)->gen < 9)
I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
+
+   if (type == INTEL_OUTPUT_HDMI) {
+   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+
+   intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
+   }
 }
 
 static void intel_enable_ddi(struct intel_encoder *intel_encoder)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 944eacbfb6a9..2e4fa4337c59 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -706,6 +706,7 @@ struct intel_hdmi {
int ddc_bus;
struct {
int max_tmds_clock;
+   bool tmds_output_control;
} dp_dual_mode;
bool limited_color_range;
bool color_range_auto;
@@ -1355,6 +1356,7 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
 struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
 bool intel_hdmi_compute_config(struct intel_encoder *encoder,
   struct intel_crtc_state *pipe_config);
+void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable);
 
 
 /* intel_lvds.c */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1e8cfdb18dc7..4b528a669f8e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -837,6 +837,20 @@ static void hsw_set_infoframes(struct drm_encoder *encoder,
intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
 }
 
+void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
+{
+   if (hdmi->dp_dual_mode.tmds_output_control) {
+   struct drm_i915_private *dev_priv = 
to_i915(intel_hdmi_to_dev(hdmi));
+   struct i2c_adapter *adapter =
+   intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
+
+   DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS output\n",
+ enable ? "Enabling" : "Disabling");
+
+   drm_dp_dual_mode_set_tmds_output(adapter, enable);
+   }
+}
+
 static void intel_hdmi_prepare(struct intel_encoder *encoder)
 {
struct drm_device *dev = encoder->base.dev;
@@ -846,6 +860,8 @@ static void intel_hdmi_prepare(struct intel_encoder 
*encoder)
const struct drm_display_mode *adjusted_mode = 
>config->base.adjusted_mode;
u32 hdmi_val;
 
+   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
+
hdmi_val = SDVO_ENCODING_HDMI;
if (!HAS_PCH_SPLIT(dev) && crtc->config->limited_color_range)
hdmi_val |= HDMI_COLOR_RANGE_16_235;
@@ -1144,6 +1160,8 @@ static void intel_disable_hdmi(struct intel_encoder 
*encoder)
}
 
intel_hdmi->set_infoframes(>base, false, NULL);
+
+   intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
 }
 
 static void g4x_disable_hdmi(struct intel_encoder *encoder)
@@ -1369,6 +1387,7 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
intel_hdmi->rgb_quant_range_selectable = false;
 
intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
+   intel_hdmi->dp_dual_mode.tmds_output_control = false;
 
kfree(to_intel_connector(connector)->detect_edid);
to_intel_connector(connector)->detect_edid = NULL;
@@ -1392,15 +1411,23 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector 
*connector)
 */
if (type == DRM_DP_DUAL_MODE_TYPE2_DVI ||
type == DRM_DP_DUAL_MODE_TYPE2_HDMI) {
+   bool tmds_enabled;
+

Re: [Intel-gfx] [PATCH v5] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

[Dave Gordon]

On 25/02/16 10:05, Chris Wilson wrote:

On Wed, Feb 24, 2016 at 10:02:58AM +, Dave Gordon wrote:

@@ -907,7 +942,8 @@ int intel_logical_ring_reserve_space(struct 
drm_i915_gem_request *request)
 * adding any commands to it then there might not actually be
 * sufficient room for the submission commands.
 */
-   intel_ring_reserved_space_reserve(request->ringbuf, 
MIN_SPACE_FOR_ADD_REQUEST);
+   intel_ring_reserved_space_reserve(request->ringbuf,
+   MIN_SPACE_FOR_ADD_REQUEST + WA_TAIL_DWORDS(request));


No, no and thrice no. MIN_SPACE_FOR_ADD_REQUEST already has to and does
take this into account. We either make it variable and universally compute
it per-engine/per-gen or keep using the fixed constant that is large enough
for everybody. This code should remain common to all paths until the
duplication is removed.
-Chris


As I said on the last iteration:

I didn't put it there because we *needed* the extra space -- as you say, 
the constant is already large enough -- but rather so that people 
changing either of those two values would be more likely to think about 
whether there were any unexpected interactions.


The sum of two constants is still just a constant. We *could* just 
update the comment about how MIN_SPACE_FOR_ADD_REQUEST was arrived at, 
noting that includes enough space for any possible workaround on any 
platform, without even changing the value. But that's more likely to get 
ignored if anyone ever finds a reason to increase the size of the 
padding (for example, if a context can be resubmitted more than once due 
to preemption, do we need to apply the workaround of adding 2 DWords 
EACH time?)


When we come to *use* the padding (in intel_logical_ring_submit()), 
there's a comment noting that the ring_begin() "is safe because we 
reserved the space earlier". So mentioning the padding at the point of 
allocation helps tie these two together and makes it clearer that the 
padding being consumed here is the same padding reserved earlier.


But the whole point of Rodrigo's original patch:
  drm/i915: Make wa_tail_dwords flexible for future platforms.
was to make this NOT (necessarily) a constant -- in which case we MUST 
add it to the reserved amount at the point of allocation, as above.

The commit message noted:
  we don't have a clean way to implement or remove WaIdleLiteRestore
  for different platforms.
  This patch aims to let it more flexible. So we just emit the NOOPs
  equivalent of what was initialized.
  Also let's just include the platforms we know that needs this Wa,
  i.e gen8 and gen9 platforms.

Personally, I'm not convinced that it really *needs* to be dynamic; but 
the implementation above /allows/ it to be so if it's ever necessary -- 
thus satisfying Rodrigo's intent -- while adding no overhead as long as 
the actual value remains a constant.


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

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drv_hangman: test for acthd increasing through invalid VM space

[Daniele Ceraolo Spurio]

On 25/02/16 11:32, Chris Wilson wrote:

On Thu, Feb 25, 2016 at 11:12:06AM +, Daniele Ceraolo Spurio wrote:


On 25/02/16 10:41, Chris Wilson wrote:

On Thu, Feb 25, 2016 at 10:32:11AM +, daniele.ceraolospu...@intel.com wrote:

+/* This test covers the case where we end up in an uninitialised area of the
+ * ppgtt at an offset greater than the one where the last buffer is mapped. 
This
+ * is particularly relevant if 48b ppgtt is enabled because the ppgtt is
+ * massively bigger compared to the 32b case and it takes a lot more time to
+ * wrap, so the acthd can potentially keep increasing for a long time
+ */
+#define NSEC_PER_SEC   10L
+static void ppgtt_walking(void)
+{
+   int fd;
+   int64_t timeout_ns = 100 * NSEC_PER_SEC; /* 100 seconds */

This needs a note that this has to be greater than ~5*hangcheck.


+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct drm_i915_gem_exec_object2 gem_exec;
+   uint32_t handle;
+   uint32_t batch[4];
+
+   fd = drm_open_driver(DRIVER_INTEL);
+   igt_require(gem_gtt_type(fd) > 2);

Nope, just full-ppgtt is required (and provides a sensible hangcheck
test if !48bit as well).

Note this does require that the hangcheck is enabled, so igt_require().


+
+   /* the batch will be mapped to an offset < 4GB because the flag to allow
+* 48b offsets is not specified, so jump to address 0x0001 
+*/
+   batch[0] = MI_BATCH_BUFFER_START | 1;
+   batch[1] = 0;
+   batch[2] = 1;
+   batch[3] = MI_BATCH_BUFFER_END;

The vm is entirely empty. Just submit an unterminated (empty) batch, and
it will walk from 0 to 1<<48bit and around and around and around and
around...

I chose to jump instead of just leaving the batch unterminated to
cover the (rare) case where the rest of the allocated 4k of the
batch contain some random values, which could cause a hang and thus
falsely pass the test.

That would be a huge kernel bug. Freshly allocated buffers have to be
zero to avoid information leaks. I hope you are confusing allocating
from the userspace buffer cache with a fresh kernel allocation...
-Chris



Apologies for the confusion, you're correct I was thinking about it from 
a libdrm level and not from a bare kernel level.


Daniele

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Pipe level color management (rev8)

[Patchwork]

== Series Details ==

Series: Pipe level color management (rev8)
URL   : https://patchwork.freedesktop.org/series/2720/
State : failure

== Summary ==

Series 2720v8 Pipe level color management
2016-02-25T10:37:34.469471 
http://patchwork.freedesktop.org/api/1.0/series/2720/revisions/8/mbox/
Applying: drm/i915: Extract out gamma table and CSC to their own file
Applying: drm/i915: Do not read GAMMA_MODE register
Applying: drm: introduce pipe color correction properties
Applying: drm/i915: Implement color management on bdw/skl/bxt/kbl
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0004 drm/i915: Implement color management on bdw/skl/bxt/kbl

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Update VBT fields for child devices

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Update VBT fields for child devices
URL   : https://patchwork.freedesktop.org/series/3785/
State : failure

== Summary ==

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

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (byt-nuc)
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (ivb-t430s)
Subgroup force-load-detect:
fail   -> DMESG-FAIL (snb-dellxps)
fail   -> DMESG-FAIL (ilk-hp8440p)
Subgroup prune-stale-modes:
pass   -> SKIP   (ivb-t430s)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:135  dwarn:2   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:142  dwarn:0   dfail:0   fail:1   skip:25 
hsw-brixbox  total:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
hsw-gt2  total:168  pass:157  dwarn:0   dfail:1   fail:0   skip:10 
ilk-hp8440p  total:168  pass:118  dwarn:0   dfail:1   fail:0   skip:49 
ivb-t430stotal:168  pass:151  dwarn:0   dfail:0   fail:1   skip:16 
skl-i7k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:1   fail:0   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1474/

eb8b161ee8760105238ce372afa47b4565590125 drm-intel-nightly: 
2016y-02m-25d-08h-16m-19s UTC integration manifest
68243399a1ea0df70e2a004e733927ac45ac355c drm/i915: Set invert bit for hpd based 
on VBT
8cb41eb42a5e8d8c010b8a1fd494b12e8d8c4042 drm/i915: Update VBT fields for child 
devices

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

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drv_hangman: test for acthd increasing through invalid VM space

[Chris Wilson]

On Thu, Feb 25, 2016 at 11:12:06AM +, Daniele Ceraolo Spurio wrote:
> 
> 
> On 25/02/16 10:41, Chris Wilson wrote:
> >On Thu, Feb 25, 2016 at 10:32:11AM +, daniele.ceraolospu...@intel.com 
> >wrote:
> >>+/* This test covers the case where we end up in an uninitialised area of 
> >>the
> >>+ * ppgtt at an offset greater than the one where the last buffer is 
> >>mapped. This
> >>+ * is particularly relevant if 48b ppgtt is enabled because the ppgtt is
> >>+ * massively bigger compared to the 32b case and it takes a lot more time 
> >>to
> >>+ * wrap, so the acthd can potentially keep increasing for a long time
> >>+ */
> >>+#define NSEC_PER_SEC   10L
> >>+static void ppgtt_walking(void)
> >>+{
> >>+   int fd;
> >>+   int64_t timeout_ns = 100 * NSEC_PER_SEC; /* 100 seconds */
> >This needs a note that this has to be greater than ~5*hangcheck.
> >
> >>+   struct drm_i915_gem_execbuffer2 execbuf;
> >>+   struct drm_i915_gem_exec_object2 gem_exec;
> >>+   uint32_t handle;
> >>+   uint32_t batch[4];
> >>+
> >>+   fd = drm_open_driver(DRIVER_INTEL);
> >>+   igt_require(gem_gtt_type(fd) > 2);
> >Nope, just full-ppgtt is required (and provides a sensible hangcheck
> >test if !48bit as well).
> >
> >Note this does require that the hangcheck is enabled, so igt_require().
> >
> >>+
> >>+   /* the batch will be mapped to an offset < 4GB because the flag to allow
> >>+* 48b offsets is not specified, so jump to address 0x0001 
> >>+*/
> >>+   batch[0] = MI_BATCH_BUFFER_START | 1;
> >>+   batch[1] = 0;
> >>+   batch[2] = 1;
> >>+   batch[3] = MI_BATCH_BUFFER_END;
> >The vm is entirely empty. Just submit an unterminated (empty) batch, and
> >it will walk from 0 to 1<<48bit and around and around and around and
> >around...
> 
> I chose to jump instead of just leaving the batch unterminated to
> cover the (rare) case where the rest of the allocated 4k of the
> batch contain some random values, which could cause a hang and thus
> falsely pass the test.

That would be a huge kernel bug. Freshly allocated buffers have to be
zero to avoid information leaks. I hope you are confusing allocating
from the userspace buffer cache with a fresh kernel allocation...
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a 
RS (rev2)
URL   : https://patchwork.freedesktop.org/series/3725/
State : failure

== Summary ==

Series 3725v2 drm/i915/lrc: Only set RS ctx enable in ctx control reg if there 
is a RS
http://patchwork.freedesktop.org/api/1.0/series/3725/revisions/2/mbox/

Test drv_hangman:
Subgroup error-state-basic:
pass   -> FAIL   (ilk-hp8440p)
Test gem_sync:
Subgroup basic-default:
pass   -> DMESG-FAIL (hsw-brixbox)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-load-detect:
fail   -> DMESG-FAIL (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (ilk-hp8440p)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (skl-i7k-2) UNSTABLE
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (bsw-nuc-2)
pass   -> SKIP   (hsw-brixbox)
dmesg-warn -> PASS   (skl-i7k-2) UNSTABLE
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:136  dwarn:0   dfail:0   fail:1   skip:31 
byt-nuc  total:168  pass:143  dwarn:0   dfail:0   fail:0   skip:25 
hsw-brixbox  total:168  pass:152  dwarn:0   dfail:1   fail:0   skip:15 
hsw-gt2  total:168  pass:157  dwarn:0   dfail:1   fail:0   skip:10 
ilk-hp8440p  total:168  pass:115  dwarn:2   dfail:1   fail:1   skip:49 
ivb-t430stotal:168  pass:153  dwarn:0   dfail:0   fail:1   skip:14 
skl-i7k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1473/

eb8b161ee8760105238ce372afa47b4565590125 drm-intel-nightly: 
2016y-02m-25d-08h-16m-19s UTC integration manifest
b593d5b2bb8f88797651fda8e988794699da8eba drm/i915/lrc: Only set RS ctx enable 
in ctx control reg if there is a RS

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

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drv_hangman: test for acthd increasing through invalid VM space

[Daniele Ceraolo Spurio]

On 25/02/16 10:41, Chris Wilson wrote:

On Thu, Feb 25, 2016 at 10:32:11AM +, daniele.ceraolospu...@intel.com wrote:

+/* This test covers the case where we end up in an uninitialised area of the
+ * ppgtt at an offset greater than the one where the last buffer is mapped. 
This
+ * is particularly relevant if 48b ppgtt is enabled because the ppgtt is
+ * massively bigger compared to the 32b case and it takes a lot more time to
+ * wrap, so the acthd can potentially keep increasing for a long time
+ */
+#define NSEC_PER_SEC   10L
+static void ppgtt_walking(void)
+{
+   int fd;
+   int64_t timeout_ns = 100 * NSEC_PER_SEC; /* 100 seconds */

This needs a note that this has to be greater than ~5*hangcheck.


+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct drm_i915_gem_exec_object2 gem_exec;
+   uint32_t handle;
+   uint32_t batch[4];
+
+   fd = drm_open_driver(DRIVER_INTEL);
+   igt_require(gem_gtt_type(fd) > 2);

Nope, just full-ppgtt is required (and provides a sensible hangcheck
test if !48bit as well).

Note this does require that the hangcheck is enabled, so igt_require().


+
+   /* the batch will be mapped to an offset < 4GB because the flag to allow
+* 48b offsets is not specified, so jump to address 0x0001 
+*/
+   batch[0] = MI_BATCH_BUFFER_START | 1;
+   batch[1] = 0;
+   batch[2] = 1;
+   batch[3] = MI_BATCH_BUFFER_END;

The vm is entirely empty. Just submit an unterminated (empty) batch, and
it will walk from 0 to 1<<48bit and around and around and around and
around...


I chose to jump instead of just leaving the batch unterminated to cover 
the (rare) case where the rest of the allocated 4k of the batch contain 
some random values, which could cause a hang and thus falsely pass the 
test. I'll respin with a memset to 0 of the batch (plus all the other 
suggested changes).


Thanks,
Daniele




+
+   handle = gem_create(fd, 4096);
+   gem_write(fd, handle, 0, batch, sizeof(batch));
+
+   memset(_exec, 0, sizeof(gem_exec));
+   gem_exec.handle = handle;
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = (uintptr_t)_exec;
+   execbuf.buffer_count = 1;
+   execbuf.batch_len = 16;
+
+   gem_execbuf(fd, );
+
+   igt_assert(gem_wait(fd, handle, _ns) == 0);

igt_assert_eq(gem_wait(), 0); so you get the information about the
failure.


+   igt_assert(timeout_ns > 0);

Redundant. gem_wait() returns ETIME if we wait for timeout_ns without
completion.


+
+   gem_close(fd, handle);

Irrelevant, it will be closed with close(fd).


+   close(fd);
+}
+
  igt_main
  {
const struct intel_execution_engine *e;
@@ -314,4 +361,7 @@ igt_main
test_error_state_capture(e->exec_id | e->flags,
 e->full_name);
}
+
+   igt_subtest("ppgtt-walking")
+   ppgtt_walking();

This is a hangcheck test, "hangcheck-unterminated"
-Chris



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

[Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

[Lionel Landwerlin]

Implement Daniel Stone's recommendation to not read registers to infer
the hardware's state.

v2: Read GAMMA_MODE register value at init (Matt Roper's comment)

v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along
with other registers (Matt Roper's comment).

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/intel_color.c   | 12 
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 5e0b997..16657eb 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -121,6 +121,8 @@ static void haswell_load_luts(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);
+   struct intel_crtc_state *intel_crtc_state =
+   to_intel_crtc_state(crtc->state);
bool reenable_ips = false;
 
/*
@@ -128,11 +130,12 @@ static void haswell_load_luts(struct drm_crtc *crtc)
 * GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
 */
if (IS_HASWELL(dev) && intel_crtc->config->ips_enabled &&
-   ((I915_READ(GAMMA_MODE(intel_crtc->pipe)) & GAMMA_MODE_MODE_MASK) ==
-GAMMA_MODE_MODE_SPLIT)) {
+   (intel_crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
hsw_disable_ips(intel_crtc);
reenable_ips = true;
}
+
+   intel_crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
I915_WRITE(GAMMA_MODE(intel_crtc->pipe), GAMMA_MODE_MODE_8BIT);
 
i9xx_load_luts(crtc);
@@ -183,8 +186,9 @@ void intel_color_init(struct drm_crtc *crtc)
}
 
if (IS_HASWELL(dev) ||
-   (INTEL_INFO(dev)->gen >= 8 && !IS_CHERRYVIEW(dev)))
+   (INTEL_INFO(dev)->gen >= 8 && !IS_CHERRYVIEW(dev))) {
dev_priv->display.load_luts = haswell_load_luts;
-   else
+   } else {
dev_priv->display.load_luts = i9xx_load_luts;
+   }
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index acbb1d9..19f8284 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9891,6 +9891,8 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,
 
intel_get_pipe_timings(crtc, pipe_config);
 
+   pipe_config->gamma_mode = I915_READ(GAMMA_MODE(crtc->pipe));
+
if (INTEL_INFO(dev)->gen >= 9) {
skl_init_scalers(dev, crtc, pipe_config);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7532f61..8c48131 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -517,6 +517,9 @@ struct intel_crtc_state {
struct skl_pipe_wm skl;
} optimal;
} wm;
+
+   /* Gamma mode programmed on the pipe */
+   uint32_t gamma_mode;
 };
 
 struct vlv_wm_state {
-- 
2.7.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: Implement color management on chv

[Lionel Landwerlin]

Patch based on a previous series by Shashank Sharma.

v2: Update contributors

v3: Refactor degamma/gamma LUTs load into a single function

v4: Remove unused variable

Signed-off-by: Shashank Sharma 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c|   3 +
 drivers/gpu/drm/i915/i915_reg.h|  31 +
 drivers/gpu/drm/i915/intel_color.c | 133 +++--
 3 files changed, 161 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3807b73..8a2aaa7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -68,6 +68,8 @@ static struct drm_driver driver;
 
 #define BDW_COLORS \
.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+#define CHV_COLORS \
+   .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
 
 static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
@@ -325,6 +327,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
+   CHV_COLORS,
 };
 
 static const struct intel_device_info intel_skylake_info = {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 76a9e49..ea599a9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7673,6 +7673,37 @@ enum skl_disp_power_wells {
 #define PREC_PAL_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A, 
_PAL_PREC_GC_MAX_B) + (i) * 4)
 #define PREC_PAL_EXT_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, 
_PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4)
 
+/* pipe CSC & degamma/gamma LUTs on CHV */
+#define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
+#define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
+#define _CGM_PIPE_A_CSC_COEFF45(VLV_DISPLAY_BASE + 0x67908)
+#define _CGM_PIPE_A_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6790C)
+#define _CGM_PIPE_A_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x67910)
+#define _CGM_PIPE_A_DEGAMMA(VLV_DISPLAY_BASE + 0x66000)
+#define _CGM_PIPE_A_GAMMA  (VLV_DISPLAY_BASE + 0x67000)
+#define _CGM_PIPE_A_MODE   (VLV_DISPLAY_BASE + 0x67A00)
+#define   CGM_PIPE_MODE_GAMMA  (1 << 2)
+#define   CGM_PIPE_MODE_CSC(1 << 1)
+#define   CGM_PIPE_MODE_DEGAMMA(1 << 0)
+
+#define _CGM_PIPE_B_CSC_COEFF01(VLV_DISPLAY_BASE + 0x69900)
+#define _CGM_PIPE_B_CSC_COEFF23(VLV_DISPLAY_BASE + 0x69904)
+#define _CGM_PIPE_B_CSC_COEFF45(VLV_DISPLAY_BASE + 0x69908)
+#define _CGM_PIPE_B_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6990C)
+#define _CGM_PIPE_B_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x69910)
+#define _CGM_PIPE_B_DEGAMMA(VLV_DISPLAY_BASE + 0x68000)
+#define _CGM_PIPE_B_GAMMA  (VLV_DISPLAY_BASE + 0x69000)
+#define _CGM_PIPE_B_MODE   (VLV_DISPLAY_BASE + 0x69A00)
+
+#define CGM_PIPE_CSC_COEFF01(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF01, _CGM_PIPE_B_CSC_COEFF01)
+#define CGM_PIPE_CSC_COEFF23(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF23, _CGM_PIPE_B_CSC_COEFF23)
+#define CGM_PIPE_CSC_COEFF45(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF45, _CGM_PIPE_B_CSC_COEFF45)
+#define CGM_PIPE_CSC_COEFF67(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF67, _CGM_PIPE_B_CSC_COEFF67)
+#define CGM_PIPE_CSC_COEFF8(pipe)  _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF8, _CGM_PIPE_B_CSC_COEFF8)
+#define CGM_PIPE_DEGAMMA(pipe, i, w)   _MMIO(_PIPE(pipe, _CGM_PIPE_A_DEGAMMA, 
_CGM_PIPE_B_DEGAMMA) + (i) * 8 + (w) * 4)
+#define CGM_PIPE_GAMMA(pipe, i, w) _MMIO(_PIPE(pipe, _CGM_PIPE_A_GAMMA, 
_CGM_PIPE_B_GAMMA) + (i) * 8 + (w) * 4)
+#define CGM_PIPE_MODE(pipe)_MMIO_PIPE(pipe, _CGM_PIPE_A_MODE, 
_CGM_PIPE_B_MODE)
+
 /* MIPI DSI registers */
 
 #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c)   /* ports A and C only */
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index a6dc2af..9ad37e5 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -29,6 +29,7 @@
 #define CTM_COEFF_1_0  (1ULL << 32)
 #define CTM_COEFF_2_0  (CTM_COEFF_1_0 << 1)
 #define CTM_COEFF_4_0  (CTM_COEFF_2_0 << 1)
+#define CTM_COEFF_8_0  (CTM_COEFF_4_0 << 1)
 #define CTM_COEFF_0_5  (CTM_COEFF_1_0 >> 1)
 #define CTM_COEFF_0_25 (CTM_COEFF_0_5 >> 1)
 #define CTM_COEFF_0_125(CTM_COEFF_0_25 >> 1)
@@ -199,6 +200,58 @@ static void i9xx_load_csc_matrix(struct drm_crtc *crtc)
}
 }
 
+/*
+ * Set up the pipe CSC unit on CherryView.
+ */
+static void cherryview_load_csc_matrix(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_crtc_state *state = crtc->state;
+   struct 

[Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

[Lionel Landwerlin]

Patch based on a previous series by Shashank Sharma.

This introduces optional properties to enable color correction at the
pipe level. It relies on 3 transformations applied to every pixels
displayed. First a lookup into a degamma table, then a multiplication
of the rgb components by a 3x3 matrix and finally another lookup into
a gamma table.

The following properties can be added to a pipe :
  - DEGAMMA_LUT : blob containing degamma LUT
  - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT
  - CTM : transformation matrix applied after the degamma LUT
  - GAMMA_LUT : blob containing gamma LUT
  - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT

DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by
the driver to tell userspace applications what sizes should be the
lookup tables in DEGAMMA_LUT and GAMMA_LUT.

A helper is also provided so legacy gamma correction is redirected
through these new properties.

v2: Register LUT size properties as range

v3: Fix round in drm_color_lut_get_value() helper
More docs on how degamma/gamma properties are used

v4: Update contributors

v5: Rename CTM_MATRIX property to CTM (Doh!)
Add legacy gamma_set atomic helper
Describe CTM/LUT acronyms in the kernel doc

Signed-off-by: Shashank Sharma 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
Reviewed-by: Matt Roper 
---
 Documentation/DocBook/gpu.tmpl  |  59 -
 drivers/gpu/drm/drm_atomic.c|  86 +-
 drivers/gpu/drm/drm_atomic_helper.c | 103 
 drivers/gpu/drm/drm_crtc.c  |  35 
 drivers/gpu/drm/drm_crtc_helper.c   |  33 
 include/drm/drm_atomic_helper.h |   3 ++
 include/drm/drm_crtc.h  |  46 +++-
 include/drm/drm_crtc_helper.h   |   3 ++
 include/uapi/drm/drm_mode.h |  15 ++
 9 files changed, 378 insertions(+), 5 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index fe6b36a..1692c4d 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions


-   DRM
+   DRM
Generic
“rotation”
BITMASK
@@ -2068,7 +2068,7 @@ void intel_crt_init(struct drm_device *dev)
property to suggest an Y offset for a connector


-   Optional
+   Optional
“scaling mode”
ENUM
{ "None", "Full", "Center", "Full aspect" }
@@ -2092,6 +2092,61 @@ void intel_crt_init(struct drm_device *dev)
TBD


+   “DEGAMMA_LUT”
+   BLOB
+   0
+   CRTC
+   DRM property to set the degamma lookup table
+   (LUT) mapping pixel data from the framebuffer before it is
+   given to the transformation matrix. The data is an interpreted
+   as an array of struct drm_color_lut elements. Hardware might
+   choose not to use the full precision of the LUT elements nor
+   use all the elements of the LUT (for example the hardware
+   might choose to interpolate between LUT[0] and LUT[4]). 
+   
+   
+   “DEGAMMA_LUT_SIZE”
+   RANGE | IMMUTABLE
+   Min=0, Max=UINT_MAX
+   CRTC
+   DRM property to gives the size of the lookup
+   table to be set on the DEGAMMA_LUT property (the size depends
+   on the underlying hardware).
+   
+   
+   “CTM”
+   BLOB
+   0
+   CRTC
+   DRM property to set the current
+   transformation matrix (CTM) apply to pixel data after the
+   lookup through the degamma LUT and before the lookup through
+   the gamma LUT. The data is an interpreted as a struct
+   drm_color_ctm.
+   
+   
+   “GAMMA_LUT”
+   BLOB
+   0
+   CRTC
+   DRM property to set the gamma lookup table
+   (LUT) mapping pixel data after to the transformation matrix to
+   data sent to the connector. The data is an interpreted as an
+   array of struct drm_color_lut elements. Hardware might choose
+   not to use the full precision of the LUT elements nor use all
+   the elements of the LUT (for example the hardware might choose
+   to interpolate between LUT[0] and LUT[4]).
+   
+   
+   “GAMMA_LUT_SIZE”
+   RANGE | IMMUTABLE
+   Min=0, Max=UINT_MAX
+   CRTC
+   DRM property to gives the size of the lookup
+   table to be set on the GAMMA_LUT property (the size depends on
+   the underlying hardware).
+   
+   
i915
Generic
"Broadcast RGB"

[Intel-gfx] [PATCH 1/5] drm/i915: Extract out gamma table and CSC to their own file

[Lionel Landwerlin]

The moves a couple of functions programming the gamma LUT and CSC
units into their own file.

On generations prior to Haswell there is only a gamma LUT. From
haswell on there is also a new enhanced color correction unit that
isn't used yet. This is why we need to set the GAMMA_MODE register,
either we're using the legacy 8bits LUT or enhanced LUTs (of 10 or
12bits).

The CSC unit is only available from Haswell on.

We also need to make a special case for CherryView which is recognized
as a gen 8 but doesn't have the same enhanced color correction unit
from Haswell on.

v2: Fix access to GAMMA_MODE register on older generations than
Haswell (from Matt Roper's comments)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/intel_color.c   | 190 +++
 drivers/gpu/drm/i915/intel_display.c | 163 +++---
 drivers/gpu/drm/i915/intel_drv.h |  10 ++
 5 files changed, 215 insertions(+), 151 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07..0516300 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -55,6 +55,7 @@ i915-y += intel_audio.o \
  intel_atomic.o \
  intel_atomic_plane.o \
  intel_bios.o \
+ intel_color.o \
  intel_display.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9e76bfc..8cb4418 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -662,6 +662,8 @@ struct drm_i915_display_funcs {
/* render clock increase/decrease */
/* display clock increase/decrease */
/* pll clock increase/decrease */
+
+   void (*load_luts)(struct drm_crtc *crtc);
 };
 
 enum forcewake_domain_id {
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
new file mode 100644
index 000..5e0b997
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_drv.h"
+
+/*
+ * Set up the pipe CSC unit.
+ *
+ * Currently only full range RGB to limited range RGB conversion
+ * is supported, but eventually this should handle various
+ * RGB<->YCbCr scenarios as well.
+ */
+static void i9xx_load_csc_matrix(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;
+   uint16_t coeff = 0x7800; /* 1.0 */
+
+   /*
+* TODO: Check what kind of values actually come out of the pipe
+* with these coeff/postoff values and adjust to get the best
+* accuracy. Perhaps we even need to take the bpc value into
+* consideration.
+*/
+
+   if (intel_crtc->config->limited_color_range)
+   coeff = ((235 - 16) * (1 << 12) / 255) & 0xff8; /* 0.xxx... */
+
+   I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), coeff << 16);
+   I915_WRITE(PIPE_CSC_COEFF_BY(pipe), 0);
+
+   I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), coeff);
+   I915_WRITE(PIPE_CSC_COEFF_BU(pipe), 0);
+
+   I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), 0);
+   I915_WRITE(PIPE_CSC_COEFF_BV(pipe), coeff << 16);
+
+   I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+   if (INTEL_INFO(dev)->gen > 6) {
+   uint16_t postoff = 0;
+
+   if 

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drv_hangman: test for acthd increasing through invalid VM space

[Chris Wilson]

On Thu, Feb 25, 2016 at 10:32:11AM +, daniele.ceraolospu...@intel.com wrote:
> +/* This test covers the case where we end up in an uninitialised area of the
> + * ppgtt at an offset greater than the one where the last buffer is mapped. 
> This
> + * is particularly relevant if 48b ppgtt is enabled because the ppgtt is
> + * massively bigger compared to the 32b case and it takes a lot more time to
> + * wrap, so the acthd can potentially keep increasing for a long time
> + */
> +#define NSEC_PER_SEC 10L
> +static void ppgtt_walking(void)
> +{
> + int fd;
> + int64_t timeout_ns = 100 * NSEC_PER_SEC; /* 100 seconds */

This needs a note that this has to be greater than ~5*hangcheck.

> + struct drm_i915_gem_execbuffer2 execbuf;
> + struct drm_i915_gem_exec_object2 gem_exec;
> + uint32_t handle;
> + uint32_t batch[4];
> +
> + fd = drm_open_driver(DRIVER_INTEL);
> + igt_require(gem_gtt_type(fd) > 2);

Nope, just full-ppgtt is required (and provides a sensible hangcheck
test if !48bit as well).

Note this does require that the hangcheck is enabled, so igt_require().

> +
> + /* the batch will be mapped to an offset < 4GB because the flag to allow
> +  * 48b offsets is not specified, so jump to address 0x0001 
> +  */
> + batch[0] = MI_BATCH_BUFFER_START | 1;
> + batch[1] = 0;
> + batch[2] = 1;
> + batch[3] = MI_BATCH_BUFFER_END;

The vm is entirely empty. Just submit an unterminated (empty) batch, and
it will walk from 0 to 1<<48bit and around and around and around and
around...

> +
> + handle = gem_create(fd, 4096);
> + gem_write(fd, handle, 0, batch, sizeof(batch));
> +
> + memset(_exec, 0, sizeof(gem_exec));
> + gem_exec.handle = handle;
> +
> + memset(, 0, sizeof(execbuf));
> + execbuf.buffers_ptr = (uintptr_t)_exec;
> + execbuf.buffer_count = 1;
> + execbuf.batch_len = 16;
> +
> + gem_execbuf(fd, );
> +
> + igt_assert(gem_wait(fd, handle, _ns) == 0);

igt_assert_eq(gem_wait(), 0); so you get the information about the
failure.

> + igt_assert(timeout_ns > 0);

Redundant. gem_wait() returns ETIME if we wait for timeout_ns without
completion.

> +
> + gem_close(fd, handle);

Irrelevant, it will be closed with close(fd).

> + close(fd);
> +}
> +
>  igt_main
>  {
>   const struct intel_execution_engine *e;
> @@ -314,4 +361,7 @@ igt_main
>   test_error_state_capture(e->exec_id | e->flags,
>e->full_name);
>   }
> +
> + igt_subtest("ppgtt-walking")
> + ppgtt_walking();

This is a hangcheck test, "hangcheck-unterminated"
-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 v5] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

[Chris Wilson]

On Wed, Feb 24, 2016 at 10:02:58AM +, Dave Gordon wrote:
> @@ -907,7 +942,8 @@ int intel_logical_ring_reserve_space(struct 
> drm_i915_gem_request *request)
>* adding any commands to it then there might not actually be
>* sufficient room for the submission commands.
>*/
> - intel_ring_reserved_space_reserve(request->ringbuf, 
> MIN_SPACE_FOR_ADD_REQUEST);
> + intel_ring_reserved_space_reserve(request->ringbuf,
> + MIN_SPACE_FOR_ADD_REQUEST + WA_TAIL_DWORDS(request));

No, no and thrice no. MIN_SPACE_FOR_ADD_REQUEST already has to and does
take this into account. We either make it variable and universally compute
it per-engine/per-gen or keep using the fixed constant that is large enough
for everybody. This code should remain common to all paths until the
duplication is removed.
-Chris

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

[Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices

[Shubhangi Shrivastava]

This patch adds new fields that are not yet added in drm code
in child devices struct

Signed-off-by: Sivakumar Thulasimani 
Signed-off-by: Durgadoss R 
Signed-off-by: Shubhangi Shrivastava 
---
 drivers/gpu/drm/i915/intel_bios.c | 15 ++-
 drivers/gpu/drm/i915/intel_bios.h | 16 +++-
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index bf62a19..a26d4b4 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1124,7 +1124,7 @@ static void parse_ddi_port(struct drm_i915_private 
*dev_priv, enum port port,
}
 
/* Parse the I_boost config for SKL and above */
-   if (bdb->version >= 196 && (child->common.flags_1 & IBOOST_ENABLE)) {
+   if (bdb->version >= 196 && child->common.iboost) {
info->dp_boost_level = 
translate_iboost(child->common.iboost_level & 0xF);
DRM_DEBUG_KMS("VBT (e)DP boost level for port %c: %d\n",
  port_name(port), info->dp_boost_level);
@@ -1250,6 +1250,19 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
 */
memcpy(child_dev_ptr, p_child,
   min_t(size_t, p_defs->child_dev_size, sizeof(*p_child)));
+
+   /*
+* copied full block, now init values when they are not
+* available in current version
+*/
+   if (bdb->version < 196) {
+   /* Set default values for bits added from v196 */
+   child_dev_ptr->common.iboost = 0;
+   child_dev_ptr->common.hpd_invert = 0;
+   }
+
+   if (bdb->version < 192)
+   child_dev_ptr->common.lspcon = 0;
}
return;
 }
diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index 350d4e0..2898323 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -250,9 +250,6 @@ struct old_child_dev_config {
  * versions. Notice that the meaning of the contents contents may still change,
  * but at least the offsets are consistent. */
 
-/* Definitions for flags_1 */
-#define IBOOST_ENABLE (1<<3)
-
 struct common_child_dev_config {
u16 handle;
u16 device_type;
@@ -261,8 +258,17 @@ struct common_child_dev_config {
u8 not_common2[2];
u8 ddc_pin;
u16 edid_ptr;
-   u8 obsolete;
-   u8 flags_1;
+   u8 dvo_cfg; /* See DEVICE_CFG_* above */
+   u8 efp_routed:1;
+   u8 lane_reversal:1;
+   u8 lspcon:1;
+   u8 iboost:1;
+   u8 hpd_invert:1;
+   u8 flag_reserved:3;
+   u8 hdmi_support:1;
+   u8 dp_support:1;
+   u8 tmds_support:1;
+   u8 support_reserved:5;
u8 not_common3[13];
u8 iboost_level;
 } __packed;
-- 
2.6.1

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

[Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

[Shubhangi Shrivastava]

This patch sets the invert bit for hpd detection for each port
based on VBT configuration. Since each AOB can be designed to
depend on invert bit or not, it is expected if an AOB requires
invert bit, the user will set respective bit in VBT.

v2: Separated VBT parsing from the rest of the logic. (Jani)

v3: Moved setting invert bit logic to bxt_hpd_irq_setup()
and changed its logic to avoid looping twice. (Ville)

Signed-off-by: Sivakumar Thulasimani 
Signed-off-by: Durgadoss R 
Signed-off-by: Shubhangi Shrivastava 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/i915_irq.c   | 22 +++-
 drivers/gpu/drm/i915/i915_reg.h   |  8 
 drivers/gpu/drm/i915/intel_bios.c | 42 +++
 4 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8216665..457f175 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3393,6 +3393,7 @@ extern void intel_i2c_reset(struct drm_device *dev);
 /* intel_bios.c */
 int intel_bios_init(struct drm_i915_private *dev_priv);
 bool intel_bios_is_valid_vbt(const void *buf, size_t size);
+bool intel_bios_is_port_hpd_inverted(struct drm_device *dev, enum port port);
 
 /* intel_opregion.c */
 #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 25a8937..525da56 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -36,6 +36,7 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
+#include "intel_bios.h"
 
 /**
  * DOC: interrupt handling
@@ -3484,6 +3485,7 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hotplug_irqs, hotplug, enabled_irqs;
+   int val = 0;
 
enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_bxt);
hotplug_irqs = BXT_DE_PORT_HOTPLUG_MASK;
@@ -3493,7 +3495,25 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
hotplug = I915_READ(PCH_PORT_HOTPLUG);
hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
PORTA_HOTPLUG_ENABLE;
-   I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
+
+   /*
+* For BXT invert bit has to be set based on AOB design
+* for HPD detection logic, update it based on VBT fields.
+*/
+   if ((enabled_irqs & BXT_DE_PORT_HP_DDIA)
+   && intel_bios_is_port_hpd_inverted(dev, PORT_A))
+   val |= BXT_DDIA_HPD_INVERT;
+   if ((enabled_irqs & BXT_DE_PORT_HP_DDIB)
+   && intel_bios_is_port_hpd_inverted(dev, PORT_B))
+   val |= BXT_DDIB_HPD_INVERT;
+   if ((enabled_irqs & BXT_DE_PORT_HP_DDIC)
+   && intel_bios_is_port_hpd_inverted(dev, PORT_C))
+   val |= BXT_DDIC_HPD_INVERT;
+
+   DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x val:%x\n",
+   hotplug, enabled_irqs, val);
+   hotplug &= ~BXT_DDI_HPD_INVERT_MASK;
+   I915_WRITE(PCH_PORT_HOTPLUG, hotplug | val);
 }
 
 static void ibx_irq_postinstall(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6732fc1..9ed42bb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5940,6 +5940,14 @@ enum skl_disp_power_wells {
 #define GEN8_PCU_IIR _MMIO(0x444e8)
 #define GEN8_PCU_IER _MMIO(0x444ec)
 
+/* BXT hotplug control */
+#define BXT_DDIA_HPD_INVERT(1 << 27)
+#define BXT_DDIC_HPD_INVERT(1 << 11)
+#define BXT_DDIB_HPD_INVERT(1 << 3)
+#define BXT_DDI_HPD_INVERT_MASK(BXT_DDIA_HPD_INVERT | \
+BXT_DDIB_HPD_INVERT | \
+BXT_DDIC_HPD_INVERT)
+
 #define ILK_DISPLAY_CHICKEN2   _MMIO(0x42004)
 /* Required on all Ironlake and Sandybridge according to the B-Spec. */
 #define  ILK_ELPIN_409_SELECT  (1 << 25)
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index a26d4b4..24d0077 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -105,6 +105,48 @@ find_section(const void *_bdb, int section_id)
return NULL;
 }
 
+bool
+intel_bios_is_port_hpd_inverted(struct drm_device *dev, enum port port)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   int i;
+
+   if (!IS_BROXTON(dev)) {
+   DRM_ERROR("Bit inversion is not required in this platform\n");
+   return false;
+   }
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+
+   if (dev_priv->vbt.child_dev[i].common.hpd_invert == 1) {
+
+   switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
+ 

[Intel-gfx] [PATCH RESEND_FOR_CI] drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS

[Michel Thierry]

The driver should only set the "RS context enable" bit in the context
image if we plan to use the resource streamer.

Reviewed-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e12fcab..c3779b9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2382,7 +2382,8 @@ populate_lr_context(struct intel_context *ctx, struct 
drm_i915_gem_object *ctx_o
ASSIGN_CTX_REG(reg_state, CTX_CONTEXT_CONTROL, 
RING_CONTEXT_CONTROL(ring),
   _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH |
  CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT |
- CTX_CTRL_RS_CTX_ENABLE));
+ (HAS_RESOURCE_STREAMER(dev) ?
+   CTX_CTRL_RS_CTX_ENABLE : 0)));
ASSIGN_CTX_REG(reg_state, CTX_RING_HEAD, RING_HEAD(ring->mmio_base), 0);
ASSIGN_CTX_REG(reg_state, CTX_RING_TAIL, RING_TAIL(ring->mmio_base), 0);
/* Ring buffer start address is not known until the buffer is pinned.
-- 
2.7.1

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

Re: [Intel-gfx] [PATCH v2.1 5/6] drm/atomic: Handle encoder assignment conflicts in a separate check, v2.

[Maarten Lankhorst]

The current check doesn't handle the case where we don't steal an
encoder, but keep it on the current connector. If we repurpose
disable_conflicting_encoders to do the checking, we just have
to reject the ones that conflict.

Changes since v1:
- Return early when encoder_mask is empty, drm_for_each_connector
  requires connection_mutex held.

Signed-off-by: Maarten Lankhorst 
Testcase: kms_setmode.invalid-clone-single-crtc-stealing
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3543c7fcd072..f44c043596d0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -86,7 +86,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
}
 }
 
-static int disable_conflicting_connectors(struct drm_atomic_state *state)
+static int handle_conflicting_encoders(struct drm_atomic_state *state,
+  bool disable_conflicting_encoders)
 {
struct drm_connector_state *conn_state;
struct drm_connector *connector;
@@ -106,10 +107,22 @@ static int disable_conflicting_connectors(struct 
drm_atomic_state *state)
else
new_encoder = funcs->best_encoder(connector);
 
-   if (new_encoder)
+   if (new_encoder) {
+   if (encoder_mask & (1 << 
drm_encoder_index(new_encoder))) {
+   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] on 
[CONNECTOR:%d:%s] already assigned\n",
+   new_encoder->base.id, new_encoder->name,
+   connector->base.id, connector->name);
+
+   return -EINVAL;
+   }
+
encoder_mask |= 1 << drm_encoder_index(new_encoder);
+   }
}
 
+   if (!encoder_mask)
+   return 0;
+
drm_for_each_connector(connector, state->dev) {
struct drm_crtc_state *crtc_state;
 
@@ -120,6 +133,15 @@ static int disable_conflicting_connectors(struct 
drm_atomic_state *state)
if (!encoder || !(encoder_mask & (1 << 
drm_encoder_index(encoder
continue;
 
+   if (!disable_conflicting_encoders) {
+   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on 
[CRTC:%d:%s] by [CONNECTOR:%d:%s]\n",
+encoder->base.id, encoder->name,
+connector->state->crtc->base.id,
+connector->state->crtc->name,
+connector->base.id, connector->name);
+   return -EINVAL;
+   }
+
conn_state = drm_atomic_get_connector_state(state, connector);
if (IS_ERR(conn_state))
return PTR_ERR(conn_state);
@@ -148,26 +170,6 @@ static int disable_conflicting_connectors(struct 
drm_atomic_state *state)
return 0;
 }
 
-static bool
-check_pending_encoder_assignment(struct drm_atomic_state *state,
-struct drm_encoder *new_encoder)
-{
-   struct drm_connector *connector;
-   struct drm_connector_state *conn_state;
-   int i;
-
-   for_each_connector_in_state(state, connector, conn_state, i) {
-   if (conn_state->best_encoder != new_encoder)
-   continue;
-
-   /* encoder already assigned and we're trying to re-steal it! */
-   if (connector->state->best_encoder != conn_state->best_encoder)
-   return false;
-   }
-
-   return true;
-}
-
 static void
 set_best_encoder(struct drm_atomic_state *state,
 struct drm_connector_state *conn_state,
@@ -326,13 +328,6 @@ update_connector_routing(struct drm_atomic_state *state,
return 0;
}
 
-   if (!check_pending_encoder_assignment(state, new_encoder)) {
-   DRM_DEBUG_ATOMIC("Encoder for [CONNECTOR:%d:%s] already 
assigned\n",
-connector->base.id,
-connector->name);
-   return -EINVAL;
-   }
-
ret = steal_encoder(state, new_encoder);
if (ret) {
DRM_DEBUG_ATOMIC("Encoder stealing failed for 
[CONNECTOR:%d:%s]\n",
@@ -511,11 +506,9 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
}
}
 
-   if (state->legacy_set_config) {
-   ret = disable_conflicting_connectors(state);
-   if (ret)
-   return ret;
-   }
+   ret = handle_conflicting_encoders(state, state->legacy_set_config);
+   if (ret)
+   return ret;
 
for_each_connector_in_state(state, connector, connector_state, i) {
/*

___
Intel-gfx mailing 

Re: [Intel-gfx] Delayed mail delivery problem

[Daniel Stone]

Hi,

On 25 February 2016 at 05:15, Tian, Kevin  wrote:
> I had some replies to this mailing list yesterday, but received below 
> notification:
>
> ---
> Delivery is delayed to these recipients or groups:
>
> intel-gfx@lists.freedesktop.org
>
> Subject: RE: [RFCv2 PATCH 00/14] gvt: Hacking i915 for GVT context requirement
>
> This message hasn't been delivered yet. Delivery will continue to be 
> attempted.
> ---
>
> Do I need to wait for some time or better to resend my replies?

The list server had some downtime yesterday, but it was fixed then -
as you'll notice by this mail having been delivered ...

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