Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"

[Daniel Vetter]

On Wed, Mar 01, 2017 at 07:35:15PM +0200, Jani Nikula wrote:
> On Wed, 01 Mar 2017, Chris Wilson  wrote:
> > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
> >> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
> >> 
> >> I assumed it's ok, but really should have double-checked - CI caught
> >> tons of fail :(
> 
> Considering the velocity of drm-tip, I think any CI results for patches
> have a rather limited best before date. The patch should've been resent
> and gone through testing again before merging.

Well the original patch also failed in the CI report, so the issue is
known even without resubmit.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v2] lib: Define a common bit operations library

[Daniel Vetter]

On Wed, Mar 01, 2017 at 04:14:31PM +, Chris Wilson wrote:
> On Wed, Mar 01, 2017 at 07:52:26AM -0800, Michel Thierry wrote:
> > Bring the test/set/clear bit functions we have into a single place.
> > 
> > v2: Add gtk-doc comment blocks (Daniel)
> 
> Hiss, boo! Will someone take gtk-doc and bury it? -flto to save the day?

... I thought it's perfectly ok with inline functions. Is it not?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

[Tvrtko Ursulin]

On 01/03/2017 20:07, Michal Wajdeczko wrote:

On Wed, Mar 01, 2017 at 07:29:15PM +, Tvrtko Ursulin wrote:


On 01/03/2017 17:39, Michal Wajdeczko wrote:

Engine related definitions are located in different files
and it is easy to break their cross dependency.

Additionally use GEM_WARN_ON to catch invalid engine index.

v2: compare against array size

Signed-off-by: Michal Wajdeczko 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a238304..c1f58b5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -84,11 +84,16 @@ static const struct engine_info {

 static int
 intel_engine_setup(struct drm_i915_private *dev_priv,
-  enum intel_engine_id id)
+  unsigned int id)
 {
const struct engine_info *info = _engines[id];
struct intel_engine_cs *engine;

+   BUILD_BUG_ON(ARRAY_SIZE(intel_engines) !=
+ARRAY_SIZE(dev_priv->engine));
+   if (GEM_WARN_ON(id >= ARRAY_SIZE(intel_engines)))
+   return -EINVAL;
+
GEM_BUG_ON(dev_priv->engine[id]);
engine = kzalloc(sizeof(*engine), GFP_KERNEL);
if (!engine)



I would add asserts for id >= ARRAY_SIZE(intel_engines) and id >=
ARRAY_SIZE(dev_priv->engine). That provides guarantees for no out of bounds
access within this function and should be enough for this function.


True, but then we will loose early (ie. at build time) detection that our
engine array definitions are not in sync (which was primary reason for this
patch).



The rest sounds just like trouble for now.


I would not call extra check as a trouble.
But if you prefer freedom over robustness, then I will step back.


Lets call it flexibility and pragmatism. :)


Also I am not sure about negative enum, do we elsewhere check for that class
of errors? Is it worth it? Maybe then just cast to unsigned in the above
mentioned asserts?


Note that the caller function is not using enum at all, this id/index is defined
there as plain "unsigned". Then it is promoted in this function only, where we
start to use it as index again (except id assignment).


Maybe we should make the loop in intel_engines_init_early use the id 
instead of i then...



IMHO enums are not the best choice for indexing arrays, and if you really want
to do so, you should add some guards to prevent unexpected use.


... although it is still a local function with a single call site so 
doesn't get me too excited. But since I'm usually all for data type tidy 
so feel free to do it.



Using cast in these two asserts will do the trick.

Let's try this as compromise ;)


Yes I think this compromise is robust enough! ;)

Regards,

Tvrtko

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

[Intel-gfx] [PATCH 2/2] drm/i915: Restore the invalid access without RPM warning

[Chris Wilson]

A long time ago we turned off the warning as it was too painful, we had
too much broken code. Turn it back on now as we are mostly clean and
need to prevent returning to such orangeness.

Signed-off-by: Chris Wilson 
Cc: Imre Deak 
---
 drivers/gpu/drm/i915/intel_drv.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b9d3e26b7023..0e96f4e6c2a1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1744,8 +1744,8 @@ assert_rpm_wakelock_held(struct drm_i915_private 
*dev_priv)
assert_rpm_device_not_suspended(dev_priv);
/* FIXME: Needs to be converted back to WARN_ONCE, but currently causes
 * too much noise. */
-   if (!atomic_read(_priv->pm.wakeref_count))
-   DRM_DEBUG_DRIVER("RPM wakelock ref not held during HW access");
+   WARN_ONCE(!atomic_read(_priv->pm.wakeref_count),
+ "RPM wakelock ref not held during HW access");
 }
 
 /**
-- 
2.11.0

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

[Intel-gfx] [PATCH 1/2] drm/i915: Hold rpm during GEM suspend in driver unload/suspend

[Chris Wilson]

i915_gem_suspend() tries to access the device to ensure it is idle and
all writes from the device are flushed to memory. It assumed is already
held the runtime pm wakeref, but we should explicitly acquire it for our
access to be safe.

[  619.926287] WARNING: CPU: 3 PID: 9353 at 
drivers/gpu/drm/i915/intel_drv.h:1750 gen6_write32+0x23e/0x2a0 [i915]
[  619.926300] RPM wakelock ref not held during HW access
[  619.926311] Modules linked in: vgem x86_pkg_temp_thermal intel_powerclamp 
snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec coretemp snd_hwdep 
crct10dif_pclmul snd_hda_core crc32_pclmul snd_pcm mei_me mei lpc_ich 
ghash_clmulni_intel i915(-) sdhci_pci sdhci mmc_core e1000e ptp pps_core 
prime_numbers [last unloaded: snd_hda_intel]
[  619.926578] CPU: 3 PID: 9353 Comm: drv_module_relo Tainted: G U  
4.10.0-CI-Trybot_609+ #1
[  619.926585] Hardware name: LENOVO 42962WU/42962WU, BIOS 8DET56WW (1.26 ) 
12/01/2011
[  619.926592] Call Trace:
[  619.926609]  dump_stack+0x67/0x92
[  619.926625]  __warn+0xc6/0xe0
[  619.926640]  warn_slowpath_fmt+0x4a/0x50
[  619.926726]  gen6_write32+0x23e/0x2a0 [i915]
[  619.926801]  gen6_mm_switch+0x38/0x70 [i915]
[  619.926871]  i915_switch_context+0xec/0xa10 [i915]
[  619.926942]  i915_gem_switch_to_kernel_context+0x13c/0x2b0 [i915]
[  619.927019]  i915_gem_suspend+0x2b/0x180 [i915]
[  619.927079]  i915_driver_unload+0x22/0x200 [i915]
[  619.927093]  ? __this_cpu_preempt_check+0x13/0x20
[  619.927105]  ? trace_hardirqs_on_caller+0xe7/0x200
[  619.927118]  ? trace_hardirqs_on+0xd/0x10
[  619.927128]  ? _raw_spin_unlock_irqrestore+0x3d/0x60
[  619.927192]  i915_pci_remove+0x14/0x20 [i915]
[  619.927205]  pci_device_remove+0x34/0xb0
[  619.927219]  device_release_driver_internal+0x158/0x210
[  619.927234]  driver_detach+0x3b/0x80
[  619.927245]  bus_remove_driver+0x53/0xd0
[  619.927256]  driver_unregister+0x27/0x50
[  619.927267]  pci_unregister_driver+0x25/0xa0
[  619.927351]  i915_exit+0x1a/0xb1a [i915]
[  619.927362]  SyS_delete_module+0x193/0x1e0
[  619.927378]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  619.927386] RIP: 0033:0x7f82b46c5d37
[  619.927393] RSP: 002b:7ffdb6f610d8 EFLAGS: 0246 ORIG_RAX: 
00b0
[  619.927408] RAX: ffda RBX: 81481ff3 RCX: 7f82b46c5d37
[  619.927415] RDX: 0001 RSI: 0800 RDI: 0224f558
[  619.927422] RBP: c90001187f88 R08:  R09: 7ffdb6f61100
[  619.927428] R10: 0224f4e0 R11: 0246 R12: 
[  619.927435] R13: 7ffdb6f612b0 R14:  R15: 
[  619.927451]  ? __this_cpu_preempt_check+0x13/0x20

or

[  641.646590] WARNING: CPU: 1 PID: 8913 at 
drivers/gpu/drm/i915/intel_drv.h:1750 intel_runtime_pm_get_noresume+0x8b/0x90 
[i915]
[  641.646595] RPM wakelock ref not held during HW access
[  641.646600] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_generic 
x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec snd_hwdep 
crct10dif_pclmul snd_hda_core crc32_pclmul ghash_clmulni_intel snd_pcm mei_me 
mei i915(-) r8169 mii prime_numbers i2c_hid [last unloaded: snd_hda_intel]
[  641.646825] CPU: 1 PID: 8913 Comm: drv_module_relo Tainted: G U  
4.10.0-CI-Trybot_609+ #1
[  641.646836] Hardware name: TOSHIBA SATELLITE P50-C/06F4  
  , BIOS 1.20 10/08/2015
[  641.646843] Call Trace:
[  641.646857]  dump_stack+0x67/0x92
[  641.646869]  __warn+0xc6/0xe0
[  641.646880]  warn_slowpath_fmt+0x4a/0x50
[  641.646893]  ? __this_cpu_preempt_check+0x13/0x20
[  641.646904]  ? trace_hardirqs_on_caller+0xe7/0x200
[  641.646957]  intel_runtime_pm_get_noresume+0x8b/0x90 [i915]
[  641.647022]  __i915_add_request+0x423/0x540 [i915]
[  641.647080]  i915_gem_switch_to_kernel_context+0x148/0x2b0 [i915]
[  641.647145]  i915_gem_suspend+0x2b/0x180 [i915]
[  641.647189]  i915_driver_unload+0x22/0x200 [i915]
[  641.647200]  ? __this_cpu_preempt_check+0x13/0x20
[  641.647210]  ? trace_hardirqs_on_caller+0xe7/0x200
[  641.647220]  ? trace_hardirqs_on+0xd/0x10
[  641.647231]  ? _raw_spin_unlock_irqrestore+0x3d/0x60
[  641.647276]  i915_pci_remove+0x14/0x20 [i915]
[  641.647293]  pci_device_remove+0x34/0xb0
[  641.647307]  device_release_driver_internal+0x158/0x210
[  641.647321]  driver_detach+0x3b/0x80
[  641.647330]  bus_remove_driver+0x53/0xd0
[  641.647338]  driver_unregister+0x27/0x50
[  641.647348]  pci_unregister_driver+0x25/0xa0
[  641.647415]  i915_exit+0x1a/0xb1a [i915]
[  641.647429]  SyS_delete_module+0x193/0x1e0
[  641.647444]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  641.647453] RIP: 0033:0x7fc622bd2d37
[  641.647463] RSP: 002b:78ffb5c8 EFLAGS: 0246 ORIG_RAX: 
00b0
[  641.647475] RAX: ffda RBX: 81481ff3 RCX: 7fc622bd2d37
[  641.647480] RDX: 0001 RSI: 0800 RDI: 00d49118
[  641.647485] RBP: c9997f88 R08:  R09: 78ffb5f0
[  641.647491] R10: 

Re: [Intel-gfx] [PATCH] drm/i915: Use GEM_WARN_ON to catch invalid engine indices.

[Tvrtko Ursulin]

On 01/03/2017 20:27, Michal Wajdeczko wrote:

Engine related definitions are located in different files
and it is easy to break their cross dependency.

v2: compare against array size
v3: don't use BUILD_BUG (Tvrtko)

Signed-off-by: Michal Wajdeczko 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a238304..8675164 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -89,7 +89,11 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
const struct engine_info *info = _engines[id];


Just need to move this assignment after the assert.


struct intel_engine_cs *engine;

-   GEM_BUG_ON(dev_priv->engine[id]);
+   if (GEM_WARN_ON((unsigned)id >= ARRAY_SIZE(intel_engines)))
+   return -EINVAL;
+   if (GEM_WARN_ON((unsigned)id >= ARRAY_SIZE(dev_priv->engine)))
+   return -EINVAL;
+
engine = kzalloc(sizeof(*engine), GFP_KERNEL);
if (!engine)
return -ENOMEM;
@@ -105,6 +109,7 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;

+   GEM_BUG_ON(dev_priv->engine[id]);


It doesn't really matter but I think moving this one was not needed.


dev_priv->engine[id] = engine;
return 0;
 }



Regards,

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

Re: [Intel-gfx] [PULL] topic/designware-baytrail for 4.12

[Daniel Vetter]

On Wed, Mar 01, 2017 at 11:42:48AM +0100, Daniel Vetter wrote:
> Hi all,
> 
> topic/designware-baytrail-2017-03-01:
> Baytrail PMIC vs. PMU race fixes from Hans de Goede
> 
> I opted to put all the patches for all subsystems into the topic branches,
> so that if needed, each subsystem can apply refactorings to the entire
> thing. Which might be needed since we're very early in the 4.12 cycle.
> 
> This has baked for a few days in the drm-intel CI and looks good afaics.
> I'll pull this into drm-intel.git for 4.12, feel free to pull into any
> other subsystem where needed.

Hold the presses, 0day found a compile warning. Not sure whether it's a
special config or why I/0day didn't spot this in the few days I let this
soak, but well.

Hans, can you pls provide I fixup patch? I'll respin the pull once I have
that.
-Daniel

> 
> Cheers, Daniel
> 
> 
> The following changes since commit 64a577196d66b44e37384bc5c4d78c61f59d5b2a:
> 
>   lib/Kconfig: make PRIME_NUMBERS not user selectable. (2017-02-24 12:11:21 
> +1000)
> 
> are available in the git repository at:
> 
>   git://anongit.freedesktop.org/git/drm-intel 
> tags/topic/designware-baytrail-2017-03-01
> 
> for you to fetch changes up to ca9b131b63aaf21419725bcf90497877d6bf6271:
> 
>   drm/i915: Listen for PMIC bus access notifications (2017-02-26 21:23:13 
> +0100)
> 
> 
> Baytrail PMIC vs. PMU race fixes from Hans de Goede
> 
> 
> Hans de Goede (12):
>   x86/platform/intel/iosf_mbi: Add a mutex for P-Unit access
>   x86/platform/intel/iosf_mbi: Add a PMIC bus access notifier
>   i2c: designware: Rename accessor_flags to flags
>   i2c: designware-baytrail: Pass dw_i2c_dev into helper functions
>   i2c: designware-baytrail: Only check iosf_mbi_available() for shared 
> hosts
>   i2c: designware-baytrail: Disallow the CPU to enter C6 or C7 while 
> holding the punit semaphore
>   i2c: designware-baytrail: Fix race when resetting the semaphore
>   i2c: designware-baytrail: Add support for cherrytrail
>   i2c: designware-baytrail: Acquire P-Unit access on bus acquire
>   i2c: designware-baytrail: Call pmic_bus_access_notifier_chain
>   drm/i915: Add intel_uncore_suspend / resume functions
>   drm/i915: Listen for PMIC bus access notifications
> 
>  arch/x86/include/asm/iosf_mbi.h  | 85 
> 
>  arch/x86/platform/intel/iosf_mbi.c   | 49 
>  drivers/gpu/drm/i915/Kconfig |  1 +
>  drivers/gpu/drm/i915/i915_drv.c  |  6 +-
>  drivers/gpu/drm/i915/i915_drv.h  |  7 +--
>  drivers/gpu/drm/i915/intel_uncore.c  | 53 +++--
>  drivers/i2c/busses/i2c-designware-baytrail.c | 83 +++
>  drivers/i2c/busses/i2c-designware-core.c | 14 ++---
>  drivers/i2c/busses/i2c-designware-core.h | 13 -
>  drivers/i2c/busses/i2c-designware-pcidrv.c   | 26 ++---
>  drivers/i2c/busses/i2c-designware-platdrv.c  |  8 ++-
>  11 files changed, 288 insertions(+), 57 deletions(-)
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

[Intel-gfx] [drm-intel:topic/designware-baytrail 2/12] arch/x86/include/asm/iosf_mbi.h:137:55: warning: 'struct notifier_block' declared inside parameter list

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel topic/designware-baytrail
head:   ca9b131b63aaf21419725bcf90497877d6bf6271
commit: 26363e10f680194a71c8d4287c8e2886ed539c4e [2/12] 
x86/platform/intel/iosf_mbi: Add a PMIC bus access notifier
config: i386-randconfig-c0-03021134 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 26363e10f680194a71c8d4287c8e2886ed539c4e
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from arch/x86/platform/intel-quark/imr.c:30:0:
>> arch/x86/include/asm/iosf_mbi.h:137:55: warning: 'struct notifier_block' 
>> declared inside parameter list
int iosf_mbi_register_pmic_bus_access_notifier(struct notifier_block *nb);
  ^
>> arch/x86/include/asm/iosf_mbi.h:137:55: warning: its scope is only this 
>> definition or declaration, which is probably not what you want
   arch/x86/include/asm/iosf_mbi.h:144:57: warning: 'struct notifier_block' 
declared inside parameter list
int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb);
^

vim +137 arch/x86/include/asm/iosf_mbi.h

   121  
   122  /**
   123   * iosf_mbi_register_pmic_bus_access_notifier - Register PMIC bus 
notifier
   124   *
   125   * This function can be used by drivers which may need to acquire P-Unit
   126   * managed resources from interrupt context, where 
iosf_mbi_punit_acquire()
   127   * can not be used.
   128   *
   129   * This function allows a driver to register a notifier to get notified 
(in a
   130   * process context) before other drivers start accessing the PMIC bus.
   131   *
   132   * This allows the driver to acquire any resources, which it may need 
during
   133   * the window the other driver is accessing the PMIC, before hand.
   134   *
   135   * @nb: notifier_block to register
   136   */
 > 137  int iosf_mbi_register_pmic_bus_access_notifier(struct notifier_block 
 > *nb);
   138  
   139  /**
   140   * iosf_mbi_register_pmic_bus_access_notifier - Unregister PMIC bus 
notifier
   141   *
   142   * @nb: notifier_block to unregister
   143   */
   144  int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block 
*nb);
   145  

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


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

Re: [Intel-gfx] [PATCH v5 5/6] drm/i915: enable scrambling

[Sharma, Shashank]

Regards

Shashank


On 3/1/2017 8:41 PM, Ville Syrjälä wrote:

On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote:

Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.

This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.

V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
   driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
   in intel_enable_ddi() before enabling the port.

V3: Addressed review comments from Jani
  - In comments, function names, use "sink" instead of "monitor",
so that the implementation could be close to the language of
HDMI spec.

V4: Addressed review comment from Maarten
  - scrambling -> hdmi_scrambling
high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio

V5: Addressed review comments from Ville and Ander
  - Do not modifiy the crtc_state after compute_config. Move all
scrambling and tmds_clock_ratio calcutations to compute_config.
  - While setting scrambling for source/sink, do not check the
conditions again, just go by the crtc_state flags. This will
simplyfy the condition checks.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/i915_reg.h   |  4 ++
  drivers/gpu/drm/i915/intel_ddi.c  | 29 
  drivers/gpu/drm/i915/intel_drv.h  | 14 ++
  drivers/gpu/drm/i915/intel_hdmi.c | 98 +++
  4 files changed, 145 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ce6f096..1759b64 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7824,7 +7824,11 @@ enum {
  #define  TRANS_DDI_EDP_INPUT_B_ONOFF  (5<<12)
  #define  TRANS_DDI_EDP_INPUT_C_ONOFF  (6<<12)
  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
+#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
+#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
  #define  TRANS_DDI_BFI_ENABLE (1<<4)
+#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define  TRANS_DDI_HDMI_SCRAMBLING (1<<0)
  
  /* DisplayPort Transport Control */

  #define _DP_TP_CTL_A  0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a7c08d7..24bc3a8 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1311,6 +1311,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+   if (IS_GEMINILAKE(dev_priv))
+   temp = intel_hdmi_handle_source_scrambling(
+   intel_encoder,
+   intel_crtc->config, temp);
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
@@ -1885,6 +1890,21 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder,
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
  
+		if (IS_GEMINILAKE(dev_priv)) {

+   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
+   /*
+* GLK sports a native HDMI 2.0 controller. If required
+* clock rate is > 340 Mhz && scrambling is supported
+* by sink, enable scrambling before enabling the
+* HDMI 2.0 port. The sink can choose to disable the
+* scrambling if it doesn't detect a scrambled within
+* 100 ms.
+*/
+   intel_hdmi_handle_sink_scrambling(intel_encoder,
+   conn_state->connector,
+   crtc->config, true);
+   }
+
/* In HDMI/DVI mode, the port width, and swing/emphasis values
 * are ignored so nothing special needs to be done besides
 * enabling the port.
@@ -1912,11 +1932,20 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder,
  struct drm_connector_state *old_conn_state)
  {
struct drm_encoder *encoder = _encoder->base;
+   struct drm_i915_private *dev_priv = encoder->dev->dev_private;
int type = intel_encoder->type;
  
  	if (old_crtc_state->has_audio)

intel_audio_codec_disable(intel_encoder);
  
+	if ((type == INTEL_OUTPUT_HDMI) && IS_GEMINILAKE(dev_priv)) {

 ^ ^

Pointless parens. Also I'm nor sure we want 

Re: [Intel-gfx] [PATCH v5 4/6] drm/edid: detect SCDC support in HF-VSDB

[Sharma, Shashank]

Regards

Shashank


On 3/1/2017 8:28 PM, Ville Syrjälä wrote:

On Tue, Feb 28, 2017 at 02:09:08PM +0530, Shashank Sharma wrote:

This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
   This structure will be used to save and indicate if sink
   supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
   reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
   in scdc structure
- If SCDC is present, checks if sink is capable of generating
   SCDC read request, and marks it in scdc structure.

V2: Addressed review comments
   Thierry:
   - Fix typos in commit message and make abbreviation consistent
 across the commit message.
   - Change structure object name from hdmi_info -> hdmi
   - Fix typos and abbreviations in description of structure drm_hdmi_info
 end the description with a full stop.
   - Create a structure drm_scdc, and keep all information related to SCDC
 register set (supported, read request supported) etc in it.

   Ville:
   - Change rr -> read_request
   - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
 of HF-VSDB parsing can be kept in same function, in incremental
 patches.

V3: Rebase.
V4: Rebase.
V5: Rebase.

Signed-off-by: Shashank Sharma 
Reviewed-by: Thierry Reding 
---
  drivers/gpu/drm/drm_edid.c|  33 +++-
  drivers/gpu/drm/drm_scdc_helper.c | 111 ++
  include/drm/drm_connector.h   |  19 +++
  include/drm/drm_edid.h|   6 ++-
  include/drm/drm_scdc_helper.h |  27 ++
  5 files changed, 194 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0881108..e84c5ab 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "drm_crtc_internal.h"
  
@@ -3817,13 +3818,43 @@ enum hdmi_quantization_range

  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 const u8 *hf_vsdb)
  {
-   struct drm_hdmi_info *hdmi = >display_info.hdmi;
+   struct drm_display_info *display = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi;
  
  	if (hf_vsdb[6] & 0x80) {

hdmi->scdc.supported = true;
if (hf_vsdb[6] & 0x40)
hdmi->scdc.read_request = true;
}
+
+   /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
+* * SCDC support available (let's check)
+* Lets check it out.
+*/
+
+   if (hf_vsdb[5]) {
+   /* max clock is 5000 KHz times block value */
+   u32 max_tmds_clock = hf_vsdb[5] * 5000;
+   struct drm_scdc *scdc = >scdc;
+
+   if (max_tmds_clock > 34) {
+   display->max_tmds_clock = max_tmds_clock;
+   DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+   display->max_tmds_clock);
+   }
+
+   if (scdc->supported) {
+   scdc->scrambling.supported = true;
+
+   /* Few sinks support scrambling for cloks < 340M */
+   if ((hf_vsdb[6] & 0x8))
+   scdc->scrambling.low_rates = true;
+   }
+   }
  }
  
  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,

diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index c2dd33f..180a7cd 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -22,8 +22,10 @@
   */
  
  #include 

+#include 
  
  #include 

+#include 
  
  /**

   * DOC: scdc helpers
@@ -121,3 +123,112 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8 
offset,
return 0;
  }
  EXPORT_SYMBOL(drm_scdc_write);
+
+/**
+ * drm_scdc_check_scrambling_status - what is status of scrambling?
+ * @adapter: I2C adapter for DDC channel
+ *
+ * Reads the scrambler status over SCDC, and checks the
+ * scrambling status.
+ *
+ * Returns:
+ * True if the scrambling is enabled, false otherwise.
+ */
+
+bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter)
+{
+   u8 status;
+   int ret;
+
+   ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );
+   if (ret < 0) {
+   DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
+   return false;
+   }
+
+   return status & SCDC_SCRAMBLING_STATUS;
+}
+EXPORT_SYMBOL(drm_scdc_get_scrambling_status);
+
+/**
+ * drm_scdc_set_scrambling - 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Use GEM_WARN_ON to catch invalid engine indices.

[Patchwork]

== Series Details ==

Series: drm/i915: Use GEM_WARN_ON to catch invalid engine indices.
URL   : https://patchwork.freedesktop.org/series/20486/
State : warning

== Summary ==

Series 20486v1 drm/i915: Use GEM_WARN_ON to catch invalid engine indices.
https://patchwork.freedesktop.org/api/1.0/series/20486/revisions/1/mbox/

Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-bxt-t5700)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:192  dwarn:36  dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:216  dwarn:44  dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

a777f02a6f1fbe44b42f245d6397b3f960a0a257 drm-tip: 2017y-03m-01d-20h-32m-24s UTC 
integration manifest
c8051c6 drm/i915: Use GEM_WARN_ON to catch invalid engine indices.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4025/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't use enums for hardware engine id (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Don't use enums for hardware engine id (rev2)
URL   : https://patchwork.freedesktop.org/series/20396/
State : success

== Summary ==

Series 20396v2 drm/i915: Don't use enums for hardware engine id
https://patchwork.freedesktop.org/api/1.0/series/20396/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-bxt-t5700)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:192  dwarn:36  dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:216  dwarn:44  dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

a777f02a6f1fbe44b42f245d6397b3f960a0a257 drm-tip: 2017y-03m-01d-20h-32m-24s UTC 
integration manifest
94ada26 drm/i915: Don't use enums for hardware engine id

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4024/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915/HuC: Add an extra check for platforms that do not have HUC

[Patchwork]

== Series Details ==

Series: i915/HuC: Add an extra check for platforms that do not have HUC
URL   : https://patchwork.freedesktop.org/series/20482/
State : failure

== Summary ==

Series 20482v1 i915/HuC: Add an extra check for platforms that do not have HUC
https://patchwork.freedesktop.org/api/1.0/series/20482/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-bxt-t5700)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (fi-skl-6770hq) fdo#99739
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-c:
pass   -> FAIL   (fi-skl-6770hq)

fdo#99739 https://bugs.freedesktop.org/show_bug.cgi?id=99739

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:192  dwarn:36  dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:216  dwarn:44  dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:266  dwarn:0   dfail:0   fail:2   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

a777f02a6f1fbe44b42f245d6397b3f960a0a257 drm-tip: 2017y-03m-01d-20h-32m-24s UTC 
integration manifest
60ac8ba i915/HuC: Add an extra check for platforms that do not have HUC

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4023/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Don't use enums for hardware engine id

[Chris Wilson]

On Wed, Mar 01, 2017 at 08:26:15PM +, Michal Wajdeczko wrote:
> Generally we are using macros for any hardware identifiers as these
> may change between Gens. Do the same with hardware engine ids.
> 
> v2: move hw engine defs to i915_reg.h (Chris)
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Daniele Ceraolo Spurio 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  6 ++
>  drivers/gpu/drm/i915/intel_engine_cs.c  |  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 33 
> +
>  3 files changed, 24 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 93dcbbc..456cb7d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -77,7 +77,13 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  #define _MASKED_BIT_ENABLE(a)({ typeof(a) _a = (a); 
> _MASKED_FIELD(_a, _a); })
>  #define _MASKED_BIT_DISABLE(a)   (_MASKED_FIELD((a), 0))
>  
> +/* Engine ID */
>  
> +#define RCS_HW   0
> +#define VCS_HW   1
> +#define BCS_HW   2
> +#define VECS_HW  3
> +#define VCS2_HW  4

Works for me. I dream of i915_reg.h being broken up as well.

>  
>  /* PCI config space */
>  
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index c4d4698..a238304 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -29,7 +29,7 @@
>  static const struct engine_info {
>   const char *name;
>   unsigned exec_id;
> - enum intel_engine_hw_id hw_id;
> + unsigned hw_id;
>   u32 mmio_base;
>   unsigned irq_shift;
>   int (*init_legacy)(struct intel_engine_cs *engine);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 3dd6eee..b5767c5 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -186,26 +186,27 @@ struct i915_ctx_workarounds {
>  struct drm_i915_gem_request;
>  struct intel_render_state;
>  
> +
> +/*
> + * Engine IDs definitions.
> + * Keep instances of the same type engine together.
> + */
> +enum intel_engine_id {
> + RCS = 0,
> + BCS,
> + VCS,
> + VCS2,
> +#define _VCS(n) (VCS + (n))
> + VECS
> +};
> +
>  struct intel_engine_cs {
>   struct drm_i915_private *i915;
>   const char  *name;
> - enum intel_engine_id {
> - RCS = 0,
> - BCS,
> - VCS,
> - VCS2,   /* Keep instances of the same type engine together. */
> - VECS
> - } id;
> -#define _VCS(n) (VCS + (n))
> + enum intel_engine_id id;
>   unsigned int exec_id;
> - enum intel_engine_hw_id {
> - RCS_HW = 0,
> - VCS_HW,
> - BCS_HW,
> - VECS_HW,
> - VCS2_HW
> - } hw_id;
> - enum intel_engine_hw_id guc_id; /* XXX same as hw_id? */
> + unsigned int hw_id;
> + unsigned int guc_id;

Bah. There goes the reminder that guc_id is not special and we just want
to get an architect to confirm that they won't differ!.

Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Move w/a LRI debug message from context-init to driver load

[Chris Wilson]

On Wed, Mar 01, 2017 at 07:23:36PM +, Tvrtko Ursulin wrote:
> 
> On 01/03/2017 12:11, Chris Wilson wrote:
> >The spam of every context initialisation saying the same thing is annoying
> >me! Move the information to the setup of the engine.
> 
> Yes I've noticed this ugly side effect of code consolidation. :)
> 
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
[snip]
> Reviewed-by: Tvrtko Ursulin 

Thanks, now to hope nothing emerges from noise...
-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] drm/i915: Use GEM_WARN_ON to catch invalid engine indices.

[Michal Wajdeczko]

Engine related definitions are located in different files
and it is easy to break their cross dependency.

v2: compare against array size
v3: don't use BUILD_BUG (Tvrtko)

Signed-off-by: Michal Wajdeczko 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a238304..8675164 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -89,7 +89,11 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
const struct engine_info *info = _engines[id];
struct intel_engine_cs *engine;
 
-   GEM_BUG_ON(dev_priv->engine[id]);
+   if (GEM_WARN_ON((unsigned)id >= ARRAY_SIZE(intel_engines)))
+   return -EINVAL;
+   if (GEM_WARN_ON((unsigned)id >= ARRAY_SIZE(dev_priv->engine)))
+   return -EINVAL;
+
engine = kzalloc(sizeof(*engine), GFP_KERNEL);
if (!engine)
return -ENOMEM;
@@ -105,6 +109,7 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;
 
+   GEM_BUG_ON(dev_priv->engine[id]);
dev_priv->engine[id] = engine;
return 0;
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH v2] drm/i915: Don't use enums for hardware engine id

[Michal Wajdeczko]

Generally we are using macros for any hardware identifiers as these
may change between Gens. Do the same with hardware engine ids.

v2: move hw engine defs to i915_reg.h (Chris)

Signed-off-by: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_reg.h |  6 ++
 drivers/gpu/drm/i915/intel_engine_cs.c  |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h | 33 +
 3 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 93dcbbc..456cb7d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -77,7 +77,13 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define _MASKED_BIT_ENABLE(a)  ({ typeof(a) _a = (a); _MASKED_FIELD(_a, _a); })
 #define _MASKED_BIT_DISABLE(a) (_MASKED_FIELD((a), 0))
 
+/* Engine ID */
 
+#define RCS_HW 0
+#define VCS_HW 1
+#define BCS_HW 2
+#define VECS_HW3
+#define VCS2_HW4
 
 /* PCI config space */
 
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index c4d4698..a238304 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -29,7 +29,7 @@
 static const struct engine_info {
const char *name;
unsigned exec_id;
-   enum intel_engine_hw_id hw_id;
+   unsigned hw_id;
u32 mmio_base;
unsigned irq_shift;
int (*init_legacy)(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 3dd6eee..b5767c5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -186,26 +186,27 @@ struct i915_ctx_workarounds {
 struct drm_i915_gem_request;
 struct intel_render_state;
 
+
+/*
+ * Engine IDs definitions.
+ * Keep instances of the same type engine together.
+ */
+enum intel_engine_id {
+   RCS = 0,
+   BCS,
+   VCS,
+   VCS2,
+#define _VCS(n) (VCS + (n))
+   VECS
+};
+
 struct intel_engine_cs {
struct drm_i915_private *i915;
const char  *name;
-   enum intel_engine_id {
-   RCS = 0,
-   BCS,
-   VCS,
-   VCS2,   /* Keep instances of the same type engine together. */
-   VECS
-   } id;
-#define _VCS(n) (VCS + (n))
+   enum intel_engine_id id;
unsigned int exec_id;
-   enum intel_engine_hw_id {
-   RCS_HW = 0,
-   VCS_HW,
-   BCS_HW,
-   VECS_HW,
-   VCS2_HW
-   } hw_id;
-   enum intel_engine_hw_id guc_id; /* XXX same as hw_id? */
+   unsigned int hw_id;
+   unsigned int guc_id;
u32 mmio_base;
unsigned int irq_shift;
struct intel_ring *buffer;
-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix use after free in lpe_audio_platdev_destroy()

[Patchwork]

== Series Details ==

Series: drm/i915: Fix use after free in lpe_audio_platdev_destroy()
URL   : https://patchwork.freedesktop.org/series/20476/
State : success

== Summary ==

Series 20476v1 drm/i915: Fix use after free in lpe_audio_platdev_destroy()
https://patchwork.freedesktop.org/api/1.0/series/20476/revisions/1/mbox/

Test gem_exec_reloc:
Subgroup basic-gtt-cpu-active:
incomplete -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:192  dwarn:36  dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:216  dwarn:44  dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

07e9f4ad3a2ca599975099c1fe49189a24be1884 drm-tip: 2017y-03m-01d-18h-00m-03s UTC 
integration manifest
6df3ff3 drm/i915: Fix use after free in lpe_audio_platdev_destroy()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4022/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

[Michal Wajdeczko]

On Wed, Mar 01, 2017 at 07:29:15PM +, Tvrtko Ursulin wrote:
> 
> On 01/03/2017 17:39, Michal Wajdeczko wrote:
> > Engine related definitions are located in different files
> > and it is easy to break their cross dependency.
> > 
> > Additionally use GEM_WARN_ON to catch invalid engine index.
> > 
> > v2: compare against array size
> > 
> > Signed-off-by: Michal Wajdeczko 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Cc: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >  drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index a238304..c1f58b5 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -84,11 +84,16 @@ static const struct engine_info {
> > 
> >  static int
> >  intel_engine_setup(struct drm_i915_private *dev_priv,
> > -  enum intel_engine_id id)
> > +  unsigned int id)
> >  {
> > const struct engine_info *info = _engines[id];
> > struct intel_engine_cs *engine;
> > 
> > +   BUILD_BUG_ON(ARRAY_SIZE(intel_engines) !=
> > +ARRAY_SIZE(dev_priv->engine));
> > +   if (GEM_WARN_ON(id >= ARRAY_SIZE(intel_engines)))
> > +   return -EINVAL;
> > +
> > GEM_BUG_ON(dev_priv->engine[id]);
> > engine = kzalloc(sizeof(*engine), GFP_KERNEL);
> > if (!engine)
> > 
> 
> I would add asserts for id >= ARRAY_SIZE(intel_engines) and id >=
> ARRAY_SIZE(dev_priv->engine). That provides guarantees for no out of bounds
> access within this function and should be enough for this function.

True, but then we will loose early (ie. at build time) detection that our
engine array definitions are not in sync (which was primary reason for this
patch).

> 
> The rest sounds just like trouble for now.

I would not call extra check as a trouble.
But if you prefer freedom over robustness, then I will step back.

> 
> Also I am not sure about negative enum, do we elsewhere check for that class
> of errors? Is it worth it? Maybe then just cast to unsigned in the above
> mentioned asserts?

Note that the caller function is not using enum at all, this id/index is defined
there as plain "unsigned". Then it is promoted in this function only, where we
start to use it as index again (except id assignment).

IMHO enums are not the best choice for indexing arrays, and if you really want
to do so, you should add some guards to prevent unexpected use.

Using cast in these two asserts will do the trick.

Let's try this as compromise ;)

-Michal





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

[Intel-gfx] [PATCH] i915/HuC: Add an extra check for platforms that do not have HUC

[Anusha Srivatsa]

Return silently without producing much noise on platforms
that have a HuC but the firmware is absent.

Cc: Ander Conselvan De Oliveira 
Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_huc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index c28543d..e660109 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -181,12 +181,14 @@ void intel_huc_init(struct drm_i915_private *dev_priv)
}
 
huc_fw->path = fw_path;
+
+   if (huc_fw->path == NULL)
+   return;
+
huc_fw->fetch_status = INTEL_UC_FIRMWARE_PENDING;
 
DRM_DEBUG_DRIVER("HuC firmware pending, path %s\n", fw_path);
 
-   WARN(huc_fw->path == NULL, "HuC present but no fw path\n");
-
intel_uc_fw_fetch(dev_priv, huc_fw);
 }
 
-- 
2.7.4

___
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/glk: Fix DSI enable I/O sequence

[Patchwork]

== Series Details ==

Series: drm/i915/glk: Fix DSI enable I/O sequence
URL   : https://patchwork.freedesktop.org/series/20474/
State : warning

== Summary ==

Series 20474v1 drm/i915/glk: Fix DSI enable I/O sequence
https://patchwork.freedesktop.org/api/1.0/series/20474/revisions/1/mbox/

Test gem_exec_reloc:
Subgroup basic-gtt-cpu-active:
incomplete -> PASS   (fi-byt-j1900)
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-bxt-t5700)
Test gem_flink_basic:
Subgroup bad-flink:
pass   -> DMESG-WARN (fi-skl-6700k)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (fi-bxt-j4205)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:258  dwarn:1   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:257  dwarn:1   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:192  dwarn:36  dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:215  dwarn:45  dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

07e9f4ad3a2ca599975099c1fe49189a24be1884 drm-tip: 2017y-03m-01d-18h-00m-03s UTC 
integration manifest
80faace drm/i915/glk: Fix DSI enable I/O sequence

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4021/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't use enums for hardware engine id

[Michal Wajdeczko]

On Tue, Feb 28, 2017 at 09:53:37PM +, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 07:07:38PM +0100, Michal Wajdeczko wrote:
> > On Tue, Feb 28, 2017 at 04:52:34PM +, Chris Wilson wrote:
> > > On Tue, Feb 28, 2017 at 04:43:02PM +, Chris Wilson wrote:
> > > > On Tue, Feb 28, 2017 at 02:12:09PM +, Michal Wajdeczko wrote:
> > > > > +/* Hardware Engine ID definitions */
> > > > > +#define RCS_HW   0
> > > > > +#define VCS_HW   1
> > > > > +#define BCS_HW   2
> > > > > +#define VECS_HW  3
> > > > > +#define VCS2_HW  4
> > > > 
> > > > So don't put them in the header if they may have inconsistent meanings.
> > > 
> > > Or if you do want to keep them in a header, either i915_reg.h or
> > > intel_engine_reg.h as somewhere out of the way, and clear that they are
> > > not meant for the rest of the bookkeeping in intel_ringbuffer.h.
> > 
> > I can't find nice spot for these engine IDs in the i915_reg.h
> > 
> > Can I just move these definitions to the top of this header?
> 
> I would rather we spend a little effort on splitting our driver API from
> hw innards.

Sounds reasonable.

As it looks that engine->hw_id is mostly used in code related to semaphores,
I'll move these engine definitions to i915_reg.h near MI_SEMAPHORE_SIGNAL
instruction.

In case of guc_id, it looks that these engine ids are already defined in
intel_guc_fwif.h (see GUC_RENDER_ENGINE..GUC_VIDEO_ENGINE2)

For now they are the same, but who knows what the future brings ;)

-Michal



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

Re: [Intel-gfx] [PATCH v2] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

[Tvrtko Ursulin]

On 01/03/2017 17:39, Michal Wajdeczko wrote:

Engine related definitions are located in different files
and it is easy to break their cross dependency.

Additionally use GEM_WARN_ON to catch invalid engine index.

v2: compare against array size

Signed-off-by: Michal Wajdeczko 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a238304..c1f58b5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -84,11 +84,16 @@ static const struct engine_info {

 static int
 intel_engine_setup(struct drm_i915_private *dev_priv,
-  enum intel_engine_id id)
+  unsigned int id)
 {
const struct engine_info *info = _engines[id];
struct intel_engine_cs *engine;

+   BUILD_BUG_ON(ARRAY_SIZE(intel_engines) !=
+ARRAY_SIZE(dev_priv->engine));
+   if (GEM_WARN_ON(id >= ARRAY_SIZE(intel_engines)))
+   return -EINVAL;
+
GEM_BUG_ON(dev_priv->engine[id]);
engine = kzalloc(sizeof(*engine), GFP_KERNEL);
if (!engine)



I would add asserts for id >= ARRAY_SIZE(intel_engines) and id >= 
ARRAY_SIZE(dev_priv->engine). That provides guarantees for no out of 
bounds access within this function and should be enough for this function.


The rest sounds just like trouble for now.

Also I am not sure about negative enum, do we elsewhere check for that 
class of errors? Is it worth it? Maybe then just cast to unsigned in the 
above mentioned asserts?


Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Move w/a LRI debug message from context-init to driver load

[Tvrtko Ursulin]

On 01/03/2017 12:11, Chris Wilson wrote:

The spam of every context initialisation saying the same thing is annoying
me! Move the information to the setup of the engine.


Yes I've noticed this ugly side effect of code consolidation. :)


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

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index c4d4698f98e7..c58339b22f6a 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1009,30 +1009,32 @@ static int glk_init_workarounds(struct intel_engine_cs 
*engine)
 int init_workarounds_ring(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
+   int err;

WARN_ON(engine->id != RCS);

dev_priv->workarounds.count = 0;
-   dev_priv->workarounds.hw_whitelist_count[RCS] = 0;
+   dev_priv->workarounds.hw_whitelist_count[engine->id] = 0;

if (IS_BROADWELL(dev_priv))
-   return bdw_init_workarounds(engine);
-
-   if (IS_CHERRYVIEW(dev_priv))
-   return chv_init_workarounds(engine);
-
-   if (IS_SKYLAKE(dev_priv))
-   return skl_init_workarounds(engine);
-
-   if (IS_BROXTON(dev_priv))
-   return bxt_init_workarounds(engine);
-
-   if (IS_KABYLAKE(dev_priv))
-   return kbl_init_workarounds(engine);
-
-   if (IS_GEMINILAKE(dev_priv))
-   return glk_init_workarounds(engine);
+   err = bdw_init_workarounds(engine);
+   else if (IS_CHERRYVIEW(dev_priv))
+   err = chv_init_workarounds(engine);
+   else if (IS_SKYLAKE(dev_priv))
+   err =  skl_init_workarounds(engine);
+   else if (IS_BROXTON(dev_priv))
+   err = bxt_init_workarounds(engine);
+   else if (IS_KABYLAKE(dev_priv))
+   err = kbl_init_workarounds(engine);
+   else if (IS_GEMINILAKE(dev_priv))
+   err =  glk_init_workarounds(engine);
+   else
+   err = 0;
+   if (err)
+   return err;

+   DRM_DEBUG_DRIVER("%s: Number of context specific w/a: %d\n",
+engine->name, dev_priv->workarounds.count);
return 0;
 }

@@ -1066,8 +1068,6 @@ int intel_ring_workarounds_emit(struct 
drm_i915_gem_request *req)
if (ret)
return ret;

-   DRM_DEBUG_DRIVER("Number of Workarounds emitted: %d\n", w->count);
-
return 0;
 }




Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use BUILD_BUG_ON to detected missing engine definitions (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Use BUILD_BUG_ON to detected missing engine definitions (rev2)
URL   : https://patchwork.freedesktop.org/series/20394/
State : success

== Summary ==

Series 20394v2 drm/i915: Use BUILD_BUG_ON to detected missing engine definitions
https://patchwork.freedesktop.org/api/1.0/series/20394/revisions/2/mbox/

Test gem_exec_reloc:
Subgroup basic-gtt-cpu-active:
incomplete -> PASS   (fi-byt-j1900)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:192  dwarn:36  dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:216  dwarn:44  dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

07e9f4ad3a2ca599975099c1fe49189a24be1884 drm-tip: 2017y-03m-01d-18h-00m-03s UTC 
integration manifest
05b8c8e drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4020/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Fix use after free in lpe_audio_platdev_destroy()

[Chris Wilson]

[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 
[i915] at addr 8801f7788358
[31908.547297] Read of size 8 by task drv_selftest/3781
[31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: GBU  W   
4.10.0+ #451
[31908.547553] Hardware name:  /, BIOS 
PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[31908.547682] Call Trace:
[31908.547772]  dump_stack+0x68/0x9f
[31908.547857]  kasan_object_err+0x1c/0x70
[31908.547947]  kasan_report_error+0x1f1/0x4f0
[31908.548038]  ? kfree+0xaa/0x170
[31908.548121]  kasan_report+0x34/0x40
[31908.548211]  ? klist_children_get+0x20/0x30
[31908.548472]  ? intel_lpe_audio_teardown+0x78/0xb0 [i915]
[31908.548567]  __asan_load8+0x5e/0x70
[31908.548824]  intel_lpe_audio_teardown+0x78/0xb0 [i915]
[31908.549080]  intel_audio_deinit+0x28/0x80 [i915]
[31908.549315]  i915_driver_unload+0xe4/0x360 [i915]
[31908.549551]  ? i915_driver_load+0x1d70/0x1d70 [i915]
[31908.549651]  ? trace_hardirqs_on+0xd/0x10
[31908.549885]  i915_pci_remove+0x23/0x30 [i915]
[31908.549978]  pci_device_remove+0x5c/0x100
[31908.550069]  device_release_driver_internal+0x1db/0x2e0
[31908.550165]  driver_detach+0x68/0xc0
[31908.550256]  bus_remove_driver+0x8b/0x150
[31908.550346]  driver_unregister+0x3e/0x60
[31908.550439]  pci_unregister_driver+0x1d/0x110
[31908.550531]  ? find_module_all+0x7a/0xa0
[31908.550791]  i915_exit+0x1a/0x87 [i915]
[31908.550881]  SyS_delete_module+0x264/0x2c0
[31908.550971]  ? free_module+0x430/0x430
[31908.551064]  ? trace_hardirqs_off_caller+0x16/0x110
[31908.551159]  ? trace_hardirqs_on_caller+0x16/0x280
[31908.551256]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[31908.551350]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.551440] RIP: 0033:0x7f1d67312ec7
[31908.551520] RSP: 002b:7ffebe34e888 EFLAGS: 0206 ORIG_RAX: 
00b0
[31908.551650] RAX: ffda RBX: 811123f6 RCX: 7f1d67312ec7
[31908.551743] RDX:  RSI: 0800 RDI: 560d0af476b8
[31908.551837] RBP: 880233d87f98 R08:  R09: 7ffebe34e8b8
[31908.551930] R10: 7f1d68adf8c0 R11: 0206 R12: 
[31908.552023] R13: 560d0af46440 R14: 0034 R15: 7ffebe34d860
[31908.552121]  ? trace_hardirqs_off_caller+0x16/0x110
[31908.552217] Object at 8801f7788000, in cache kmalloc-2048 size: 2048
[31908.552306] Allocated:
[31908.552377] PID = 3781
[31908.552456]  save_stack_trace+0x16/0x20
[31908.552539]  kasan_kmalloc+0xee/0x190
[31908.552627]  __kmalloc+0xdb/0x1b0
[31908.552713]  platform_device_alloc+0x27/0x90
[31908.552804]  platform_device_register_full+0x36/0x220
[31908.553066]  intel_lpe_audio_init+0x41e/0x570 [i915]
[31908.553320]  intel_audio_init+0xd/0x40 [i915]
[31908.553552]  i915_driver_load+0x13f5/0x1d70 [i915]
[31908.553788]  i915_pci_probe+0x65/0xe0 [i915]
[31908.553881]  pci_device_probe+0xda/0x140
[31908.553969]  driver_probe_device+0x400/0x660
[31908.554058]  __driver_attach+0x11c/0x120
[31908.554147]  bus_for_each_dev+0xe6/0x150
[31908.554237]  driver_attach+0x26/0x30
[31908.554325]  bus_add_driver+0x26b/0x3b0
[31908.554412]  driver_register+0xce/0x190
[31908.554502]  __pci_register_driver+0xaf/0xc0
[31908.554589]  0xa0550063
[31908.554675]  do_one_initcall+0x8b/0x1e0
[31908.554764]  do_init_module+0x102/0x325
[31908.554852]  load_module+0x3aad/0x45e0
[31908.554944]  SyS_finit_module+0x169/0x1a0
[31908.555033]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.555119] Freed:
[31908.555188] PID = 3781
[31908.555266]  save_stack_trace+0x16/0x20
[31908.555349]  kasan_slab_free+0xb0/0x180
[31908.555436]  kfree+0xaa/0x170
[31908.20]  platform_device_release+0x76/0x80
[31908.555610]  device_release+0x45/0xe0
[31908.555698]  kobject_put+0x11f/0x260
[31908.555785]  put_device+0x12/0x20
[31908.555871]  platform_device_unregister+0x1b/0x20
[31908.556135]  intel_lpe_audio_teardown+0x5c/0xb0 [i915]
[31908.556390]  intel_audio_deinit+0x28/0x80 [i915]
[31908.556622]  i915_driver_unload+0xe4/0x360 [i915]
[31908.556858]  i915_pci_remove+0x23/0x30 [i915]
[31908.556948]  pci_device_remove+0x5c/0x100
[31908.557037]  device_release_driver_internal+0x1db/0x2e0
[31908.557129]  driver_detach+0x68/0xc0
[31908.557217]  bus_remove_driver+0x8b/0x150
[31908.557304]  driver_unregister+0x3e/0x60
[31908.557394]  pci_unregister_driver+0x1d/0x110
[31908.557653]  i915_exit+0x1a/0x87 [i915]
[31908.557741]  SyS_delete_module+0x264/0x2c0
[31908.557834]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[31908.557919] Memory state around the buggy address:
[31908.558005]  8801f7788200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[31908.558127]  8801f7788280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[31908.558255] >8801f7788300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[31908.558374] ^
[31908.558467]  8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
fb
[31908.558595]  8801f7788400: 

Re: [Intel-gfx] [GLK MIPI DSI V7] drm/i915/glk: Add MIPIIO Enable/disable sequence

[Chauhan, Madhav]

> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, March 1, 2017 7:44 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander ;
> Shankar, Uma ; Mukherjee, Indranil
> ; Saarinen, Jani ;
> Kamath, Sunil ; Deepak M
> ; Chauhan, Madhav 
> Subject: Re: [GLK MIPI DSI V7] drm/i915/glk: Add MIPIIO Enable/disable
> sequence
> 
> On Wed, 01 Mar 2017, Madhav Chauhan 
> wrote:
> > From: Deepak M 
> >
> > v2: Addressed Jani's Review comments(renamed bit field macros)
> > v3: Jani's Review comment for aligning code to platforms and added
> > wrapper functions.
> > v4: Corrected enable/disable seuqence as per BSPEC
> > v5: Corrected waiting twice for same bit (Review comments: Jani)
> > v6: Rebased to Han's patches(dsi restructuring code)
> >
> > Signed-off-by: Deepak M 
> > Signed-off-by: Madhav Chauhan 
> > ---
> >  drivers/gpu/drm/i915/intel_dsi.c | 206
> > ---
> >  1 file changed, 195 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index 20ed799..8e97bae3 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -357,6 +357,109 @@ static bool intel_dsi_compute_config(struct
> intel_encoder *encoder,
> > return true;
> >  }
> >
> > +static void glk_dsi_device_ready(struct intel_encoder *encoder) {
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> > +   enum port port;
> > +   u32 tmp, val;
> > +
> > +   /* Set the MIPI mode
> > +* If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
> > +* Power ON MIPI IO first and then write into IO reset and LP wake
> bits
> > +*/
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   tmp = I915_READ(MIPI_CTRL(port));
> > +   I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE);
> > +   }
> > +
> > +   /* Put the IO into reset */
> > +   tmp = I915_READ(MIPI_CTRL(PORT_A));
> > +   tmp &= ~GLK_MIPIIO_RESET_RELEASED;
> > +   I915_WRITE(MIPI_CTRL(PORT_A), tmp);
> > +
> > +   /* Program LP Wake */
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   tmp = I915_READ(MIPI_CTRL(port));
> > +   tmp |= GLK_LP_WAKE;
> > +   I915_WRITE(MIPI_CTRL(port), tmp);
> > +   }
> > +
> > +   /* Wait for Pwr ACK */
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   if (intel_wait_for_register(dev_priv,
> > +   MIPI_CTRL(port),
> GLK_MIPIIO_PORT_POWERED,
> > +   GLK_MIPIIO_PORT_POWERED, 20))
> > +   DRM_ERROR("MIPIO port is powergated\n");
> > +   }
> > +
> > +   /* Wait for MIPI PHY status bit to set */
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   if (intel_wait_for_register(dev_priv,
> > +   MIPI_CTRL(port),
> GLK_PHY_STATUS_PORT_READY,
> > +   GLK_PHY_STATUS_PORT_READY, 20))
> > +   DRM_ERROR("PHY is not ON\n");
> > +   }
> > +
> > +   /* Get IO out of reset */
> > +   tmp = I915_READ(MIPI_CTRL(PORT_A));
> > +   I915_WRITE(MIPI_CTRL(PORT_A), tmp |
> GLK_MIPIIO_RESET_RELEASED);
> > +
> > +   /* Get IO out of Low power state*/
> > +   for_each_dsi_port(port, intel_dsi->ports) {
> > +   if (!(I915_READ(MIPI_DEVICE_READY(port)) &
> DEVICE_READY)) {
> > +   val = I915_READ(MIPI_DEVICE_READY(port));
> > +   val &= ~ULPS_STATE_MASK;
> > +   val |= DEVICE_READY;
> > +   I915_WRITE(MIPI_DEVICE_READY(port), val);
> > +   usleep_range(10, 15);
> > +   }
> > +
> > +   /* Enter ULPS */
> > +   val = I915_READ(MIPI_DEVICE_READY(port));
> > +   val &= ~ULPS_STATE_MASK;
> > +   val |= (ULPS_STATE_ENTER | DEVICE_READY);
> > +   I915_WRITE(MIPI_DEVICE_READY(port), val);
> > +
> > +   /* Wait for ULPS Not active */
> > +   if (intel_wait_for_register(dev_priv,
> > +   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> > +   GLK_ULPS_NOT_ACTIVE, 20))
> 
> 
> Auch, I missed this. The if statement covers the next line, and my compiler
> didn't complain. I already pushed this, so please send a follow-up fix on top.

Done. Thanks for capturing this.

> 
> BR,
> Jani.
> 
> > +
> > +   /* Exit ULPS */
> > +   val = I915_READ(MIPI_DEVICE_READY(port));
> > +   val &= ~ULPS_STATE_MASK;
> > +   val |= (ULPS_STATE_EXIT | DEVICE_READY);
> > +   

[Intel-gfx] [PATCH] drm/i915/glk: Fix DSI enable I/O sequence

[Madhav Chauhan]

One of the if statement covers the next line in enable I/O sequence.
This patch correct the same by adding error message.

Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/intel_dsi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 8e97bae3..c92004b 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -425,6 +425,7 @@ static void glk_dsi_device_ready(struct intel_encoder 
*encoder)
if (intel_wait_for_register(dev_priv,
MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
GLK_ULPS_NOT_ACTIVE, 20))
+   DRM_ERROR("ULPS is still active\n");
 
/* Exit ULPS */
val = I915_READ(MIPI_DEVICE_READY(port));
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Make intel_guc_send a function pointer

[Michal Wajdeczko]

On Tue, Feb 07, 2017 at 01:20:35AM -0800, Oscar Mateo wrote:
> From: Michal Wajdeczko 
> 
> Prepare for an alternate GuC communication interface.
> 
> v2: Make a few functions static and name them correctly while we are at it 
> (Oscar)
> v3: Leave an intel_guc_send_mmio interface for users that require old-style 
> communication
> 
> Signed-off-by: Michel Thierry 
> Signed-off-by: Michal Wajdeczko 
> Signed-off-by: Oscar Mateo 
> ---
>  drivers/gpu/drm/i915/intel_uc.c | 25 +++--
>  drivers/gpu/drm/i915/intel_uc.h | 10 +-
>  2 files changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
> index c46bc85..2fa70a9 100644
> --- a/drivers/gpu/drm/i915/intel_uc.c
> +++ b/drivers/gpu/drm/i915/intel_uc.c



> @@ -98,6 +96,14 @@ int intel_guc_send(struct intel_guc *guc, const u32 
> *action, u32 len)
>   return ret;
>  }
>  
> +void intel_uc_init_early(struct drm_i915_private *dev_priv)
> +{
> + struct intel_guc *guc = _priv->guc;
> +
> + mutex_init(>send_mutex);
> + guc->send = intel_guc_send_mmio;
> +}
> +

As intel_guc_send_mmio() is again public, there is no need to move
intel_uc_init_early() down to this place, it can stay at the top
of the file.

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

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"

[Ville Syrjälä]

On Wed, Mar 01, 2017 at 08:18:18PM +0200, Jani Nikula wrote:
> On Wed, 01 Mar 2017, Ville Syrjälä  wrote:
> > On Wed, Mar 01, 2017 at 07:35:15PM +0200, Jani Nikula wrote:
> >> On Wed, 01 Mar 2017, Chris Wilson  wrote:
> >> > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
> >> >> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
> >> >> 
> >> >> I assumed it's ok, but really should have double-checked - CI caught
> >> >> tons of fail :(
> >> 
> >> Considering the velocity of drm-tip, I think any CI results for patches
> >> have a rather limited best before date. The patch should've been resent
> >> and gone through testing again before merging.
> >> 
> >> > For the record, the failure comes from the error message in
> >> > intel_dp_get_link_train_fallback_values() as take the fallback path. As
> >> > userspace is informed, we don't need an *ERROR* at that point.
> >> >
> >> > The really interesting question is why we are seeing link-training
> >> > failures in CI at all, and whether igt should be checking and reporting
> >> > link-status=BAD.
> >> 
> >> It's possible (I didn't check the logs) this pertains to the failure
> >> mode I've sometimes seen, where clock recovery fails, but as we continue
> >> with channel equalization anyway (without this patch), everything
> >> succeeds there. At worst we need to root cause and fix that issue
> >> first. :(
> >
> > The skl case seems pretty clear. We register DP for both port A and port
> > E even though we should register it only for port E (I think). They
> > both end up both using AUX A and so we think the same sink is connected
> > to both, and then we try to enable port A which fail for obvious reasons.
> >
> > The culprit is init_vbt_defaults() which always sets .supports_dp=true
> > for port A unless later overridden by the VBT. In this case the VBT has
> > no port A, so we leave the .supports_dp flag set. So presumably we
> > should just nuke this stuff from init_vbt_defaults().
> >
> > IIRC this was discussed at some point between Imre and Paulo, but I
> > can't remember what the conclusion was, or if in fact there was one.
> 
> I think one idea was simply
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index e144f033f4b5..0261c841756f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1377,10 +1377,6 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
>   _priv->vbt.ddi_port_info[port];
>  
>   info->hdmi_level_shift = HDMI_LEVEL_SHIFT_UNKNOWN;
> -
> - info->supports_dvi = (port != PORT_A && port != PORT_E);
> - info->supports_hdmi = info->supports_dvi;
> - info->supports_dp = (port != PORT_E);
>   }
>  }
>  
> ---
> 
> but apparently it's problematic for machines without VBT, specifically
> some Chromebooks [citation needed].

I guess the other option would to be split this out and do it only when
there's no VBT. Or we could make the VBT parsing code explicitly clear
anything not present in the VBT.

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

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"

[Jani Nikula]

On Wed, 01 Mar 2017, Ville Syrjälä  wrote:
> On Wed, Mar 01, 2017 at 07:35:15PM +0200, Jani Nikula wrote:
>> On Wed, 01 Mar 2017, Chris Wilson  wrote:
>> > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
>> >> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
>> >> 
>> >> I assumed it's ok, but really should have double-checked - CI caught
>> >> tons of fail :(
>> 
>> Considering the velocity of drm-tip, I think any CI results for patches
>> have a rather limited best before date. The patch should've been resent
>> and gone through testing again before merging.
>> 
>> > For the record, the failure comes from the error message in
>> > intel_dp_get_link_train_fallback_values() as take the fallback path. As
>> > userspace is informed, we don't need an *ERROR* at that point.
>> >
>> > The really interesting question is why we are seeing link-training
>> > failures in CI at all, and whether igt should be checking and reporting
>> > link-status=BAD.
>> 
>> It's possible (I didn't check the logs) this pertains to the failure
>> mode I've sometimes seen, where clock recovery fails, but as we continue
>> with channel equalization anyway (without this patch), everything
>> succeeds there. At worst we need to root cause and fix that issue
>> first. :(
>
> The skl case seems pretty clear. We register DP for both port A and port
> E even though we should register it only for port E (I think). They
> both end up both using AUX A and so we think the same sink is connected
> to both, and then we try to enable port A which fail for obvious reasons.
>
> The culprit is init_vbt_defaults() which always sets .supports_dp=true
> for port A unless later overridden by the VBT. In this case the VBT has
> no port A, so we leave the .supports_dp flag set. So presumably we
> should just nuke this stuff from init_vbt_defaults().
>
> IIRC this was discussed at some point between Imre and Paulo, but I
> can't remember what the conclusion was, or if in fact there was one.

I think one idea was simply

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index e144f033f4b5..0261c841756f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1377,10 +1377,6 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
_priv->vbt.ddi_port_info[port];
 
info->hdmi_level_shift = HDMI_LEVEL_SHIFT_UNKNOWN;
-
-   info->supports_dvi = (port != PORT_A && port != PORT_E);
-   info->supports_hdmi = info->supports_dvi;
-   info->supports_dp = (port != PORT_E);
}
 }
 
---

but apparently it's problematic for machines without VBT, specifically
some Chromebooks [citation needed].

Jani.


>
> The ilk failure case is a lot less clear. It's one of those cases
> where the sink just keeps requesting the same vswing/preemph all
> the time. I've seen it sometime in the past, but I've never been
> able to figure out what has caused it to happen with any specific
> sink.

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

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support

[Ville Syrjälä]

On Wed, Mar 01, 2017 at 09:50:56AM -0800, Ben Widawsky wrote:
> On 17-03-01 12:51:17, Ville Syrjälä wrote:
> >On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:
> >> On 17-02-28 12:18:39, Jason Ekstrand wrote:
> >
> >> >I've said it before but reading through Ben's patches again make me want 
> >> >to
> >> >be peskier about it.  I would really like the UABI to treat the CCS as if
> >> >it's Y-tiled with a tile size of 128B x 32 rows.  Why?  Because this is
> >> >what all the docs say it is.  From the display docs for "Color Control
> >> >Surface":
> >> >
> >> >"The Color Control Surface (CCS) contains the compression status of the
> >> >cache-line pairs. The
> >> >compression state of the cache-line pair is specified by 2 bits in the 
> >> >CCS.
> >> >Each CCS cache-line represents
> >> >an area on the main surface of 16 x16 sets of 128 byte Y-tiled
> >> >cache-line-pairs. CCS is always Y tiled."
> >> >
> >> >This contains 95% of the information needed to know the relation between
> >> >the CCS and the main surface.  The other 5% (which is badly documented) is
> >> >that cache line pairs are horizontally adjacent.  This gives a 
> >> >relationship
> >> >of one cache line in the CCS maps to 32x64 cache lines in the main 
> >> >surface.
> >> >
> >> >But it's not actually Y-tiled?  Of course not.  I've worked out the exact
> >> >tiling and it looks something like Y but isn't quite the same.  However,
> >> >this isn't unique to CCS.  Stencil (W-tiled), HiZ, and gen7-8
> >> >single-sampled MCS also each have their own tiling (Haswell MCS is
> >> >especially exotic) but the docs call all of them Y-tiled and I think the
> >> >hardware internally treats them as Y-tiled with the cache lines shuffled
> >> >around a bit.
> >> >
> >> >Given the fact that they seem to like to change the MCS/CCS tiling around
> >> >on every hardware generation, I'm reluctant to base UABI on the fact that
> >> >the CCS appears to have 64x64 "pixels" per tile with each "pixel"
> >> >corresponding to 16x8 pixels in the color surface.  That's not what we had
> >> >on any previous gen and may change on gen10 for no aparent reason.  I'd
> >> >much rather base it on Y-tiling and a relationship between cache lines
> >> >which, even if they change the exact swizzle on gen10, will probably 
> >> >remain
> >> >the same.  (For the gen7-8 analogue of CCS, they changed the tiling every
> >> >generation but the relationship of one MCS cache line maps to 32x128 color
> >> >cache lines remained the same).
> >> >
> >> >Ok, I've said my peice.  If we have to divide by 2 in userspace, we won't
> >> >die, but I'd like to get the UABI right before we chissel it in stone.
> >> >
> >> >--Jason
> >> >
> >> >
> >>
> >> I vote we make the stride in units of tiles when we have the CCS modifier.
> >
> >That won't fly with the KMS API. I suppose I could make the tile 128 bytes
> >wide by swapping the "1 byte == 16x8 pixels" notion with a
> >"1 byte == 8x16 pixels" notion. Doesn't match the actual truth anymore,
> >but I guess no one really cares.
> >
> 
> KMS API goes right out the window with modifiers. Isn't that really the whole
> point of modifiers?

Not in my opinion. It's just a mild extension. The basics still apply
perfectly fine. 

And I really don't want to add special exceptions for CCS since
that'll just mean more code and more bugs. Right now the same code
that works for your typical planar formats works for CCS as well.

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

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"

[Ville Syrjälä]

On Wed, Mar 01, 2017 at 07:35:15PM +0200, Jani Nikula wrote:
> On Wed, 01 Mar 2017, Chris Wilson  wrote:
> > On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
> >> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
> >> 
> >> I assumed it's ok, but really should have double-checked - CI caught
> >> tons of fail :(
> 
> Considering the velocity of drm-tip, I think any CI results for patches
> have a rather limited best before date. The patch should've been resent
> and gone through testing again before merging.
> 
> > For the record, the failure comes from the error message in
> > intel_dp_get_link_train_fallback_values() as take the fallback path. As
> > userspace is informed, we don't need an *ERROR* at that point.
> >
> > The really interesting question is why we are seeing link-training
> > failures in CI at all, and whether igt should be checking and reporting
> > link-status=BAD.
> 
> It's possible (I didn't check the logs) this pertains to the failure
> mode I've sometimes seen, where clock recovery fails, but as we continue
> with channel equalization anyway (without this patch), everything
> succeeds there. At worst we need to root cause and fix that issue
> first. :(

The skl case seems pretty clear. We register DP for both port A and port
E even though we should register it only for port E (I think). They
both end up both using AUX A and so we think the same sink is connected
to both, and then we try to enable port A which fail for obvious reasons.

The culprit is init_vbt_defaults() which always sets .supports_dp=true
for port A unless later overridden by the VBT. In this case the VBT has
no port A, so we leave the .supports_dp flag set. So presumably we
should just nuke this stuff from init_vbt_defaults().

IIRC this was discussed at some point between Imre and Paulo, but I
can't remember what the conclusion was, or if in fact there was one.

The ilk failure case is a lot less clear. It's one of those cases
where the sink just keeps requesting the same vswing/preemph all
the time. I've seen it sometime in the past, but I've never been
able to figure out what has caused it to happen with any specific
sink.

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

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support

[Ben Widawsky]

On 17-03-01 12:51:17, Ville Syrjälä wrote:

On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:

On 17-02-28 12:18:39, Jason Ekstrand wrote:



>I've said it before but reading through Ben's patches again make me want to
>be peskier about it.  I would really like the UABI to treat the CCS as if
>it's Y-tiled with a tile size of 128B x 32 rows.  Why?  Because this is
>what all the docs say it is.  From the display docs for "Color Control
>Surface":
>
>"The Color Control Surface (CCS) contains the compression status of the
>cache-line pairs. The
>compression state of the cache-line pair is specified by 2 bits in the CCS.
>Each CCS cache-line represents
>an area on the main surface of 16 x16 sets of 128 byte Y-tiled
>cache-line-pairs. CCS is always Y tiled."
>
>This contains 95% of the information needed to know the relation between
>the CCS and the main surface.  The other 5% (which is badly documented) is
>that cache line pairs are horizontally adjacent.  This gives a relationship
>of one cache line in the CCS maps to 32x64 cache lines in the main surface.
>
>But it's not actually Y-tiled?  Of course not.  I've worked out the exact
>tiling and it looks something like Y but isn't quite the same.  However,
>this isn't unique to CCS.  Stencil (W-tiled), HiZ, and gen7-8
>single-sampled MCS also each have their own tiling (Haswell MCS is
>especially exotic) but the docs call all of them Y-tiled and I think the
>hardware internally treats them as Y-tiled with the cache lines shuffled
>around a bit.
>
>Given the fact that they seem to like to change the MCS/CCS tiling around
>on every hardware generation, I'm reluctant to base UABI on the fact that
>the CCS appears to have 64x64 "pixels" per tile with each "pixel"
>corresponding to 16x8 pixels in the color surface.  That's not what we had
>on any previous gen and may change on gen10 for no aparent reason.  I'd
>much rather base it on Y-tiling and a relationship between cache lines
>which, even if they change the exact swizzle on gen10, will probably remain
>the same.  (For the gen7-8 analogue of CCS, they changed the tiling every
>generation but the relationship of one MCS cache line maps to 32x128 color
>cache lines remained the same).
>
>Ok, I've said my peice.  If we have to divide by 2 in userspace, we won't
>die, but I'd like to get the UABI right before we chissel it in stone.
>
>--Jason
>
>

I vote we make the stride in units of tiles when we have the CCS modifier.


That won't fly with the KMS API. I suppose I could make the tile 128 bytes
wide by swapping the "1 byte == 16x8 pixels" notion with a
"1 byte == 8x16 pixels" notion. Doesn't match the actual truth anymore,
but I guess no one really cares.



KMS API goes right out the window with modifiers. Isn't that really the whole
point of modifiers?



>> +   /* fall through */
>> case I915_FORMAT_MOD_Yf_TILED:
>> /*
>>  * Bspec seems to suggest that the Yf tile width would
>> @@ -2156,7 +2164,7 @@ static unsigned int intel_surf_alignment(const
>> struct drm_framebuffer *fb,
>> struct drm_i915_private *dev_priv = to_i915(fb->dev);
>>
>> /* AUX_DIST needs only 4K alignment */
>> -   if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
>> +   if (plane == 1)
>> return 4096;
>>
>> switch (fb->modifier) {
>> @@ -2166,6 +2174,8 @@ static unsigned int intel_surf_alignment(const
>> struct drm_framebuffer *fb,
>> if (INTEL_GEN(dev_priv) >= 9)
>> return 256 * 1024;
>> return 0;
>> +   case I915_FORMAT_MOD_Y_TILED_CCS:
>> +   case I915_FORMAT_MOD_Yf_TILED_CCS:
>> case I915_FORMAT_MOD_Y_TILED:
>> case I915_FORMAT_MOD_Yf_TILED:
>> return 1 * 1024 * 1024;
>> @@ -2472,6 +2482,7 @@ static unsigned int 
intel_fb_modifier_to_tiling(uint64_t
>> fb_modifier)
>> case I915_FORMAT_MOD_X_TILED:
>> return I915_TILING_X;
>> case I915_FORMAT_MOD_Y_TILED:
>> +   case I915_FORMAT_MOD_Y_TILED_CCS:
>> return I915_TILING_Y;
>> default:
>> return I915_TILING_NONE;
>> @@ -2536,6 +2547,35 @@ intel_fill_fb_info(struct drm_i915_private
>> *dev_priv,
>>
>> intel_fb_offset_to_xy(, , fb, i);
>>
>> +   if ((fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
>> +fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) && i ==
>> 1) {
>> +   int main_x, main_y;
>> +   int ccs_x, ccs_y;
>> +
>> +   /*
>> +* Each byte of CCS corresponds to a 16x8 area of
>> the main surface, and
>> +* each CCS tile is 64x64 bytes.
>> +*/
>> +   ccs_x = (x * 16) % (64 * 16);
>> +   ccs_y = (y * 8) % (64 * 8);
>> +   main_x = intel_fb->normal[0].x % (64 * 16);
>> + 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Fix all intel_framebuffer_init failures to take the error path

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915: Fix all intel_framebuffer_init 
failures to take the error path
URL   : https://patchwork.freedesktop.org/series/20464/
State : success

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-bxt-t5700)

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:192  dwarn:36  dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:216  dwarn:44  dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

12f8718b2eefb0b48145ab3f797f6cab46138ddf drm-tip: 2017y-03m-01d-16h-02m-25s UTC 
integration manifest
8355f20 drm/i915: Prevent concurrent tiling/framebuffer modifications
ced8b38 drm/i915: Fix all intel_framebuffer_init failures to take the error path

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4018/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Use BUILD_BUG_ON to detected missing engine definitions

[Michal Wajdeczko]

Engine related definitions are located in different files
and it is easy to break their cross dependency.

Additionally use GEM_WARN_ON to catch invalid engine index.

v2: compare against array size

Signed-off-by: Michal Wajdeczko 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index a238304..c1f58b5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -84,11 +84,16 @@ static const struct engine_info {
 
 static int
 intel_engine_setup(struct drm_i915_private *dev_priv,
-  enum intel_engine_id id)
+  unsigned int id)
 {
const struct engine_info *info = _engines[id];
struct intel_engine_cs *engine;
 
+   BUILD_BUG_ON(ARRAY_SIZE(intel_engines) !=
+ARRAY_SIZE(dev_priv->engine));
+   if (GEM_WARN_ON(id >= ARRAY_SIZE(intel_engines)))
+   return -EINVAL;
+
GEM_BUG_ON(dev_priv->engine[id]);
engine = kzalloc(sizeof(*engine), GFP_KERNEL);
if (!engine)
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"

[Jani Nikula]

On Wed, 01 Mar 2017, Jani Nikula  wrote:
> On Wed, 01 Mar 2017, Chris Wilson  wrote:
>> On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
>>> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
>>> 
>>> I assumed it's ok, but really should have double-checked - CI caught
>>> tons of fail :(
>
> Considering the velocity of drm-tip, I think any CI results for patches
> have a rather limited best before date. The patch should've been resent
> and gone through testing again before merging.
>
>> For the record, the failure comes from the error message in
>> intel_dp_get_link_train_fallback_values() as take the fallback path. As
>> userspace is informed, we don't need an *ERROR* at that point.
>>
>> The really interesting question is why we are seeing link-training
>> failures in CI at all, and whether igt should be checking and reporting
>> link-status=BAD.
>
> It's possible (I didn't check the logs) this pertains to the failure
> mode I've sometimes seen, where clock recovery fails, but as we continue
> with channel equalization anyway (without this patch), everything
> succeeds there. At worst we need to root cause and fix that issue
> first. :(

Also, possibly to "avoid noise" in CI, the relevant error messages in
intel_dp_link_training_clock_recovery() have been brushed under the
carpet by demoting them to DRM_DEBUG_KMS, so we don't really see this
happening unless we actually eyeball the logs.

>
> BR,
> Jani.

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

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"

[Jani Nikula]

On Wed, 01 Mar 2017, Chris Wilson  wrote:
> On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
>> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
>> 
>> I assumed it's ok, but really should have double-checked - CI caught
>> tons of fail :(

Considering the velocity of drm-tip, I think any CI results for patches
have a rather limited best before date. The patch should've been resent
and gone through testing again before merging.

> For the record, the failure comes from the error message in
> intel_dp_get_link_train_fallback_values() as take the fallback path. As
> userspace is informed, we don't need an *ERROR* at that point.
>
> The really interesting question is why we are seeing link-training
> failures in CI at all, and whether igt should be checking and reporting
> link-status=BAD.

It's possible (I didn't check the logs) this pertains to the failure
mode I've sometimes seen, where clock recovery fails, but as we continue
with channel equalization anyway (without this patch), everything
succeeds there. At worst we need to root cause and fix that issue
first. :(

BR,
Jani.


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

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"

[Chris Wilson]

On Wed, Mar 01, 2017 at 06:17:49PM +0100, Daniel Vetter wrote:
> This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.
> 
> I assumed it's ok, but really should have double-checked - CI caught
> tons of fail :(

For the record, the failure comes from the error message in
intel_dp_get_link_train_fallback_values() as take the fallback path. As
userspace is informed, we don't need an *ERROR* at that point.

The really interesting question is why we are seeing link-training
failures in CI at all, and whether igt should be checking and reporting
link-status=BAD.
-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] Revert "drm/i915: Implement Link Rate fallback on Link training failure"

[Daniel Vetter]

This reverts commit 233ce881dd91fb13eb6b09deefae33168e6ead4c.

I assumed it's ok, but really should have double-checked - CI caught
tons of fail :(

Cc: Jani Nikula 
Cc: Manasi Navare 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c   | 27 ---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 22 ++
 drivers/gpu/drm/i915/intel_drv.h  |  3 ---
 3 files changed, 2 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index af07a830fa95..d1670b8afbf5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5790,29 +5790,6 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
return false;
 }
 
-static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
-{
-   struct intel_connector *intel_connector;
-   struct drm_connector *connector;
-
-   intel_connector = container_of(work, typeof(*intel_connector),
-  modeset_retry_work);
-   connector = _connector->base;
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
- connector->name);
-
-   /* Grab the locks before changing connector property*/
-   mutex_lock(>dev->mode_config.mutex);
-   /* Set connector link status to BAD and send a Uevent to notify
-* userspace to do a modeset.
-*/
-   drm_mode_connector_set_link_status_property(connector,
-   DRM_MODE_LINK_STATUS_BAD);
-   mutex_unlock(>dev->mode_config.mutex);
-   /* Send Hotplug uevent so userspace can reprobe */
-   drm_kms_helper_hotplug_event(connector->dev);
-}
-
 bool
 intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector)
@@ -5825,10 +5802,6 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
enum port port = intel_dig_port->port;
int type;
 
-   /* Initialize the work for modeset in case of link train failure */
-   INIT_WORK(_connector->modeset_retry_work,
- intel_dp_modeset_retry_work_fn);
-
if (WARN(intel_dig_port->max_lanes < 1,
 "Not enough lanes (%d) for DP on port %c\n",
 intel_dig_port->max_lanes, port_name(port)))
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 955b239e7c2d..0048b520baf7 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -313,24 +313,6 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
 void
 intel_dp_start_link_train(struct intel_dp *intel_dp)
 {
-   struct intel_connector *intel_connector = intel_dp->attached_connector;
-
-   if (!intel_dp_link_training_clock_recovery(intel_dp))
-   goto failure_handling;
-   if (!intel_dp_link_training_channel_equalization(intel_dp))
-   goto failure_handling;
-
-   DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane count = %d",
- intel_dp->link_rate, intel_dp->lane_count);
-   return;
-
- failure_handling:
-   DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane count = %d",
- intel_dp->link_rate, intel_dp->lane_count);
-   if (!intel_dp_get_link_train_fallback_values(intel_dp,
-intel_dp->link_rate,
-intel_dp->lane_count))
-   /* Schedule a Hotplug Uevent to userspace to start modeset */
-   schedule_work(_connector->modeset_retry_work);
-   return;
+   intel_dp_link_training_clock_recovery(intel_dp);
+   intel_dp_link_training_channel_equalization(intel_dp);
 }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6c6abc932726..3b797909f631 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -316,9 +316,6 @@ struct intel_connector {
void *port; /* store this opaque as its illegal to dereference it */
 
struct intel_dp *mst_port;
-
-   /* Work struct to schedule a uevent on link train failure */
-   struct work_struct modeset_retry_work;
 };
 
 struct dpll {
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH i-g-t v2] lib: Define a common bit operations library

[Chris Wilson]

On Wed, Mar 01, 2017 at 07:52:26AM -0800, Michel Thierry wrote:
> Bring the test/set/clear bit functions we have into a single place.
> 
> v2: Add gtk-doc comment blocks (Daniel)

Hiss, boo! Will someone take gtk-doc and bury it? -flto to save the day?
-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] drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

[Ville Syrjälä]

On Wed, Mar 01, 2017 at 04:07:02PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote:
> > Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
> > 1.1.
> > 
> > When a sink that supports deep color is connected to the output, the
> > receiver will send EDIDs that advertise this capability, even if it
> > isn't possible with HDMI versions earlier than 1.3.
> > 
> > Currently the kernel is assuming that deep color is possible and the
> > sink displays an error.
> > 
> > This quirk will make sure that deep color isn't used with this
> > particular receiver.
> > 
> > Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=99869
> > Signed-off-by: Tomeu Vizoso 
> 
> Cc: sta...@vger.kernel.org
> Cc: Matt Horan 
> Tested-by: Matt Horan 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869
> Reviewed-by: Ville Syrjälä 

And pushed to drm-misc-fixes. Thanks for the patch/testing/bug report
etc.

> 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 24e7b282f16c..d994ccf94f88 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -148,6 +148,9 @@ static const struct edid_quirk {
> >  
> > /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
> > { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
> > +
> > +   /* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
> > +   { "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
> >  };
> >  
> >  /*
> > -- 
> > 2.9.3
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH i-g-t v2] lib: Define a common bit operations library

[Michel Thierry]

Bring the test/set/clear bit functions we have into a single place.

v2: Add gtk-doc comment blocks (Daniel)

Cc: Daniel Vetter 
Reviewed-by: Joonas Lahtinen  (v1)
Signed-off-by: Michel Thierry 
---
 .../intel-gpu-tools/intel-gpu-tools-docs.xml   |   1 +
 lib/Makefile.sources   |   2 +
 lib/igt.h  |   1 +
 lib/igt_bitops.c   | 112 +
 lib/igt_bitops.h   |  46 +
 lib/igt_primes.c   |  25 +
 6 files changed, 163 insertions(+), 24 deletions(-)
 create mode 100644 lib/igt_bitops.c
 create mode 100644 lib/igt_bitops.h

diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml 
b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
index 990bbb80..0fc51508 100644
--- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
+++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
@@ -25,6 +25,7 @@
 
 
 
+
 
 
 
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 6348487f..801312c6 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -11,6 +11,8 @@ lib_source_list = \
igt_debugfs.h   \
igt_aux.c   \
igt_aux.h   \
+   igt_bitops.c\
+   igt_bitops.h\
igt_edid_template.h \
igt_gt.c\
igt_gt.h\
diff --git a/lib/igt.h b/lib/igt.h
index 4f54698d..7a8942aa 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -28,6 +28,7 @@
 #include "i915_3d.h"
 #include "i915_pciids.h"
 #include "igt_aux.h"
+#include "igt_bitops.h"
 #include "igt_core.h"
 #include "igt_debugfs.h"
 #include "igt_draw.h"
diff --git a/lib/igt_bitops.c b/lib/igt_bitops.c
new file mode 100644
index ..12d8b532
--- /dev/null
+++ b/lib/igt_bitops.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright 2017 Intel Corporation
+ * All Rights Reserved.
+ *
+ * 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, sub license, 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 
+
+/**
+ * SECTION:igt_bitops
+ * @short_description: Useful bit operations, based on kernel functions.
+ * @title: bitops
+ * @include: igt.h
+ *
+ * This library provides functions to set/clear/test bits in a given memory
+ * location.
+ */
+
+/**
+ * set_bit:
+ * @nr: The bit to set
+ * @addr: The address to start counting from
+ *
+ * Set a bit in memory.
+ *
+ */
+void set_bit(unsigned long nr, unsigned long *addr)
+{
+   addr[nr / BITS_PER_LONG] |= __bit__(nr);
+}
+
+/**
+ * clear_bit:
+ * @nr: The bit to clear
+ * @addr: The address to start counting from
+ *
+ * Clear a bit in memory.
+ *
+ */
+void clear_bit(unsigned long nr, unsigned long *addr)
+{
+   addr[nr / BITS_PER_LONG] &= ~__bit__(nr);
+}
+
+/**
+ * test_bit:
+ * @nr: The bit to test
+ * @addr: The address to start counting from
+ *
+ * Determine whether a bit is set.
+ *
+ * Returns:
+ * True if bit was set, false otherwise.
+ */
+bool test_bit(unsigned long nr, const unsigned long *addr)
+{
+   return addr[nr / BITS_PER_LONG] & __bit__(nr);
+}
+
+/**
+ * test_and_set_bit:
+ * @nr: The bit to set
+ * @addr: The address to start counting from
+ *
+ * Set a bit and return its old value.
+ *
+ * Returns:
+ * The bit previous value.
+ */
+bool test_and_set_bit(unsigned long nr, unsigned long *addr)
+{
+   bool ret = test_bit(nr, addr);
+   set_bit(nr, addr);
+   return ret;
+}
+
+/**
+ * test_and_clear_bit:
+ * @nr: The bit to clear
+ * @addr: The address to start counting from
+ *
+ * Clear a bit and return its old value.
+ *
+ * Returns:
+ * The bit previous value.
+ */
+bool test_and_clear_bit(unsigned long nr, unsigned long *addr)
+{
+   bool ret = test_bit(nr, addr);
+   clear_bit(nr, addr);
+   

[Intel-gfx] ✓ Fi.CI.BAT: success for Try to fix MST regression with DDI IO power domains (rev2)

[Patchwork]

== Series Details ==

Series: Try to fix MST regression with DDI IO power domains (rev2)
URL   : https://patchwork.freedesktop.org/series/20345/
State : success

== Summary ==

Series 20345v2 Try to fix MST regression with DDI IO power domains
https://patchwork.freedesktop.org/api/1.0/series/20345/revisions/2/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

77db4e1f75f54471bf2fbebf114b2ba9c2d3bca7 drm-tip: 2017y-03m-01d-14h-59m-18s UTC 
integration manifest
b859863 drm/i915: Remove duplicate DDI enabling logic from MST path
881dbd6 drm/i915: Remove direct usages of intel_crtc->config from DDI code
16be05c drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable
aa0aa86 drm/i915: Pass pipe_config to fdi_link_train() functions
1f09668 drm/i915: Pass pipe_config to pch_enable() functions
ec11fe2 drm/i915: Pass intel_crtc to intel_lpt_pch_enable()
ccc54cd drm/i915: Pass intel_crtc to fdi_link_train() hooks
c371ce1 drm/i915: Enable DDI IO power domains in the DP MST path

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4016/
___
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: Prevent concurrent tiling/framebuffer modifications

[Chris Wilson]

On Wed, Mar 01, 2017 at 03:09:36PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 28, 2017 at 04:22:33PM +, Chris Wilson wrote:
> > Reintroduce a lock around tiling vs framebuffer creation to prevent
> > modification of the obj->tiling_and_stride whilst the framebuffer is
> > being created. Rather than use struct_mutex once again, use the
> > per-object lock - this will also be required in future to prevent
> > changing the tiling whilst submitting rendering.
> > 
> > Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating 
> > the framebuffer")
> > Signed-off-by: Chris Wilson 
> > Cc: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_object.h   | 18 +-
> >  drivers/gpu/drm/i915/i915_gem_shrinker.c |  2 +-
> >  drivers/gpu/drm/i915/i915_gem_tiling.c   |  9 -
> >  drivers/gpu/drm/i915/intel_display.c | 25 -
> >  4 files changed, 42 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
> > b/drivers/gpu/drm/i915/i915_gem_object.h
> > index ad1bc0b1a0c2..8c02c8ec2a3b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> > @@ -169,7 +169,7 @@ struct drm_i915_gem_object {
> > struct reservation_object *resv;
> >  
> > /** References from framebuffers, locks out tiling changes. */
> > -   atomic_t framebuffer_references;
> > +   unsigned int framebuffer_references;
> >  
> > /** Record of address bit 17 of each page at last unbind. */
> > unsigned long *bit_17;
> > @@ -263,6 +263,16 @@ extern void drm_gem_object_unreference(struct 
> > drm_gem_object *);
> >  __deprecated
> >  extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *);
> >  
> > +static inline void i915_gem_object_lock(struct drm_i915_gem_object *obj)
> > +{
> > +   reservation_object_lock(obj->resv, NULL);
> > +}
> > +
> > +static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj)
> > +{
> > +   reservation_object_unlock(obj->resv);
> > +}
> > +
> >  static inline bool
> >  i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj)
> >  {
> > @@ -303,6 +313,12 @@ i915_gem_object_clear_active_reference(struct 
> > drm_i915_gem_object *obj)
> >  
> >  void __i915_gem_object_release_unless_active(struct drm_i915_gem_object 
> > *obj);
> >  
> > +static inline bool
> > +i915_gem_object_is_framebuffer(const struct drm_i915_gem_object *obj)
> > +{
> > +   return READ_ONCE(obj->framebuffer_references);
> > +}
> > +
> >  static inline unsigned int
> >  i915_gem_object_get_tiling(struct drm_i915_gem_object *obj)
> >  {
> > diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
> > b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > index 7e3bb48e043e..630697001b38 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > @@ -210,7 +210,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
> >  
> > if (!(flags & I915_SHRINK_ACTIVE) &&
> > (i915_gem_object_is_active(obj) ||
> > -atomic_read(>framebuffer_references)))
> > +i915_gem_object_is_framebuffer(obj)))
> > continue;
> >  
> > if (!can_release_pages(obj))
> > diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
> > b/drivers/gpu/drm/i915/i915_gem_tiling.c
> > index c1d669e32f41..ad5e05f6b836 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
> > @@ -238,7 +238,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object 
> > *obj,
> > if ((tiling | stride) == obj->tiling_and_stride)
> > return 0;
> >  
> > -   if (atomic_read(>framebuffer_references))
> > +   if (i915_gem_object_is_framebuffer(obj))
> > return -EBUSY;
> >  
> > /* We need to rebind the object if its current allocation
> > @@ -258,6 +258,12 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object 
> > *obj,
> > if (err)
> > return err;
> >  
> > +   i915_gem_object_lock(obj);
> > +   if (i915_gem_object_is_framebuffer(obj)) {
> > +   i915_gem_object_unlock(obj);
> > +   return -EBUSY;
> > +   }
> > +
> > /* If the memory has unknown (i.e. varying) swizzling, we pin the
> >  * pages to prevent them being swapped out and causing corruption
> >  * due to the change in swizzling.
> > @@ -294,6 +300,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object 
> > *obj,
> > }
> >  
> > obj->tiling_and_stride = tiling | stride;
> > +   i915_gem_object_unlock(obj);
> >  
> > /* Force the fence to be reacquired for GTT access */
> > i915_gem_release_mmap(obj);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 77936ddd860a..62a1e628e399 100644
> > --- 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement Link Rate fallback on Link training failure

[Daniel Vetter]

On Fri, Dec 16, 2016 at 12:29:07PM +0200, Jani Nikula wrote:
> From: Manasi Navare 
> 
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
> to "BAD" and use a lower link rate to prune the modes. It will redo
> the modeset on the current mode at lower link rate or if the current
> mode gets pruned due to lower link constraints then, it will send a
> hotplug uevent for userspace to handle it.
> 
> This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> 4.3.1.6.
> 
> v9:
> * Use the trimmed max values of link rate/lane count based on
> link train fallback (Daniel Vetter)
> v8:
> * Set link_status to BAD first and then call mode_valid (Jani Nikula)
> v7:
> Remove the redundant variable in previous patch itself
> v6:
> * Obtain link rate index from fallback_link_rate using
> the helper intel_dp_link_rate_index (Jani Nikula)
> * Include fallback within intel_dp_start_link_train (Jani Nikula)
> v5:
> * Move set link status to drm core (Daniel Vetter, Jani Nikula)
> v4:
> * Add fallback support for non DDI platforms too
> * Set connector->link status inside set_link_status function
> (Jani Nikula)
> v3:
> * Set link status property to BAd unconditionally (Jani Nikula)
> * Dont use two separate variables link_train_failed and link_status
> to indicate same thing (Jani Nikula)
> v2:
> * Squashed a few patches (Jani Nikula)
> 
> Acked-by: Tony Cheng 
> Acked-by: Harry Wentland 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> Reviewed-by: Jani Nikula 
> Signed-off-by: Jani Nikula 

Pushed to drm-misc-next after a quick irc chat with Manasi.

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_dp.c   | 27 
> +++
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 22 --
>  drivers/gpu/drm/i915/intel_drv.h  |  3 +++
>  3 files changed, 50 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 45ebc9632633..97d1e03d22b8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5671,6 +5671,29 @@ static bool intel_edp_init_connector(struct intel_dp 
> *intel_dp,
>   return false;
>  }
>  
> +static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> +{
> + struct intel_connector *intel_connector;
> + struct drm_connector *connector;
> +
> + intel_connector = container_of(work, typeof(*intel_connector),
> +modeset_retry_work);
> + connector = _connector->base;
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> +   connector->name);
> +
> + /* Grab the locks before changing connector property*/
> + mutex_lock(>dev->mode_config.mutex);
> + /* Set connector link status to BAD and send a Uevent to notify
> +  * userspace to do a modeset.
> +  */
> + drm_mode_connector_set_link_status_property(connector,
> + DRM_MODE_LINK_STATUS_BAD);
> + mutex_unlock(>dev->mode_config.mutex);
> + /* Send Hotplug uevent so userspace can reprobe */
> + drm_kms_helper_hotplug_event(connector->dev);
> +}
> +
>  bool
>  intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
>   struct intel_connector *intel_connector)
> @@ -5683,6 +5706,10 @@ intel_dp_init_connector(struct intel_digital_port 
> *intel_dig_port,
>   enum port port = intel_dig_port->port;
>   int type;
>  
> + /* Initialize the work for modeset in case of link train failure */
> + INIT_WORK(_connector->modeset_retry_work,
> +   intel_dp_modeset_retry_work_fn);
> +
>   if (WARN(intel_dig_port->max_lanes < 1,
>"Not enough lanes (%d) for DP on port %c\n",
>intel_dig_port->max_lanes, port_name(port)))
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 0048b520baf7..955b239e7c2d 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -313,6 +313,24 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp)
>  void
>  intel_dp_start_link_train(struct intel_dp *intel_dp)
>  {
> - intel_dp_link_training_clock_recovery(intel_dp);
> - intel_dp_link_training_channel_equalization(intel_dp);
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> +
> + if (!intel_dp_link_training_clock_recovery(intel_dp))
> +   

[Intel-gfx] [CI 2/2] drm/i915: Prevent concurrent tiling/framebuffer modifications

[Chris Wilson]

Reintroduce a lock around tiling vs framebuffer creation to prevent
modification of the obj->tiling_and_stride whilst the framebuffer is
being created. Rather than use struct_mutex once again, use the
per-object lock - this will also be required in future to prevent
changing the tiling whilst submitting rendering.

Reported-by: Ville Syrjälä 
Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating the 
framebuffer")
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem_object.h   | 18 +-
 drivers/gpu/drm/i915/i915_gem_shrinker.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c   |  9 -
 drivers/gpu/drm/i915/intel_display.c | 25 -
 4 files changed, 42 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
b/drivers/gpu/drm/i915/i915_gem_object.h
index cce63b225746..33b0dc4782a9 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -165,7 +165,7 @@ struct drm_i915_gem_object {
struct reservation_object *resv;
 
/** References from framebuffers, locks out tiling changes. */
-   atomic_t framebuffer_references;
+   unsigned int framebuffer_references;
 
/** Record of address bit 17 of each page at last unbind. */
unsigned long *bit_17;
@@ -260,6 +260,16 @@ extern void drm_gem_object_unreference(struct 
drm_gem_object *);
 __deprecated
 extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *);
 
+static inline void i915_gem_object_lock(struct drm_i915_gem_object *obj)
+{
+   reservation_object_lock(obj->resv, NULL);
+}
+
+static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj)
+{
+   reservation_object_unlock(obj->resv);
+}
+
 static inline bool
 i915_gem_object_is_dead(const struct drm_i915_gem_object *obj)
 {
@@ -306,6 +316,12 @@ i915_gem_object_clear_active_reference(struct 
drm_i915_gem_object *obj)
 
 void __i915_gem_object_release_unless_active(struct drm_i915_gem_object *obj);
 
+static inline bool
+i915_gem_object_is_framebuffer(const struct drm_i915_gem_object *obj)
+{
+   return READ_ONCE(obj->framebuffer_references);
+}
+
 static inline unsigned int
 i915_gem_object_get_tiling(struct drm_i915_gem_object *obj)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 8bc515e8b2a2..006a8b908f77 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -207,7 +207,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
 
if (!(flags & I915_SHRINK_ACTIVE) &&
(i915_gem_object_is_active(obj) ||
-atomic_read(>framebuffer_references)))
+i915_gem_object_is_framebuffer(obj)))
continue;
 
if (!can_release_pages(obj))
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 46ade36dcee6..a0d6d4317a49 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -238,7 +238,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
if ((tiling | stride) == obj->tiling_and_stride)
return 0;
 
-   if (atomic_read(>framebuffer_references))
+   if (i915_gem_object_is_framebuffer(obj))
return -EBUSY;
 
/* We need to rebind the object if its current allocation
@@ -258,6 +258,12 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
if (err)
return err;
 
+   i915_gem_object_lock(obj);
+   if (i915_gem_object_is_framebuffer(obj)) {
+   i915_gem_object_unlock(obj);
+   return -EBUSY;
+   }
+
/* If the memory has unknown (i.e. varying) swizzling, we pin the
 * pages to prevent them being swapped out and causing corruption
 * due to the change in swizzling.
@@ -294,6 +300,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
}
 
obj->tiling_and_stride = tiling | stride;
+   i915_gem_object_unlock(obj);
 
/* Force the fence to be reacquired for GTT access */
i915_gem_release_mmap(obj);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f8ef03003a65..99e8d9c8d60b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14186,7 +14186,10 @@ static void intel_user_framebuffer_destroy(struct 
drm_framebuffer *fb)
 
drm_framebuffer_cleanup(fb);
 
-   WARN_ON(atomic_dec_return(_fb->obj->framebuffer_references) < 0);
+   i915_gem_object_lock(intel_fb->obj);
+   

[Intel-gfx] [CI 1/2] drm/i915: Fix all intel_framebuffer_init failures to take the error path

[Chris Wilson]

No more direct return -EINVAL as we have to unwind the
obj->framebuffer_references.

Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating the 
framebuffer")
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7673d5d9e74a..f8ef03003a65 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14314,7 +14314,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
if (INTEL_INFO(dev_priv)->gen < 4 &&
tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
DRM_DEBUG("tiling_mode must match fb modifier exactly on 
gen2/3\n");
-   return -EINVAL;
+   goto err;
}
 
stride_alignment = intel_fb_stride_alignment(dev_priv,
@@ -14359,7 +14359,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
if (INTEL_GEN(dev_priv) > 3) {
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
break;
case DRM_FORMAT_ABGR:
@@ -14367,7 +14367,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
INTEL_GEN(dev_priv) < 9) {
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
break;
case DRM_FORMAT_XBGR:
@@ -14376,14 +14376,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
if (INTEL_GEN(dev_priv) < 4) {
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
break;
case DRM_FORMAT_ABGR2101010:
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
break;
case DRM_FORMAT_YUYV:
@@ -14393,13 +14393,13 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
if (INTEL_GEN(dev_priv) < 5) {
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
break;
default:
DRM_DEBUG("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-   return -EINVAL;
+   goto err;
}
 
/* FIXME need to adjust LINOFF/TILEOFF accordingly. */
@@ -14412,7 +14412,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
 
ret = intel_fill_fb_info(dev_priv, _fb->base);
if (ret)
-   return ret;
+   goto err;
 
ret = drm_framebuffer_init(obj->base.dev,
   _fb->base,
-- 
2.11.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: Complain if we take too long under vblank evasion.

[Ville Syrjälä]

On Tue, Feb 28, 2017 at 03:28:48PM +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 27e0752d1578..375ca91b308c 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -65,6 +65,8 @@ int intel_usecs_to_scanlines(const struct drm_display_mode 
> *adjusted_mode,
>   1000 * adjusted_mode->crtc_htotal);
>  }
>  
> +#define VBLANK_EVASION_TIME_US 100
> +
>  /**
>   * intel_pipe_update_start() - start update of a set of display registers
>   * @crtc: the crtc of which the registers are going to be updated
> @@ -92,7 +94,8 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
>   vblank_start = DIV_ROUND_UP(vblank_start, 2);
>  
>   /* FIXME needs to be calibrated sensibly */
> - min = vblank_start - intel_usecs_to_scanlines(adjusted_mode, 100);
> + min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> +   VBLANK_EVASION_TIME_US);
>   max = vblank_start - 1;
>  
>   local_irq_disable();
> @@ -191,7 +194,12 @@ void intel_pipe_update_end(struct intel_crtc *crtc, 
> struct intel_flip_work *work
> ktime_us_delta(end_vbl_time, 
> crtc->debug.start_vbl_time),
> crtc->debug.min_vbl, crtc->debug.max_vbl,
> crtc->debug.scanline_start, scanline_end);
> - }
> + } else if (ktime_us_delta(end_vbl_time, crtc->debug.start_vbl_time) >
> +VBLANK_EVASION_TIME_US)
> + DRM_WARN("Atomic update on pipe (%c) took %lld us, max time 
> under evasion is %u us\n",
> +  pipe_name(pipe),
> +  ktime_us_delta(end_vbl_time, 
> crtc->debug.start_vbl_time),
> +  VBLANK_EVASION_TIME_US);

Hmm. Yeah this should make it very likely that we'll catch any
potential fails even when they don't happen to hit the actual critical
section. Hopefully it won't result in massive amounts of noise. One way
to find out ;)

Reviewed-by: Ville Syrjälä 

>  }
>  
>  static void
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move updating color management to before vblank evasion

[Ville Syrjälä]

On Tue, Feb 28, 2017 at 05:01:25PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 28, 2017 at 03:28:47PM +0100, Maarten Lankhorst wrote:
> > This cannot be done reliably during vblank evasasion
> > since the color management registers are not double buffered.
> > 
> > The original commit that moved it always during vblank evasion was
> > wrong, so revert it to before vblank evasion again.
> > 
> > Signed-off-by: Maarten Lankhorst 
> > Fixes: 20a34e78f0d7 ("drm/i915: Update color management during vblank 
> > evasion.")
> > Cc: sta...@vger.kernel.org # v4.7+
> 
> Wasn't there a bugzilla + tested-by ?

Seems we have two bugzillas now:
https://bugs.freedesktop.org/show_bug.cgi?id=91883
https://bugs.freedesktop.org/show_bug.cgi?id=1

First one is about the atomic update fails, the second about
the assert_dsi_pll() mutex vs. irq_disabled() warning.

No actual t-bs for this specific variant of the patch (yet)
from what I can see.

Anyways, this is 
Reviewed-by: Ville Syrjälä 

> 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 12 +++-
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 3c862d0ab389..a0108041fd4a 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13301,17 +13301,19 @@ static void intel_begin_crtc_commit(struct 
> > drm_crtc *crtc,
> > to_intel_atomic_state(old_crtc_state->state);
> > bool modeset = needs_modeset(crtc->state);
> >  
> > +   if (!modeset &&
> > +   (intel_cstate->base.color_mgmt_changed ||
> > +intel_cstate->update_pipe)) {
> > +   intel_color_set_csc(crtc->state);
> > +   intel_color_load_luts(crtc->state);
> > +   }
> > +
> > /* Perform vblank evasion around commit operation */
> > intel_pipe_update_start(intel_crtc);
> >  
> > if (modeset)
> > goto out;
> >  
> > -   if (crtc->state->color_mgmt_changed || 
> > to_intel_crtc_state(crtc->state)->update_pipe) {
> > -   intel_color_set_csc(crtc->state);
> > -   intel_color_load_luts(crtc->state);
> > -   }
> > -
> > if (intel_cstate->update_pipe)
> > intel_update_pipe_config(intel_crtc, old_intel_cstate);
> > else if (INTEL_GEN(dev_priv) >= 9)
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 18/18] drm/i915: Add FIFO underrun tracepoints

[Maarten Lankhorst]

Op 16-02-17 om 19:07 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä 
>
> Add tracepoints for display FIFO underruns. Makes it more convenient to
> correlate the underruns with other display tracepoints.
I'm still not sold on how crtc_state->visible_planes deviates from 
crtc_state->planes_mask and other *_mask's.

Should probably rename it to visible_plane_id_mask to make it clear it's a mask 
not using drm_plane_index.

Otherwise looks good,

so for the whole series:

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

Re: [Intel-gfx] [PATCH v5 5/6] drm/i915: enable scrambling

[Ville Syrjälä]

On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
> 
> This patch checks if the monitor supports scrambling, and if required,
> enables it during the modeset.
> 
> V2: Addressed review comments from Ville:
> - Do not track scrambling status in DRM layer, track somewhere in
>   driver like in intel_crtc_state.
> - Don't talk to monitor at such a low layer, set monitor scrambling
>   in intel_enable_ddi() before enabling the port.
> 
> V3: Addressed review comments from Jani
>  - In comments, function names, use "sink" instead of "monitor",
>so that the implementation could be close to the language of
>HDMI spec.
> 
> V4: Addressed review comment from Maarten
>  - scrambling -> hdmi_scrambling
>high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
> 
> V5: Addressed review comments from Ville and Ander
>  - Do not modifiy the crtc_state after compute_config. Move all
>scrambling and tmds_clock_ratio calcutations to compute_config.
>  - While setting scrambling for source/sink, do not check the
>conditions again, just go by the crtc_state flags. This will
>simplyfy the condition checks.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/i915_reg.h   |  4 ++
>  drivers/gpu/drm/i915/intel_ddi.c  | 29 
>  drivers/gpu/drm/i915/intel_drv.h  | 14 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 98 
> +++
>  4 files changed, 145 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ce6f096..1759b64 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7824,7 +7824,11 @@ enum {
>  #define  TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
>  #define  TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
>  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC   (1<<8)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
> +#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
>  #define  TRANS_DDI_BFI_ENABLE(1<<4)
> +#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE   (1<<4)
> +#define  TRANS_DDI_HDMI_SCRAMBLING   (1<<0)
>  
>  /* DisplayPort Transport Control */
>  #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index a7c08d7..24bc3a8 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1311,6 +1311,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
> *crtc)
>   temp |= TRANS_DDI_MODE_SELECT_HDMI;
>   else
>   temp |= TRANS_DDI_MODE_SELECT_DVI;
> +
> + if (IS_GEMINILAKE(dev_priv))
> + temp = intel_hdmi_handle_source_scrambling(
> + intel_encoder,
> + intel_crtc->config, temp);
>   } else if (type == INTEL_OUTPUT_ANALOG) {
>   temp |= TRANS_DDI_MODE_SELECT_FDI;
>   temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> @@ -1885,6 +1890,21 @@ static void intel_enable_ddi(struct intel_encoder 
> *intel_encoder,
>   struct intel_digital_port *intel_dig_port =
>   enc_to_dig_port(encoder);
>  
> + if (IS_GEMINILAKE(dev_priv)) {
> + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> + /*
> +  * GLK sports a native HDMI 2.0 controller. If required
> +  * clock rate is > 340 Mhz && scrambling is supported
> +  * by sink, enable scrambling before enabling the
> +  * HDMI 2.0 port. The sink can choose to disable the
> +  * scrambling if it doesn't detect a scrambled within
> +  * 100 ms.
> +  */
> + intel_hdmi_handle_sink_scrambling(intel_encoder,
> + conn_state->connector,
> + crtc->config, true);
> + }
> +
>   /* In HDMI/DVI mode, the port width, and swing/emphasis values
>* are ignored so nothing special needs to be done besides
>* enabling the port.
> @@ -1912,11 +1932,20 @@ static void intel_disable_ddi(struct intel_encoder 
> *intel_encoder,
> struct drm_connector_state *old_conn_state)
>  {
>   struct drm_encoder *encoder = _encoder->base;
> + struct drm_i915_private *dev_priv = encoder->dev->dev_private;
>   int type = intel_encoder->type;
>  
>   if (old_crtc_state->has_audio)
>   intel_audio_codec_disable(intel_encoder);
>  
> + if ((type == INTEL_OUTPUT_HDMI) && IS_GEMINILAKE(dev_priv)) {
 

Re: [Intel-gfx] [PATCH] drm: Fix the kernel doc warning for drm_link_status

[Daniel Vetter]

On Wed, Mar 01, 2017 at 06:45:10AM -0800, Manasi Navare wrote:
> This fixes the kernel doc warning that was introduced in
> the 'commit 40ee6fbef75fe6 ("drm: Add a new connector
> atomic property for link status")'. Description has
> been added for the enum values.
> 
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: dri-de...@lists.freedesktop.org

Thanks for the quick fix, applied.
-Daniel

> ---
>  include/drm/drm_connector.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ccc0770..fabb35a 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -94,6 +94,11 @@ enum subpixel_order {
>   *
>   * This enum is used as the connector's link status property value.
>   * It is set to the values defined in uapi.
> + *
> + * @DRM_LINK_STATUS_GOOD: DP Link is Good as a result of successful
> + *link training
> + * @DRM_LINK_STATUS_BAD: DP Link is BAD as a result of link training
> + *   failure
>   */
>  enum drm_link_status {
>   DRM_LINK_STATUS_GOOD = DRM_MODE_LINK_STATUS_GOOD,
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v5 4/6] drm/edid: detect SCDC support in HF-VSDB

[Ville Syrjälä]

On Tue, Feb 28, 2017 at 02:09:08PM +0530, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
>   This structure will be used to save and indicate if sink
>   supports advanced HDMI 2.0 features
> - Adds another structure drm_scdc within drm_hdmi_info, to
>   reflect scdc support and capabilities in connected HDMI 2.0 sink.
> - Checks the HF-VSDB block for presence of SCDC, and marks it
>   in scdc structure
> - If SCDC is present, checks if sink is capable of generating
>   SCDC read request, and marks it in scdc structure.
> 
> V2: Addressed review comments
>   Thierry:
>   - Fix typos in commit message and make abbreviation consistent
> across the commit message.
>   - Change structure object name from hdmi_info -> hdmi
>   - Fix typos and abbreviations in description of structure drm_hdmi_info
> end the description with a full stop.
>   - Create a structure drm_scdc, and keep all information related to SCDC
> register set (supported, read request supported) etc in it.
> 
>   Ville:
>   - Change rr -> read_request
>   - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
> of HF-VSDB parsing can be kept in same function, in incremental
> patches.
> 
> V3: Rebase.
> V4: Rebase.
> V5: Rebase.
> 
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_edid.c|  33 +++-
>  drivers/gpu/drm/drm_scdc_helper.c | 111 
> ++
>  include/drm/drm_connector.h   |  19 +++
>  include/drm/drm_edid.h|   6 ++-
>  include/drm/drm_scdc_helper.h |  27 ++
>  5 files changed, 194 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0881108..e84c5ab 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  
> @@ -3817,13 +3818,43 @@ enum hdmi_quantization_range
>  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
>const u8 *hf_vsdb)
>  {
> - struct drm_hdmi_info *hdmi = >display_info.hdmi;
> + struct drm_display_info *display = >display_info;
> + struct drm_hdmi_info *hdmi = >hdmi;
>  
>   if (hf_vsdb[6] & 0x80) {
>   hdmi->scdc.supported = true;
>   if (hf_vsdb[6] & 0x40)
>   hdmi->scdc.read_request = true;
>   }
> +
> + /*
> +  * All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
> +  * And as per the spec, three factors confirm this:
> +  * * Availability of a HF-VSDB block in EDID (check)
> +  * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
> +  * * SCDC support available (let's check)
> +  * Lets check it out.
> +  */
> +
> + if (hf_vsdb[5]) {
> + /* max clock is 5000 KHz times block value */
> + u32 max_tmds_clock = hf_vsdb[5] * 5000;
> + struct drm_scdc *scdc = >scdc;
> +
> + if (max_tmds_clock > 34) {
> + display->max_tmds_clock = max_tmds_clock;
> + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> + display->max_tmds_clock);
> + }
> +
> + if (scdc->supported) {
> + scdc->scrambling.supported = true;
> +
> + /* Few sinks support scrambling for cloks < 340M */
> + if ((hf_vsdb[6] & 0x8))
> + scdc->scrambling.low_rates = true;
> + }
> + }
>  }
>  
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
> b/drivers/gpu/drm/drm_scdc_helper.c
> index c2dd33f..180a7cd 100644
> --- a/drivers/gpu/drm/drm_scdc_helper.c
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -22,8 +22,10 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include 
> +#include 
>  
>  /**
>   * DOC: scdc helpers
> @@ -121,3 +123,112 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8 
> offset,
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_scdc_write);
> +
> +/**
> + * drm_scdc_check_scrambling_status - what is status of scrambling?
> + * @adapter: I2C adapter for DDC channel
> + *
> + * Reads the scrambler status over SCDC, and checks the
> + * scrambling status.
> + *
> + * Returns:
> + * True if the scrambling is enabled, false otherwise.
> + */
> +
> +bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter)
> +{
> + u8 status;
> + int ret;
> +
> + ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, );
> + if (ret < 0) {
> + DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
> + return false;
> + }
> +
> + return status & 

[Intel-gfx] [PATCH] drm: Fix the kernel doc warning for drm_link_status

[Manasi Navare]

This fixes the kernel doc warning that was introduced in
the 'commit 40ee6fbef75fe6 ("drm: Add a new connector
atomic property for link status")'. Description has
been added for the enum values.

Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drm_connector.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ccc0770..fabb35a 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -94,6 +94,11 @@ enum subpixel_order {
  *
  * This enum is used as the connector's link status property value.
  * It is set to the values defined in uapi.
+ *
+ * @DRM_LINK_STATUS_GOOD: DP Link is Good as a result of successful
+ *link training
+ * @DRM_LINK_STATUS_BAD: DP Link is BAD as a result of link training
+ *   failure
  */
 enum drm_link_status {
DRM_LINK_STATUS_GOOD = DRM_MODE_LINK_STATUS_GOOD,
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915: Pass pipe_config to pch_enable() functions

[Ville Syrjälä]

On Wed, Mar 01, 2017 at 04:13:14PM +0200, Ander Conselvan de Oliveira wrote:
> Using crtc->config directly is being removed in favor of passing a
> pipe_config. Follow the trend and pass pipe_config to pch_enable()
> functions.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 45415f0..aea302b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4456,7 +4456,8 @@ intel_trans_dp_port_sel(struct intel_crtc *crtc)
>   *   - DP transcoding bits
>   *   - transcoder
>   */
> -static void ironlake_pch_enable(struct intel_crtc *crtc)
> +static void ironlake_pch_enable(struct intel_crtc *crtc,
> + struct intel_crtc_state *pipe_config)

const

Also s/pipe_config/crtc_state/ perhaps? IMO we should try to start
unifying our naming convention to reduce the confusion a bit.

You could also pass just the state since you can dig up the crtc from
there.

>  {
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -4484,7 +4485,7 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
>   temp = I915_READ(PCH_DPLL_SEL);
>   temp |= TRANS_DPLL_ENABLE(pipe);
>   sel = TRANS_DPLLB_SEL(pipe);
> - if (crtc->config->shared_dpll ==
> + if (pipe_config->shared_dpll ==
>   intel_get_shared_dpll_by_id(dev_priv, DPLL_ID_PCH_PLL_B))
>   temp |= sel;
>   else
> @@ -4509,9 +4510,9 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
>  
>   /* For PCH DP, enable TRANS_DP_CTL */
>   if (HAS_PCH_CPT(dev_priv) &&
> - intel_crtc_has_dp_encoder(crtc->config)) {
> + intel_crtc_has_dp_encoder(pipe_config)) {
>   const struct drm_display_mode *adjusted_mode =
> - >config->base.adjusted_mode;
> + _config->base.adjusted_mode;
>   u32 bpc = (I915_READ(PIPECONF(pipe)) & PIPECONF_BPC_MASK) >> 5;
>   i915_reg_t reg = TRANS_DP_CTL(pipe);
>   temp = I915_READ(reg);
> @@ -4546,10 +4547,11 @@ static void ironlake_pch_enable(struct intel_crtc 
> *crtc)
>   ironlake_enable_pch_transcoder(dev_priv, pipe);
>  }
>  
> -static void lpt_pch_enable(struct intel_crtc *crtc)
> +static void lpt_pch_enable(struct intel_crtc *crtc,
> +struct intel_crtc_state *pipe_config)

ditto

Anyway looks correct, so w/ or w/o the extra ideas this is
Reviewed-by: Ville Syrjälä 

>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
> + enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
>  
>   assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
>  
> @@ -5283,7 +5285,7 @@ static void ironlake_crtc_enable(struct 
> intel_crtc_state *pipe_config,
>   intel_enable_pipe(intel_crtc);
>  
>   if (intel_crtc->config->has_pch_encoder)
> - ironlake_pch_enable(intel_crtc);
> + ironlake_pch_enable(intel_crtc, pipe_config);
>  
>   assert_vblank_disabled(crtc);
>   drm_crtc_vblank_on(crtc);
> @@ -5393,7 +5395,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
> *pipe_config,
>   intel_enable_pipe(intel_crtc);
>  
>   if (intel_crtc->config->has_pch_encoder)
> - lpt_pch_enable(intel_crtc);
> + lpt_pch_enable(intel_crtc, pipe_config);
>  
>   if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
>   intel_ddi_set_vc_payload_alloc(crtc, true);
> -- 
> 2.9.3

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

Re: [Intel-gfx] [GLK MIPI DSI V7] drm/i915/glk: Add MIPIIO Enable/disable sequence

[Jani Nikula]

On Wed, 01 Mar 2017, Madhav Chauhan  wrote:
> From: Deepak M 
>
> v2: Addressed Jani's Review comments(renamed bit field macros)
> v3: Jani's Review comment for aligning code to platforms and added
> wrapper functions.
> v4: Corrected enable/disable seuqence as per BSPEC
> v5: Corrected waiting twice for same bit (Review comments: Jani)
> v6: Rebased to Han's patches(dsi restructuring code)
>
> Signed-off-by: Deepak M 
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 206 
> ---
>  1 file changed, 195 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 20ed799..8e97bae3 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -357,6 +357,109 @@ static bool intel_dsi_compute_config(struct 
> intel_encoder *encoder,
>   return true;
>  }
>  
> +static void glk_dsi_device_ready(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> + enum port port;
> + u32 tmp, val;
> +
> + /* Set the MIPI mode
> +  * If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
> +  * Power ON MIPI IO first and then write into IO reset and LP wake bits
> +  */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(MIPI_CTRL(port));
> + I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE);
> + }
> +
> + /* Put the IO into reset */
> + tmp = I915_READ(MIPI_CTRL(PORT_A));
> + tmp &= ~GLK_MIPIIO_RESET_RELEASED;
> + I915_WRITE(MIPI_CTRL(PORT_A), tmp);
> +
> + /* Program LP Wake */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(MIPI_CTRL(port));
> + tmp |= GLK_LP_WAKE;
> + I915_WRITE(MIPI_CTRL(port), tmp);
> + }
> +
> + /* Wait for Pwr ACK */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED,
> + GLK_MIPIIO_PORT_POWERED, 20))
> + DRM_ERROR("MIPIO port is powergated\n");
> + }
> +
> + /* Wait for MIPI PHY status bit to set */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_PHY_STATUS_PORT_READY,
> + GLK_PHY_STATUS_PORT_READY, 20))
> + DRM_ERROR("PHY is not ON\n");
> + }
> +
> + /* Get IO out of reset */
> + tmp = I915_READ(MIPI_CTRL(PORT_A));
> + I915_WRITE(MIPI_CTRL(PORT_A), tmp | GLK_MIPIIO_RESET_RELEASED);
> +
> + /* Get IO out of Low power state*/
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY)) {
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= DEVICE_READY;
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> + usleep_range(10, 15);
> + }
> +
> + /* Enter ULPS */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_ENTER | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> +
> + /* Wait for ULPS Not active */
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> + GLK_ULPS_NOT_ACTIVE, 20))


Auch, I missed this. The if statement covers the next line, and my
compiler didn't complain. I already pushed this, so please send a
follow-up fix on top.

BR,
Jani.

> +
> + /* Exit ULPS */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_EXIT | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> +
> + /* Enter Normal Mode */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> +
> + tmp = I915_READ(MIPI_CTRL(port));
> + tmp &= ~GLK_LP_WAKE;
> + I915_WRITE(MIPI_CTRL(port), tmp);
> + }
> +
> + /* Wait for Stop state */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_DATA_LANE_STOP_STATE,
> + 

[Intel-gfx] [PATCH v2 1/8] drm/i915: Enable DDI IO power domains in the DP MST path

[Ander Conselvan de Oliveira]

Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after
enabling DPLL") changed how the DDI IO power domains get enabled, but
neglected the need to enable those domains when enabling a DP connector
with MST enabled, leading to

Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast 
exception handler

Fixes: 62b695662a24 ("drm/i915: Only enable DDI IO power domains after enabling 
DPLL")
Cc: David Weinehall 
Cc: Imre Deak 
Cc: Ander Conselvan de Oliveira 
Cc: David Weinehall 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Cc: Ville Syrjälä 
Reported-by: Ville Syrjälä 
Signed-off-by: Ander Conselvan de Oliveira 

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

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index d94fd4b..a8334e1 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -163,6 +163,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
intel_ddi_clk_select(_dig_port->base,
 pipe_config->shared_dpll);
 
+   intel_display_power_get(dev_priv,
+   intel_dig_port->ddi_io_power_domain);
+
intel_prepare_dp_ddi_buffers(_dig_port->base);
intel_dp_set_link_params(intel_dp,
 pipe_config->port_clock,
-- 
2.9.3

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

[Intel-gfx] [PATCH v2 8/8] drm/i915: Remove duplicate DDI enabling logic from MST path

[Ander Conselvan de Oliveira]

The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
by calling the post_disable hook on the intel_dig_port instead of
duplicating that code.

v2: Don't oops because of a NULL encoder->crtc. (Ville)
Cc: Imre Deak 
Cc: Ville Syrjälä 
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_ddi.c|  2 ++
 drivers/gpu/drm/i915/intel_dp_mst.c | 23 +++
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2f26c75..208500a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1714,6 +1714,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
enum port port = intel_ddi_get_encoder_port(encoder);
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
 
+   WARN_ON(link_mst && port == PORT_A);
+
intel_dp_set_link_params(intel_dp, link_rate, lane_count,
 link_mst);
if (encoder->type == INTEL_OUTPUT_EDP)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index a8334e1..094cbdc 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -159,26 +159,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
 
-   if (intel_dp->active_mst_links == 0) {
-   intel_ddi_clk_select(_dig_port->base,
-pipe_config->shared_dpll);
-
-   intel_display_power_get(dev_priv,
-   intel_dig_port->ddi_io_power_domain);
-
-   intel_prepare_dp_ddi_buffers(_dig_port->base);
-   intel_dp_set_link_params(intel_dp,
-pipe_config->port_clock,
-pipe_config->lane_count,
-true);
-
-   intel_ddi_init_dp_buf_reg(_dig_port->base);
-
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-
-   intel_dp_start_link_train(intel_dp);
-   intel_dp_stop_link_train(intel_dp);
-   }
+   if (intel_dp->active_mst_links == 0)
+   intel_dig_port->base.pre_enable(_dig_port->base,
+   pipe_config, NULL);
 
ret = drm_dp_mst_allocate_vcpi(_dp->mst_mgr,
   connector->port,
-- 
2.9.3

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

Re: [Intel-gfx] kbl_guc and bxt_guc firmware missing from linux-firmware

[Seth Forshee]

On Wed, Mar 01, 2017 at 03:23:06PM +0200, Jani Nikula wrote:
> On Wed, 15 Feb 2017, Seth Forshee  wrote:
> > Maybe it would be good to have something like MODULE_OPTIONAL_FIRMWARE
> > to identify firmware that isn't required but will be used by the driver
> > if available. Then mkinitramfs can try to copy those files along with
> > the module but know that there's no need to produce a warning if it's
> > not present.
> 
> The documentation for the current MODULE_FIRMWARE already says,
> "Optional firmware file (or files) needed by the module format is simply
> firmware file name."

That may have been the intention. But since it is the only thing
available it has been used for any firmware files, including many which
will cause device probe to fail if not present. Userspace tools seem to
treat the firmware files in modinfo to mean, "firmware files without
which the hardware may fail to function or may not function properly,"
because in many cases that is true. I'd argue that this is the de facto
definition of MODULE_FIRMWARE, and that the comment is at best
misleading.

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

Re: [Intel-gfx] [PATCH i-g-t 3/8] lib: Define a common bit operations library

[Michel Thierry]

On 2/27/2017 1:35 AM, Daniel Vetter wrote:

On Thu, Feb 09, 2017 at 09:34:49AM +0200, Joonas Lahtinen wrote:

On ke, 2017-02-08 at 18:18 -0800, Michel Thierry wrote:

Bring the test/set/clear bit functions we have into a single place.

Signed-off-by: Michel Thierry 


Reviewed-by: Joonas Lahtinen 


Can we please have docs for this new library?



Sure; although they won't be static (or just a .h file) anymore.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 5/8] drm/i915: Pass pipe_config to fdi_link_train() functions

[Ander Conselvan de Oliveira]

It is preferred to pass pipe_config to functions instead of accessing
crtc->config directly. Follow suit and pass pipe_config to the fdi link
train functions.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
 drivers/gpu/drm/i915/intel_ddi.c |  9 +
 drivers/gpu/drm/i915/intel_display.c | 19 +++
 drivers/gpu/drm/i915/intel_drv.h |  3 ++-
 4 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8b11cdf..82d3d16 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -669,7 +669,8 @@ struct drm_i915_display_funcs {
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
void (*audio_codec_disable)(struct intel_encoder *encoder);
-   void (*fdi_link_train)(struct intel_crtc *crtc);
+   void (*fdi_link_train)(struct intel_crtc *crtc,
+  struct intel_crtc_state *pipe_config);
void (*init_clock_gating)(struct drm_i915_private *dev_priv);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 111f660..ccff024 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -674,7 +674,8 @@ static uint32_t hsw_pll_to_ddi_pll_sel(struct 
intel_shared_dpll *pll)
  * DDI A (which is used for eDP)
  */
 
-void hsw_fdi_link_train(struct intel_crtc *crtc)
+void hsw_fdi_link_train(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -700,7 +701,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
/* Enable the PCH Receiver FDI PLL */
rx_ctl_val = dev_priv->fdi_rx_config | FDI_RX_ENHANCE_FRAME_ENABLE |
 FDI_RX_PLL_ENABLE |
-FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
+FDI_DP_PORT_WIDTH(pipe_config->fdi_lanes);
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
POSTING_READ(FDI_RX_CTL(PIPE_A));
udelay(220);
@@ -710,7 +711,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
 
/* Configure Port Clock Select */
-   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc->config->shared_dpll);
+   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(pipe_config->shared_dpll);
I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
 
@@ -730,7 +731,7 @@ void hsw_fdi_link_train(struct intel_crtc *crtc)
 * port reversal bit */
I915_WRITE(DDI_BUF_CTL(PORT_E),
   DDI_BUF_CTL_ENABLE |
-  ((crtc->config->fdi_lanes - 1) << 1) |
+  ((pipe_config->fdi_lanes - 1) << 1) |
   DDI_BUF_TRANS_SELECT(i / 2));
POSTING_READ(DDI_BUF_CTL(PORT_E));
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index aea302b..16822ef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3689,7 +3689,8 @@ static void intel_fdi_normal_train(struct intel_crtc 
*crtc)
 }
 
 /* The FDI link training functions for ILK/Ibexpeak. */
-static void ironlake_fdi_link_train(struct intel_crtc *crtc)
+static void ironlake_fdi_link_train(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3714,7 +3715,7 @@ static void ironlake_fdi_link_train(struct intel_crtc 
*crtc)
reg = FDI_TX_CTL(pipe);
temp = I915_READ(reg);
temp &= ~FDI_DP_PORT_WIDTH_MASK;
-   temp |= FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
+   temp |= FDI_DP_PORT_WIDTH(pipe_config->fdi_lanes);
temp &= ~FDI_LINK_TRAIN_NONE;
temp |= FDI_LINK_TRAIN_PATTERN_1;
I915_WRITE(reg, temp | FDI_TX_ENABLE);
@@ -3789,7 +3790,8 @@ static const int snb_b_fdi_train_param[] = {
 };
 
 /* The FDI link training functions for SNB/Cougarpoint. */
-static void gen6_fdi_link_train(struct intel_crtc *crtc)
+static void gen6_fdi_link_train(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3812,7 +3814,7 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc)
reg = FDI_TX_CTL(pipe);
temp = I915_READ(reg);
temp &= ~FDI_DP_PORT_WIDTH_MASK;
-   temp 

[Intel-gfx] [PATCH v2 7/8] drm/i915: Remove direct usages of intel_crtc->config from DDI code

[Ander Conselvan de Oliveira]

Remove direct usages of intel_crtc->config from the DDI code. Functions
that didn't yet take a pipe_config as an argument were coverted to do
so.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_ddi.c | 61 +++-
 drivers/gpu/drm/i915/intel_display.c | 12 +++
 drivers/gpu/drm/i915/intel_drv.h | 16 +++---
 3 files changed, 49 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 5e21bb5..2f26c75 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1193,11 +1193,12 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc,
  intel_encoder);
 }
 
-void intel_ddi_set_pipe_settings(struct intel_crtc *crtc)
+void intel_ddi_set_pipe_settings(struct intel_crtc *crtc,
+struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
int type = intel_encoder->type;
uint32_t temp;
 
@@ -1205,7 +1206,7 @@ void intel_ddi_set_pipe_settings(struct intel_crtc *crtc)
WARN_ON(transcoder_is_dsi(cpu_transcoder));
 
temp = TRANS_MSA_SYNC_CLK;
-   switch (crtc->config->pipe_bpp) {
+   switch (pipe_config->pipe_bpp) {
case 18:
temp |= TRANS_MSA_6_BPC;
break;
@@ -1225,10 +1226,12 @@ void intel_ddi_set_pipe_settings(struct intel_crtc 
*crtc)
}
 }
 
-void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc, bool state)
+void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config,
+   bool state)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
uint32_t temp;
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (state == true)
@@ -1238,12 +1241,13 @@ void intel_ddi_set_vc_payload_alloc(struct intel_crtc 
*crtc, bool state)
I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
 }
 
-void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc)
+void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc,
+ struct intel_crtc_state *pipe_config)
 {
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
uint32_t temp;
@@ -1252,7 +1256,7 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc 
*crtc)
temp = TRANS_DDI_FUNC_ENABLE;
temp |= TRANS_DDI_SELECT_PORT(port);
 
-   switch (crtc->config->pipe_bpp) {
+   switch (pipe_config->pipe_bpp) {
case 18:
temp |= TRANS_DDI_BPC_6;
break;
@@ -1269,9 +1273,9 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc 
*crtc)
BUG();
}
 
-   if (crtc->config->base.adjusted_mode.flags & DRM_MODE_FLAG_PVSYNC)
+   if (pipe_config->base.adjusted_mode.flags & DRM_MODE_FLAG_PVSYNC)
temp |= TRANS_DDI_PVSYNC;
-   if (crtc->config->base.adjusted_mode.flags & DRM_MODE_FLAG_PHSYNC)
+   if (pipe_config->base.adjusted_mode.flags & DRM_MODE_FLAG_PHSYNC)
temp |= TRANS_DDI_PHSYNC;
 
if (cpu_transcoder == TRANSCODER_EDP) {
@@ -1282,8 +1286,8 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc 
*crtc)
 * using motion blur mitigation (which we don't
 * support). */
if (IS_HASWELL(dev_priv) &&
-   (crtc->config->pch_pfit.enabled ||
-crtc->config->pch_pfit.force_thru))
+   (pipe_config->pch_pfit.enabled ||
+pipe_config->pch_pfit.force_thru))
temp |= TRANS_DDI_EDP_INPUT_A_ONOFF;
else
temp |= TRANS_DDI_EDP_INPUT_A_ON;
@@ -1301,20 +1305,20 @@ void intel_ddi_enable_transcoder_func(struct intel_crtc 
*crtc)
}
 
if (type == INTEL_OUTPUT_HDMI) {
-   if (crtc->config->has_hdmi_sink)

[Intel-gfx] [PATCH v2 3/8] drm/i915: Pass intel_crtc to intel_lpt_pch_enable()

[Ander Conselvan de Oliveira]

The function intel_lpt_pch_enable() needs an intel_crtc so pass that
instead of the generic crtc type.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_display.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c627f7e..45415f0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4250,10 +4250,10 @@ void lpt_disable_iclkip(struct drm_i915_private 
*dev_priv)
 }
 
 /* Program iCLKIP clock to the desired frequency */
-static void lpt_program_iclkip(struct drm_crtc *crtc)
+static void lpt_program_iclkip(struct intel_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   int clock = to_intel_crtc(crtc)->config->base.adjusted_mode.crtc_clock;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   int clock = crtc->config->base.adjusted_mode.crtc_clock;
u32 divsel, phaseinc, auxdiv, phasedir = 0;
u32 temp;
 
@@ -4546,19 +4546,17 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
ironlake_enable_pch_transcoder(dev_priv, pipe);
 }
 
-static void lpt_pch_enable(struct drm_crtc *crtc)
+static void lpt_pch_enable(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
 
assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
 
lpt_program_iclkip(crtc);
 
/* Set transcoder timing. */
-   ironlake_pch_transcoder_set_timings(intel_crtc, PIPE_A);
+   ironlake_pch_transcoder_set_timings(crtc, PIPE_A);
 
lpt_enable_pch_transcoder(dev_priv, cpu_transcoder);
 }
@@ -5395,7 +5393,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   lpt_pch_enable(crtc);
+   lpt_pch_enable(intel_crtc);
 
if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(crtc, true);
-- 
2.9.3

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

[Intel-gfx] [PATCH v2 2/8] drm/i915: Pass intel_crtc to fdi_link_train() hooks

[Ander Conselvan de Oliveira]

The implementation of the fdi_link_train() hooks need an intel_crtc so
just pass that instead of the generic crtc type.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/intel_ddi.c | 13 
 drivers/gpu/drm/i915/intel_display.c | 63 +---
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 4 files changed, 37 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bc9283b..8b11cdf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -669,7 +669,7 @@ struct drm_i915_display_funcs {
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
void (*audio_codec_disable)(struct intel_encoder *encoder);
-   void (*fdi_link_train)(struct drm_crtc *crtc);
+   void (*fdi_link_train)(struct intel_crtc *crtc);
void (*init_clock_gating)(struct drm_i915_private *dev_priv);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a7c08d7..111f660 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -674,15 +674,14 @@ static uint32_t hsw_pll_to_ddi_pll_sel(struct 
intel_shared_dpll *pll)
  * DDI A (which is used for eDP)
  */
 
-void hsw_fdi_link_train(struct drm_crtc *crtc)
+void hsw_fdi_link_train(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
+   struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *encoder;
u32 temp, i, rx_ctl_val, ddi_pll_sel;
 
-   for_each_encoder_on_crtc(dev, crtc, encoder) {
+   for_each_encoder_on_crtc(dev, >base, encoder) {
WARN_ON(encoder->type != INTEL_OUTPUT_ANALOG);
intel_prepare_dp_ddi_buffers(encoder);
}
@@ -701,7 +700,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
/* Enable the PCH Receiver FDI PLL */
rx_ctl_val = dev_priv->fdi_rx_config | FDI_RX_ENHANCE_FRAME_ENABLE |
 FDI_RX_PLL_ENABLE |
-FDI_DP_PORT_WIDTH(intel_crtc->config->fdi_lanes);
+FDI_DP_PORT_WIDTH(crtc->config->fdi_lanes);
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
POSTING_READ(FDI_RX_CTL(PIPE_A));
udelay(220);
@@ -711,7 +710,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), rx_ctl_val);
 
/* Configure Port Clock Select */
-   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(intel_crtc->config->shared_dpll);
+   ddi_pll_sel = hsw_pll_to_ddi_pll_sel(crtc->config->shared_dpll);
I915_WRITE(PORT_CLK_SEL(PORT_E), ddi_pll_sel);
WARN_ON(ddi_pll_sel != PORT_CLK_SEL_SPLL);
 
@@ -731,7 +730,7 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
 * port reversal bit */
I915_WRITE(DDI_BUF_CTL(PORT_E),
   DDI_BUF_CTL_ENABLE |
-  ((intel_crtc->config->fdi_lanes - 1) << 1) |
+  ((crtc->config->fdi_lanes - 1) << 1) |
   DDI_BUF_TRANS_SELECT(i / 2));
POSTING_READ(DDI_BUF_CTL(PORT_E));
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7673d5d..c627f7e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3647,12 +3647,11 @@ static void intel_update_pipe_config(struct intel_crtc 
*crtc,
}
 }
 
-static void intel_fdi_normal_train(struct drm_crtc *crtc)
+static void intel_fdi_normal_train(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
+   struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   int pipe = intel_crtc->pipe;
+   int pipe = crtc->pipe;
i915_reg_t reg;
u32 temp;
 
@@ -3690,12 +3689,11 @@ static void intel_fdi_normal_train(struct drm_crtc 
*crtc)
 }
 
 /* The FDI link training functions for ILK/Ibexpeak. */
-static void ironlake_fdi_link_train(struct drm_crtc *crtc)
+static void ironlake_fdi_link_train(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
+   struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   int pipe = intel_crtc->pipe;
+   int pipe = crtc->pipe;
i915_reg_t reg;
u32 temp, tries;
 
@@ -3716,7 +3714,7 @@ static void ironlake_fdi_link_train(struct drm_crtc 

[Intel-gfx] [PATCH v2 0/8] Try to fix MST regression with DDI IO power domains

[Ander Conselvan de Oliveira]

Hi,

Here's a v2 of the fix for the regression caused by the recent DDI IO
power domain changes. This time with moar patches and actual testing.
The new patches remove the usage of crtc->config from intel_ddi.c and
that also removes the oops with encoder->crtc being NULL.

Ander Conselvan de Oliveira (8):
  drm/i915: Enable DDI IO power domains in the DP MST path
  drm/i915: Pass intel_crtc to fdi_link_train() hooks
  drm/i915: Pass intel_crtc to intel_lpt_pch_enable()
  drm/i915: Pass pipe_config to pch_enable() functions
  drm/i915: Pass pipe_config to fdi_link_train() functions
  drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable
  drm/i915: Remove direct usages of intel_crtc->config from DDI code
  drm/i915: Remove duplicate DDI enabling logic from MST path

 drivers/gpu/drm/i915/i915_drv.h  |   3 +-
 drivers/gpu/drm/i915/intel_ddi.c | 103 +--
 drivers/gpu/drm/i915/intel_display.c | 100 +-
 drivers/gpu/drm/i915/intel_dp_mst.c  |  20 +--
 drivers/gpu/drm/i915/intel_drv.h |  19 +--
 5 files changed, 117 insertions(+), 128 deletions(-)

-- 
2.9.3

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

[Intel-gfx] [PATCH v2 6/8] drm/i915: Pass intel_crtc to DDI functions called from crtc en/disable

[Ander Conselvan de Oliveira]

Pass intel_crtc to functions intel_ddi_enable_transcoder_func(),
intel_ddi_set_pipe_settings() and intel_ddi_set_vc_payload_alloc(),
instead of the generic crtc type. By changing the functions
intel_ddi_get_crtc_encoder() so that it receives an intel_crtc
parameter, there is no need for the drm_crtc in the callers.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_ddi.c | 62 
 drivers/gpu/drm/i915/intel_display.c |  8 ++---
 drivers/gpu/drm/i915/intel_drv.h |  6 ++--
 3 files changed, 34 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ccff024..5e21bb5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -818,21 +818,20 @@ void intel_ddi_init_dp_buf_reg(struct intel_encoder 
*encoder)
 }
 
 static struct intel_encoder *
-intel_ddi_get_crtc_encoder(struct drm_crtc *crtc)
+intel_ddi_get_crtc_encoder(struct intel_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_device *dev = crtc->base.dev;
struct intel_encoder *intel_encoder, *ret = NULL;
int num_encoders = 0;
 
-   for_each_encoder_on_crtc(dev, crtc, intel_encoder) {
+   for_each_encoder_on_crtc(dev, >base, intel_encoder) {
ret = intel_encoder;
num_encoders++;
}
 
if (num_encoders != 1)
WARN(1, "%d encoders on crtc for pipe %c\n", num_encoders,
-pipe_name(intel_crtc->pipe));
+pipe_name(crtc->pipe));
 
BUG_ON(ret == NULL);
return ret;
@@ -1194,12 +1193,11 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc,
  intel_encoder);
 }
 
-void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
+void intel_ddi_set_pipe_settings(struct intel_crtc *crtc)
 {
-   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
int type = intel_encoder->type;
uint32_t temp;
 
@@ -1207,7 +1205,7 @@ void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
WARN_ON(transcoder_is_dsi(cpu_transcoder));
 
temp = TRANS_MSA_SYNC_CLK;
-   switch (intel_crtc->config->pipe_bpp) {
+   switch (crtc->config->pipe_bpp) {
case 18:
temp |= TRANS_MSA_6_BPC;
break;
@@ -1227,12 +1225,10 @@ void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
}
 }
 
-void intel_ddi_set_vc_payload_alloc(struct drm_crtc *crtc, bool state)
+void intel_ddi_set_vc_payload_alloc(struct intel_crtc *crtc, bool state)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
uint32_t temp;
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (state == true)
@@ -1242,14 +1238,12 @@ void intel_ddi_set_vc_payload_alloc(struct drm_crtc 
*crtc, bool state)
I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
 }
 
-void intel_ddi_enable_transcoder_func(struct drm_crtc *crtc)
+void intel_ddi_enable_transcoder_func(struct intel_crtc *crtc)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
-   struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   enum pipe pipe = intel_crtc->pipe;
-   enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+   enum pipe pipe = crtc->pipe;
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder->type;
uint32_t temp;
@@ -1258,7 +1252,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
temp = TRANS_DDI_FUNC_ENABLE;
temp |= TRANS_DDI_SELECT_PORT(port);
 
-   switch (intel_crtc->config->pipe_bpp) {
+   switch (crtc->config->pipe_bpp) {
case 18:
temp |= TRANS_DDI_BPC_6;
break;
@@ -1275,9 +1269,9 @@ void 

[Intel-gfx] [PATCH v2 4/8] drm/i915: Pass pipe_config to pch_enable() functions

[Ander Conselvan de Oliveira]

Using crtc->config directly is being removed in favor of passing a
pipe_config. Follow the trend and pass pipe_config to pch_enable()
functions.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_display.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 45415f0..aea302b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4456,7 +4456,8 @@ intel_trans_dp_port_sel(struct intel_crtc *crtc)
  *   - DP transcoding bits
  *   - transcoder
  */
-static void ironlake_pch_enable(struct intel_crtc *crtc)
+static void ironlake_pch_enable(struct intel_crtc *crtc,
+   struct intel_crtc_state *pipe_config)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -4484,7 +4485,7 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
temp = I915_READ(PCH_DPLL_SEL);
temp |= TRANS_DPLL_ENABLE(pipe);
sel = TRANS_DPLLB_SEL(pipe);
-   if (crtc->config->shared_dpll ==
+   if (pipe_config->shared_dpll ==
intel_get_shared_dpll_by_id(dev_priv, DPLL_ID_PCH_PLL_B))
temp |= sel;
else
@@ -4509,9 +4510,9 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
 
/* For PCH DP, enable TRANS_DP_CTL */
if (HAS_PCH_CPT(dev_priv) &&
-   intel_crtc_has_dp_encoder(crtc->config)) {
+   intel_crtc_has_dp_encoder(pipe_config)) {
const struct drm_display_mode *adjusted_mode =
-   >config->base.adjusted_mode;
+   _config->base.adjusted_mode;
u32 bpc = (I915_READ(PIPECONF(pipe)) & PIPECONF_BPC_MASK) >> 5;
i915_reg_t reg = TRANS_DP_CTL(pipe);
temp = I915_READ(reg);
@@ -4546,10 +4547,11 @@ static void ironlake_pch_enable(struct intel_crtc *crtc)
ironlake_enable_pch_transcoder(dev_priv, pipe);
 }
 
-static void lpt_pch_enable(struct intel_crtc *crtc)
+static void lpt_pch_enable(struct intel_crtc *crtc,
+  struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
 
assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
 
@@ -5283,7 +5285,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   ironlake_pch_enable(intel_crtc);
+   ironlake_pch_enable(intel_crtc, pipe_config);
 
assert_vblank_disabled(crtc);
drm_crtc_vblank_on(crtc);
@@ -5393,7 +5395,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_enable_pipe(intel_crtc);
 
if (intel_crtc->config->has_pch_encoder)
-   lpt_pch_enable(intel_crtc);
+   lpt_pch_enable(intel_crtc, pipe_config);
 
if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(crtc, true);
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

[Ville Syrjälä]

On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote:
> Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
> 1.1.
> 
> When a sink that supports deep color is connected to the output, the
> receiver will send EDIDs that advertise this capability, even if it
> isn't possible with HDMI versions earlier than 1.3.
> 
> Currently the kernel is assuming that deep color is possible and the
> sink displays an error.
> 
> This quirk will make sure that deep color isn't used with this
> particular receiver.
> 
> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
> References: https://bugs.freedesktop.org/show_bug.cgi?id=99869
> Signed-off-by: Tomeu Vizoso 

Cc: sta...@vger.kernel.org
Cc: Matt Horan 
Tested-by: Matt Horan 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99869
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_edid.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 24e7b282f16c..d994ccf94f88 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -148,6 +148,9 @@ static const struct edid_quirk {
>  
>   /* Panel in Samsung NP700G7A-S01PL notebook reports 6bpc */
>   { "SEC", 0xd033, EDID_QUIRK_FORCE_8BPC },
> +
> + /* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
> + { "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
>  };
>  
>  /*
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RESEND,FOR,CI,01/10] drm/i915/dsi: Document the panel enable / disable sequences from the spec

[Jani Nikula]

On Wed, 01 Mar 2017, Patchwork  wrote:
> == Series Details ==
>
> Series: series starting with [RESEND,FOR,CI,01/10] drm/i915/dsi: Document the 
> panel enable / disable sequences from the spec
> URL   : https://patchwork.freedesktop.org/series/20456/
> State : failure
>
> == Summary ==
>
> Series 20456v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/20456/revisions/1/mbox/
>
> Test gem_exec_fence:
> Subgroup await-hang-default:
> incomplete -> PASS   (fi-hsw-4770) fdo#99726
> Test gem_exec_reloc:
> Subgroup basic-write-gtt-active:
> pass   -> INCOMPLETE (fi-byt-j1900)

Should not have anything to do with DSI patches.

Pushed the lot, thanks for the patches and review.

BR,
Jani.

> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS   (fi-bsw-n3050)
>
> fdo#99726 https://bugs.freedesktop.org/show_bug.cgi?id=99726
>
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
> fi-byt-j1900 total:96   pass:86   dwarn:0   dfail:0   fail:0   skip:9  
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 
>
> 73ef819d4281caf11663007299032aee4a388ad6 drm-tip: 2017y-03m-01d-11h-16m-44s 
> UTC integration manifest
> d7be9a5 drm/i915/dsi: Skip delays for v3 VBTs in vid-mode
> 64b2987 drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode 
> (untested)
> 22bb143 drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable
> e6edb17 drm/i915/dsi: Document always using v3 SHUTDOWN / 
> MIPI_SEQ_DISPLAY_OFF order
> 1c58d25f drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with 
> panel_[en|dis]able_backlight
> a66cd5f drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling 
> device_ready()
> 7e41705 drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable
> 26833c8 drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic 
> gpio calls
> 17004c5 drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON
> 579e545 drm/i915/dsi: Document the panel enable / disable sequences from the 
> spec
>
> == Logs ==
>
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4015/

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RESEND,FOR,CI,01/10] drm/i915/dsi: Document the panel enable / disable sequences from the spec

[Patchwork]

== Series Details ==

Series: series starting with [RESEND,FOR,CI,01/10] drm/i915/dsi: Document the 
panel enable / disable sequences from the spec
URL   : https://patchwork.freedesktop.org/series/20456/
State : failure

== Summary ==

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

Test gem_exec_fence:
Subgroup await-hang-default:
incomplete -> PASS   (fi-hsw-4770) fdo#99726
Test gem_exec_reloc:
Subgroup basic-write-gtt-active:
pass   -> INCOMPLETE (fi-byt-j1900)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-bsw-n3050)

fdo#99726 https://bugs.freedesktop.org/show_bug.cgi?id=99726

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:96   pass:86   dwarn:0   dfail:0   fail:0   skip:9  
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

73ef819d4281caf11663007299032aee4a388ad6 drm-tip: 2017y-03m-01d-11h-16m-44s UTC 
integration manifest
d7be9a5 drm/i915/dsi: Skip delays for v3 VBTs in vid-mode
64b2987 drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode 
(untested)
22bb143 drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable
e6edb17 drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF 
order
1c58d25f drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with 
panel_[en|dis]able_backlight
a66cd5f drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling 
device_ready()
7e41705 drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable
26833c8 drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio 
calls
17004c5 drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON
579e545 drm/i915/dsi: Document the panel enable / disable sequences from the 
spec

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4015/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: use BUILD_BUG_ON to ensure platform name has been set up

[Jani Nikula]

On Tue, 28 Feb 2017, Chris Wilson  wrote:
> On Tue, Feb 28, 2017 at 01:11:43PM +0200, Jani Nikula wrote:
>> Leave the runtime check in place in case the platform variable itself
>> comes from bogus sources.
>> 
>> Signed-off-by: Jani Nikula 
>
> Neat.
> Reviewed-by: Chris Wilson 

Pushed, thanks for the review.

BR,
Jani.


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

Re: [Intel-gfx] kbl_guc and bxt_guc firmware missing from linux-firmware

[Jani Nikula]

On Wed, 15 Feb 2017, Seth Forshee  wrote:
> Maybe it would be good to have something like MODULE_OPTIONAL_FIRMWARE
> to identify firmware that isn't required but will be used by the driver
> if available. Then mkinitramfs can try to copy those files along with
> the module but know that there's no need to produce a warning if it's
> not present.

The documentation for the current MODULE_FIRMWARE already says,
"Optional firmware file (or files) needed by the module format is simply
firmware file name."

BR,
Jani.


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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Move w/a LRI debug message from context-init to driver load

[Patchwork]

== Series Details ==

Series: drm/i915: Move w/a LRI debug message from context-init to driver load
URL   : https://patchwork.freedesktop.org/series/20452/
State : warning

== Summary ==

Series 20452v1 drm/i915: Move w/a LRI debug message from context-init to driver 
load
https://patchwork.freedesktop.org/api/1.0/series/20452/revisions/1/mbox/

Test gem_exec_fence:
Subgroup await-hang-default:
incomplete -> PASS   (fi-hsw-4770) fdo#99726
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-bxt-t5700)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-bsw-n3050)

fdo#99726 https://bugs.freedesktop.org/show_bug.cgi?id=99726

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:257  dwarn:1   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

73ef819d4281caf11663007299032aee4a388ad6 drm-tip: 2017y-03m-01d-11h-16m-44s UTC 
integration manifest
c41c63a drm/i915: Move w/a LRI debug message from context-init to driver load

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4014/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH RESEND FOR CI 07/10] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order

[Jani Nikula]

From: Hans de Goede 

According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
first.

Since the v2 order has known issues, we use the v3 order everywhere,
add a comment documenting this.

Signed-off-by: Hans de Goede 
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b132841587cc..5a50645c3a37 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -872,6 +872,11 @@ static void intel_dsi_pre_disable(struct intel_encoder 
*encoder,
I915_WRITE(MIPI_DEVICE_READY(port), 0);
}
 
+   /*
+* According to the spec we should send SHUTDOWN before
+* MIPI_SEQ_DISPLAY_OFF only for v3+ VBTs, but field testing
+* has shown that the v3 sequence works for v2 VBTs too
+*/
if (is_vid_mode(intel_dsi)) {
/* Send Shutdown command to the panel in LP mode */
for_each_dsi_port(port, intel_dsi->ports)
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND FOR CI 10/10] drm/i915/dsi: Skip delays for v3 VBTs in vid-mode

[Jani Nikula]

From: Hans de Goede 

For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
we should not also delay ourselves otherwise we get double delays.

Signed-off-by: Hans de Goede 
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 7d5fb9d3fa64..dd38b6835528 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -725,6 +725,17 @@ static void intel_dsi_prepare(struct intel_encoder 
*intel_encoder,
  struct intel_crtc_state *pipe_config);
 static void intel_dsi_unprepare(struct intel_encoder *encoder);
 
+static void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec)
+{
+   struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
+
+   /* For v3 VBTs in vid-mode the delays are part of the VBT sequences */
+   if (is_vid_mode(intel_dsi) && dev_priv->vbt.dsi.seq_version >= 3)
+   return;
+
+   msleep(msec);
+}
+
 /*
  * Panel enable/disable sequences from the VBT spec.
  *
@@ -806,7 +817,7 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
if (intel_dsi->gpio_panel)
gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
-   msleep(intel_dsi->panel_on_delay);
+   intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
 
/* Deassert reset */
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
@@ -828,7 +839,7 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
msleep(20); /* XXX */
for_each_dsi_port(port, intel_dsi->ports)
dpi_send_cmd(intel_dsi, TURN_ON, false, port);
-   msleep(100);
+   intel_dsi_msleep(intel_dsi, 100);
 
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
 
@@ -955,7 +966,7 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder,
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
 
/* Power off, try both CRC pmic gpio and VBT */
-   msleep(intel_dsi->panel_off_delay);
+   intel_dsi_msleep(intel_dsi, intel_dsi->panel_off_delay);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF);
if (intel_dsi->gpio_panel)
gpiod_set_value_cansleep(intel_dsi->gpio_panel, 0);
@@ -964,7 +975,7 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder,
 * FIXME As we do with eDP, just make a note of the time here
 * and perform the wait before the next panel power on.
 */
-   msleep(intel_dsi->panel_pwr_cycle_delay);
+   intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
 }
 
 static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND FOR CI 03/10] drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio calls

[Jani Nikula]

From: Hans de Goede 

Now that we are no longer bound to the drm_panel_ callbacks, call
MIPI_SEQ_POWER_ON/OFF at the proper place.

Signed-off-by: Hans de Goede 
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index f9b0767ef073..ab905474b9dd 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -793,10 +793,10 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
 
intel_dsi_prepare(encoder, pipe_config);
 
-   /* Panel Enable over CRC PMIC */
+   /* Power on, try both CRC pmic gpio and VBT */
if (intel_dsi->gpio_panel)
gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
-
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
msleep(intel_dsi->panel_on_delay);
 
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
@@ -811,7 +811,6 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
/* put device in ready state */
intel_dsi_device_ready(encoder);
 
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
 
@@ -940,11 +939,10 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder,
}
 
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF);
 
+   /* Power off, try both CRC pmic gpio and VBT */
msleep(intel_dsi->panel_off_delay);
-
-   /* Panel Disable over CRC PMIC */
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF);
if (intel_dsi->gpio_panel)
gpiod_set_value_cansleep(intel_dsi->gpio_panel, 0);
 
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND FOR CI 02/10] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON

[Jani Nikula]

From: Hans de Goede 

intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET,
will always be called at some point before intel_dsi_pre_enable()
making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundant.

In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes
against the VBT spec.

Signed-off-by: Hans de Goede 
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 234592c62141..f9b0767ef073 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -811,7 +811,6 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
/* put device in ready state */
intel_dsi_device_ready(encoder);
 
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND FOR CI 09/10] drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)

[Jani Nikula]

From: Hans de Goede 

According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
on enable for cmd-mode, just like we already call their counterparts
on disable. Note: untested, my panel is a vid-mode panel.

Signed-off-by: Hans de Goede 
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 7dbef67a5fa0..7d5fb9d3fa64 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -822,6 +822,8 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
if (is_cmd_mode(intel_dsi)) {
for_each_dsi_port(port, intel_dsi->ports)
I915_WRITE(MIPI_MAX_RETURN_PKT_SIZE(port), 8 * 4);
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_ON);
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
} else {
msleep(20); /* XXX */
for_each_dsi_port(port, intel_dsi->ports)
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND FOR CI 06/10] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight

[Jani Nikula]

From: Hans de Goede 

Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_enable_backlight() / intel_panel_disable_backlight().

Signed-off-by: Hans de Goede 
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b7b590d78b31..b132841587cc 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -829,12 +829,12 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
msleep(100);
 
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
 
intel_dsi_port_enable(encoder);
}
 
intel_panel_enable_backlight(intel_dsi->attached_connector);
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
 }
 
 static void intel_dsi_enable_nop(struct intel_encoder *encoder,
@@ -860,6 +860,7 @@ static void intel_dsi_pre_disable(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("\n");
 
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_panel_disable_backlight(intel_dsi->attached_connector);
 
/*
@@ -915,7 +916,6 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder,
 * if disable packets are sent before sending shutdown packet then in
 * some next enable sequence send turn on packet error is observed
 */
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
 
/* Transition to LP-00 */
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND FOR CI 08/10] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable

[Jani Nikula]

From: Hans de Goede 

For v3+ VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF,
v2 VBTs do not have MIPI_SEQ_TEAR_OFF so there this is a nop.

Signed-off-by: Hans de Goede 
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 5a50645c3a37..7dbef67a5fa0 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -921,6 +921,8 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder,
 * if disable packets are sent before sending shutdown packet then in
 * some next enable sequence send turn on packet error is observed
 */
+   if (is_cmd_mode(intel_dsi))
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_OFF);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
 
/* Transition to LP-00 */
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND FOR CI 04/10] drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable

[Jani Nikula]

From: Hans de Goede 

Move the DPOunit clock gate workaround to directly after the PLL enable.

The exact location of the workaround does not matter and there are 2
reasons to group it with the PLL enable:

1) This moves it out of the middle of the init sequence from the spec,
   making it easier to follow the init sequence / compare it to the spec

2) It is grouped with the pll disable call in intel_dsi_post_disable,
   so for consistency it should be grouped with the pll enable in
   intel_dsi_pre_enable

Signed-off-by: Hans de Goede 
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index ab905474b9dd..da798a579e11 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -791,14 +791,6 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, 0);
}
 
-   intel_dsi_prepare(encoder, pipe_config);
-
-   /* Power on, try both CRC pmic gpio and VBT */
-   if (intel_dsi->gpio_panel)
-   gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
-   msleep(intel_dsi->panel_on_delay);
-
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
u32 val;
 
@@ -808,6 +800,14 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
I915_WRITE(DSPCLK_GATE_D, val);
}
 
+   intel_dsi_prepare(encoder, pipe_config);
+
+   /* Power on, try both CRC pmic gpio and VBT */
+   if (intel_dsi->gpio_panel)
+   gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
+   msleep(intel_dsi->panel_on_delay);
+
/* put device in ready state */
intel_dsi_device_ready(encoder);
 
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND FOR CI 05/10] drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready()

[Jani Nikula]

From: Hans de Goede 

Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready
state (LP-11), this is the sequence in which things should be done
according to the spec.

Signed-off-by: Hans de Goede 
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index da798a579e11..b7b590d78b31 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -808,10 +808,13 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
msleep(intel_dsi->panel_on_delay);
 
-   /* put device in ready state */
+   /* Deassert reset */
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
+
+   /* Put device in ready state (LP-11) */
intel_dsi_device_ready(encoder);
 
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
+   /* Send initialization commands in LP mode */
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
 
/* Enable port in pre-enable phase itself because as per hw team
@@ -915,6 +918,7 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder,
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
 
+   /* Transition to LP-00 */
intel_dsi_clear_device_ready(encoder);
 
if (IS_BROXTON(dev_priv)) {
@@ -938,6 +942,7 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder,
I915_WRITE(DSPCLK_GATE_D, val);
}
 
+   /* Assert reset */
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
 
/* Power off, try both CRC pmic gpio and VBT */
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND FOR CI 01/10] drm/i915/dsi: Document the panel enable / disable sequences from the spec

[Jani Nikula]

From: Hans de Goede 

Document the DSI panel enable / disable sequences from the spec,
for easy comparison between the code and the spec.

Signed-off-by: Hans de Goede 
Acked-by: Jani Nikula 
Reviewed-by: Bob Paauwe 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 8e97bae378f1..234592c62141 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -725,6 +725,43 @@ static void intel_dsi_prepare(struct intel_encoder 
*intel_encoder,
  struct intel_crtc_state *pipe_config);
 static void intel_dsi_unprepare(struct intel_encoder *encoder);
 
+/*
+ * Panel enable/disable sequences from the VBT spec.
+ *
+ * Note the spec has AssertReset / DeassertReset swapped from their
+ * usual naming. We use the normal names to avoid confusion (so below
+ * they are swapped compared to the spec).
+ *
+ * Steps starting with MIPI refer to VBT sequences, note that for v2
+ * VBTs several steps which have a VBT in v2 are expected to be handled
+ * directly by the driver, by directly driving gpios for example.
+ *
+ * v2 video mode seq v3 video mode seq command mode seq
+ * - power on- MIPIPanelPowerOn- power on
+ * - wait t1+t2- wait t1+t2
+ * - MIPIDeassertResetPin- MIPIDeassertResetPin- MIPIDeassertResetPin
+ * - io lines to lp-11   - io lines to lp-11   - io lines to lp-11
+ * - MIPISendInitialDcsCmds  - MIPISendInitialDcsCmds  - MIPISendInitialDcsCmds
+ * - MIPITearOn
+ * - MIPIDisplayOn
+ * - turn on DPI - turn on DPI - set pipe to dsr mode
+ * - MIPIDisplayOn   - MIPIDisplayOn
+ * - wait t5   - wait t5
+ * - backlight on- MIPIBacklightOn - backlight on
+ * ...   ...   ... issue mem cmds ...
+ * - backlight off   - MIPIBacklightOff- backlight off
+ * - wait t6   - wait t6
+ * - MIPIDisplayOff
+ * - turn off DPI- turn off DPI- disable pipe dsr mode
+ * - MIPITearOff
+ *   - MIPIDisplayOff  - MIPIDisplayOff
+ * - io lines to lp-00   - io lines to lp-00   - io lines to lp-00
+ * - MIPIAssertResetPin  - MIPIAssertResetPin  - MIPIAssertResetPin
+ * - wait t3   - wait t3
+ * - power off   - MIPIPanelPowerOff   - power off
+ * - wait t4   - wait t4
+ */
+
 static void intel_dsi_pre_enable(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config,
 struct drm_connector_state *conn_state)
-- 
2.1.4

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

[Intel-gfx] drm/i915/dsi: the rest of Hans' DSI patches

[Jani Nikula]

Resending again to get CI...

BR,
Jani.


___
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: Prevent concurrent tiling/framebuffer modifications

[Ville Syrjälä]

On Tue, Feb 28, 2017 at 04:22:33PM +, Chris Wilson wrote:
> Reintroduce a lock around tiling vs framebuffer creation to prevent
> modification of the obj->tiling_and_stride whilst the framebuffer is
> being created. Rather than use struct_mutex once again, use the
> per-object lock - this will also be required in future to prevent
> changing the tiling whilst submitting rendering.
> 
> Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating 
> the framebuffer")
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_gem_object.h   | 18 +-
>  drivers/gpu/drm/i915/i915_gem_shrinker.c |  2 +-
>  drivers/gpu/drm/i915/i915_gem_tiling.c   |  9 -
>  drivers/gpu/drm/i915/intel_display.c | 25 -
>  4 files changed, 42 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
> b/drivers/gpu/drm/i915/i915_gem_object.h
> index ad1bc0b1a0c2..8c02c8ec2a3b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> @@ -169,7 +169,7 @@ struct drm_i915_gem_object {
>   struct reservation_object *resv;
>  
>   /** References from framebuffers, locks out tiling changes. */
> - atomic_t framebuffer_references;
> + unsigned int framebuffer_references;
>  
>   /** Record of address bit 17 of each page at last unbind. */
>   unsigned long *bit_17;
> @@ -263,6 +263,16 @@ extern void drm_gem_object_unreference(struct 
> drm_gem_object *);
>  __deprecated
>  extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *);
>  
> +static inline void i915_gem_object_lock(struct drm_i915_gem_object *obj)
> +{
> + reservation_object_lock(obj->resv, NULL);
> +}
> +
> +static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj)
> +{
> + reservation_object_unlock(obj->resv);
> +}
> +
>  static inline bool
>  i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj)
>  {
> @@ -303,6 +313,12 @@ i915_gem_object_clear_active_reference(struct 
> drm_i915_gem_object *obj)
>  
>  void __i915_gem_object_release_unless_active(struct drm_i915_gem_object 
> *obj);
>  
> +static inline bool
> +i915_gem_object_is_framebuffer(const struct drm_i915_gem_object *obj)
> +{
> + return READ_ONCE(obj->framebuffer_references);
> +}
> +
>  static inline unsigned int
>  i915_gem_object_get_tiling(struct drm_i915_gem_object *obj)
>  {
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index 7e3bb48e043e..630697001b38 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -210,7 +210,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
>  
>   if (!(flags & I915_SHRINK_ACTIVE) &&
>   (i915_gem_object_is_active(obj) ||
> -  atomic_read(>framebuffer_references)))
> +  i915_gem_object_is_framebuffer(obj)))
>   continue;
>  
>   if (!can_release_pages(obj))
> diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
> b/drivers/gpu/drm/i915/i915_gem_tiling.c
> index c1d669e32f41..ad5e05f6b836 100644
> --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
> +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
> @@ -238,7 +238,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object 
> *obj,
>   if ((tiling | stride) == obj->tiling_and_stride)
>   return 0;
>  
> - if (atomic_read(>framebuffer_references))
> + if (i915_gem_object_is_framebuffer(obj))
>   return -EBUSY;
>  
>   /* We need to rebind the object if its current allocation
> @@ -258,6 +258,12 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object 
> *obj,
>   if (err)
>   return err;
>  
> + i915_gem_object_lock(obj);
> + if (i915_gem_object_is_framebuffer(obj)) {
> + i915_gem_object_unlock(obj);
> + return -EBUSY;
> + }
> +
>   /* If the memory has unknown (i.e. varying) swizzling, we pin the
>* pages to prevent them being swapped out and causing corruption
>* due to the change in swizzling.
> @@ -294,6 +300,7 @@ i915_gem_object_set_tiling(struct drm_i915_gem_object 
> *obj,
>   }
>  
>   obj->tiling_and_stride = tiling | stride;
> + i915_gem_object_unlock(obj);
>  
>   /* Force the fence to be reacquired for GTT access */
>   i915_gem_release_mmap(obj);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 77936ddd860a..62a1e628e399 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14255,7 +14255,10 @@ static void intel_user_framebuffer_destroy(struct 
> drm_framebuffer *fb)
>  
>   drm_framebuffer_cleanup(fb);
>  
> - 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix all intel_framebuffer_init failures to take the error path

[Ville Syrjälä]

On Tue, Feb 28, 2017 at 04:22:32PM +, Chris Wilson wrote:
> No more direct return -EINVAL as we have to unwind the
> obj->framebuffer_references.
> 
> Fixes: 24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating 
> the framebuffer")
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 

lgtm

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 10e68dfb7260..77936ddd860a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14383,7 +14383,7 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>   if (INTEL_INFO(dev_priv)->gen < 4 &&
>   tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
>   DRM_DEBUG("tiling_mode must match fb modifier exactly on 
> gen2/3\n");
> - return -EINVAL;
> + goto err;
>   }
>  
>   stride_alignment = intel_fb_stride_alignment(dev_priv,
> @@ -14428,7 +14428,7 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>   if (INTEL_GEN(dev_priv) > 3) {
>   DRM_DEBUG("unsupported pixel format: %s\n",
> drm_get_format_name(mode_cmd->pixel_format, 
> _name));
> - return -EINVAL;
> + goto err;
>   }
>   break;
>   case DRM_FORMAT_ABGR:
> @@ -14436,7 +14436,7 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>   INTEL_GEN(dev_priv) < 9) {
>   DRM_DEBUG("unsupported pixel format: %s\n",
> drm_get_format_name(mode_cmd->pixel_format, 
> _name));
> - return -EINVAL;
> + goto err;
>   }
>   break;
>   case DRM_FORMAT_XBGR:
> @@ -14445,14 +14445,14 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>   if (INTEL_GEN(dev_priv) < 4) {
>   DRM_DEBUG("unsupported pixel format: %s\n",
> drm_get_format_name(mode_cmd->pixel_format, 
> _name));
> - return -EINVAL;
> + goto err;
>   }
>   break;
>   case DRM_FORMAT_ABGR2101010:
>   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
>   DRM_DEBUG("unsupported pixel format: %s\n",
> drm_get_format_name(mode_cmd->pixel_format, 
> _name));
> - return -EINVAL;
> + goto err;
>   }
>   break;
>   case DRM_FORMAT_YUYV:
> @@ -14462,13 +14462,13 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>   if (INTEL_GEN(dev_priv) < 5) {
>   DRM_DEBUG("unsupported pixel format: %s\n",
> drm_get_format_name(mode_cmd->pixel_format, 
> _name));
> - return -EINVAL;
> + goto err;
>   }
>   break;
>   default:
>   DRM_DEBUG("unsupported pixel format: %s\n",
> drm_get_format_name(mode_cmd->pixel_format, 
> _name));
> - return -EINVAL;
> + goto err;
>   }
>  
>   /* FIXME need to adjust LINOFF/TILEOFF accordingly. */
> @@ -14481,7 +14481,7 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>  
>   ret = intel_fill_fb_info(dev_priv, _fb->base);
>   if (ret)
> - return ret;
> + goto err;
>  
>   ret = drm_framebuffer_init(obj->base.dev,
>  _fb->base,
> -- 
> 2.11.0

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

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Add more OA configs for BDW, CHV, SKL + BXT

[Matthew Auld]

On 02/22, Robert Bragg wrote:
> These are auto generated from an XML description of metric sets,
> currently maintained in gputop, ref:
> 
>  https://github.com/rib/gputop
>  > gputop-data/oa-*.xml
>  > scripts/i915-perf-kernelgen.py
> 
>  $ make -C gputop-data -f Makefile.xml
> 
> Signed-off-by: Robert Bragg 
> ---



> +
> +static const struct i915_oa_reg *
> +get_compute_extended_mux_config(struct drm_i915_private *dev_priv,
> + int *len)
> +{
> + if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x01) {
> + *len = 
> ARRAY_SIZE(mux_config_compute_extended_1_0_subslices_0x01);
> + return mux_config_compute_extended_1_0_subslices_0x01;
> + } else if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x08) {
> + *len = 
> ARRAY_SIZE(mux_config_compute_extended_1_1_subslices_0x08);
> + return mux_config_compute_extended_1_1_subslices_0x08;
> + } else if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x02) {
> + *len = 
> ARRAY_SIZE(mux_config_compute_extended_1_2_subslices_0x02);
> + return mux_config_compute_extended_1_2_subslices_0x02;
> + } else if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x10) {
> + *len = 
> ARRAY_SIZE(mux_config_compute_extended_1_3_subslices_0x10);
> + return mux_config_compute_extended_1_3_subslices_0x10;
> + } else if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x04) {
> + *len = 
> ARRAY_SIZE(mux_config_compute_extended_1_4_subslices_0x04);
> + return mux_config_compute_extended_1_4_subslices_0x04;
> + } else if (INTEL_INFO(dev_priv)->sseu.subslice_mask & 0x20) {
> + *len = 
> ARRAY_SIZE(mux_config_compute_extended_1_5_subslices_0x20);
> + return mux_config_compute_extended_1_5_subslices_0x20;
> + *len = ARRAY_SIZE(mux_config_compute_extended);
> + return mux_config_compute_extended;
It looks like your script doesn't properly handle the unconditional mux
config here.



> +
> +static const struct i915_oa_reg *
> +get_test_oa_mux_config(struct drm_i915_private *dev_priv,
> +int *len)
> +{
> + *len = ARRAY_SIZE(mux_config_test_oa);
> + return mux_config_test_oa;
> +}
> +
> +int i915_oa_select_metric_set_bdw(struct drm_i915_private *dev_priv)
> +{
> + dev_priv->perf.oa.mux_regs = NULL;
> + dev_priv->perf.oa.mux_regs_len = 0;
> + dev_priv->perf.oa.b_counter_regs = NULL;
> + dev_priv->perf.oa.b_counter_regs_len = 0;
> + dev_priv->perf.oa.flex_regs = NULL;
> + dev_priv->perf.oa.flex_regs_len = 0;
> +
> + switch (dev_priv->perf.oa.metrics_set) {
> + case METRIC_SET_ID_RENDER_BASIC:
> + dev_priv->perf.oa.mux_regs =
> + get_render_basic_mux_config(dev_priv,
> + 
> _priv->perf.oa.mux_regs_len);
> + if (!dev_priv->perf.oa.mux_regs) {
> + DRM_DEBUG_DRIVER("No suitable MUX config for 
> \"RENDER_BASIC\" metric set");
Your script also needs to output a newline for DRM_DEBUG_DRIVER.

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

Re: [Intel-gfx] [RFC 05/11] drm/i915/preempt: Handle preemption event in guc tasklet

[Chris Wilson]

On Thu, Feb 23, 2017 at 08:14:15PM +0100, Michał Winiarski wrote:
> +static void unsubmit_inflight_requests(struct intel_engine_cs *engine,
> +  struct list_head *resubmit)
> +{
> + struct drm_i915_gem_request *rq, *prev;
> +
> + assert_spin_locked(>timeline->lock);
> +
> + list_for_each_entry_safe_reverse(rq, prev,
> +  >timeline->requests, link) {
> + if (!i915_gem_request_completed(rq)) {
> + i915_gem_request_get(rq);
> + __i915_gem_request_unsubmit(rq);
> + list_add(>resubmit_link, resubmit);

I was thinking it would be going back to the execlist queue, where it
would be priority sorted against later requests.

Pro/cons?
-Chris

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

Re: [Intel-gfx] [RFC 10/11] drm/i915/preempt: Emit MI_ARB_CHECK before the start of user batch

[Chris Wilson]

On Thu, Feb 23, 2017 at 08:14:20PM +0100, Michał Winiarski wrote:
> We should probably do this conditionally, based on whether preemption is
> actually enabled.
> 
> Signed-off-by: Michał Winiarski 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 869b96e..972f9bd 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1418,10 +1418,13 @@ static int gen8_emit_bb_start(struct 
> drm_i915_gem_request *req,
>   req->ctx->ppgtt->pd_dirty_rings &= 
> ~intel_engine_flag(req->engine);
>   }
>  
> - cs = intel_ring_begin(req, 4);
> + cs = intel_ring_begin(req, 6);
>   if (IS_ERR(cs))
>   return PTR_ERR(cs);
>  
> + *cs++ = MI_ARB_CHECK;
> + *cs++ = MI_NOOP;
> +
>   /* FIXME(BDW): Address space and security selectors. */
>   *cs++ = MI_BATCH_BUFFER_START_GEN8 | (ppgtt << 8) | (dispatch_flags &
>   I915_DISPATCH_RS ? MI_BATCH_RESOURCE_STREAMER : 0);

Shouldn't we only enable arbitration across the batch, i.e. add the
disable here? The flush and breadcrumb are not worth interrupting and
saves us some work if they are not.
-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 4/4] drm/i915/guc: Break out the GuC log "extras"

[Joonas Lahtinen]

On pe, 2017-02-24 at 06:01 -0800, Oscar Mateo wrote:
> When initializing the GuC log struct, there is an object we need to
> allocate always, since the GuC needs its address at fw load time.
> The rest are "extras", in the sense that we only need them if we
> actually enable GuC logging. Make that distinction explicit by
> subdividing further the intel_guc_log struct.
> 
> Cc: Daniele Ceraolo Spurio 
> Cc: Joonas Lahtinen 
> Signed-off-by: Oscar Mateo 

I'm not sure about calling them extras. How about runtime?

Also, I'm not quite sure if the abstractions are currently correct
(despite the names), logging seems to control overall guc interrups,
for example (i915_guc_log_unregister func).

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

Re: [Intel-gfx] [PATCH 2/4 v2] drm/i915/guc: Add onion teardown to the GuC setup

[Joonas Lahtinen]

On pe, 2017-02-24 at 06:01 -0800, Oscar Mateo wrote:
> Starting with intel_guc_loader, down to intel_guc_submission
> and finally to intel_guc_log.
> 
> v2:
>   - Null execbuf client outside guc_client_free (Daniele)
>   - Assert if things try to get allocated twice (Daniele/Joonas)
>   - Null guc->log.buf_addr when destroyed (Daniele)
>   - Newline between returning success and error labels (Joonas)
>   - Remove some unnecessary comments (Joonas)
>   - Keep guc_log_create_extras naming convention (Joonas)
>   - Helper function guc_log_has_extras (Joonas)
>   - No need for separate relay_channel create/destroy. It's just another 
> extra.
>   - No need to nullify guc->log.flush_wq when destroyed (Joonas)
>   - Hoist the check for has_extras out of guc_log_create_extras (Joonas)
>   - Try to do i915_guc_log_register/unregister calls (kind of) symmetric 
> (Daniele)
>   - Make sure initel_guc_fini is not called before init is ever called 
> (Daniele)
> 
> Cc: Daniele Ceraolo Spurio 
> Cc: Joonas Lahtinen 
> Signed-off-by: Oscar Mateo 



> @@ -404,120 +348,105 @@ static void capture_logs_work(struct work_struct 
> *work)
>   guc_log_capture_logs(guc);
>  }
>  
> +static bool guc_log_has_extras(struct intel_guc *guc)
> +{
> + return (guc->log.buf_addr != NULL);
> +}

brackets not needed.

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH v5] drm/i915/guc: Extract param logic form guc_init_fw()

[Joonas Lahtinen]

On ma, 2017-02-27 at 13:50 +0100, Arkadiusz Hiler wrote:
> Let intel_guc_init_fw() focus on determining and fetching the correct
> firmware.
> 
> This patch introduces intel_uc_sanitize_options() that is called from
> intel_sanitize_options().
> 
> Then, if we have GuC, we can call intel_guc_init_fw() conditionally
> and we do not have to do the internal checks.
> 
> v2: fix comment, notify when nuking GuC explicitly enabled (M. Wajdeczko)
> v3: fix comment again, change the nuke message (M. Wajdeczko)
> v4: update title to reflect new function name + rebase
> v5: text && remove 2 uneccessary checks (M. Wajeczko)
> 
> Cc: Michal Winiarski 
> Cc: Michal Wajdeczko 
> Cc: Daniele Ceraolo Spurio 
> Cc: Joonas Lahtinen 
> Signed-off-by: Arkadiusz Hiler 

Reviewed-by: Joonas Lahtinen 

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

[Intel-gfx] [PATCH] drm/i915: Move w/a LRI debug message from context-init to driver load

[Chris Wilson]

The spam of every context initialisation saying the same thing is annoying
me! Move the information to the setup of the engine.

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

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index c4d4698f98e7..c58339b22f6a 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1009,30 +1009,32 @@ static int glk_init_workarounds(struct intel_engine_cs 
*engine)
 int init_workarounds_ring(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
+   int err;
 
WARN_ON(engine->id != RCS);
 
dev_priv->workarounds.count = 0;
-   dev_priv->workarounds.hw_whitelist_count[RCS] = 0;
+   dev_priv->workarounds.hw_whitelist_count[engine->id] = 0;
 
if (IS_BROADWELL(dev_priv))
-   return bdw_init_workarounds(engine);
-
-   if (IS_CHERRYVIEW(dev_priv))
-   return chv_init_workarounds(engine);
-
-   if (IS_SKYLAKE(dev_priv))
-   return skl_init_workarounds(engine);
-
-   if (IS_BROXTON(dev_priv))
-   return bxt_init_workarounds(engine);
-
-   if (IS_KABYLAKE(dev_priv))
-   return kbl_init_workarounds(engine);
-
-   if (IS_GEMINILAKE(dev_priv))
-   return glk_init_workarounds(engine);
+   err = bdw_init_workarounds(engine);
+   else if (IS_CHERRYVIEW(dev_priv))
+   err = chv_init_workarounds(engine);
+   else if (IS_SKYLAKE(dev_priv))
+   err =  skl_init_workarounds(engine);
+   else if (IS_BROXTON(dev_priv))
+   err = bxt_init_workarounds(engine);
+   else if (IS_KABYLAKE(dev_priv))
+   err = kbl_init_workarounds(engine);
+   else if (IS_GEMINILAKE(dev_priv))
+   err =  glk_init_workarounds(engine);
+   else
+   err = 0;
+   if (err)
+   return err;
 
+   DRM_DEBUG_DRIVER("%s: Number of context specific w/a: %d\n",
+engine->name, dev_priv->workarounds.count);
return 0;
 }
 
@@ -1066,8 +1068,6 @@ int intel_ring_workarounds_emit(struct 
drm_i915_gem_request *req)
if (ret)
return ret;
 
-   DRM_DEBUG_DRIVER("Number of Workarounds emitted: %d\n", w->count);
-
return 0;
 }
 
-- 
2.11.0

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

Re: [Intel-gfx] [igt PATCH] configure.ac: require libdrm >= 2.4.75 for I915_EXEC_FENCE_OUT

[Petri Latvala]

On 03/01/2017 01:34 PM, Jani Nikula wrote:

I915_EXEC_FENCE_OUT was added in libdrm commit a3d715ee14b2 ("Import
uapi/i915_drm.h from v4.10-rc5-950-g152d5750dda9") and released in
libdrm-2.4.75.

Signed-off-by: Jani Nikula 


Reviewed-by: Petri Latvala 



---

I'm probably doing something wrong. This passes configure for me, but
build still fails with:

gem_latency.c: In function ‘setup_latency’:
gem_latency.c:290:16: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in 
this function)
eb->flags |= I915_EXEC_FENCE_OUT;
 ^
gem_latency.c:290:16: note: each undeclared identifier is reported only once 
for each function it appears in
gem_latency.c: In function ‘measure_latency’:
gem_latency.c:328:44: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in 
this function)
   if (!(p->latency_dispatch.execbuf.flags & I915_EXEC_FENCE_OUT))
 ^
gem_latency.c: In function ‘producer’:
gem_latency.c:364:43: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in 
this function)
if (p->latency_dispatch.execbuf.flags & I915_EXEC_FENCE_OUT)


Possibly an old libdrm somewhere in your filesystem, configure finding 
the new one's .pc file but gcc finding the old one's headers first...




--
Petri Latvala

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

[Intel-gfx] [igt PATCH] configure.ac: require libdrm >= 2.4.75 for I915_EXEC_FENCE_OUT

[Jani Nikula]

I915_EXEC_FENCE_OUT was added in libdrm commit a3d715ee14b2 ("Import
uapi/i915_drm.h from v4.10-rc5-950-g152d5750dda9") and released in
libdrm-2.4.75.

Signed-off-by: Jani Nikula 

---

I'm probably doing something wrong. This passes configure for me, but
build still fails with:

gem_latency.c: In function ‘setup_latency’:
gem_latency.c:290:16: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in 
this function)
   eb->flags |= I915_EXEC_FENCE_OUT;
^
gem_latency.c:290:16: note: each undeclared identifier is reported only once 
for each function it appears in
gem_latency.c: In function ‘measure_latency’:
gem_latency.c:328:44: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in 
this function)
  if (!(p->latency_dispatch.execbuf.flags & I915_EXEC_FENCE_OUT))
^
gem_latency.c: In function ‘producer’:
gem_latency.c:364:43: error: ‘I915_EXEC_FENCE_OUT’ undeclared (first use in 
this function)
   if (p->latency_dispatch.execbuf.flags & I915_EXEC_FENCE_OUT)
   ^
Makefile:767: recipe for target 'gem_latency-gem_latency.o' failed
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 562d5525e894..407fddf5fe2b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -187,10 +187,10 @@ AC_ARG_ENABLE(intel, AS_HELP_STRING([--disable-intel],
  [Enable building of intel specific parts (default: auto)]),
  [INTEL=$enableval], [INTEL=auto])
 if test "x$INTEL" = xauto; then
-   PKG_CHECK_EXISTS([libdrm_intel >= 2.4.74], [INTEL=yes], [INTEL=no])
+   PKG_CHECK_EXISTS([libdrm_intel >= 2.4.75], [INTEL=yes], [INTEL=no])
 fi
 if test "x$INTEL" = xyes; then
-   PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.74])
+   PKG_CHECK_MODULES(DRM_INTEL, [libdrm_intel >= 2.4.75])
AC_DEFINE(HAVE_LIBDRM_INTEL, 1, [Have intel support])
 else
DRM_INTEL_CFLAGS=-I$\(top_srcdir\)/lib/stubs/drm/
-- 
2.1.4

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9: Increase PCODE request timeout to 100ms (rev2)

[Imre Deak]

On Fri, Feb 24, 2017 at 03:52:15PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/gen9: Increase PCODE request timeout to 100ms (rev2)
> URL   : https://patchwork.freedesktop.org/series/19961/
> State : success
> 
> == Summary ==
> 
> Series 19961v2 drm/i915/gen9: Increase PCODE request timeout to 100ms
> https://patchwork.freedesktop.org/api/1.0/series/19961/revisions/2/mbox/
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
> fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 
> 
> 69fbd8896f5f272550747b763068883326962d76 drm-tip: 2017y-02m-24d-14h-04m-04s 
> UTC integration manifest
> 11e17c3 drm/i915/gen9: Increase PCODE request timeout to 50ms

I pushed this to -dinq with Chris' ack, thanks for the reviews.

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

Re: [Intel-gfx] [GLK MIPI DSI V7] drm/i915/glk: Add MIPIIO Enable/disable sequence

[Jani Nikula]

On Wed, 01 Mar 2017, Madhav Chauhan  wrote:
> From: Deepak M 
>
> v2: Addressed Jani's Review comments(renamed bit field macros)
> v3: Jani's Review comment for aligning code to platforms and added
> wrapper functions.
> v4: Corrected enable/disable seuqence as per BSPEC
> v5: Corrected waiting twice for same bit (Review comments: Jani)
> v6: Rebased to Han's patches(dsi restructuring code)
>
> Signed-off-by: Deepak M 
> Signed-off-by: Madhav Chauhan 

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

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 206 
> ---
>  1 file changed, 195 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 20ed799..8e97bae3 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -357,6 +357,109 @@ static bool intel_dsi_compute_config(struct 
> intel_encoder *encoder,
>   return true;
>  }
>  
> +static void glk_dsi_device_ready(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> + enum port port;
> + u32 tmp, val;
> +
> + /* Set the MIPI mode
> +  * If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
> +  * Power ON MIPI IO first and then write into IO reset and LP wake bits
> +  */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(MIPI_CTRL(port));
> + I915_WRITE(MIPI_CTRL(port), tmp | GLK_MIPIIO_ENABLE);
> + }
> +
> + /* Put the IO into reset */
> + tmp = I915_READ(MIPI_CTRL(PORT_A));
> + tmp &= ~GLK_MIPIIO_RESET_RELEASED;
> + I915_WRITE(MIPI_CTRL(PORT_A), tmp);
> +
> + /* Program LP Wake */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(MIPI_CTRL(port));
> + tmp |= GLK_LP_WAKE;
> + I915_WRITE(MIPI_CTRL(port), tmp);
> + }
> +
> + /* Wait for Pwr ACK */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_MIPIIO_PORT_POWERED,
> + GLK_MIPIIO_PORT_POWERED, 20))
> + DRM_ERROR("MIPIO port is powergated\n");
> + }
> +
> + /* Wait for MIPI PHY status bit to set */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_PHY_STATUS_PORT_READY,
> + GLK_PHY_STATUS_PORT_READY, 20))
> + DRM_ERROR("PHY is not ON\n");
> + }
> +
> + /* Get IO out of reset */
> + tmp = I915_READ(MIPI_CTRL(PORT_A));
> + I915_WRITE(MIPI_CTRL(PORT_A), tmp | GLK_MIPIIO_RESET_RELEASED);
> +
> + /* Get IO out of Low power state*/
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY)) {
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= DEVICE_READY;
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> + usleep_range(10, 15);
> + }
> +
> + /* Enter ULPS */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_ENTER | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> +
> + /* Wait for ULPS Not active */
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE,
> + GLK_ULPS_NOT_ACTIVE, 20))
> +
> + /* Exit ULPS */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_EXIT | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> +
> + /* Enter Normal Mode */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
> +
> + tmp = I915_READ(MIPI_CTRL(port));
> + tmp &= ~GLK_LP_WAKE;
> + I915_WRITE(MIPI_CTRL(port), tmp);
> + }
> +
> + /* Wait for Stop state */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (intel_wait_for_register(dev_priv,
> + MIPI_CTRL(port), GLK_DATA_LANE_STOP_STATE,
> + GLK_DATA_LANE_STOP_STATE, 20))
> + DRM_ERROR("Date lane not in STOP state\n");
> + }
> +
> + /* 

[Intel-gfx] [i-g-t PATCH] intel-ci: Add initial generic testlist

[Abdiel Janulgue]

Similar to fast-feedback test list. The point of the generic test list is to 
gather
pass-rate when running generic tests - i.e., tests that don't rely on specific 
GPUs.
Again, this test list is dynamic and will either shrink or grow over time.

Signed-off-by: Abdiel Janulgue 
Cc: Petri Latvala 
Cc: Tomi Sarvela 
---
 tests/intel-ci/README   |   6 ++
 tests/intel-ci/generic.testlist | 125 
 2 files changed, 131 insertions(+)
 create mode 100644 tests/intel-ci/generic.testlist

diff --git a/tests/intel-ci/README b/tests/intel-ci/README
index dc7e5c8..314b343 100644
--- a/tests/intel-ci/README
+++ b/tests/intel-ci/README
@@ -32,3 +32,9 @@ test per feature.
 
 The string "basic" in a test name means the test probably belongs in
 this list.
+
+==
+generic.testlist
+==
+
+Generic is the testlist for GPU-agnostic tests.
\ No newline at end of file
diff --git a/tests/intel-ci/generic.testlist b/tests/intel-ci/generic.testlist
new file mode 100644
index 000..433acdf
--- /dev/null
+++ b/tests/intel-ci/generic.testlist
@@ -0,0 +1,125 @@
+igt@core_auth@many-magics
+igt@core_auth@basic-auth
+igt@core_getclient
+igt@core_get_client_auth@master-drop
+igt@core_get_client_auth@simple
+igt@core_getstats
+igt@core_getversion
+igt@core_prop_blob@invalid-get-prop
+igt@core_prop_blob@blob-prop-lifetime
+igt@core_prop_blob@invalid-set-prop-any
+igt@core_prop_blob@invalid-set-prop
+igt@core_prop_blob@blob-prop-validate
+igt@core_prop_blob@blob-multiple
+igt@core_prop_blob@blob-prop-core
+igt@core_prop_blob@basic
+igt@core_prop_blob@invalid-get-prop-any
+igt@core_setmaster_vs_auth
+igt@drm_read@empty-nonblock
+igt@drm_read@short-buffer-block
+igt@drm_read@empty-block
+igt@drm_read@invalid-buffer
+igt@drm_read@short-buffer-nonblock
+igt@drm_read@fault-buffer
+igt@kms_addfb_basic@no-handle
+igt@kms_addfb_basic@bad-pitch-32
+igt@kms_addfb_basic@bad-pitch-999
+igt@kms_addfb_basic@invalid-set-prop-any
+igt@kms_addfb_basic@bad-pitch-0
+igt@kms_addfb_basic@bad-pitch-1024
+igt@kms_addfb_basic@bad-pitch-256
+igt@kms_addfb_basic@too-wide
+igt@kms_addfb_basic@small-bo
+igt@kms_addfb_basic@invalid-get-prop
+igt@kms_addfb_basic@basic
+igt@kms_addfb_basic@size-max
+igt@kms_addfb_basic@bad-pitch-128
+igt@kms_addfb_basic@invalid-get-prop-any
+igt@kms_addfb_basic@invalid-set-prop
+igt@kms_addfb_basic@bad-pitch-63
+igt@kms_render@direct-render
+igt@kms_setmode@invalid-clone-single-crtc-stealing
+igt@testdisplay
+igt@vgem_basic@mmap
+igt@vgem_basic@dmabuf-mmap
+igt@vgem_basic@dmabuf-fence-before
+igt@vgem_basic@dmabuf-export
+igt@vgem_basic@debugfs
+igt@vgem_basic@dmabuf-fence
+igt@vgem_basic@second-client
+igt@vgem_basic@sysfs
+igt@vgem_basic@unload
+igt@vgem_basic@create
+igt@kms_flip@wf_vblank-interruptible
+igt@kms_flip@flip-vs-dpms-off-vs-modeset
+igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset-interruptible
+igt@kms_flip@2x-wf_vblank-ts-check
+igt@kms_flip@absolute-wf_vblank
+igt@kms_flip@nonexisting-fb-interruptible
+igt@kms_flip@2x-flip-vs-rmfb-interruptible
+igt@kms_flip@2x-plain-flip-ts-check
+igt@kms_flip@2x-blocking-absolute-wf_vblank-interruptible
+igt@kms_flip@modeset-vs-vblank-race
+igt@kms_flip@2x-plain-flip-interruptible
+igt@kms_flip@2x-vblank-vs-dpms-suspend
+igt@kms_flip@nonexisting-fb
+igt@kms_flip@dpms-vs-vblank-race-interruptible
+igt@kms_flip@2x-flip-vs-blocking-wf-vblank
+igt@kms_flip@2x-modeset-vs-vblank-race-interruptible
+igt@kms_flip@2x-plain-flip
+igt@kms_flip@wf_vblank-ts-check
+igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset
+igt@kms_flip@2x-flip-vs-modeset
+igt@kms_flip@2x-absolute-wf_vblank-interruptible
+igt@kms_flip@absolute-wf_vblank-interruptible
+igt@kms_flip@blocking-absolute-wf_vblank
+igt@kms_flip@dpms-off-confusion-interruptible
+igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-modeset
+igt@kms_flip@flip-vs-expired-vblank-interruptible
+igt@kms_flip@2x-wf_vblank
+igt@kms_flip@flip-vs-dpms-off-vs-modeset-interruptible
+igt@kms_flip@vblank-vs-dpms-suspend-interruptible
+igt@kms_flip@flip-vs-modeset-interruptible
+igt@kms_flip@dpms-vs-vblank-race
+igt@kms_flip@2x-wf_vblank-interruptible
+igt@kms_flip@2x-single-buffer-flip-vs-dpms-off-vs-modeset-interruptible
+igt@kms_flip@basic-flip-vs-wf_vblank
+igt@kms_flip@basic-flip-vs-modeset
+igt@kms_flip@blocking-absolute-wf_vblank-interruptible
+igt@kms_flip@2x-flip-vs-modeset-interruptible
+igt@kms_flip@2x-flip-vs-panning-interruptible
+igt@kms_flip@flip-vs-blocking-wf-vblank
+igt@kms_flip@2x-dpms-vs-vblank-race-interruptible
+igt@kms_flip@flip-vs-panning-interruptible
+igt@kms_flip@vblank-vs-dpms-suspend
+igt@kms_flip@2x-flip-vs-expired-vblank-interruptible
+igt@kms_flip@2x-dpms-vs-vblank-race
+igt@kms_flip@2x-flip-vs-rmfb
+igt@kms_flip@2x-nonexisting-fb
+igt@kms_flip@blocking-wf_vblank
+igt@kms_flip@dpms-off-confusion
+igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Use drm_connector_list_iter in debugfs

[Patchwork]

== Series Details ==

Series: series starting with [1/6] drm/i915: Use drm_connector_list_iter in 
debugfs
URL   : https://patchwork.freedesktop.org/series/20441/
State : failure

== Summary ==

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

Test gem_ctx_create:
Subgroup basic-files:
pass   -> INCOMPLETE (fi-bdw-5557u)
Test kms_busy:
Subgroup basic-flip-default-a:
fail   -> PASS   (fi-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-n2820)

fi-bdw-5557u total:17   pass:16   dwarn:0   dfail:0   fail:0   skip:0  
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:246  dwarn:1   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

5e40124690ed25976cb436f1a3f83ba657b8fafb drm-tip: 2017y-03m-01d-09h-46m-54s UTC 
integration manifest
eb43dd1 drm/i915: Fix up verify_encoder_state
ea8bbb3 drm/i915: use for_each_intel_connector_iter in intel_display.c
87b27ca drm/i915: Make intel_get_pipe_from_connector atomic
d5d4e9b drm/i915: use drm_connector_list_iter in intel_opregion.c
ae16a12 drm/i915: use drm_connector_list_iter in intel_hotplug.c
47814de drm/i915: Use drm_connector_list_iter in debugfs

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4013/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx