[Intel-gfx] [PATCH v2] drm: i915: remove intel_hdmi variable declaration

2016-03-14 Thread Pierre-Louis Bossart
'intel_hdmi' variable was redeclared, use same variable declared in
function scope

Signed-off-by: Pierre-Louis Bossart 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index e2dab48..d031be6 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1418,8 +1418,6 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
intel_hdmi_unset_edid(connector);
 
if (intel_hdmi_set_edid(connector, live_status)) {
-   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
-
hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
status = connector_status_connected;
} else
-- 
1.9.1

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


Re: [Intel-gfx] [PATCH] drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write

2016-03-14 Thread Chris Wilson
On Mon, Mar 14, 2016 at 07:24:56PM +0100, Michał Winiarski wrote:
> On gen8+ size of PIPE_CONTROL with Post Sync Operation should be 6 dwords.

5 or 6 depending on the size of the write.

> Cc: Chris Wilson 
> Signed-off-by: Michał Winiarski 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 6fcbf6b..8fabca5 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1933,7 +1933,7 @@ static int gen8_emit_request_render(struct 
> drm_i915_gem_request *request)
>* need a prior CS_STALL, which is emitted by the flush
>* following the batch.
>*/
> - intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(5));
> + intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
>   intel_logical_ring_emit(ringbuf,
>   (PIPE_CONTROL_GLOBAL_GTT_IVB |
>PIPE_CONTROL_CS_STALL |
> @@ -1941,6 +1941,7 @@ static int gen8_emit_request_render(struct 
> drm_i915_gem_request *request)
>   intel_logical_ring_emit(ringbuf, hws_seqno_address(request->ring));
>   intel_logical_ring_emit(ringbuf, 0);
>   intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
> + intel_logical_ring_emit(ringbuf, 0);
>   intel_logical_ring_emit(ringbuf, MI_USER_INTERRUPT);

Qword alignment forgotten anyway.
-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: Adjust size of PIPE_CONTROL used for gen8 render seqno write

2016-03-14 Thread Michał Winiarski
On gen8+ size of PIPE_CONTROL with Post Sync Operation should be 6 dwords.

Cc: Chris Wilson 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6fcbf6b..8fabca5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1933,7 +1933,7 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
 * need a prior CS_STALL, which is emitted by the flush
 * following the batch.
 */
-   intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(5));
+   intel_logical_ring_emit(ringbuf, GFX_OP_PIPE_CONTROL(6));
intel_logical_ring_emit(ringbuf,
(PIPE_CONTROL_GLOBAL_GTT_IVB |
 PIPE_CONTROL_CS_STALL |
@@ -1941,6 +1941,7 @@ static int gen8_emit_request_render(struct 
drm_i915_gem_request *request)
intel_logical_ring_emit(ringbuf, hws_seqno_address(request->ring));
intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request));
+   intel_logical_ring_emit(ringbuf, 0);
intel_logical_ring_emit(ringbuf, MI_USER_INTERRUPT);
return intel_logical_ring_advance_and_submit(request);
 }
-- 
2.7.1

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


Re: [Intel-gfx] [PATCH] drm/i915/skl: Remove unused skl_disable_dc6 function

2016-03-14 Thread Imre Deak
On ma, 2016-03-14 at 14:35 +0100, Patrik Jakobsson wrote:
> Left behind by DC state rework and is no longer needed.
> 
> Cc: Imre Deak 
> Signed-off-by: Patrik Jakobsson 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_drv.h| 1 -
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 7 ---
>  2 files changed, 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 02b3d22..51c43e7 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1240,7 +1240,6 @@ void skl_init_cdclk(struct drm_i915_private
> *dev_priv);
>  int skl_sanitize_cdclk(struct drm_i915_private *dev_priv);
>  void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
>  void skl_enable_dc6(struct drm_i915_private *dev_priv);
> -void skl_disable_dc6(struct drm_i915_private *dev_priv);
>  void intel_dp_get_m_n(struct intel_crtc *crtc,
>     struct intel_crtc_state *pipe_config);
>  void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set
> m_n);
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 2e88a5e..316f96d 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -617,13 +617,6 @@ void skl_enable_dc6(struct drm_i915_private
> *dev_priv)
>  
>  }
>  
> -void skl_disable_dc6(struct drm_i915_private *dev_priv)
> -{
> - DRM_DEBUG_KMS("Disabling DC6\n");
> -
> - gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> -}
> -
>  static void skl_set_power_well(struct drm_i915_private *dev_priv,
>   struct i915_power_well *power_well, bool
> enable)
>  {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2] drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs

2016-03-14 Thread Imre Deak
After the commit below the Broxton PLL IDs had an off-by-one error, so
fix this up. Also add a missing brace at intel_shared_dpll_init(), it
happened to compile only due to the way the IS_BROXTON macro is defined.

v2:
- remove debugging left-over

Fixes: a3c988ea068c ("drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll 
code")
CC: Ander Conselvan de Oliveira 
CC: Maarten Lankhorst 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_display.c  | 6 +++---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 8 
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a720628..3cbb02b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9762,15 +9762,15 @@ static void bxt_get_ddi_pll(struct drm_i915_private 
*dev_priv,
switch (port) {
case PORT_A:
pipe_config->ddi_pll_sel = SKL_DPLL0;
-   id = DPLL_ID_SKL_DPLL1;
+   id = DPLL_ID_SKL_DPLL0;
break;
case PORT_B:
pipe_config->ddi_pll_sel = SKL_DPLL1;
-   id = DPLL_ID_SKL_DPLL2;
+   id = DPLL_ID_SKL_DPLL1;
break;
case PORT_C:
pipe_config->ddi_pll_sel = SKL_DPLL2;
-   id = DPLL_ID_SKL_DPLL3;
+   id = DPLL_ID_SKL_DPLL2;
break;
default:
DRM_ERROR("Incorrect port type\n");
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 4b636c4..74d5aec 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1706,9 +1706,9 @@ static const struct intel_dpll_mgr skl_pll_mgr = {
 };
 
 static const struct dpll_info bxt_plls[] = {
-   { "PORT PLL A", 0, _ddi_pll_funcs, 0 },
-   { "PORT PLL B", 1, _ddi_pll_funcs, 0 },
-   { "PORT PLL C", 2, _ddi_pll_funcs, 0 },
+   { "PORT PLL A", DPLL_ID_SKL_DPLL0, _ddi_pll_funcs, 0 },
+   { "PORT PLL B", DPLL_ID_SKL_DPLL1, _ddi_pll_funcs, 0 },
+   { "PORT PLL C", DPLL_ID_SKL_DPLL2, _ddi_pll_funcs, 0 },
{ NULL, -1, NULL, },
 };
 
@@ -1726,7 +1726,7 @@ void intel_shared_dpll_init(struct drm_device *dev)
 
if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
dpll_mgr = _pll_mgr;
-   else if IS_BROXTON(dev)
+   else if (IS_BROXTON(dev))
dpll_mgr = _pll_mgr;
else if (HAS_DDI(dev))
dpll_mgr = _pll_mgr;
-- 
2.5.0

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


[Intel-gfx] [PATCH] drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs

2016-03-14 Thread Imre Deak
After the commit below the Broxton PLL IDs had an off-by-one error, so
fix this up. Also add a missing brace at intel_shared_dpll_init(), it
happened to compile only due to the way the IS_BROXTON macro is defined.

Fixes: a3c988ea068c ("drm/i915: Make SKL/KBL DPLL0 managed by the shared dpll 
code")
CC: Ander Conselvan de Oliveira 
CC: Maarten Lankhorst 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_display.c  | 9 ++---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 8 
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a720628..0167f67 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9762,21 +9762,24 @@ static void bxt_get_ddi_pll(struct drm_i915_private 
*dev_priv,
switch (port) {
case PORT_A:
pipe_config->ddi_pll_sel = SKL_DPLL0;
-   id = DPLL_ID_SKL_DPLL1;
+   id = DPLL_ID_SKL_DPLL0;
break;
case PORT_B:
pipe_config->ddi_pll_sel = SKL_DPLL1;
-   id = DPLL_ID_SKL_DPLL2;
+   id = DPLL_ID_SKL_DPLL1;
break;
case PORT_C:
pipe_config->ddi_pll_sel = SKL_DPLL2;
-   id = DPLL_ID_SKL_DPLL3;
+   id = DPLL_ID_SKL_DPLL2;
break;
default:
DRM_ERROR("Incorrect port type\n");
return;
}
 
+   DRM_DEBUG_DRIVER("port %c PLL id %d\n", port_name(port),
+id);
+
pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 4b636c4..74d5aec 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1706,9 +1706,9 @@ static const struct intel_dpll_mgr skl_pll_mgr = {
 };
 
 static const struct dpll_info bxt_plls[] = {
-   { "PORT PLL A", 0, _ddi_pll_funcs, 0 },
-   { "PORT PLL B", 1, _ddi_pll_funcs, 0 },
-   { "PORT PLL C", 2, _ddi_pll_funcs, 0 },
+   { "PORT PLL A", DPLL_ID_SKL_DPLL0, _ddi_pll_funcs, 0 },
+   { "PORT PLL B", DPLL_ID_SKL_DPLL1, _ddi_pll_funcs, 0 },
+   { "PORT PLL C", DPLL_ID_SKL_DPLL2, _ddi_pll_funcs, 0 },
{ NULL, -1, NULL, },
 };
 
@@ -1726,7 +1726,7 @@ void intel_shared_dpll_init(struct drm_device *dev)
 
if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
dpll_mgr = _pll_mgr;
-   else if IS_BROXTON(dev)
+   else if (IS_BROXTON(dev))
dpll_mgr = _pll_mgr;
else if (HAS_DDI(dev))
dpll_mgr = _pll_mgr;
-- 
2.5.0

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


Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

2016-03-14 Thread Pierre-Louis Bossart

On 3/14/16 10:30 AM, Ville Syrjälä wrote:

On Mon, Mar 14, 2016 at 05:21:54PM +0200, Ville Syrjälä wrote:

On Mon, Mar 14, 2016 at 10:13:58AM -0500, Pierre-Louis Bossart wrote:

On 3/11/16 1:09 PM, Ville Syrjälä wrote:

On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:

Thanks for the review Ville

[snip]


Kinda hard to see where everything gets used due to the way the patches
are split up.


Yes, it's far from great...


At least the hotplug/mode change events are not needed. We only have the
two points where i915 should inform the audio driver about this stuff,
and those are the intel_audio_code_enable/disable(). For that we
already have the .pin_eld_notify() hook.

The interrupt stuff should mostly vanish from i915 with the subdevice
approach. As in i915 would just call the interrupt handler of the audio
driver based on the LPE bits in IIR, and the audio driver can then do
whatever it wants based on its own status register.


Are you saying that the subdevice would provide a read/write interface
for the audio driver to look at display registers, and the i915 driver
would only provide a notification interface (EDID and interrupts) to the
audio driver?


The audio driver would simply ioremap the appropriate range of
registers itself.


If yes, would there be two component framework links, one between
i915/audio driver and one between subdevice/audio driver.


Yeah sort of. i915 registers the platform device for the audio, the
audio driver can then bind to the device via the platform driver .probe
callback. It can then register with the audio component stuff at some
point to get the relevant notifications on the display state. When
i915 gets unloaded we remove the platform device, at which point the
audio driver's platform driver .remove() callback gets invoked and
it should unregister/cleanup everything.


we don't want to expose this interface when HDAudio is present and
enabled so we would need to add a test for this.
Also it looks like you want the creation of the platform device done in
i915, we were thinking of doing this as part of the audio drivers but in
the end this looks equivalent. In both cases we would end-up ignoring
the HAD022A8 HID and not use acpi for this extension


Well, if you have a device you can hang off from then i915 should need
to register it I suppose. Though that would make the interrupt
forwarding perhaps less nice. There's also the suspend/resume order
dependency to deal with if there's no parent/child relationship between
the devices.


Oh and I suppose you'd end up ioremapping part of the pci dev2 mmio bar
to get at the registers, which would look a bit funkly at least.


I understand the benefits of a parent/child device/subdevice model. What 
I don't see is whether we need the component framework at all here?
It was used in the case of HDaudio since both i915 and HDaudio 
controllers get probed at different times, here the HDMI interface is 
just a bunch of registers/DMA from the same hardware so the whole 
master/client interface exposed by the component framework to 'bind' 
independent drivers is a bit overkill?


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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove redundant memset in skl_clear_wm

2016-03-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove redundant memset in skl_clear_wm
URL   : https://patchwork.freedesktop.org/series/4436/
State : failure

== Summary ==

Series 4436v1 drm/i915: Remove redundant memset in skl_clear_wm
http://patchwork.freedesktop.org/api/1.0/series/4436/revisions/1/mbox/

Test drv_hangman:
Subgroup error-state-basic:
pass   -> INCOMPLETE (snb-dellxps)
Test gem_exec_basic:
Subgroup readonly-render:
incomplete -> PASS   (ilk-hp8440p)
Test gem_mmap_gtt:
Subgroup basic-write-no-prefault:
incomplete -> PASS   (ilk-hp8440p)
Test gem_ringfill:
Subgroup basic-default-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
incomplete -> DMESG-WARN (ilk-hp8440p)
Test gem_tiled_pread_basic:
incomplete -> PASS   (byt-nuc)
Test kms_addfb_basic:
Subgroup addfb25-yf-tiled:
incomplete -> PASS   (ilk-hp8440p)
Subgroup bad-pitch-1024:
incomplete -> PASS   (ilk-hp8440p)
Subgroup size-max:
incomplete -> PASS   (ilk-hp8440p)
Subgroup small-bo:
incomplete -> PASS   (ilk-hp8440p)
Subgroup unused-offsets:
incomplete -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-flip-vs-modeset:
incomplete -> PASS   (bsw-nuc-2)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (bdw-ultra)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (hsw-gt2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (snb-dellxps)
Test prime_self_import:
Subgroup basic-llseek-size:
incomplete -> PASS   (ilk-hp8440p)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:172  dwarn:1   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:154  dwarn:4   dfail:0   fail:1   skip:35 
hsw-brixbox  total:194  pass:172  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:177  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:194  pass:126  dwarn:4   dfail:0   fail:1   skip:63 
ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:66   pass:54   dwarn:1   dfail:0   fail:0   skip:10 
snb-x220ttotal:194  pass:159  dwarn:1   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1596/

3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 drm-intel-nightly: 
2016y-03m-14d-09h-06m-00s UTC integration manifest
f93db4af1658e9b9ab6007b6ba44efd33dd7be5b drm/i915: Remove redundant memset in 
skl_clear_wm

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


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

2016-03-14 Thread Martin Peres

On 10/03/16 10:39, Martin Peres wrote:

On 09/03/16 11:09, akash.g...@intel.com wrote:

From: Akash Goel 

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

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

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

Signed-off-by: Akash Goel 
Signed-off-by: Chris Wilson 
Reviewed-by: Damien Lespiau 


Chris, Damien,

Do you still stand by your S-o-b and R-b? If so, I can push the patch in
the coming days.


Another ping, with both Chris and Damien CCed this time.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2] i915: module param to disable DisplayPort MST

2016-03-14 Thread Nathan Schulte
Updated to resolve merge conflicts and rename parameter to match module style.

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


[Intel-gfx] [PATCH] [i915] add module param "enable_dp_mst"

2016-03-14 Thread Nathan Schulte
Adds an (unsafe; auto-kernel-tainting) boolean module parameter to the i915
drm driver: "enable_dp_mst", which is enabled by default.  Disabling the
parameter forces newly connected DisplayPort sinks to report as not
supporting multi-stream transport (MST), thus "forcing" the use of
single-stream transport (SST).
---
 drivers/gpu/drm/i915/i915_params.c | 5 +
 drivers/gpu/drm/i915/i915_params.h | 1 +
 drivers/gpu/drm/i915/intel_dp.c| 3 +++
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 278c9c4..97691f1 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,6 +56,7 @@ struct i915_params i915 __read_mostly = {
.edp_vswing = 0,
.enable_guc_submission = false,
.guc_log_level = -1,
+   .enable_dp_mst = true,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -201,3 +202,7 @@ MODULE_PARM_DESC(enable_guc_submission, "Enable GuC 
submission (default:false)")
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
"GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
+
+module_param_named_unsafe(enable_dp_mst, i915.enable_dp_mst, bool, 0600);
+MODULE_PARM_DESC(enable_dp_mst,
+   "Enable multi-stream transport (MST) for new DisplayPort sinks. 
(default: true)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index bd5026b..87153b0 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -59,6 +59,7 @@ struct i915_params {
bool enable_guc_submission;
bool verbose_state_checks;
bool nuclear_pageflip;
+   bool enable_dp_mst;
 };
 
 extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0e326e7..ba2d024 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3882,6 +3882,9 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
 {
u8 buf[1];
 
+   if (!i915.enable_dp_mst)
+   return false;
+
if (!intel_dp->can_mst)
return false;
 
-- 
2.7.0

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix power domain HW state cleanup on error path

2016-03-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix power domain HW state cleanup on error path
URL   : https://patchwork.freedesktop.org/series/4435/
State : failure

== Summary ==

Series 4435v1 drm/i915: Fix power domain HW state cleanup on error path
2016-03-14T14:52:33.167290 
http://patchwork.freedesktop.org/api/1.0/series/4435/revisions/1/mbox/
Applying: drm/i915: Fix power domain HW state cleanup on error path
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_dma.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_dma.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_dma.c
Patch failed at 0001 drm/i915: Fix power domain HW state cleanup on error path

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mocs: Program MOCS for all engines on init (rev6)

2016-03-14 Thread Patchwork
== Series Details ==

Series: drm/i915/mocs: Program MOCS for all engines on init (rev6)
URL   : https://patchwork.freedesktop.org/series/4310/
State : failure

== Summary ==

Series 4310v6 drm/i915/mocs: Program MOCS for all engines on init
http://patchwork.freedesktop.org/api/1.0/series/4310/revisions/6/mbox/

Test drv_hangman:
Subgroup error-state-basic:
pass   -> INCOMPLETE (snb-dellxps)
Test gem_exec_basic:
Subgroup readonly-render:
incomplete -> PASS   (ilk-hp8440p)
Test gem_mmap_gtt:
Subgroup basic-small-copy:
pass   -> DMESG-WARN (ilk-hp8440p)
Subgroup basic-write-no-prefault:
incomplete -> PASS   (ilk-hp8440p)
Test gem_ringfill:
Subgroup basic-default-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
incomplete -> DMESG-WARN (ilk-hp8440p)
Test kms_addfb_basic:
Subgroup addfb25-yf-tiled:
incomplete -> PASS   (ilk-hp8440p)
Subgroup bad-pitch-1024:
incomplete -> PASS   (ilk-hp8440p)
Subgroup size-max:
incomplete -> PASS   (ilk-hp8440p)
Subgroup small-bo:
incomplete -> PASS   (ilk-hp8440p)
Subgroup unused-offsets:
incomplete -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (bdw-ultra)
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
incomplete -> PASS   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (hsw-brixbox)
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (hsw-gt2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (snb-dellxps)
Test prime_self_import:
Subgroup basic-llseek-size:
incomplete -> PASS   (ilk-hp8440p)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:177  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:194  pass:124  dwarn:6   dfail:0   fail:1   skip:63 
ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:152  pass:124  dwarn:1   dfail:0   fail:0   skip:26 
snb-x220ttotal:194  pass:159  dwarn:1   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1594/

3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 drm-intel-nightly: 
2016y-03m-14d-09h-06m-00s UTC integration manifest
2825cd26c9cf60a6122737f79520aecde49098a1 drm/i915/mocs: Program MOCS for all 
engines on init

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


Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

2016-03-14 Thread Ville Syrjälä
On Mon, Mar 14, 2016 at 05:21:54PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 14, 2016 at 10:13:58AM -0500, Pierre-Louis Bossart wrote:
> > On 3/11/16 1:09 PM, Ville Syrjälä wrote:
> > > On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:
> > >> Thanks for the review Ville
> > >>
> > >> [snip]
> > >>
> > >>> Kinda hard to see where everything gets used due to the way the patches
> > >>> are split up.
> > >>
> > >> Yes, it's far from great...
> > >>
> > >>> At least the hotplug/mode change events are not needed. We only have the
> > >>> two points where i915 should inform the audio driver about this stuff,
> > >>> and those are the intel_audio_code_enable/disable(). For that we
> > >>> already have the .pin_eld_notify() hook.
> > >>>
> > >>> The interrupt stuff should mostly vanish from i915 with the subdevice
> > >>> approach. As in i915 would just call the interrupt handler of the audio
> > >>> driver based on the LPE bits in IIR, and the audio driver can then do
> > >>> whatever it wants based on its own status register.
> > >>
> > >> Are you saying that the subdevice would provide a read/write interface
> > >> for the audio driver to look at display registers, and the i915 driver
> > >> would only provide a notification interface (EDID and interrupts) to the
> > >> audio driver?
> > >
> > > The audio driver would simply ioremap the appropriate range of
> > > registers itself.
> > >
> > >> If yes, would there be two component framework links, one between
> > >> i915/audio driver and one between subdevice/audio driver.
> > >
> > > Yeah sort of. i915 registers the platform device for the audio, the
> > > audio driver can then bind to the device via the platform driver .probe
> > > callback. It can then register with the audio component stuff at some
> > > point to get the relevant notifications on the display state. When
> > > i915 gets unloaded we remove the platform device, at which point the
> > > audio driver's platform driver .remove() callback gets invoked and
> > > it should unregister/cleanup everything.
> > 
> > we don't want to expose this interface when HDAudio is present and 
> > enabled so we would need to add a test for this.
> > Also it looks like you want the creation of the platform device done in 
> > i915, we were thinking of doing this as part of the audio drivers but in 
> > the end this looks equivalent. In both cases we would end-up ignoring 
> > the HAD022A8 HID and not use acpi for this extension
> 
> Well, if you have a device you can hang off from then i915 should need
> to register it I suppose. Though that would make the interrupt
> forwarding perhaps less nice. There's also the suspend/resume order
> dependency to deal with if there's no parent/child relationship between
> the devices.

Oh and I suppose you'd end up ioremapping part of the pci dev2 mmio bar
to get at the registers, which would look a bit funkly at least.

> 
> > 
> > > I just tried to frob around with the VED code a bit, and got it to load
> > > at least. It's not quite happy about reloading i915 while the ipvr
> > > driver was loaded though. Not sure what's going on there, but I do
> > > think this approach should work. So the VED patch could serve as a
> > > decent enough model to follow.
> > >
> 
> -- 
> 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] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

2016-03-14 Thread Ville Syrjälä
On Mon, Mar 14, 2016 at 10:13:58AM -0500, Pierre-Louis Bossart wrote:
> On 3/11/16 1:09 PM, Ville Syrjälä wrote:
> > On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:
> >> Thanks for the review Ville
> >>
> >> [snip]
> >>
> >>> Kinda hard to see where everything gets used due to the way the patches
> >>> are split up.
> >>
> >> Yes, it's far from great...
> >>
> >>> At least the hotplug/mode change events are not needed. We only have the
> >>> two points where i915 should inform the audio driver about this stuff,
> >>> and those are the intel_audio_code_enable/disable(). For that we
> >>> already have the .pin_eld_notify() hook.
> >>>
> >>> The interrupt stuff should mostly vanish from i915 with the subdevice
> >>> approach. As in i915 would just call the interrupt handler of the audio
> >>> driver based on the LPE bits in IIR, and the audio driver can then do
> >>> whatever it wants based on its own status register.
> >>
> >> Are you saying that the subdevice would provide a read/write interface
> >> for the audio driver to look at display registers, and the i915 driver
> >> would only provide a notification interface (EDID and interrupts) to the
> >> audio driver?
> >
> > The audio driver would simply ioremap the appropriate range of
> > registers itself.
> >
> >> If yes, would there be two component framework links, one between
> >> i915/audio driver and one between subdevice/audio driver.
> >
> > Yeah sort of. i915 registers the platform device for the audio, the
> > audio driver can then bind to the device via the platform driver .probe
> > callback. It can then register with the audio component stuff at some
> > point to get the relevant notifications on the display state. When
> > i915 gets unloaded we remove the platform device, at which point the
> > audio driver's platform driver .remove() callback gets invoked and
> > it should unregister/cleanup everything.
> 
> we don't want to expose this interface when HDAudio is present and 
> enabled so we would need to add a test for this.
> Also it looks like you want the creation of the platform device done in 
> i915, we were thinking of doing this as part of the audio drivers but in 
> the end this looks equivalent. In both cases we would end-up ignoring 
> the HAD022A8 HID and not use acpi for this extension

Well, if you have a device you can hang off from then i915 should need
to register it I suppose. Though that would make the interrupt
forwarding perhaps less nice. There's also the suspend/resume order
dependency to deal with if there's no parent/child relationship between
the devices.

> 
> > I just tried to frob around with the VED code a bit, and got it to load
> > at least. It's not quite happy about reloading i915 while the ipvr
> > driver was loaded though. Not sure what's going on there, but I do
> > think this approach should work. So the VED patch could serve as a
> > decent enough model to follow.
> >

-- 
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 v6 4/7] drm/i915: Delay the freeing of requests until retire time

2016-03-14 Thread John Harrison

On 01/03/2016 15:18, Maarten Lankhorst wrote:

Hey,

Op 18-02-16 om 15:24 schreef john.c.harri...@intel.com:

From: John Harrison 

The request structure is reference counted. When the count reached
zero, the request was immediately freed and all associated objects
were unrefereced/unallocated. This meant that the driver mutex lock
must be held at the point where the count reaches zero. This was fine
while all references were held internally to the driver. However, the
plan is to allow the underlying fence object (and hence the request
itself) to be returned to other drivers and to userland. External
users cannot be expected to acquire a driver private mutex lock.

Rather than attempt to disentangle the request structure from the
driver mutex lock, the decsion was to defer the free code until a
later (safer) point. Hence this patch changes the unreference callback
to merely move the request onto a delayed free list. The driver's
retire worker thread will then process the list and actually call the
free function on the requests.

v2: New patch in series.

v3: Updated after review comments by Tvrtko Ursulin. Rename list nodes
to 'link' rather than 'list'. Update list processing to be more
efficient/safer with respect to spinlocks.

v4: Changed to use basic spinlocks rather than IRQ ones - missed
update from earlier feedback by Tvrtko.

v5: Improved a comment to keep the style checker happy.

For: VIZ-5190
Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 

Looks like Chris also mentioned it, but a fence can stay alive for an unknown 
period of time.

As a result when a fence is signaled all associated data should be freed as 
soon as the fence is signaled,
not when the last refcount is dropped to 0. This will remove the delayed free 
dance and clean up code. :)
I'm not sure what you mean. The delayed free thing is purely because 
freeing up the resources associated with the request requires holding 
the driver mutex lock - unpinning and freeing contexts basically. Chris 
has claimed that this is easy to resolve but it does not look trivial to 
me.


It might be possible to move the context, client and IRQ release from 
the final ref count -> 0 function to the retire function instead. I 
think that would be the soonest non-interrupt opportunity after the 
request has been signalled. I'm not sure it really buys you much though. 
The context is likely to be locked by a newer request anyway, the client 
release is only removing up a node from list and the IRQ is already 
being released at the point of signal (it is only in the ref -> 0 path 
for the case where the request got aborted before completing).


The real holder of resources is the object tracking code. It is the 
object/vma freeing when the object itself is retired that really 
releases memory. And that is not changing - it is not part of the 
request signal code path. That all happens from 
'i915_gem_retire_requests_ring' or from an explicit wait-on-request. It 
might be possible to trigger the process from the request signal handler 
as well but again, I can't see it being easy to make that IRQ-time 
friendly. I'm pretty sure it would have to be another deferred work 
handler rather than doing it in the IRQ.




~Maarten


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


[Intel-gfx] [PATCH] drm/i915: Remove redundant memset in skl_clear_wm

2016-03-14 Thread Gabriel Feceoru
Since I915_MAX_PLANES = PLANE_CURSOR + 1, explicit clearing the wm
values for PLANE_CURSOR is already done earlier by a memset.

Signed-off-by: Gabriel Feceoru 
---
 drivers/gpu/drm/i915/intel_pm.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f65e841..f6afeae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3641,7 +3641,6 @@ static void skl_clear_wm(struct skl_wm_values 
*watermarks, enum pipe pipe)
   sizeof(uint32_t) * 8 * I915_MAX_PLANES);
memset(watermarks->plane_trans[pipe],
   0, sizeof(uint32_t) * I915_MAX_PLANES);
-   watermarks->plane_trans[pipe][PLANE_CURSOR] = 0;
 
/* Clear ddb entries for pipe */
memset(>ddb.pipe[pipe], 0, sizeof(struct skl_ddb_entry));
@@ -3649,9 +3648,6 @@ static void skl_clear_wm(struct skl_wm_values 
*watermarks, enum pipe pipe)
   sizeof(struct skl_ddb_entry) * I915_MAX_PLANES);
memset(>ddb.y_plane[pipe], 0,
   sizeof(struct skl_ddb_entry) * I915_MAX_PLANES);
-   memset(>ddb.plane[pipe][PLANE_CURSOR], 0,
-  sizeof(struct skl_ddb_entry));
-
 }
 
 static void skl_update_wm(struct drm_crtc *crtc)
-- 
1.9.1

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


Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

2016-03-14 Thread Pierre-Louis Bossart

On 3/11/16 1:09 PM, Ville Syrjälä wrote:

On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:

Thanks for the review Ville

[snip]


Kinda hard to see where everything gets used due to the way the patches
are split up.


Yes, it's far from great...


At least the hotplug/mode change events are not needed. We only have the
two points where i915 should inform the audio driver about this stuff,
and those are the intel_audio_code_enable/disable(). For that we
already have the .pin_eld_notify() hook.

The interrupt stuff should mostly vanish from i915 with the subdevice
approach. As in i915 would just call the interrupt handler of the audio
driver based on the LPE bits in IIR, and the audio driver can then do
whatever it wants based on its own status register.


Are you saying that the subdevice would provide a read/write interface
for the audio driver to look at display registers, and the i915 driver
would only provide a notification interface (EDID and interrupts) to the
audio driver?


The audio driver would simply ioremap the appropriate range of
registers itself.


If yes, would there be two component framework links, one between
i915/audio driver and one between subdevice/audio driver.


Yeah sort of. i915 registers the platform device for the audio, the
audio driver can then bind to the device via the platform driver .probe
callback. It can then register with the audio component stuff at some
point to get the relevant notifications on the display state. When
i915 gets unloaded we remove the platform device, at which point the
audio driver's platform driver .remove() callback gets invoked and
it should unregister/cleanup everything.


we don't want to expose this interface when HDAudio is present and 
enabled so we would need to add a test for this.
Also it looks like you want the creation of the platform device done in 
i915, we were thinking of doing this as part of the audio drivers but in 
the end this looks equivalent. In both cases we would end-up ignoring 
the HAD022A8 HID and not use acpi for this extension



I just tried to frob around with the VED code a bit, and got it to load
at least. It's not quite happy about reloading i915 while the ipvr
driver was loaded though. Not sure what's going on there, but I do
think this approach should work. So the VED patch could serve as a
decent enough model to follow.



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


[Intel-gfx] [PATCH] drm/i915: Fix power domain HW state cleanup on error path

2016-03-14 Thread Imre Deak
Move the cleanup of the power domain HW state on the error path to the
same function where the corresponding init call was called from. I
noticed this problem when loading the module with load failure injection
enabled, making i915_load_modeset_init() fail.

CC: Chris Wilson 
Signed-off-by: Imre Deak 
---

[This depends on
 https://lists.freedesktop.org/archives/intel-gfx/2016-March/089597.html]

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

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 7490307..784e091 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -456,6 +456,7 @@ cleanup_irq:
intel_teardown_gmbus(dev);
 cleanup_csr:
intel_csr_ucode_fini(dev_priv);
+   intel_power_domains_fini(dev_priv);
vga_switcheroo_unregister_client(dev->pdev);
 cleanup_vga_client:
vga_client_register(dev->pdev, NULL, NULL, NULL);
@@ -1319,7 +1320,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
ret = i915_load_modeset_init(dev);
if (ret < 0) {
DRM_ERROR("failed to init modeset\n");
-   goto out_power_well;
+   goto out_cleanup_vblank;
}
 
i915_driver_register(dev_priv);
@@ -1330,8 +1331,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
 
return 0;
 
-out_power_well:
-   intel_power_domains_fini(dev_priv);
+out_cleanup_vblank:
drm_vblank_cleanup(dev);
 out_cleanup_hw:
i915_driver_cleanup_hw(dev_priv);
-- 
2.5.0

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


[Intel-gfx] [PATCH v4] drm/i915/mocs: Program MOCS for all engines on init

2016-03-14 Thread Peter Antoine
Allow for the MOCS to be programmed for all engines.
Currently we program the MOCS when the first render batch
goes through. This works on most platforms but fails on
platforms that do not run a render batch early,
i.e. headless servers. The patch now programs all initialised engines
on init and the RCS is programmed again within the initial batch. This
is done for predictable consistency with regards to the hardware
context.

Hardware context loading sets the values of the MOCS for RCS
and L3CC. Programming them from within the batch makes sure that
the render context is valid, no matter what the previous state of
the saved-context was.

v2: posted correct version to the mailing list.
v3: moved programming to within engine->init_hw() (Chris Wilson)
v4: code formatting and white-space changes. (Chris Wilson)

Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/i915_gem.c   |   3 +
 drivers/gpu/drm/i915/intel_lrc.c  |   2 +-
 drivers/gpu/drm/i915/intel_mocs.c | 132 ++
 drivers/gpu/drm/i915/intel_mocs.h |   2 +
 4 files changed, 110 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b854af2..73e4892 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -32,6 +32,7 @@
 #include "i915_vgpu.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
+#include "intel_mocs.h"
 #include 
 #include 
 #include 
@@ -4882,6 +4883,8 @@ i915_gem_init_hw(struct drm_device *dev)
goto out;
}
 
+   intel_mocs_init_l3cc_table(dev);
+
/* We can't enable contexts until all firmware is loaded */
if (HAS_GUC_UCODE(dev)) {
ret = intel_guc_ucode_load(dev);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 27c9ee3..03ead7f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1603,7 +1603,7 @@ static int gen8_init_common_ring(struct intel_engine_cs 
*ring)
 
memset(>hangcheck, 0, sizeof(ring->hangcheck));
 
-   return 0;
+   return intel_mocs_init_engine(ring);
 }
 
 static int gen8_init_render_ring(struct intel_engine_cs *ring)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
b/drivers/gpu/drm/i915/intel_mocs.c
index fed7bea..8e490af 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -128,9 +128,9 @@ static const struct drm_i915_mocs_entry 
broxton_mocs_table[] = {
 
 /**
  * get_mocs_settings()
- * @dev:DRM device.
+ * @dev:   DRM device.
  * @table:  Output table that will be made to point at appropriate
- *  MOCS values for the device.
+ *   MOCS values for the device.
  *
  * This function will return the values of the MOCS table that needs to
  * be programmed for the platform. It will return the values that need
@@ -179,6 +179,47 @@ static i915_reg_t mocs_register(enum intel_ring_id ring, 
int index)
 }
 
 /**
+ * intel_mocs_init_engine() - emit the mocs control table
+ * @ring:  The engine for whom to emit the registers.
+ *
+ * This function simply emits a MI_LOAD_REGISTER_IMM command for the
+ * given table starting at the given address.
+ *
+ * Return: 0 on success, otherwise the error status.
+ */
+int intel_mocs_init_engine(struct intel_engine_cs *ring)
+{
+   struct drm_device *dev = ring->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_mocs_table table;
+   unsigned int index;
+
+   if (!get_mocs_settings(dev, ))
+   return 0;
+
+   if (WARN_ON(table.size > GEN9_NUM_MOCS_ENTRIES))
+   return -ENODEV;
+
+   for (index = 0; index < table.size; index++)
+   I915_WRITE(mocs_register(ring->id, index),
+  table.table[index].control_value);
+
+   /*
+* Ok, now set the unused entries to uncached. These entries
+* are officially undefined and no contract for the contents
+* and settings is given for these entries.
+*
+* Entry 0 in the table is uncached - so we are just writing
+* that value to all the used entries.
+*/
+   for (; index < GEN9_NUM_MOCS_ENTRIES; index++)
+   I915_WRITE(mocs_register(ring->id, index),
+  table.table[0].control_value);
+
+   return 0;
+}
+
+/**
  * emit_mocs_control_table() - emit the mocs control table
  * @req:   Request to set up the MOCS table for.
  * @table: The values to program into the control regs.
@@ -234,6 +275,14 @@ static int emit_mocs_control_table(struct 
drm_i915_gem_request *req,
return 0;
 }
 
+static inline u32 l3cc_combine(const struct drm_i915_mocs_table *table,
+  u16 low,
+  u16 high)
+{
+   return table->table[low].l3cc_value |
+  table->table[high].l3cc_value << 16;
+}
+
 /**
  * 

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add fault injection support (rev3)

2016-03-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Add fault injection support (rev3)
URL   : https://patchwork.freedesktop.org/series/4385/
State : failure

== Summary ==

Series 4385v3 drm/i915: Add fault injection support
2016-03-14T14:37:24.542491 
http://patchwork.freedesktop.org/api/1.0/series/4385/revisions/3/mbox/
Applying: drm/i915: Add fault injection support
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_dma.c
M   drivers/gpu/drm/i915/i915_drv.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_drv.h
Auto-merging drivers/gpu/drm/i915/i915_dma.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_dma.c
Patch failed at 0001 drm/i915: Add fault injection support

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


[Intel-gfx] [PATCH v3] drm/i915: Add fault injection support

2016-03-14 Thread Imre Deak
Add support for forcing an error at selected places in the driver. As an
example add 4 options to fail during driver loading.

Requested by Chris.

v2:
- Add fault point for modeset initialization
- Print debug message when injecting an error
v3:
- Rename inject_fault to inject_load_failure, rename the related macros
  and helper accordingly (Chris)

CC: Chris Wilson 
Signed-off-by: Imre Deak 
---

[This depends on
 https://lists.freedesktop.org/archives/intel-gfx/2016-March/089597.html]

 drivers/gpu/drm/i915/i915_dma.c| 12 
 drivers/gpu/drm/i915/i915_drv.h| 16 
 drivers/gpu/drm/i915/i915_params.c |  5 +
 drivers/gpu/drm/i915/i915_params.h |  1 +
 4 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a5121cd..7490307 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -370,6 +370,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
 
+   if (i915_inject_load_failure(I915_FAIL_INIT_MODESET))
+   return -ENODEV;
+
ret = intel_bios_init(dev_priv);
if (ret)
DRM_INFO("failed to find VBIOS tables\n");
@@ -950,6 +953,9 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
struct intel_device_info *device_info;
int ret = 0;
 
+   if (i915_inject_load_failure(I915_FAIL_INIT_EARLY))
+   return -ENODEV;
+
dev_priv->dev = dev;
 
/* Setup the write-once "constant" device info */
@@ -1064,6 +1070,9 @@ static int i915_driver_init_mmio(struct drm_i915_private 
*dev_priv)
struct drm_device *dev = dev_priv->dev;
int ret;
 
+   if (i915_inject_load_failure(I915_FAIL_INIT_MMIO))
+   return -ENODEV;
+
if (i915_get_bridge_dev(dev))
return -EIO;
 
@@ -1107,6 +1116,9 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
uint32_t aperture_size;
int ret;
 
+   if (i915_inject_load_failure(I915_FAIL_INIT_HW))
+   return -ENODEV;
+
intel_device_info_runtime_init(dev);
 
ret = i915_gem_gtt_init(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 25274e1..e2d21d5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -98,6 +98,22 @@
 #define I915_STATE_WARN_ON(x)  \
I915_STATE_WARN((x), "%s", "WARN_ON(" __stringify(x) ")")
 
+#define I915_FAIL_INIT_EARLY   BIT(0)
+#define I915_FAIL_INIT_MMIOBIT(1)
+#define I915_FAIL_INIT_HW  BIT(2)
+#define I915_FAIL_INIT_MODESET BIT(3)
+
+static inline bool i915_inject_load_failure(unsigned int fail_mask)
+{
+   if (i915.inject_load_failure & fail_mask) {
+   DRM_DEBUG_DRIVER("Injecting failure %08x\n", fail_mask);
+
+   return true;
+   }
+
+   return false;
+}
+
 static inline const char *yesno(bool v)
 {
return v ? "yes" : "no";
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 278c9c4..4faeeed 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,6 +56,7 @@ struct i915_params i915 __read_mostly = {
.edp_vswing = 0,
.enable_guc_submission = false,
.guc_log_level = -1,
+   .inject_load_failure = 0,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -201,3 +202,7 @@ MODULE_PARM_DESC(enable_guc_submission, "Enable GuC 
submission (default:false)")
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
"GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
+
+module_param_named(inject_load_failure, i915.inject_load_failure, uint, 0600);
+MODULE_PARM_DESC(inject_load_failure,
+   "Force an error at selected points (0:disabled, 0x1:INIT_EARLY, 
0x2:INIT_MMIO, 0x4:INIT_HW, 0x8:INIT_MODESET)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index bd5026b..b691026 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -59,6 +59,7 @@ struct i915_params {
bool enable_guc_submission;
bool verbose_state_checks;
bool nuclear_pageflip;
+   unsigned int inject_load_failure;
 };
 
 extern struct i915_params i915 __read_mostly;
-- 
2.5.0

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


Re: [Intel-gfx] [PATCH v3] drm/i915/mocs: Program MOCS for all engines on init

2016-03-14 Thread Peter Antoine

On Fri, 11 Mar 2016, Chris Wilson wrote:


On Fri, Mar 11, 2016 at 02:00:22PM +, Peter Antoine wrote:

Allow for the MOCS to be programmed for all engines.
Currently we program the MOCS when the first render batch
goes through. This works on most platforms but fails on
platforms that do not run a render batch early,
i.e. headless servers. The patch now programs all initialised engines
on init and the RCS is programmed again within the initial batch. This
is done for predictable consistency with regards to the hardware
context.

Hardware context loading sets the values of the MOCS for RCS
and L3CC. Programming them from within the batch makes sure that
the render context is valid, no matter what the previous state of
the saved-context was.

v2: posted correct version to the mailing list.
v3: moved programming to within engine->init_hw() (Chris Wilson)

Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/i915_gem.c   |   3 +
 drivers/gpu/drm/i915/intel_lrc.c  |   4 ++
 drivers/gpu/drm/i915/intel_mocs.c | 120 +-
 drivers/gpu/drm/i915/intel_mocs.h |   2 +
 4 files changed, 114 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b854af2..3e18cbd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -32,6 +32,7 @@
 #include "i915_vgpu.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
+#include "intel_mocs.h"
 #include 
 #include 
 #include 
@@ -4882,6 +4883,8 @@ i915_gem_init_hw(struct drm_device *dev)
goto out;
}

+   program_mocs_l3cc_table(dev);


intel_mocs_init_l3cc_table(dev_priv);


Changed.



+
/* We can't enable contexts until all firmware is loaded */
if (HAS_GUC_UCODE(dev)) {
ret = intel_guc_ucode_load(dev);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 27c9ee3..2ef7a161 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1603,6 +1603,8 @@ static int gen8_init_common_ring(struct intel_engine_cs 
*ring)

memset(>hangcheck, 0, sizeof(ring->hangcheck));

+   program_mocs_control_table(ring);


ret = intel_mocs_init_engine(ring);



Check and propagate the errors!

Ok.



+
return 0;
 }

@@ -2151,6 +2153,8 @@ static int logical_render_ring_init(struct drm_device 
*dev)
  ret);
}

+   program_mocs_control_table(ring);


Due to the splitting inside intel_lrc, it actually makes sense to do a
ret = engine->init_hw(engine) call here. But for the time being, adding
the setup here is redundant.


This call is not required and has been removed.

 /**
+ * program_mocs_control_table() - emit the mocs control table
+ * @ring:  The engine for whom to emit the registers.
+ *
+ * This function simply emits a MI_LOAD_REGISTER_IMM command for the
+ * given table starting at the given address.
+ *
+ * Return: 0 on success, otherwise the error status.
+ */
+int program_mocs_control_table(struct intel_engine_cs *ring)
+{
+   struct drm_device *dev = ring->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_i915_mocs_table table;
+   unsigned int index;
+
+   if (get_mocs_settings(dev, )) {


if (!get_mocs_setttings())
return 0;

And then we can lose one level of indentation.

Ok. I like the indentation I find it easier to read. But will change.




+   if (WARN_ON(table.size > GEN9_NUM_MOCS_ENTRIES))
+   return -ENODEV;
+
+   for (index = 0; index < table.size; index++) {
+   I915_WRITE(mocs_register(ring->id, index),
+   table.table[index].control_value);


Whitespace makes this easier to read. Please align continuation lines
with the opening bracket.

Ok.




+   }
+
+   /*
+* Ok, now set the unused entries to uncached. These entries
+* are officially undefined and no contract for the contents
+* and settings is given for these entries.
+*
+* Entry 0 in the table is uncached - so we are just writing
+* that value to all the used entries.
+*/
+   for (; index < GEN9_NUM_MOCS_ENTRIES; index++) {
+   I915_WRITE(mocs_register(ring->id, index),
+   table.table[0].control_value);


Especially here.

done.



+   }
+   }
+
+   return 0;
+}
+
+/**
  * emit_mocs_control_table() - emit the mocs control table
  * @req:   Request to set up the MOCS table for.
  * @table: The values to program into the control regs.
@@ -210,7 +252,8 @@ static int emit_mocs_control_table(struct 
drm_i915_gem_request *req,
MI_LOAD_REGISTER_IMM(GEN9_NUM_MOCS_ENTRIES));

 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for DPCD Backlight Control (rev4)

2016-03-14 Thread Adebisi, YetundeX
It doesn’t look like any of these warnings have anything to do with my patch.

They mostly have to do with " Device suspended during HW access" from 
drm_atomic_commit  call.
The fail on snb-x220t is a pre-existing one  and the last one is " *ERROR* 
Unclaimed access detected prior to suspending" on bdw-ultra which is also 
pre-existing. 

-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org] 
Sent: Monday, March 07, 2016 5:55 PM
To: Adebisi, YetundeX
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for DPCD Backlight Control (rev4)

== Series Details ==

Series: DPCD Backlight Control (rev4)
URL   : https://patchwork.freedesktop.org/series/1864/
State : failure

== Summary ==

Series 1864v4 DPCD Backlight Control
http://patchwork.freedesktop.org/api/1.0/series/1864/revisions/4/mbox/

Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (hsw-gt2)
skip   -> DMESG-WARN (hsw-brixbox)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (snb-x220t)
Subgroup suspend-read-crc-pipe-a:
pass   -> SKIP   (byt-nuc)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-fail -> FAIL   (snb-x220t)
dmesg-warn -> PASS   (bsw-nuc-2)
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)
dmesg-warn -> PASS   (snb-dellxps)

bdw-nuci7total:183  pass:172  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:183  pass:164  dwarn:1   dfail:0   fail:0   skip:18 
bsw-nuc-2total:183  pass:148  dwarn:1   dfail:0   fail:0   skip:34 
byt-nuc  total:183  pass:151  dwarn:0   dfail:0   fail:0   skip:32 
hsw-brixbox  total:183  pass:163  dwarn:1   dfail:0   fail:0   skip:19 
hsw-gt2  total:183  pass:169  dwarn:0   dfail:0   fail:0   skip:14 
ivb-t430stotal:183  pass:162  dwarn:0   dfail:0   fail:0   skip:21 
skl-i5k-2total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20 
skl-i7k-2total:183  pass:163  dwarn:0   dfail:0   fail:0   skip:20 
snb-dellxps  total:183  pass:153  dwarn:1   dfail:0   fail:0   skip:29 
snb-x220ttotal:183  pass:153  dwarn:1   dfail:0   fail:1   skip:28 

Results at /archive/results/CI_IGT_test/Patchwork_1536/

0fd8a4bae2f65cf961a055bd40ad5083c6fb483a drm-intel-nightly: 
2016y-03m-07d-16h-40m-01s UTC integration manifest
9a6e2273023028048b8fd0b2870c4528d77b8a85 drm/i915: Add backlight Control using 
DPCD registers for DP connectors
b2eb6e0a2948737aefcfa5d3d2f4e1ad236fb389 drm/i915: Add Backlight Control using 
DPCD for eDP connectors (v7)
6609c0fbeb01f51631a56a39c4f95e37ec294978 drm/dp: Add definition for Display 
Control DPCD Registers capability size

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl: Remove unused skl_disable_dc6 function

2016-03-14 Thread Patchwork
== Series Details ==

Series: drm/i915/skl: Remove unused skl_disable_dc6 function
URL   : https://patchwork.freedesktop.org/series/4427/
State : failure

== Summary ==

Series 4427v1 drm/i915/skl: Remove unused skl_disable_dc6 function
http://patchwork.freedesktop.org/api/1.0/series/4427/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (ivb-t430s)
Test gem_exec_basic:
Subgroup readonly-render:
incomplete -> PASS   (ilk-hp8440p)
Test gem_mmap_gtt:
Subgroup basic-write-no-prefault:
incomplete -> PASS   (ilk-hp8440p)
Test gem_ringfill:
Subgroup basic-default-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
incomplete -> DMESG-WARN (ilk-hp8440p)
Test gem_tiled_pread_basic:
incomplete -> PASS   (byt-nuc)
Test kms_addfb_basic:
Subgroup addfb25-yf-tiled:
incomplete -> PASS   (ilk-hp8440p)
Subgroup bad-pitch-1024:
incomplete -> PASS   (ilk-hp8440p)
Subgroup size-max:
incomplete -> PASS   (ilk-hp8440p)
Subgroup small-bo:
incomplete -> PASS   (ilk-hp8440p)
Subgroup unused-offsets:
incomplete -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-flip-vs-modeset:
incomplete -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ilk-hp8440p) UNSTABLE
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (hsw-gt2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (snb-dellxps)
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)
Test prime_self_import:
Subgroup basic-llseek-size:
incomplete -> PASS   (ilk-hp8440p)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:156  dwarn:1   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:154  dwarn:4   dfail:0   fail:1   skip:35 
hsw-brixbox  total:194  pass:172  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:86   pass:75   dwarn:0   dfail:0   fail:0   skip:10 
ilk-hp8440p  total:194  pass:124  dwarn:5   dfail:0   fail:2   skip:63 
ivb-t430stotal:194  pass:168  dwarn:0   dfail:0   fail:0   skip:26 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:194  pass:158  dwarn:2   dfail:0   fail:0   skip:34 
snb-x220ttotal:194  pass:159  dwarn:1   dfail:1   fail:0   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1592/

3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 drm-intel-nightly: 
2016y-03m-14d-09h-06m-00s UTC integration manifest
a4a6b3ddd6457b4cddc4fd149bac99c1af7c989c drm/i915/skl: Remove unused 
skl_disable_dc6 function

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


Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

2016-03-14 Thread Ville Syrjälä
On Mon, Mar 14, 2016 at 10:04:00AM +0100, Daniel Vetter wrote:
> On Fri, Mar 11, 2016 at 09:09:12PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:
> > > Thanks for the review Ville
> > > 
> > > [snip]
> > > 
> > > > Kinda hard to see where everything gets used due to the way the patches
> > > > are split up.
> > > 
> > > Yes, it's far from great...
> > > 
> > > > At least the hotplug/mode change events are not needed. We only have the
> > > > two points where i915 should inform the audio driver about this stuff,
> > > > and those are the intel_audio_code_enable/disable(). For that we
> > > > already have the .pin_eld_notify() hook.
> > > >
> > > > The interrupt stuff should mostly vanish from i915 with the subdevice
> > > > approach. As in i915 would just call the interrupt handler of the audio
> > > > driver based on the LPE bits in IIR, and the audio driver can then do
> > > > whatever it wants based on its own status register.
> > > 
> > > Are you saying that the subdevice would provide a read/write interface 
> > > for the audio driver to look at display registers, and the i915 driver 
> > > would only provide a notification interface (EDID and interrupts) to the 
> > > audio driver?
> > 
> > The audio driver would simply ioremap the appropriate range of
> > registers itself.
> > 
> > > If yes, would there be two component framework links, one between 
> > > i915/audio driver and one between subdevice/audio driver.
> > 
> > Yeah sort of. i915 registers the platform device for the audio, the
> > audio driver can then bind to the device via the platform driver .probe
> > callback. It can then register with the audio component stuff at some
> > point to get the relevant notifications on the display state. When
> > i915 gets unloaded we remove the platform device, at which point the
> > audio driver's platform driver .remove() callback gets invoked and
> > it should unregister/cleanup everything.
> > 
> > I just tried to frob around with the VED code a bit, and got it to load
> > at least. It's not quite happy about reloading i915 while the ipvr
> > driver was loaded though. Not sure what's going on there, but I do
> > think this approach should work. So the VED patch could serve as a
> > decent enough model to follow.
> 
> platform devices registerd by modules are apparently inherently racy and
> in an unfixable way. At least I remember something like that from VED
> discussion.
> 
> In short you _must_ unload VED manually before unloading i915, or it all
> goes boom. If this is the only thing that went boom it's acceptable.

VED goes boom due drm_global_mutex deadlock at least if you load
i915 while ipvr is already loaded. I didn't check to hard if there
were any booms on pure unload so far.

Anyways, I was a bit worried about the races so I did a pair of 
small test modules to try out this model, and to me it looked to
work so far. I just unregistered the platform device from the parent
pci driver .remove() hook, and it got blocked until the platform
driver's .remove() hook was done.

In any case if this is broken, then I assume mfd must be broken. And
that thing is at least used quite extensively.

-- 
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 2/8] drm/i915: Merge ironlake_get_refclk() into its only caller

2016-03-14 Thread Conselvan De Oliveira, Ander
On Mon, 2016-03-14 at 15:55 +0200, Ville Syrjälä wrote:
> On Mon, Mar 14, 2016 at 10:55:41AM +0200, Ander Conselvan de Oliveira wrote:
> > A previous patche made ironlake_get_refclk() very simple, so merge
> > it into its only caller.
> 
> Again I'd like to keep the pch and gmch code as similar as possible.
> So could do the same for the gmch code.
> 
> I already had a patch in my lvds_downclock branch that moved some of
> the gmch platform differences out from i9xx_get_refclk() into the
> caller, so I guess might as well move the whole thing I suppose.

I think we should just split i9xx_crtc_compute_clock() into more platform
specific functions and kill i9xx_get_reclk(), intel_limit() and ->find_dpll().
We are jumping through hoops to make the code look like it's generic, but there
is a lot of platform specific details. IMO it would be a lot easier to read that
way.

I wrote some patches going into that direction today. The end result looks like
the following:

static int chv_crtc_compute_clock(struct intel_crtc *crtc,
  struct intel_crtc_state *crtc_state)
{
int refclk;
bool ok;
const intel_limit_t *limit;

memset(_state->dpll_hw_state, 0,
   sizeof(crtc_state->dpll_hw_state));

if (crtc_state->has_dsi_encoder)
return 0;

limit = _limits_chv;

if (!crtc_state->clock_set) {
refclk = 10;

ok = chv_find_best_dpll(limit, crtc_state,
crtc_state->port_clock, refclk,
NULL, _state->dpll);
if (!ok) {
DRM_ERROR("Couldn't find PLL settings for mode!\n");
return -EINVAL;
}
}

chv_compute_dpll(crtc, crtc_state);

return 0;
}

static int vlv_crtc_compute_clock(struct intel_crtc *crtc,
  struct intel_crtc_state *crtc_state)
{
int refclk;
bool ok;
const intel_limit_t *limit;

memset(_state->dpll_hw_state, 0,
   sizeof(crtc_state->dpll_hw_state));

if (crtc_state->has_dsi_encoder)
return 0;

limit = _limits_vlv;

if (!crtc_state->clock_set) {
refclk = 10;

ok = vlv_find_best_dpll(limit, crtc_state,
crtc_state->port_clock, refclk,
NULL, _state->dpll);
if (!ok) {
DRM_ERROR("Couldn't find PLL settings for mode!\n");
return -EINVAL;
}
}

vlv_compute_dpll(crtc, crtc_state);

return 0;
}

static int gen2_crtc_compute_clock(struct intel_crtc *crtc,
   struct intel_crtc_state *crtc_state)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
int refclk;
const intel_limit_t *limit;

memset(_state->dpll_hw_state, 0,
   sizeof(crtc_state->dpll_hw_state));

if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
intel_panel_use_ssc(dev_priv)) {
refclk = dev_priv->vbt.lvds_ssc_freq;
DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n", refclk);
} else {
refclk = 48000;
}

if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS))
limit = _limits_i8xx_lvds;
else if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_DVO))
limit = _limits_i8xx_dvo;
else
limit = _limits_i8xx_dac;

if (!crtc_state->clock_set &&
!i9xx_find_best_dpll(limit, crtc_state, crtc_state->port_clock,
 refclk, NULL, _state->dpll)) {
DRM_ERROR("Couldn't find PLL settings for mode!\n");
return -EINVAL;
}

i8xx_compute_dpll(crtc, crtc_state, NULL);

return 0;
}

static int i9xx_crtc_compute_clock(struct intel_crtc *crtc,
   struct intel_crtc_state *crtc_state)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
int refclk;
bool ok;
const intel_limit_t *limit;

memset(_state->dpll_hw_state, 0,
   sizeof(crtc_state->dpll_hw_state));

if (crtc_state->has_dsi_encoder)
return 0;

if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
intel_panel_use_ssc(dev_priv)) {
refclk = dev_priv->vbt.lvds_ssc_freq;
DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n", refclk);
} else {
refclk = 96000;
}

if (!crtc_state->clock_set) {
/*
 * 

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Remove checks for clone config with LVDS in ILK+ dpll code

2016-03-14 Thread Ville Syrjälä
On Mon, Mar 14, 2016 at 01:55:49PM +, Conselvan De Oliveira, Ander wrote:
> On Mon, 2016-03-14 at 15:51 +0200, Ville Syrjälä wrote:
> > On Mon, Mar 14, 2016 at 10:55:40AM +0200, Ander Conselvan de Oliveira wrote:
> > > LVDS is not cloneable, so the check is unnecessary. Removing it makes
> > > the surrouding code a bit simpler.
> > > 
> > > Signed-off-by: Ander Conselvan de Oliveira <
> > > ander.conselvan.de.olive...@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 31 ---
> > >  1 file changed, 4 insertions(+), 27 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 2d151ad..e7d6584 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -8593,30 +8593,9 @@ static int ironlake_get_refclk(struct
> > > intel_crtc_state *crtc_state)
> > >  {
> > >   struct drm_device *dev = crtc_state->base.crtc->dev;
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > > - struct drm_atomic_state *state = crtc_state->base.state;
> > > - struct drm_connector *connector;
> > > - struct drm_connector_state *connector_state;
> > > - struct intel_encoder *encoder;
> > > - int num_connectors = 0, i;
> > > - bool is_lvds = false;
> > > -
> > > - for_each_connector_in_state(state, connector, connector_state, i) {
> > > - if (connector_state->crtc != crtc_state->base.crtc)
> > > - continue;
> > > -
> > > - encoder = to_intel_encoder(connector_state->best_encoder);
> > > -
> > > - switch (encoder->type) {
> > > - case INTEL_OUTPUT_LVDS:
> > > - is_lvds = true;
> > > - break;
> > > - default:
> > > - break;
> > > - }
> > > - num_connectors++;
> > > - }
> > >  
> > > - if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2)
> > > {
> > 
> > We have the exact same checks in the gmch code as well. For consistency
> > you should change those as well.
> 
> True. Would it be ok in a follow-up patch? I did that today now that I started
> doing some clean ups for i9xx_crtc_compute_clock(). If not, I can resend.

Followup is fine by me. I had some dpll code unification patches in my
lvds_downclock branch too, feel free to steal any if you think they are
helpful. Hoping I can reduce that branch as much as possuble before I
start bombing the list with it :P

> 
> Thanks,
> Ander
> 
> > 
> > > + if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> > > + intel_panel_use_ssc(dev_priv)) {
> > >   DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
> > > dev_priv->vbt.lvds_ssc_freq);
> > >   return dev_priv->vbt.lvds_ssc_freq;
> > > @@ -8842,7 +8821,7 @@ static uint32_t ironlake_compute_dpll(struct
> > > intel_crtc *intel_crtc,
> > >   struct drm_connector_state *connector_state;
> > >   struct intel_encoder *encoder;
> > >   uint32_t dpll;
> > > - int factor, num_connectors = 0, i;
> > > + int factor, i;
> > >   bool is_lvds = false, is_sdvo = false;
> > >  
> > >   for_each_connector_in_state(state, connector, connector_state, i) {
> > > @@ -8862,8 +8841,6 @@ static uint32_t ironlake_compute_dpll(struct
> > > intel_crtc *intel_crtc,
> > >   default:
> > >   break;
> > >   }
> > > -
> > > - num_connectors++;
> > >   }
> > >  
> > >   /* Enable autotuning of the PLL clock (if permissible) */
> > > @@ -8917,7 +8894,7 @@ static uint32_t ironlake_compute_dpll(struct
> > > intel_crtc *intel_crtc,
> > >   break;
> > >   }
> > >  
> > > - if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2)
> > > + if (is_lvds && intel_panel_use_ssc(dev_priv))
> > >   dpll |= PLLB_REF_INPUT_SPREADSPECTRUMIN;
> > >   else
> > >   dpll |= PLL_REF_INPUT_DREFCLK;
> > > -- 
> > > 2.4.3
> > > 
> > > ___
> > > 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/8] drm/i915: Remove checks for clone config with LVDS in ILK+ dpll code

2016-03-14 Thread Conselvan De Oliveira, Ander
On Mon, 2016-03-14 at 15:51 +0200, Ville Syrjälä wrote:
> On Mon, Mar 14, 2016 at 10:55:40AM +0200, Ander Conselvan de Oliveira wrote:
> > LVDS is not cloneable, so the check is unnecessary. Removing it makes
> > the surrouding code a bit simpler.
> > 
> > Signed-off-by: Ander Conselvan de Oliveira <
> > ander.conselvan.de.olive...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 31 ---
> >  1 file changed, 4 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 2d151ad..e7d6584 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8593,30 +8593,9 @@ static int ironlake_get_refclk(struct
> > intel_crtc_state *crtc_state)
> >  {
> > struct drm_device *dev = crtc_state->base.crtc->dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > -   struct drm_atomic_state *state = crtc_state->base.state;
> > -   struct drm_connector *connector;
> > -   struct drm_connector_state *connector_state;
> > -   struct intel_encoder *encoder;
> > -   int num_connectors = 0, i;
> > -   bool is_lvds = false;
> > -
> > -   for_each_connector_in_state(state, connector, connector_state, i) {
> > -   if (connector_state->crtc != crtc_state->base.crtc)
> > -   continue;
> > -
> > -   encoder = to_intel_encoder(connector_state->best_encoder);
> > -
> > -   switch (encoder->type) {
> > -   case INTEL_OUTPUT_LVDS:
> > -   is_lvds = true;
> > -   break;
> > -   default:
> > -   break;
> > -   }
> > -   num_connectors++;
> > -   }
> >  
> > -   if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2)
> > {
> 
> We have the exact same checks in the gmch code as well. For consistency
> you should change those as well.

True. Would it be ok in a follow-up patch? I did that today now that I started
doing some clean ups for i9xx_crtc_compute_clock(). If not, I can resend.

Thanks,
Ander

> 
> > +   if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> > +   intel_panel_use_ssc(dev_priv)) {
> > DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
> >   dev_priv->vbt.lvds_ssc_freq);
> > return dev_priv->vbt.lvds_ssc_freq;
> > @@ -8842,7 +8821,7 @@ static uint32_t ironlake_compute_dpll(struct
> > intel_crtc *intel_crtc,
> > struct drm_connector_state *connector_state;
> > struct intel_encoder *encoder;
> > uint32_t dpll;
> > -   int factor, num_connectors = 0, i;
> > +   int factor, i;
> > bool is_lvds = false, is_sdvo = false;
> >  
> > for_each_connector_in_state(state, connector, connector_state, i) {
> > @@ -8862,8 +8841,6 @@ static uint32_t ironlake_compute_dpll(struct
> > intel_crtc *intel_crtc,
> > default:
> > break;
> > }
> > -
> > -   num_connectors++;
> > }
> >  
> > /* Enable autotuning of the PLL clock (if permissible) */
> > @@ -8917,7 +8894,7 @@ static uint32_t ironlake_compute_dpll(struct
> > intel_crtc *intel_crtc,
> > break;
> > }
> >  
> > -   if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2)
> > +   if (is_lvds && intel_panel_use_ssc(dev_priv))
> > dpll |= PLLB_REF_INPUT_SPREADSPECTRUMIN;
> > else
> > dpll |= PLL_REF_INPUT_DREFCLK;
> > -- 
> > 2.4.3
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

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


Re: [Intel-gfx] [PATCH 2/8] drm/i915: Merge ironlake_get_refclk() into its only caller

2016-03-14 Thread Ville Syrjälä
On Mon, Mar 14, 2016 at 10:55:41AM +0200, Ander Conselvan de Oliveira wrote:
> A previous patche made ironlake_get_refclk() very simple, so merge
> it into its only caller.

Again I'd like to keep the pch and gmch code as similar as possible.
So could do the same for the gmch code.

I already had a patch in my lvds_downclock branch that moved some of
the gmch platform differences out from i9xx_get_refclk() into the
caller, so I guess might as well move the whole thing I suppose.

> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e7d6584..07b5244 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8589,21 +8589,6 @@ void intel_init_pch_refclk(struct drm_device *dev)
>   lpt_init_pch_refclk(dev);
>  }
>  
> -static int ironlake_get_refclk(struct intel_crtc_state *crtc_state)
> -{
> - struct drm_device *dev = crtc_state->base.crtc->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
> - if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> - intel_panel_use_ssc(dev_priv)) {
> - DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
> -   dev_priv->vbt.lvds_ssc_freq);
> - return dev_priv->vbt.lvds_ssc_freq;
> - }
> -
> - return 12;
> -}
> -
>  static void ironlake_set_pipeconf(struct drm_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = crtc->dev->dev_private;
> @@ -8775,7 +8760,14 @@ static bool ironlake_compute_clocks(struct drm_crtc 
> *crtc,
>   const intel_limit_t *limit;
>   bool ret;
>  
> - refclk = ironlake_get_refclk(crtc_state);
> + if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> + intel_panel_use_ssc(dev_priv)) {
> + DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
> +   dev_priv->vbt.lvds_ssc_freq);
> + refclk = dev_priv->vbt.lvds_ssc_freq;
> + } else {
> + refclk = 12;
> + }
>  
>   /*
>* Returns a set of divisors for the desired target clock with the given
> -- 
> 2.4.3
> 
> ___
> 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/8] drm/i915: Remove checks for clone config with LVDS in ILK+ dpll code

2016-03-14 Thread Ville Syrjälä
On Mon, Mar 14, 2016 at 10:55:40AM +0200, Ander Conselvan de Oliveira wrote:
> LVDS is not cloneable, so the check is unnecessary. Removing it makes
> the surrouding code a bit simpler.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 31 ---
>  1 file changed, 4 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 2d151ad..e7d6584 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8593,30 +8593,9 @@ static int ironlake_get_refclk(struct intel_crtc_state 
> *crtc_state)
>  {
>   struct drm_device *dev = crtc_state->base.crtc->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - struct drm_atomic_state *state = crtc_state->base.state;
> - struct drm_connector *connector;
> - struct drm_connector_state *connector_state;
> - struct intel_encoder *encoder;
> - int num_connectors = 0, i;
> - bool is_lvds = false;
> -
> - for_each_connector_in_state(state, connector, connector_state, i) {
> - if (connector_state->crtc != crtc_state->base.crtc)
> - continue;
> -
> - encoder = to_intel_encoder(connector_state->best_encoder);
> -
> - switch (encoder->type) {
> - case INTEL_OUTPUT_LVDS:
> - is_lvds = true;
> - break;
> - default:
> - break;
> - }
> - num_connectors++;
> - }
>  
> - if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2) {

We have the exact same checks in the gmch code as well. For consistency
you should change those as well.

> + if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
> + intel_panel_use_ssc(dev_priv)) {
>   DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
> dev_priv->vbt.lvds_ssc_freq);
>   return dev_priv->vbt.lvds_ssc_freq;
> @@ -8842,7 +8821,7 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
> *intel_crtc,
>   struct drm_connector_state *connector_state;
>   struct intel_encoder *encoder;
>   uint32_t dpll;
> - int factor, num_connectors = 0, i;
> + int factor, i;
>   bool is_lvds = false, is_sdvo = false;
>  
>   for_each_connector_in_state(state, connector, connector_state, i) {
> @@ -8862,8 +8841,6 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
> *intel_crtc,
>   default:
>   break;
>   }
> -
> - num_connectors++;
>   }
>  
>   /* Enable autotuning of the PLL clock (if permissible) */
> @@ -8917,7 +8894,7 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
> *intel_crtc,
>   break;
>   }
>  
> - if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2)
> + if (is_lvds && intel_panel_use_ssc(dev_priv))
>   dpll |= PLLB_REF_INPUT_SPREADSPECTRUMIN;
>   else
>   dpll |= PLL_REF_INPUT_DREFCLK;
> -- 
> 2.4.3
> 
> ___
> 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 v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

2016-03-14 Thread Bastien Nocera
On Mon, 2016-03-14 at 13:41 +0100, Lukas Wunner wrote:
> Hi Bastien,
> 
> sorry for the delay.
> 
> On Sat, Mar 05, 2016 at 05:31:55PM +0100, Bastien Nocera wrote:
> > 
> > We could, on boot, force using the integrated GPU, turning off the
> > discrete GPU that we're not interested in.
> Yes, many people "solve" this by having grub write the requisite
> commands
> to gmux' I/O ports, however this approach won't work with gummiboot.
> Also, the commands that need to be sent to gmux differ between
> retinas
> and pre-retinas.

Which is why I'd be fine with having user-space doing it later on. I
don't think users should have to poke at the boot parameters under
normal circumstances.

> > So I'd push DIGD to the switch sysfs entry on boot. But I'm
> > guessing
> > that won't turn off the other output we're not interested in.
> IGD and DIGD switch to the integrated GPU and also turn off the
> discrete
> GPU. However if the machine is already switched to the integrated
> GPU,
> the commands are no-ops and the discrete GPU is not turned off.
> 
> In other words you need to check (by reading the switch file) which
> GPU
> the machine is switched to. If it's the integrated GPU, write OFF to
> the
> switch file. If it's the discrete GPU, write DIGD to the switch file.
> 
> Once runtime pm works, writing DIGD is sufficient.

This isn't the greatest API, but let me make a note of that:
https://github.com/hadess/switcheroo-control/issues/1

I guess that's only useful until we get runtime PM support.

> > DIGD and DDIS should help (you need to log out/log in again), and
> > if
> > the current GPU is the integrated one, you could force running,
> > say, a
> > game on the discrete GPU using DRI_PRIME=1, correct?
> If runtime pm works, then yes. Otherwise you'd have to manually power
> up
> the GPU before using DRI_PRIME=1 and power it down afterwards.

Another need for run-time PM.

> > FWIW, using OFF at runtime made my machine hang, and without any
> > ways
> > for me to get debug output.
> Which GPU were you switched to? Did you issue the command while X11
> was
> running? Since the machine is switched to the AMD on boot, I guess
> you
> were powering down the Intel GPU. This works on my machine, I get a
> log
> entry "i915: switched off". If this doesn't work on your machine it
> might
> be an i915 bug on your Sandy Bridge GPU or it might be because X11 is
> running.
> 
> Try booting with "drm.debug=0xf log_buf_len=10M" and see if this gets
> you
> log output. If it doesn't, netconsole might help if the hang occurs
> while
> the console is locked.

I'll try it out with your runtime PM patches on top of the latest
upstream one.

> > Ok, so using GIGD or DDIS would just switch the output, but not
> > turn
> > off the unused GPU without runtime PM management.
> No. They do switch off the other GPU if runtime pm is disabled.
> 
> 
> > 
> > > 
> > > http://wunner.de/mbp_switcheroo_v5-4.5.tar.gz   => gpu
> > > switching
> > > for 4.5
> > That's the same patch that's already applied to the kernel above
> > (the
> > ones from this patchset thread), right?
> I'm not sure, the patches in the copr repository might be an earlier
> test version.

Might explain the problems I had.

> > My concerns here would be:
> > - Do we know how to turn off the integrated GPU automatically, if
> > the
> > user only used the internal screen and wanted to use the discrete
> > GPU?
> Runtime pm is currently disabled by default for i915. The Intel folks
> are on it. Until that works, the integrated GPU will be powered down
> when the user manually switches to the discrete GPU with DIS / DDIS
> and powered up when switching back with IGD / DIGD.

Do we have a way to know whether runtime PM is available for one/both
GPUs in the machine? Otherwise this really explodes the testing grid,
and it really makes everything harder.

> > - If only the discrete GPU is powered on, do we know how to power
> > on
> > the integrated GPU so it can drive the external screen when plugged
> > in?
> On the MBP5 2008/09 and MBP6 2010, the external DP port can be
> switched
> between GPUs and we switch it together with the panel. So if you
> switch
> to the discrete GPU, you can also drive the external DP port on these
> models and the integrated GPU can be turned off.
> 
> On the MBP8 2011 and newer, external ports are combined
> DP/Thunderbolt
> ports which can only be driven by the discrete GPU. For some reason
> the
> HPD/AUX pins of the ports can still be switched but not the other
> pins.
> We should nail these ports to the discrete GPU and not switch those
> pins
> together with the panel as we currently do. There's a patch in
> mbp_switcheroo_v5-4.5-runpm.tar.gz which fixes that. The patch also
> wakes
> up the discrete GPU on hotplug, which obviously needs runtime pm.

So that's something else that we can't handle properly without runtime
PM support.

> > - While plymouth is short-lived at boot, Wayland and X11 GNOME
> > sessions
> > use the GPU. The first 

[Intel-gfx] [PATCH] drm/i915/skl: Remove unused skl_disable_dc6 function

2016-03-14 Thread Patrik Jakobsson
Left behind by DC state rework and is no longer needed.

Cc: Imre Deak 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/i915/intel_drv.h| 1 -
 drivers/gpu/drm/i915/intel_runtime_pm.c | 7 ---
 2 files changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 02b3d22..51c43e7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1240,7 +1240,6 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv);
 int skl_sanitize_cdclk(struct drm_i915_private *dev_priv);
 void skl_uninit_cdclk(struct drm_i915_private *dev_priv);
 void skl_enable_dc6(struct drm_i915_private *dev_priv);
-void skl_disable_dc6(struct drm_i915_private *dev_priv);
 void intel_dp_get_m_n(struct intel_crtc *crtc,
  struct intel_crtc_state *pipe_config);
 void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 2e88a5e..316f96d 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -617,13 +617,6 @@ void skl_enable_dc6(struct drm_i915_private *dev_priv)
 
 }
 
-void skl_disable_dc6(struct drm_i915_private *dev_priv)
-{
-   DRM_DEBUG_KMS("Disabling DC6\n");
-
-   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
-}
-
 static void skl_set_power_well(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well, bool enable)
 {
-- 
2.5.0

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


Re: [Intel-gfx] [PATCH 6/8] drm/i915: Don't calculate a new clock in ILK+ code if it is already set

2016-03-14 Thread Maarten Lankhorst
Op 14-03-16 om 14:01 schreef Ander Conselvan De Oliveira:
> On Mon, 2016-03-14 at 12:51 +0100, Maarten Lankhorst wrote:
>> Op 14-03-16 om 09:55 schreef Ander Conselvan de Oliveira:
>>> Remove the clock calculation from ironlake_crtc_compute_clock() when the
>>> encoder compute_config() already set one. The value was just thrown away
>>> in that case.
>>>
>>> Signed-off-by: Ander Conselvan de Oliveira <
>>> ander.conselvan.de.olive...@intel.com>
>>>
>> It was thrown away, but it could still reject based on the limits, which this
>> patch changes.
>> This might be made more clear in the commit message.
> Good point. To be honest, I didn't very this as carefully as I should have
> before sending and missed that detail. It turns out that change is safe. To
> verify I extracted the relevant code and run it with all possible port clocks 
> we
> could have with either the sdvo or the dp encoder setting the clock. See the
> attached C file. I was too lazy to actually understand what the
> g4x_find_best_dpll() does.
>
I'm not sure this would have mattered even if the limits were different, since 
they wouldn't be used. Just something to make a note of.

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


Re: [Intel-gfx] [PATCH 6/8] drm/i915: Don't calculate a new clock in ILK+ code if it is already set

2016-03-14 Thread Ander Conselvan De Oliveira
On Mon, 2016-03-14 at 12:51 +0100, Maarten Lankhorst wrote:
> Op 14-03-16 om 09:55 schreef Ander Conselvan de Oliveira:
> > Remove the clock calculation from ironlake_crtc_compute_clock() when the
> > encoder compute_config() already set one. The value was just thrown away
> > in that case.
> > 
> > Signed-off-by: Ander Conselvan de Oliveira <
> > ander.conselvan.de.olive...@intel.com>
> > 
> It was thrown away, but it could still reject based on the limits, which this
> patch changes.
> This might be made more clear in the commit message.

Good point. To be honest, I didn't very this as carefully as I should have
before sending and missed that detail. It turns out that change is safe. To
verify I extracted the relevant code and run it with all possible port clocks we
could have with either the sdvo or the dp encoder setting the clock. See the
attached C file. I was too lazy to actually understand what the
g4x_find_best_dpll() does.

Anyway, I'll send another version with a note about this.

Thanks,
Ander/*
 * Copyright © 2006-2007 Intel Corporation
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the "Software"),
 * to deal in the Software without restriction, including without limitation
 * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 * and/or sell copies of the Software, and to permit persons to whom the
 * Software is furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice (including the next
 * paragraph) shall be included in all copies or substantial portions of the
 * Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
 * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 * DEALINGS IN THE SOFTWARE.
 *
 * Authors:
 *	Eric Anholt 
 */

#include 
#include 
#include 
#include 
#include 

typedef struct dpll {
	/* given values */
	int n;
	int m1, m2;
	int p1, p2;
	/* derived values */
	int	dot;
	int	vco;
	int	m;
	int	p;
} intel_clock_t;

typedef struct {
	int	min, max;
} intel_range_t;

typedef struct {
	int	dot_limit;
	int	p2_slow, p2_fast;
} intel_p2_t;

typedef struct intel_limit intel_limit_t;
struct intel_limit {
	intel_range_t   dot, vco, n, m, m1, m2, p, p1;
	intel_p2_t	p2;
};

/* Ironlake / Sandybridge
 *
 * We calculate clock using (register_value + 2) for N/M1/M2, so here
 * the range value for them is (actual_value - 2).
 */
static const intel_limit_t intel_limits_ironlake_dac = {
	.dot = { .min = 25000, .max = 35 },
	.vco = { .min = 176, .max = 351 },
	.n = { .min = 1, .max = 5 },
	.m = { .min = 79, .max = 127 },
	.m1 = { .min = 12, .max = 22 },
	.m2 = { .min = 5, .max = 9 },
	.p = { .min = 5, .max = 80 },
	.p1 = { .min = 1, .max = 8 },
	.p2 = { .dot_limit = 225000,
		.p2_slow = 10, .p2_fast = 5 },
};

static const intel_limit_t intel_limits_ironlake_single_lvds = {
	.dot = { .min = 25000, .max = 35 },
	.vco = { .min = 176, .max = 351 },
	.n = { .min = 1, .max = 3 },
	.m = { .min = 79, .max = 118 },
	.m1 = { .min = 12, .max = 22 },
	.m2 = { .min = 5, .max = 9 },
	.p = { .min = 28, .max = 112 },
	.p1 = { .min = 2, .max = 8 },
	.p2 = { .dot_limit = 225000,
		.p2_slow = 14, .p2_fast = 14 },
};

static const intel_limit_t intel_limits_ironlake_dual_lvds = {
	.dot = { .min = 25000, .max = 35 },
	.vco = { .min = 176, .max = 351 },
	.n = { .min = 1, .max = 3 },
	.m = { .min = 79, .max = 127 },
	.m1 = { .min = 12, .max = 22 },
	.m2 = { .min = 5, .max = 9 },
	.p = { .min = 14, .max = 56 },
	.p1 = { .min = 2, .max = 8 },
	.p2 = { .dot_limit = 225000,
		.p2_slow = 7, .p2_fast = 7 },
};

/* LVDS 100mhz refclk limits. */
static const intel_limit_t intel_limits_ironlake_single_lvds_100m = {
	.dot = { .min = 25000, .max = 35 },
	.vco = { .min = 176, .max = 351 },
	.n = { .min = 1, .max = 2 },
	.m = { .min = 79, .max = 126 },
	.m1 = { .min = 12, .max = 22 },
	.m2 = { .min = 5, .max = 9 },
	.p = { .min = 28, .max = 112 },
	.p1 = { .min = 2, .max = 8 },
	.p2 = { .dot_limit = 225000,
		.p2_slow = 14, .p2_fast = 14 },
};

static const intel_limit_t intel_limits_ironlake_dual_lvds_100m = {
	.dot = { .min = 25000, .max = 35 },
	.vco = { .min = 176, .max = 351 },
	.n = { .min = 1, .max = 3 },
	.m = { .min = 79, .max = 126 },
	.m1 = { .min = 12, .max = 22 },
	.m2 = { .min = 5, .max = 9 },
	.p = { .min = 14, .max = 42 },
	.p1 = { .min = 2, .max = 6 },
	.p2 = { .dot_limit = 225000,
		.p2_slow = 7, .p2_fast = 7 },
};

/* stubs */

#define WARN_ON(x)	(x)

#define INTEL_OUTPUT_LVDS 1

struct drm_device {
	

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

2016-03-14 Thread Lukas Wunner
Hi Bastien,

sorry for the delay.

On Sat, Mar 05, 2016 at 05:31:55PM +0100, Bastien Nocera wrote:
> We could, on boot, force using the integrated GPU, turning off the
> discrete GPU that we're not interested in.

Yes, many people "solve" this by having grub write the requisite commands
to gmux' I/O ports, however this approach won't work with gummiboot.
Also, the commands that need to be sent to gmux differ between retinas
and pre-retinas.


> So I'd push DIGD to the switch sysfs entry on boot. But I'm guessing
> that won't turn off the other output we're not interested in.

IGD and DIGD switch to the integrated GPU and also turn off the discrete
GPU. However if the machine is already switched to the integrated GPU,
the commands are no-ops and the discrete GPU is not turned off.

In other words you need to check (by reading the switch file) which GPU
the machine is switched to. If it's the integrated GPU, write OFF to the
switch file. If it's the discrete GPU, write DIGD to the switch file.

Once runtime pm works, writing DIGD is sufficient.


> DIGD and DDIS should help (you need to log out/log in again), and if
> the current GPU is the integrated one, you could force running, say, a
> game on the discrete GPU using DRI_PRIME=1, correct?

If runtime pm works, then yes. Otherwise you'd have to manually power up
the GPU before using DRI_PRIME=1 and power it down afterwards.


> FWIW, using OFF at runtime made my machine hang, and without any ways
> for me to get debug output.

Which GPU were you switched to? Did you issue the command while X11 was
running? Since the machine is switched to the AMD on boot, I guess you
were powering down the Intel GPU. This works on my machine, I get a log
entry "i915: switched off". If this doesn't work on your machine it might
be an i915 bug on your Sandy Bridge GPU or it might be because X11 is
running.

Try booting with "drm.debug=0xf log_buf_len=10M" and see if this gets you
log output. If it doesn't, netconsole might help if the hang occurs while
the console is locked.


> Ok, so using GIGD or DDIS would just switch the output, but not turn
> off the unused GPU without runtime PM management.

No. They do switch off the other GPU if runtime pm is disabled.


> > http://wunner.de/mbp_switcheroo_v5-4.5.tar.gz   => gpu switching
> > for 4.5
> That's the same patch that's already applied to the kernel above (the
> ones from this patchset thread), right?

I'm not sure, the patches in the copr repository might be an earlier
test version.


> My concerns here would be:
> - Do we know how to turn off the integrated GPU automatically, if the
> user only used the internal screen and wanted to use the discrete GPU?

Runtime pm is currently disabled by default for i915. The Intel folks
are on it. Until that works, the integrated GPU will be powered down
when the user manually switches to the discrete GPU with DIS / DDIS
and powered up when switching back with IGD / DIGD.


> - If only the discrete GPU is powered on, do we know how to power on
> the integrated GPU so it can drive the external screen when plugged in?

On the MBP5 2008/09 and MBP6 2010, the external DP port can be switched
between GPUs and we switch it together with the panel. So if you switch
to the discrete GPU, you can also drive the external DP port on these
models and the integrated GPU can be turned off.

On the MBP8 2011 and newer, external ports are combined DP/Thunderbolt
ports which can only be driven by the discrete GPU. For some reason the
HPD/AUX pins of the ports can still be switched but not the other pins.
We should nail these ports to the discrete GPU and not switch those pins
together with the panel as we currently do. There's a patch in
mbp_switcheroo_v5-4.5-runpm.tar.gz which fixes that. The patch also wakes
up the discrete GPU on hotplug, which obviously needs runtime pm.


> - While plymouth is short-lived at boot, Wayland and X11 GNOME sessions
> use the GPU. The first user session will run on a VT that's separate
> from the greeter to implement fast-user switching. So, if we wanted to
> force using the other GPU for future sessions, we'd need to tell gdm to
> kill its graphical session and to respawn it so it doesn't hog the GPU
> and avoid the switch happening. Correct?

I think so, yes.


> On the 8,2, still, and with the kernel from the COPR repo[1].
> 
> I tried running:
> echo DIGD > switch
> 
> to (later) switch to the integrated GPU. Log out, get to gdm, log back
> in to a black screen with the cursor visible and nothing else.
> 
> I'm wondering if it's the gdm X11 session running in the background
> that makes this fail.

That's possible, I have no idea. I have zero issues with GPU switching
on my Nvidia-based MacBook Pro, though I only switch on the console with
no X11 running. On the AMD-based MBP8 that you're using, the patches have
only been tested by William Brown, a colleague of yours at Red Hat
Australia.

If you send me dmesg output with "drm.debug=0xf log_buf_len=10M"
I 

Re: [Intel-gfx] [PATCH i-g-t v3 1/6] ioctl_wrappers: make gem_has_ring non static

2016-03-14 Thread Daniele Ceraolo Spurio



On 10/03/16 11:03, Derek Morton wrote:

For tests that use multiple rings to test interactions it is
useful to know if a ring exists without triggering the test to skip.

Signed-off-by: Derek Morton 
---
  lib/ioctl_wrappers.c | 2 +-
  lib/ioctl_wrappers.h | 1 +
  2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 5d49729..f42e2c9 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1396,7 +1396,7 @@ void gem_require_caching(int fd)
errno = 0;
  }
  
-static int gem_has_ring(int fd, int ring)

+int gem_has_ring(int fd, int ring)


If this becomes non-static it will need documentation, also to explain 
how it differs from gem_has_enable_ring.


Regards,
Daniele


  {
uint32_t bbe = MI_BATCH_BUFFER_END;
struct drm_i915_gem_execbuffer2 execbuf;
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index f59eafb..e095c41 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -150,6 +150,7 @@ uint64_t gem_global_aperture_size(int fd);
  uint64_t gem_mappable_aperture_size(void);
  bool gem_has_softpin(int fd);
  
+int gem_has_ring(int fd, int ring);

  /* check functions which auto-skip tests by calling igt_skip() */
  void gem_require_caching(int fd);
  void gem_require_ring(int fd, int ring_id);


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


Re: [Intel-gfx] [PATCH i-g-t v3 2/6] lib/intel_batchbuffer: Add functions to be used in the scheduler test

2016-03-14 Thread Daniele Ceraolo Spurio



On 10/03/16 11:03, Derek Morton wrote:

Adds functions to create a number of different batch buffers to perform
several functions including:
Batch buffer which will run for a long duration to provide a delay on a
specified ring.
Function to calibrate the delay batch buffer to run for a specified period
of time.
Function to create a batch buffer which writes timestamps to a buffer object.
Function to compare timestamps allowing for wrapping of the values.

v2: Moved code to intel_batchbuffer (Daniel Vetter)
 Addressed review comments from Daniele Ceraolo Spurio

Signed-off-by: Derek Morton 
---
  lib/intel_batchbuffer.c | 384 +++-
  lib/intel_batchbuffer.h |  14 ++
  2 files changed, 393 insertions(+), 5 deletions(-)

diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index 692521f..30e78c5 100644
--- a/lib/intel_batchbuffer.c
+++ b/lib/intel_batchbuffer.c
@@ -1,8 +1,8 @@
  /**
- *
+ *
   * Copyright 2006 Tungsten Graphics, Inc., Cedar Park, Texas.
   * 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
@@ -10,11 +10,11 @@
   * 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 NON-INFRINGEMENT.
@@ -22,7 +22,7 @@
   * 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 

@@ -30,6 +30,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  
  #include "drm.h"

  #include "drmtest.h"
@@ -42,6 +44,7 @@
  #include "ioctl_wrappers.h"
  #include "media_spin.h"
  #include "gpgpu_fill.h"
+#include "igt_gt.h"
  
  #include 
  
@@ -817,3 +820,374 @@ igt_media_spinfunc_t igt_get_media_spinfunc(int devid)
  
  	return spin;

  }
+
+#define SEC_TO_NSEC (1000 * 1000 * 1000)
+#define DWORDS_TO_BYTES(x) ((x)*4)
+
+#define MI_STORE_REGISTER_MEM(LENGTH)   ((0x024 << 23) | ((LENGTH - 2) & 0xff))
+#define MI_MATH(NrInst) ((0x01A << 23) | ((NrInst - 1) & 0x3f))
+#define MI_CONDITIONAL_BATCH_BUFFER_END ((0x036 << 23) | (1 << 21) | 2)
+#define MI_COPY_MEM_MEM ((0x02E << 23) | (3))
+
+#define ALU_LOAD(TO, FROM)  ((0x080 << 20) | ((TO) << 10) | (FROM))
+#define ALU_SUB ( 0x101 << 20)
+#define ALU_STORE(TO, FROM) ((0x180 << 20) | ((TO) << 10) | (FROM))
+
+#define TIMESTAMP_offset  (0x358) /* Elapsed time from system start */
+#define CTX_TIMESTAMP_offset  (0x3A8) /* Elapsed Time from context creation */
+#define ALU_GPU_R0_LSB_offset (0x600)
+#define ALU_GPU_R0_MSB_offset (0x604)
+#define ALU_GPU_R1_LSB_offset (0x608)
+#define ALU_GPU_R1_MSB_offset (0x60C)
+#define ALU_GPU_R2_LSB_offset (0x610)
+#define ALU_GPU_R2_MSB_offset (0x614)
+
+#define ALU_R0_ENCODING   (0x00)
+#define ALU_R1_ENCODING   (0x01)
+#define ALU_SRCA_ENCODING (0x20)
+#define ALU_SRCB_ENCODING (0x21)
+#define ALU_ACCU_ENCODING (0x31)
+
+static int bb_address_size_dw(int fd)
+{
+   if (intel_gen(intel_get_drm_devid(fd)) >= 8)
+   return 2;
+   else
+   return 1;
+}
+
+static uint32_t get_mmio_base(int ringid)
+{
+   switch (ringid) {
+   case I915_EXEC_RENDER:
+   return 0x02000;
+   case I915_EXEC_BSD:
+   case I915_EXEC_BSD | 1<<13: /* BSD1 */
+   return 0x12000;
+   case I915_EXEC_BSD | 2<<13: /* BSD2 */
+   return 0x1c000;
+   case I915_EXEC_BLT:
+   return 0x22000;
+   case I915_EXEC_VEBOX:
+   return 0x1A000;
+   default:
+   igt_assert_f(0, "Invalid ringid %d passed to 
get_mmio_base()\n", ringid);
+   }
+}
+
+/**
+ * igt_batch_used
+ * @batch batchbuffer to get offset from
+ *
+ * This returns the number of bytes of the batchbuffer that have been used.
+ * e.g. The offset into the batchbuffer that the next OUT_BATCH would write to.
+ *
+ * Returns:
+ * The number of bytes of the batchbuffer that have been used.
+ */
+uint32_t igt_batch_used(struct intel_batchbuffer *batch)
+{
+   return batch->ptr - batch->buffer;
+}
+
+/**
+ * igt_create_delay_bb:
+ * @fd: 

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Simplify ironlake_crtc_compute_clock() CPU eDP case

2016-03-14 Thread Maarten Lankhorst
Op 14-03-16 om 09:55 schreef Ander Conselvan de Oliveira:
> None of the code in ironlake_crtc_compute_clock() is relevant for CPU
> eDP. The CPU eDP PLL is turned on and off in ironlake_edp_pll_{on,off}
> from the DP code and that doesn't depend on the crtc_state->dpll values,
> so just return early in that case.
>
> v2: Rebase without patch that drops lvds downclock code. (Ville)
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 47 
> ++--
>  1 file changed, 23 insertions(+), 24 deletions(-)
>
For the whole series:

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


Re: [Intel-gfx] [PATCH 3/8] drm/i915: Fold intel_ironlake_limit() into clock computation function

2016-03-14 Thread Maarten Lankhorst
Op 14-03-16 om 12:53 schreef Ander Conselvan De Oliveira:
> On Mon, 2016-03-14 at 12:46 +0100, Maarten Lankhorst wrote:
>> Op 14-03-16 om 09:55 schreef Ander Conselvan de Oliveira:
>>> The funcion intel_ironlake_limit() is only called by the crtc compute
>>> clock path. By merging it into ironlake_compute_clocks(), the code gets
>>> clearer, since there's no more if-ladders to follow.
>>>
>>> Signed-off-by: Ander Conselvan de Oliveira <
>>> ander.conselvan.de.olive...@intel.com>
>>> ---
>>>  drivers/gpu/drm/i915/intel_display.c | 56 +++--
>>> ---
>>>  1 file changed, 23 insertions(+), 33 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>>> b/drivers/gpu/drm/i915/intel_display.c
>>> index 07b5244..ea71430 100644
>>> --- a/drivers/gpu/drm/i915/intel_display.c
>>> +++ b/drivers/gpu/drm/i915/intel_display.c
>>> @@ -566,30 +566,6 @@ static bool intel_pipe_will_have_type(const struct
>>> intel_crtc_state *crtc_state,
>>>  }
>>>  
>>>  static const intel_limit_t *
>>> -intel_ironlake_limit(struct intel_crtc_state *crtc_state, int refclk)
>>> -{
>>> -   struct drm_device *dev = crtc_state->base.crtc->dev;
>>> -   const intel_limit_t *limit;
>>> -
>>> -   if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
>>> -   if (intel_is_dual_link_lvds(dev)) {
>>> -   if (refclk == 10)
>>> -   limit =
>>> _limits_ironlake_dual_lvds_100m;
>>> -   else
>>> -   limit = _limits_ironlake_dual_lvds;
>>> -   } else {
>>> -   if (refclk == 10)
>>> -   limit =
>>> _limits_ironlake_single_lvds_100m;
>>> -   else
>>> -   limit = _limits_ironlake_single_lvds;
>>> -   }
>>> -   } else
>>> -   limit = _limits_ironlake_dac;
>>> -
>>> -   return limit;
>>> -}
>>> -
>>> -static const intel_limit_t *
>>>  intel_g4x_limit(struct intel_crtc_state *crtc_state)
>>>  {
>>> struct drm_device *dev = crtc_state->base.crtc->dev;
>>> @@ -619,8 +595,8 @@ intel_limit(struct intel_crtc_state *crtc_state, int
>>> refclk)
>>>  
>>> if (IS_BROXTON(dev))
>>> limit = _limits_bxt;
>>> -   else if (HAS_PCH_SPLIT(dev))
>>> -   limit = intel_ironlake_limit(crtc_state, refclk);
>>> +   else if (WARN_ON(HAS_PCH_SPLIT(dev)))
>>> +   limit = NULL;
>>> else if (IS_G4X(dev)) {
>>> limit = intel_g4x_limit(crtc_state);
>>> } else if (IS_PINEVIEW(dev)) {
>> I'm curious, when is intel_limits_bxt ever used? Seems like dead code..
>>
>> It would appear it uses haswell_crtc_compute_clock, which never calls into
>> intel_limit().
> It is called from bxt_find_best_dpll(), which is called form the broxton 
> shared
> dpll code. I just wrote a patch this morning to make that function reference
>  intel_limits_bxt directly. I want to get rid of intel_limit() altogether if
> possible, since those if-ladders get confusing really fast.
>
Ah, no idea why I missed it. But indeed, best get rid of it.

On that you can add my r-b, same for this series if CI is happy. :)

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Split driver init step to phases (rev4)

2016-03-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Split driver init step to phases (rev4)
URL   : https://patchwork.freedesktop.org/series/4374/
State : failure

== Summary ==

Series 4374v4 drm/i915: Split driver init step to phases
http://patchwork.freedesktop.org/api/1.0/series/4374/revisions/4/mbox/

Test drv_hangman:
Subgroup error-state-basic:
pass   -> INCOMPLETE (snb-dellxps)
Test gem_exec_basic:
Subgroup readonly-render:
incomplete -> PASS   (ilk-hp8440p)
Test gem_mmap_gtt:
Subgroup basic-write-no-prefault:
incomplete -> PASS   (ilk-hp8440p)
Test gem_ringfill:
Subgroup basic-default-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
incomplete -> DMESG-WARN (ilk-hp8440p)
Test gem_tiled_pread_basic:
incomplete -> PASS   (byt-nuc)
Test kms_addfb_basic:
Subgroup addfb25-yf-tiled:
incomplete -> PASS   (ilk-hp8440p)
Subgroup bad-pitch-1024:
incomplete -> PASS   (ilk-hp8440p)
Subgroup size-max:
incomplete -> PASS   (ilk-hp8440p)
Subgroup small-bo:
incomplete -> PASS   (ilk-hp8440p)
Subgroup unused-offsets:
incomplete -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (bdw-ultra)
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
incomplete -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (hsw-brixbox)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (hsw-brixbox)
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (ivb-t430s)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> DMESG-WARN (bdw-ultra)
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (hsw-gt2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (bsw-nuc-2)
Test prime_self_import:
Subgroup basic-llseek-size:
incomplete -> PASS   (ilk-hp8440p)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:172  dwarn:1   dfail:0   fail:0   skip:21 
bsw-nuc-2total:194  pass:157  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:154  dwarn:4   dfail:0   fail:1   skip:35 
hsw-brixbox  total:194  pass:170  dwarn:2   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:177  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p  total:194  pass:125  dwarn:5   dfail:0   fail:1   skip:63 
ivb-t430stotal:194  pass:168  dwarn:0   dfail:0   fail:0   skip:26 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:27   pass:20   dwarn:0   dfail:0   fail:0   skip:6  
snb-x220ttotal:194  pass:159  dwarn:1   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1591/

3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 drm-intel-nightly: 
2016y-03m-14d-09h-06m-00s UTC integration manifest
9b7c99c102fcc948ed5e593f4f0474629d039ea9 drm/i915: Split out load time 
interface registration
677f47e901d2914a1ebb84d2f1254a6dc05e3ff9 drm/i915: Split out load time HW 
initialization
4bd8f04f778f8e4d0addcdd6e691c45625e3561a drm/i915: Split out load time MMIO 
initialization
9ba20b3995619a371f3c81e2a4cd0ba65ad81425 drm/i915: Split out load time early 
initialization
58739ffb77f1ab2742cee9074ffcfbb90699d66b drm/i915: Move unload time opregion 
unregistration earlier
83e35d8bbb77e3e604477ee35c742adcbbe37a3d drm/i915: Move unload time GTT, MSI 
IRQ cleanup later
d89be579d478859f52b5e03807d39b8258eaeca6 drm/i915: Move unload time display 
power domain uninit later
a9178ed2ecd73c99a2aad7b3fe675c469e3c drm/i915: Move load time audio 
component registration earlier
4acc396227838b4ae9740e9e15d992cab2b46d8b drm/i915: Move load time shrinker 
registration later
d6e96bba9320ebfd684aab032a68854b15e97024 drm/i915: Move load time runtime PM 
get later
8eff8bdd26eccbed7bc90bdee8d83bcd749601e0 drm/i915: Move load time gem_load_init 
earlier
9d3a1bfcab8df0eab58d319c712eec5021730915 drm/i915: Move load time runtime 
device info init earlier
e9a0b7bf2667192cd0bbe43db3a723279ebb00d9 drm/i915: Move load time init of clock 
gating hooks earlier
e666353fb978f8c1db531264d85a9bce5a768161 drm/i915: Move load time init of 
display/audio hooks earlier
c06d4cfa3680256ee8cd1d487206482d469da646 drm/i915: Move load time IRQ SW init 
earlier
be54dcc7a88765fd8518a62f739a7404766736be drm/i915: Move load time PCH detect, 
DPIO, power domain SW init earlier
06325f6fc613e924cab65916c8a479d9d6a8d962 Fix MCHBAR cleanup on the 

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Fold intel_ironlake_limit() into clock computation function

2016-03-14 Thread Ander Conselvan De Oliveira
On Mon, 2016-03-14 at 12:46 +0100, Maarten Lankhorst wrote:
> Op 14-03-16 om 09:55 schreef Ander Conselvan de Oliveira:
> > The funcion intel_ironlake_limit() is only called by the crtc compute
> > clock path. By merging it into ironlake_compute_clocks(), the code gets
> > clearer, since there's no more if-ladders to follow.
> > 
> > Signed-off-by: Ander Conselvan de Oliveira <
> > ander.conselvan.de.olive...@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 56 +++--
> > ---
> >  1 file changed, 23 insertions(+), 33 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 07b5244..ea71430 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -566,30 +566,6 @@ static bool intel_pipe_will_have_type(const struct
> > intel_crtc_state *crtc_state,
> >  }
> >  
> >  static const intel_limit_t *
> > -intel_ironlake_limit(struct intel_crtc_state *crtc_state, int refclk)
> > -{
> > -   struct drm_device *dev = crtc_state->base.crtc->dev;
> > -   const intel_limit_t *limit;
> > -
> > -   if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
> > -   if (intel_is_dual_link_lvds(dev)) {
> > -   if (refclk == 10)
> > -   limit =
> > _limits_ironlake_dual_lvds_100m;
> > -   else
> > -   limit = _limits_ironlake_dual_lvds;
> > -   } else {
> > -   if (refclk == 10)
> > -   limit =
> > _limits_ironlake_single_lvds_100m;
> > -   else
> > -   limit = _limits_ironlake_single_lvds;
> > -   }
> > -   } else
> > -   limit = _limits_ironlake_dac;
> > -
> > -   return limit;
> > -}
> > -
> > -static const intel_limit_t *
> >  intel_g4x_limit(struct intel_crtc_state *crtc_state)
> >  {
> > struct drm_device *dev = crtc_state->base.crtc->dev;
> > @@ -619,8 +595,8 @@ intel_limit(struct intel_crtc_state *crtc_state, int
> > refclk)
> >  
> > if (IS_BROXTON(dev))
> > limit = _limits_bxt;
> > -   else if (HAS_PCH_SPLIT(dev))
> > -   limit = intel_ironlake_limit(crtc_state, refclk);
> > +   else if (WARN_ON(HAS_PCH_SPLIT(dev)))
> > +   limit = NULL;
> > else if (IS_G4X(dev)) {
> > limit = intel_g4x_limit(crtc_state);
> > } else if (IS_PINEVIEW(dev)) {
> I'm curious, when is intel_limits_bxt ever used? Seems like dead code..
> 
> It would appear it uses haswell_crtc_compute_clock, which never calls into
> intel_limit().

It is called from bxt_find_best_dpll(), which is called form the broxton shared
dpll code. I just wrote a patch this morning to make that function reference
 intel_limits_bxt directly. I want to get rid of intel_limit() altogether if
possible, since those if-ladders get confusing really fast.

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


Re: [Intel-gfx] [PATCH 6/8] drm/i915: Don't calculate a new clock in ILK+ code if it is already set

2016-03-14 Thread Maarten Lankhorst
Op 14-03-16 om 09:55 schreef Ander Conselvan de Oliveira:
> Remove the clock calculation from ironlake_crtc_compute_clock() when the
> encoder compute_config() already set one. The value was just thrown away
> in that case.
>
> Signed-off-by: Ander Conselvan de Oliveira 
> 
>
It was thrown away, but it could still reject based on the limits, which this 
patch changes.
This might be made more clear in the commit message.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/8] drm/i915: Fold intel_ironlake_limit() into clock computation function

2016-03-14 Thread Maarten Lankhorst
Op 14-03-16 om 09:55 schreef Ander Conselvan de Oliveira:
> The funcion intel_ironlake_limit() is only called by the crtc compute
> clock path. By merging it into ironlake_compute_clocks(), the code gets
> clearer, since there's no more if-ladders to follow.
>
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 56 
> +++-
>  1 file changed, 23 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 07b5244..ea71430 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -566,30 +566,6 @@ static bool intel_pipe_will_have_type(const struct 
> intel_crtc_state *crtc_state,
>  }
>  
>  static const intel_limit_t *
> -intel_ironlake_limit(struct intel_crtc_state *crtc_state, int refclk)
> -{
> - struct drm_device *dev = crtc_state->base.crtc->dev;
> - const intel_limit_t *limit;
> -
> - if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
> - if (intel_is_dual_link_lvds(dev)) {
> - if (refclk == 10)
> - limit = _limits_ironlake_dual_lvds_100m;
> - else
> - limit = _limits_ironlake_dual_lvds;
> - } else {
> - if (refclk == 10)
> - limit = _limits_ironlake_single_lvds_100m;
> - else
> - limit = _limits_ironlake_single_lvds;
> - }
> - } else
> - limit = _limits_ironlake_dac;
> -
> - return limit;
> -}
> -
> -static const intel_limit_t *
>  intel_g4x_limit(struct intel_crtc_state *crtc_state)
>  {
>   struct drm_device *dev = crtc_state->base.crtc->dev;
> @@ -619,8 +595,8 @@ intel_limit(struct intel_crtc_state *crtc_state, int 
> refclk)
>  
>   if (IS_BROXTON(dev))
>   limit = _limits_bxt;
> - else if (HAS_PCH_SPLIT(dev))
> - limit = intel_ironlake_limit(crtc_state, refclk);
> + else if (WARN_ON(HAS_PCH_SPLIT(dev)))
> + limit = NULL;
>   else if (IS_G4X(dev)) {
>   limit = intel_g4x_limit(crtc_state);
>   } else if (IS_PINEVIEW(dev)) {
I'm curious, when is intel_limits_bxt ever used? Seems like dead code..

It would appear it uses haswell_crtc_compute_clock, which never calls into 
intel_limit().

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


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

2016-03-14 Thread Matthew Auld
Add expect-to-fail tests for invalid rotations on each of the plane types.

v2:
(Ville Syrjälä)
- use igt_create_fb
- y-tiled will be rejected by gen < 9
- don't hardcode all the plane rotation failure combinations

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

diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index f94f8f1..fb3e2e8 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -479,6 +479,71 @@ err_commit:
igt_assert(ret == 0);
 }
 
+static void exhaust_invalid_plane_rotations(data_t *data, enum igt_plane 
plane_type)
+{
+   igt_display_t *display = >display;
+   int fd = data->gfx_fd, fb_id;
+   uint64_t tiling;
+   uint32_t pixel_format = DRM_FORMAT_XRGB;
+   enum igt_commit_style commit = COMMIT_LEGACY;
+   igt_output_t *output = >outputs[0];
+   igt_plane_t *plane;
+   drmModeModeInfo *mode;
+   drmModePropertyPtr prop;
+   uint64_t supported_plane_rotations = 0, rotation = IGT_ROTATION_0;
+   int ret, i;
+
+   if (intel_gen(intel_get_drm_devid(fd)) >= 9)
+   tiling = LOCAL_I915_FORMAT_MOD_Y_TILED;
+   else
+   tiling = LOCAL_I915_FORMAT_MOD_X_TILED;
+
+   if (plane_type == IGT_PLANE_PRIMARY || plane_type == IGT_PLANE_CURSOR) {
+   igt_require(data->display.has_universal_planes);
+   commit = COMMIT_UNIVERSAL;
+   }
+
+   igt_require(output != NULL && output->valid == true);
+
+   plane = igt_output_get_plane(output, plane_type);
+   igt_require(igt_plane_supports_rotation(plane));
+
+   mode = igt_output_get_mode(output);
+
+   fb_id = igt_create_fb(fd, mode->hdisplay, mode->vdisplay, pixel_format,
+ tiling, >fb);
+   igt_assert(fb_id);
+
+   igt_plane_set_fb(plane, NULL);
+   igt_display_commit(display);
+
+   igt_plane_set_fb(plane, >fb);
+
+   kmstest_get_property(fd, plane->drm_plane->plane_id, 
DRM_MODE_OBJECT_PLANE,
+"rotation", NULL, NULL, );
+
+   for (i = 0; i < prop->count_enums; ++i)
+   supported_plane_rotations |= (1ULL << prop->enums[i].value);
+
+   for (i = 1; i <= 4; i++) {
+   if (!(rotation & supported_plane_rotations)) {
+   igt_plane_set_rotation(plane, rotation);
+
+   ret = igt_display_try_commit2(display, commit);
+   if (ret != -EINVAL)
+   goto err_commit;
+
+   }
+   rotation <<= 1;
+   }
+
+err_commit:
+   igt_remove_fb(fd, >fb);
+   kmstest_restore_vt_mode();
+
+   igt_assert_eq(ret, -EINVAL);
+}
+
 igt_main
 {
data_t data = {};
@@ -579,6 +644,18 @@ igt_main
test_plane_rotation_exhaust_fences(, IGT_PLANE_PRIMARY);
}
 
+   igt_subtest_f("primary-rotations-invalid") {
+   exhaust_invalid_plane_rotations(, IGT_PLANE_PRIMARY);
+   }
+
+   igt_subtest_f("sprite-rotations-invalid") {
+   exhaust_invalid_plane_rotations(, IGT_PLANE_2);
+   }
+
+   igt_subtest_f("cursor-rotations-invalid") {
+   exhaust_invalid_plane_rotations(, IGT_PLANE_CURSOR);
+   }
+
igt_fixture {
igt_display_fini();
}
-- 
2.4.3

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add fault injection support (rev2)

2016-03-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Add fault injection support (rev2)
URL   : https://patchwork.freedesktop.org/series/4385/
State : failure

== Summary ==

Series 4385v2 drm/i915: Add fault injection support
2016-03-14T08:58:17.234391 
http://patchwork.freedesktop.org/api/1.0/series/4385/revisions/2/mbox/
Applying: drm/i915: Add fault injection support
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_dma.c
M   drivers/gpu/drm/i915/i915_drv.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_drv.h
Auto-merging drivers/gpu/drm/i915/i915_dma.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_dma.c
Patch failed at 0001 drm/i915: Add fault injection support

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


[Intel-gfx] [PATCH v4 17/17] drm/i915: Split out load time interface registration

2016-03-14 Thread Imre Deak
According to the new init phases scheme we should register the device
making it available via some kernel internal or user space interface as
the last step in the init sequence, so move the corresponding code to a
separate function.

Also add a TODO comment about code that still needs to be moved around
to one of the init phases functions depending on what the role and effect
of that code is.

No functional change, except for the reordering of the unload time
unregistration steps of sysfs wrt. acpi and opregion.

Suggested by Chris.

v3:
- rename i915_driver_init_register to i915_driver_init_frameworks
  (Chris)
v4:
- rename i915_driver_init_frameworks to i915_driver_register (Daniel)

CC: Chris Wilson 
CC: Daniel Vetter 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c | 83 +++--
 1 file changed, 54 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index aaf1b17..a5121cd 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1209,6 +1209,53 @@ static void i915_driver_cleanup_hw(struct 
drm_i915_private *dev_priv)
 }
 
 /**
+ * i915_driver_register - register the driver with the rest of the system
+ * @dev_priv: device private
+ *
+ * Perform any steps necessary to make the driver available via kernel
+ * internal or userspace interfaces.
+ */
+static void i915_driver_register(struct drm_i915_private *dev_priv)
+{
+   struct drm_device *dev = dev_priv->dev;
+
+   i915_gem_shrinker_init(dev_priv);
+   /*
+* Notify a valid surface after modesetting,
+* when running inside a VM.
+*/
+   if (intel_vgpu_active(dev))
+   I915_WRITE(vgtif_reg(display_ready), VGT_DRV_DISPLAY_READY);
+
+   i915_setup_sysfs(dev);
+
+   if (INTEL_INFO(dev_priv)->num_pipes) {
+   /* Must be done after probing outputs */
+   intel_opregion_init(dev);
+   acpi_video_register();
+   }
+
+   if (IS_GEN5(dev_priv))
+   intel_gpu_ips_init(dev_priv);
+
+   i915_audio_component_init(dev_priv);
+}
+
+/**
+ * i915_driver_unregister - cleanup the registration done in 
i915_driver_regiser()
+ * @dev_priv: device private
+ */
+static void i915_driver_unregister(struct drm_i915_private *dev_priv)
+{
+   i915_audio_component_cleanup(dev_priv);
+   intel_gpu_ips_teardown();
+   acpi_video_unregister();
+   intel_opregion_fini(dev_priv->dev);
+   i915_teardown_sysfs(dev_priv->dev);
+   i915_gem_shrinker_cleanup(dev_priv);
+}
+
+/**
  * i915_driver_load - setup chip and create an initial config
  * @dev: DRM device
  * @flags: startup flags
@@ -1246,6 +1293,11 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
if (ret < 0)
goto out_cleanup_mmio;
 
+   /*
+* TODO: move the vblank init and parts of modeset init steps into one
+* of the i915_driver_init_/i915_driver_register functions according
+* to the role/effect of the given init step.
+*/
if (INTEL_INFO(dev)->num_pipes) {
ret = drm_vblank_init(dev, INTEL_INFO(dev)->num_pipes);
if (ret)
@@ -1258,26 +1310,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
goto out_power_well;
}
 
-   i915_gem_shrinker_init(dev_priv);
-   /*
-* Notify a valid surface after modesetting,
-* when running inside a VM.
-*/
-   if (intel_vgpu_active(dev))
-   I915_WRITE(vgtif_reg(display_ready), VGT_DRV_DISPLAY_READY);
-
-   i915_setup_sysfs(dev);
-
-   if (INTEL_INFO(dev)->num_pipes) {
-   /* Must be done after probing outputs */
-   intel_opregion_init(dev);
-   acpi_video_register();
-   }
-
-   if (IS_GEN5(dev))
-   intel_gpu_ips_init(dev_priv);
-
-   i915_audio_component_init(dev_priv);
+   i915_driver_register(dev_priv);
 
intel_runtime_pm_enable(dev_priv);
 
@@ -1316,15 +1349,7 @@ int i915_driver_unload(struct drm_device *dev)
 
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
 
-   i915_audio_component_cleanup(dev_priv);
-
-   intel_gpu_ips_teardown();
-
-   i915_teardown_sysfs(dev);
-
-   acpi_video_unregister();
-   intel_opregion_fini(dev);
-   i915_gem_shrinker_cleanup(dev_priv);
+   i915_driver_unregister(dev_priv);
 
drm_vblank_cleanup(dev);
 
-- 
2.5.0

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Exit cherryview_irq_handler() after one pass (rev3)

2016-03-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Exit cherryview_irq_handler() after one pass (rev3)
URL   : https://patchwork.freedesktop.org/series/4298/
State : failure

== Summary ==

Series 4298v3 drm/i915: Exit cherryview_irq_handler() after one pass
http://patchwork.freedesktop.org/api/1.0/series/4298/revisions/3/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (skl-i5k-2)
pass   -> INCOMPLETE (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-s3:
dmesg-warn -> PASS   (bsw-nuc-2)
Test gem_tiled_pread_basic:
incomplete -> PASS   (byt-nuc)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS   (bdw-ultra)
Subgroup basic-flip-vs-modeset:
incomplete -> PASS   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS   (hsw-gt2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:189  pass:151  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc  total:194  pass:154  dwarn:4   dfail:0   fail:1   skip:35 
hsw-brixbox  total:194  pass:172  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2  total:194  pass:176  dwarn:1   dfail:0   fail:0   skip:17 
ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:170  dwarn:0   dfail:0   fail:0   skip:24 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
snb-dellxps  total:194  pass:159  dwarn:1   dfail:0   fail:0   skip:34 
snb-x220ttotal:194  pass:159  dwarn:1   dfail:0   fail:1   skip:33 

Results at /archive/results/CI_IGT_test/Patchwork_1589/

3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 drm-intel-nightly: 
2016y-03m-14d-09h-06m-00s UTC integration manifest
7928c2133b16eb2f26866ca05d1cb7bb6d41c765 drm/i915: Exit 
cherryview_irq_handler() after one pass

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


Re: [Intel-gfx] integration-manifest in drm-intel-nigthly

2016-03-14 Thread Daniel Vetter
On Fri, Mar 11, 2016 at 3:25 PM, Marius Vlad  wrote:
> Hi,
>
> A lot of people (including myself) have been asking what is the
> purpose of the integration manifest file in drm-intel-nigthly.  I
> for one have to rebase each time, and I'm wondering how do you pull
> the latest changes.
>
> Could you please write some lines about it? What's its purpose, and
> who generates it?

dim rebuild-nightly scrip generates it, and it was added on China QA's
request so that they know what any given -nightly is based upon. Wrt
rebasing, just use git rebase -i and remove that old integration
manifest (and any patch before that, since those have been thrown out
in upstream). I find it very handy as a marker to separate my own
patches from upstream churn. You have to rebase anyway since -nightly
is a rebasing tree itself.

Also, please don't ask questions without cc'ing mailing lists.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2] drm/i915: Add fault injection support

2016-03-14 Thread Imre Deak
Add support for forcing an error at selected places in the driver. As an
example add 4 options to fail during driver loading.

Requested by Chris.

v2:
- Add fault point for modeset initialization
- Print debug message when injecting an error

CC: Chris Wilson 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_dma.c| 12 
 drivers/gpu/drm/i915/i915_drv.h| 16 
 drivers/gpu/drm/i915/i915_params.c |  5 +
 drivers/gpu/drm/i915/i915_params.h |  1 +
 4 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b1dbf1b..65be671 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -370,6 +370,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
 
+   if (i915_inject_fault(I915_FAULT_INIT_MODESET))
+   return -ENODEV;
+
ret = intel_bios_init(dev_priv);
if (ret)
DRM_INFO("failed to find VBIOS tables\n");
@@ -950,6 +953,9 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
struct intel_device_info *device_info;
int ret = 0;
 
+   if (i915_inject_fault(I915_FAULT_INIT_EARLY))
+   return -ENODEV;
+
dev_priv->dev = dev;
 
/* Setup the write-once "constant" device info */
@@ -1064,6 +1070,9 @@ static int i915_driver_init_mmio(struct drm_i915_private 
*dev_priv)
struct drm_device *dev = dev_priv->dev;
int ret;
 
+   if (i915_inject_fault(I915_FAULT_INIT_MMIO))
+   return -ENODEV;
+
if (i915_get_bridge_dev(dev))
return -EIO;
 
@@ -1107,6 +1116,9 @@ static int i915_driver_init_hw(struct drm_i915_private 
*dev_priv)
uint32_t aperture_size;
int ret;
 
+   if (i915_inject_fault(I915_FAULT_INIT_HW))
+   return -ENODEV;
+
intel_device_info_runtime_init(dev);
 
ret = i915_gem_gtt_init(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f62b6d1..33bcc6e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -98,6 +98,22 @@
 #define I915_STATE_WARN_ON(x)  \
I915_STATE_WARN((x), "%s", "WARN_ON(" __stringify(x) ")")
 
+#define I915_FAULT_INIT_EARLY  1
+#define I915_FAULT_INIT_MMIO   2
+#define I915_FAULT_INIT_HW 4
+#define I915_FAULT_INIT_MODESET8
+
+static inline bool i915_inject_fault(unsigned int fault_mask)
+{
+   if (i915.inject_fault & fault_mask) {
+   DRM_DEBUG_DRIVER("Injecting fault %08x\n", fault_mask);
+
+   return true;
+   }
+
+   return false;
+}
+
 static inline const char *yesno(bool v)
 {
return v ? "yes" : "no";
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 278c9c4..d96c2c0 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,6 +56,7 @@ struct i915_params i915 __read_mostly = {
.edp_vswing = 0,
.enable_guc_submission = false,
.guc_log_level = -1,
+   .inject_fault = 0,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -201,3 +202,7 @@ MODULE_PARM_DESC(enable_guc_submission, "Enable GuC 
submission (default:false)")
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
"GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
+
+module_param_named(inject_fault, i915.inject_fault, uint, 0600);
+MODULE_PARM_DESC(inject_fault,
+   "Force an error at selected points (0:disabled, 1:INIT_EARLY, 
2:INIT_MMIO, 4:INIT_HW)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index bd5026b..2989a48 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -59,6 +59,7 @@ struct i915_params {
bool enable_guc_submission;
bool verbose_state_checks;
bool nuclear_pageflip;
+   unsigned int inject_fault;
 };
 
 extern struct i915_params i915 __read_mostly;
-- 
2.5.0

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


Re: [Intel-gfx] [RFC 04/15] drm/i915: Add headers for non-HDAudio HDMI interface

2016-03-14 Thread Daniel Vetter
On Fri, Mar 11, 2016 at 09:09:12PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 11, 2016 at 11:27:13AM -0600, Pierre-Louis Bossart wrote:
> > Thanks for the review Ville
> > 
> > [snip]
> > 
> > > Kinda hard to see where everything gets used due to the way the patches
> > > are split up.
> > 
> > Yes, it's far from great...
> > 
> > > At least the hotplug/mode change events are not needed. We only have the
> > > two points where i915 should inform the audio driver about this stuff,
> > > and those are the intel_audio_code_enable/disable(). For that we
> > > already have the .pin_eld_notify() hook.
> > >
> > > The interrupt stuff should mostly vanish from i915 with the subdevice
> > > approach. As in i915 would just call the interrupt handler of the audio
> > > driver based on the LPE bits in IIR, and the audio driver can then do
> > > whatever it wants based on its own status register.
> > 
> > Are you saying that the subdevice would provide a read/write interface 
> > for the audio driver to look at display registers, and the i915 driver 
> > would only provide a notification interface (EDID and interrupts) to the 
> > audio driver?
> 
> The audio driver would simply ioremap the appropriate range of
> registers itself.
> 
> > If yes, would there be two component framework links, one between 
> > i915/audio driver and one between subdevice/audio driver.
> 
> Yeah sort of. i915 registers the platform device for the audio, the
> audio driver can then bind to the device via the platform driver .probe
> callback. It can then register with the audio component stuff at some
> point to get the relevant notifications on the display state. When
> i915 gets unloaded we remove the platform device, at which point the
> audio driver's platform driver .remove() callback gets invoked and
> it should unregister/cleanup everything.
> 
> I just tried to frob around with the VED code a bit, and got it to load
> at least. It's not quite happy about reloading i915 while the ipvr
> driver was loaded though. Not sure what's going on there, but I do
> think this approach should work. So the VED patch could serve as a
> decent enough model to follow.

platform devices registerd by modules are apparently inherently racy and
in an unfixable way. At least I remember something like that from VED
discussion.

In short you _must_ unload VED manually before unloading i915, or it all
goes boom. If this is the only thing that went boom it's acceptable.

Another bit we didn't fully do for VED is abstracting away the dma mapping
stuff, because x86 dma abstraction sucks (compared to arm). Not sure, but
this might have been fixed meanwhile - if we can set up a dma_ops that the
subdevice would use, we should do so (instead of the page_to_pfn hacks VED
used).
-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


[Intel-gfx] [PATCH CI-ping] drm/i915: Exit cherryview_irq_handler() after one pass

2016-03-14 Thread Chris Wilson
This effectively reverts

commit 8e5fd599eb219f1054e39b40d18b217af669eea9
Author: Ville Syrjälä 
Date:   Wed Apr 9 13:28:50 2014 +0300

drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed

as under continuous execlists load we can saturate the IRQ handler,
destablising the tsc clock and triggering the NMI watchdog to declare a hung
CPU.

[  552.756051] clocksource: timekeeping watchdog on CPU0: Marking clocksource 
'tsc' as unstable because the skew is too large:
[  552.756080] clocksource:   'refined-jiffies' wd_now: 
10003b480 wd_last: 10003b28c mask: 
[  552.756091] clocksource:   'tsc' cs_now: d55d31aa50 
cs_last: d17446166c mask: 
[  552.756210] clocksource: Switched to clocksource refined-jiffies
[  575.217870] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
[  575.217893] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc7+ #18
[  575.217905] Hardware name:  /NUC5CPYB, BIOS 
PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[  575.217915]   88027fd05bc0 81288c6d 

[  575.217935]  0001 88027fd05be0 810e72d1 

[  575.217951]  88027fd05c80 88027fd05c20 81114b60 
000181015f1e
[  575.217967] Call Trace:
[  575.217973][] dump_stack+0x4f/0x72
[  575.217994]  [] watchdog_overflow_callback+0x151/0x160
[  575.218003]  [] __perf_event_overflow+0xa0/0x1e0
[  575.218016]  [] perf_event_overflow+0x14/0x20
[  575.218028]  [] intel_pmu_handle_irq+0x1da/0x460
[  575.218042]  [] ? poll_idle+0x3e/0x70
[  575.218052]  [] ? poll_idle+0x3e/0x70
[  575.218064]  [] perf_event_nmi_handler+0x28/0x50
[  575.218075]  [] nmi_handle+0x60/0x130
[  575.218086]  [] ? poll_idle+0x3e/0x70
[  575.218096]  [] do_nmi+0x140/0x470
[  575.218108]  [] end_repeat_nmi+0x1a/0x1e
[  575.218119]  [] ? poll_idle+0x3e/0x70
[  575.218129]  [] ? poll_idle+0x3e/0x70
[  575.218139]  [] ? poll_idle+0x3e/0x70
[  575.218148]  <>  [] cpuidle_enter_state+0xf3/0x2f0
[  575.218164]  [] cpuidle_enter+0x17/0x20
[  575.218175]  [] call_cpuidle+0x2a/0x40
[  575.218185]  [] cpu_startup_entry+0x273/0x330
[  575.218196]  [] start_secondary+0x10e/0x130

However, not servicing all available IIR within the handler does hurt the
throughput of pathological nop execbuf by about 20%, with a similar effect
upon the dispatch latency of a series of execbuf.

v2: use do {} while(0) for a smaller patch, and easier to revert again

I have reasonable confidence that we do not miss GT interrupts (as
execlists provides a stress case with a failure mechanism easily
detected by igt), however I have less confidence about all the other
sources of interrupts and worry that may lose a display hotplug
interrupt, for example.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93467
Testcase: igt/gem_exec_nop/basic # requires NMI watchdog
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Antti Koskipää 
Cc: sta...@vger.kernel.org
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_irq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 53e5104964b3..30d8bb7bf078 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1829,7 +1829,7 @@ static irqreturn_t cherryview_irq_handler(int irq, void 
*arg)
/* IRQs are synced during runtime_suspend, we don't require a wakeref */
disable_rpm_wakeref_asserts(dev_priv);
 
-   for (;;) {
+   do {
master_ctl = I915_READ(GEN8_MASTER_IRQ) & 
~GEN8_MASTER_IRQ_CONTROL;
iir = I915_READ(VLV_IIR);
 
@@ -1857,7 +1857,7 @@ static irqreturn_t cherryview_irq_handler(int irq, void 
*arg)
 
I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
POSTING_READ(GEN8_MASTER_IRQ);
-   }
+   } while (0);
 
enable_rpm_wakeref_asserts(dev_priv);
 
-- 
2.7.0

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


[Intel-gfx] [PATCH 7/8] drm/i915: Remove PCH type checks from ironlake_crtc_compute_clock()

2016-03-14 Thread Ander Conselvan de Oliveira
The checks were added in commit 5dc5298bb3e5 ("drm/i915: add proper
CPU/PCH checks to crtc_mode_set functions") in a time when there was
doubts on what PCHs would be supported by HSW. There are similar checks
for PCH type in intel_detect_pch() and the function pointers are
initialized based on platform/pch information, so the removed WARN can't
ever be reached.

v2: Rebase without patch that drops lvds downclock code. (Ville)
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_display.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bf0416d..212c53c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8886,7 +8886,6 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
*intel_crtc,
 static int ironlake_crtc_compute_clock(struct intel_crtc *crtc,
   struct intel_crtc_state *crtc_state)
 {
-   struct drm_device *dev = crtc->base.dev;
intel_clock_t clock, reduced_clock;
u32 dpll = 0, fp = 0, fp2 = 0;
bool has_reduced_clock = false;
@@ -8898,9 +8897,6 @@ static int ironlake_crtc_compute_clock(struct intel_crtc 
*crtc,
 
is_lvds = intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS);
 
-   WARN(!(HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)),
-"Unexpected PCH type %d\n", INTEL_PCH_TYPE(dev));
-
if (!crtc_state->clock_set) {
if (!ironlake_compute_clocks(>base, crtc_state, ,
 _reduced_clock,
-- 
2.4.3

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


[Intel-gfx] [PATCH 6/8] drm/i915: Don't calculate a new clock in ILK+ code if it is already set

2016-03-14 Thread Ander Conselvan de Oliveira
Remove the clock calculation from ironlake_crtc_compute_clock() when the
encoder compute_config() already set one. The value was just thrown away
in that case.

Signed-off-by: Ander Conselvan de Oliveira 

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7034667..bf0416d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8889,7 +8889,7 @@ static int ironlake_crtc_compute_clock(struct intel_crtc 
*crtc,
struct drm_device *dev = crtc->base.dev;
intel_clock_t clock, reduced_clock;
u32 dpll = 0, fp = 0, fp2 = 0;
-   bool ok, has_reduced_clock = false;
+   bool has_reduced_clock = false;
bool is_lvds = false;
struct intel_shared_dpll *pll;
 
@@ -8901,14 +8901,15 @@ static int ironlake_crtc_compute_clock(struct 
intel_crtc *crtc,
WARN(!(HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)),
 "Unexpected PCH type %d\n", INTEL_PCH_TYPE(dev));
 
-   ok = ironlake_compute_clocks(>base, crtc_state, ,
-_reduced_clock, _clock);
-   if (!ok && !crtc_state->clock_set) {
-   DRM_ERROR("Couldn't find PLL settings for mode!\n");
-   return -EINVAL;
-   }
-   /* Compat-code for transition, will disappear. */
if (!crtc_state->clock_set) {
+   if (!ironlake_compute_clocks(>base, crtc_state, ,
+_reduced_clock,
+_clock)) {
+   DRM_ERROR("Couldn't find PLL settings for mode!\n");
+   return -EINVAL;
+   }
+
+   /* Compat-code for transition, will disappear. */
crtc_state->dpll.n = clock.n;
crtc_state->dpll.m1 = clock.m1;
crtc_state->dpll.m2 = clock.m2;
-- 
2.4.3

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


[Intel-gfx] [PATCH 5/8] drm/i915: Simplify ironlake reduced clock logic a bit

2016-03-14 Thread Ander Conselvan de Oliveira
Check has_reduced_clock only once when setting dpll_hw_state, making the
code slightly more readable.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_display.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1d24254..7034667 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8921,6 +8921,8 @@ static int ironlake_crtc_compute_clock(struct intel_crtc 
*crtc,
fp = i9xx_dpll_compute_fp(_state->dpll);
if (has_reduced_clock)
fp2 = i9xx_dpll_compute_fp(_clock);
+   else
+   fp2 = fp;
 
dpll = ironlake_compute_dpll(crtc, crtc_state,
 , _clock,
@@ -8928,10 +8930,7 @@ static int ironlake_crtc_compute_clock(struct intel_crtc 
*crtc,
 
crtc_state->dpll_hw_state.dpll = dpll;
crtc_state->dpll_hw_state.fp0 = fp;
-   if (has_reduced_clock)
-   crtc_state->dpll_hw_state.fp1 = fp2;
-   else
-   crtc_state->dpll_hw_state.fp1 = fp;
+   crtc_state->dpll_hw_state.fp1 = fp2;
 
pll = intel_get_shared_dpll(crtc, crtc_state, NULL);
if (pll == NULL) {
-- 
2.4.3

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


[Intel-gfx] [PATCH 4/8] drm/i915: Call g4x_find_best_dpll() directly from ILK+ code

2016-03-14 Thread Ander Conselvan de Oliveira
The call to dev_priv->display.find_dpll() is already in platform
specific code, so avoid the extra detour.

Signed-off-by: Ander Conselvan de Oliveira 

Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ea71430..1d24254 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8765,9 +8765,8 @@ static bool ironlake_compute_clocks(struct drm_crtc *crtc,
 * refclk, or FALSE.  The returned values represent the clock equation:
 * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2.
 */
-   ret = dev_priv->display.find_dpll(limit, crtc_state,
- crtc_state->port_clock,
- refclk, NULL, clock);
+   ret = g4x_find_best_dpll(limit, crtc_state, crtc_state->port_clock,
+refclk, NULL, clock);
if (!ret)
return false;
 
-- 
2.4.3

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


[Intel-gfx] [PATCH 3/8] drm/i915: Fold intel_ironlake_limit() into clock computation function

2016-03-14 Thread Ander Conselvan de Oliveira
The funcion intel_ironlake_limit() is only called by the crtc compute
clock path. By merging it into ironlake_compute_clocks(), the code gets
clearer, since there's no more if-ladders to follow.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_display.c | 56 +++-
 1 file changed, 23 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 07b5244..ea71430 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -566,30 +566,6 @@ static bool intel_pipe_will_have_type(const struct 
intel_crtc_state *crtc_state,
 }
 
 static const intel_limit_t *
-intel_ironlake_limit(struct intel_crtc_state *crtc_state, int refclk)
-{
-   struct drm_device *dev = crtc_state->base.crtc->dev;
-   const intel_limit_t *limit;
-
-   if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
-   if (intel_is_dual_link_lvds(dev)) {
-   if (refclk == 10)
-   limit = _limits_ironlake_dual_lvds_100m;
-   else
-   limit = _limits_ironlake_dual_lvds;
-   } else {
-   if (refclk == 10)
-   limit = _limits_ironlake_single_lvds_100m;
-   else
-   limit = _limits_ironlake_single_lvds;
-   }
-   } else
-   limit = _limits_ironlake_dac;
-
-   return limit;
-}
-
-static const intel_limit_t *
 intel_g4x_limit(struct intel_crtc_state *crtc_state)
 {
struct drm_device *dev = crtc_state->base.crtc->dev;
@@ -619,8 +595,8 @@ intel_limit(struct intel_crtc_state *crtc_state, int refclk)
 
if (IS_BROXTON(dev))
limit = _limits_bxt;
-   else if (HAS_PCH_SPLIT(dev))
-   limit = intel_ironlake_limit(crtc_state, refclk);
+   else if (WARN_ON(HAS_PCH_SPLIT(dev)))
+   limit = NULL;
else if (IS_G4X(dev)) {
limit = intel_g4x_limit(crtc_state);
} else if (IS_PINEVIEW(dev)) {
@@ -8760,13 +8736,28 @@ static bool ironlake_compute_clocks(struct drm_crtc 
*crtc,
const intel_limit_t *limit;
bool ret;
 
-   if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
-   intel_panel_use_ssc(dev_priv)) {
-   DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
- dev_priv->vbt.lvds_ssc_freq);
-   refclk = dev_priv->vbt.lvds_ssc_freq;
+   refclk = 12;
+
+   if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS)) {
+   if (intel_panel_use_ssc(dev_priv)) {
+   DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
+ dev_priv->vbt.lvds_ssc_freq);
+   refclk = dev_priv->vbt.lvds_ssc_freq;
+   }
+
+   if (intel_is_dual_link_lvds(dev)) {
+   if (refclk == 10)
+   limit = _limits_ironlake_dual_lvds_100m;
+   else
+   limit = _limits_ironlake_dual_lvds;
+   } else {
+   if (refclk == 10)
+   limit = _limits_ironlake_single_lvds_100m;
+   else
+   limit = _limits_ironlake_single_lvds;
+   }
} else {
-   refclk = 12;
+   limit = _limits_ironlake_dac;
}
 
/*
@@ -8774,7 +8765,6 @@ static bool ironlake_compute_clocks(struct drm_crtc *crtc,
 * refclk, or FALSE.  The returned values represent the clock equation:
 * reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2.
 */
-   limit = intel_limit(crtc_state, refclk);
ret = dev_priv->display.find_dpll(limit, crtc_state,
  crtc_state->port_clock,
  refclk, NULL, clock);
-- 
2.4.3

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


[Intel-gfx] [PATCH 2/8] drm/i915: Merge ironlake_get_refclk() into its only caller

2016-03-14 Thread Ander Conselvan de Oliveira
A previous patche made ironlake_get_refclk() very simple, so merge
it into its only caller.

Signed-off-by: Ander Conselvan de Oliveira 

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e7d6584..07b5244 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8589,21 +8589,6 @@ void intel_init_pch_refclk(struct drm_device *dev)
lpt_init_pch_refclk(dev);
 }
 
-static int ironlake_get_refclk(struct intel_crtc_state *crtc_state)
-{
-   struct drm_device *dev = crtc_state->base.crtc->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-
-   if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
-   intel_panel_use_ssc(dev_priv)) {
-   DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
- dev_priv->vbt.lvds_ssc_freq);
-   return dev_priv->vbt.lvds_ssc_freq;
-   }
-
-   return 12;
-}
-
 static void ironlake_set_pipeconf(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = crtc->dev->dev_private;
@@ -8775,7 +8760,14 @@ static bool ironlake_compute_clocks(struct drm_crtc 
*crtc,
const intel_limit_t *limit;
bool ret;
 
-   refclk = ironlake_get_refclk(crtc_state);
+   if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
+   intel_panel_use_ssc(dev_priv)) {
+   DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
+ dev_priv->vbt.lvds_ssc_freq);
+   refclk = dev_priv->vbt.lvds_ssc_freq;
+   } else {
+   refclk = 12;
+   }
 
/*
 * Returns a set of divisors for the desired target clock with the given
-- 
2.4.3

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


[Intel-gfx] [PATCH 8/8] drm/i915: Simplify ironlake_crtc_compute_clock() CPU eDP case

2016-03-14 Thread Ander Conselvan de Oliveira
None of the code in ironlake_crtc_compute_clock() is relevant for CPU
eDP. The CPU eDP PLL is turned on and off in ironlake_edp_pll_{on,off}
from the DP code and that doesn't depend on the crtc_state->dpll values,
so just return early in that case.

v2: Rebase without patch that drops lvds downclock code. (Ville)
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_display.c | 47 ++--
 1 file changed, 23 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 212c53c..0ddba81 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8889,13 +8889,16 @@ static int ironlake_crtc_compute_clock(struct 
intel_crtc *crtc,
intel_clock_t clock, reduced_clock;
u32 dpll = 0, fp = 0, fp2 = 0;
bool has_reduced_clock = false;
-   bool is_lvds = false;
struct intel_shared_dpll *pll;
 
memset(_state->dpll_hw_state, 0,
   sizeof(crtc_state->dpll_hw_state));
 
-   is_lvds = intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS);
+   crtc->lowfreq_avail = false;
+
+   /* CPU eDP is the only output that doesn't need a PCH PLL of its own. */
+   if (!crtc_state->has_pch_encoder)
+   return 0;
 
if (!crtc_state->clock_set) {
if (!ironlake_compute_clocks(>base, crtc_state, ,
@@ -8913,34 +8916,30 @@ static int ironlake_crtc_compute_clock(struct 
intel_crtc *crtc,
crtc_state->dpll.p2 = clock.p2;
}
 
-   /* CPU eDP is the only output that doesn't need a PCH PLL of its own. */
-   if (crtc_state->has_pch_encoder) {
-   fp = i9xx_dpll_compute_fp(_state->dpll);
-   if (has_reduced_clock)
-   fp2 = i9xx_dpll_compute_fp(_clock);
-   else
-   fp2 = fp;
+   fp = i9xx_dpll_compute_fp(_state->dpll);
+   if (has_reduced_clock)
+   fp2 = i9xx_dpll_compute_fp(_clock);
+   else
+   fp2 = fp;
 
-   dpll = ironlake_compute_dpll(crtc, crtc_state,
-, _clock,
-has_reduced_clock ?  : NULL);
+   dpll = ironlake_compute_dpll(crtc, crtc_state,
+, _clock,
+has_reduced_clock ?  : NULL);
 
-   crtc_state->dpll_hw_state.dpll = dpll;
-   crtc_state->dpll_hw_state.fp0 = fp;
-   crtc_state->dpll_hw_state.fp1 = fp2;
+   crtc_state->dpll_hw_state.dpll = dpll;
+   crtc_state->dpll_hw_state.fp0 = fp;
+   crtc_state->dpll_hw_state.fp1 = fp2;
 
-   pll = intel_get_shared_dpll(crtc, crtc_state, NULL);
-   if (pll == NULL) {
-   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
-pipe_name(crtc->pipe));
-   return -EINVAL;
-   }
+   pll = intel_get_shared_dpll(crtc, crtc_state, NULL);
+   if (pll == NULL) {
+   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
+pipe_name(crtc->pipe));
+   return -EINVAL;
}
 
-   if (is_lvds && has_reduced_clock)
+   if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
+   has_reduced_clock)
crtc->lowfreq_avail = true;
-   else
-   crtc->lowfreq_avail = false;
 
return 0;
 }
-- 
2.4.3

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


[Intel-gfx] [PATCH 1/8] drm/i915: Remove checks for clone config with LVDS in ILK+ dpll code

2016-03-14 Thread Ander Conselvan de Oliveira
LVDS is not cloneable, so the check is unnecessary. Removing it makes
the surrouding code a bit simpler.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_display.c | 31 ---
 1 file changed, 4 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2d151ad..e7d6584 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8593,30 +8593,9 @@ static int ironlake_get_refclk(struct intel_crtc_state 
*crtc_state)
 {
struct drm_device *dev = crtc_state->base.crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct drm_atomic_state *state = crtc_state->base.state;
-   struct drm_connector *connector;
-   struct drm_connector_state *connector_state;
-   struct intel_encoder *encoder;
-   int num_connectors = 0, i;
-   bool is_lvds = false;
-
-   for_each_connector_in_state(state, connector, connector_state, i) {
-   if (connector_state->crtc != crtc_state->base.crtc)
-   continue;
-
-   encoder = to_intel_encoder(connector_state->best_encoder);
-
-   switch (encoder->type) {
-   case INTEL_OUTPUT_LVDS:
-   is_lvds = true;
-   break;
-   default:
-   break;
-   }
-   num_connectors++;
-   }
 
-   if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2) {
+   if (intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS) &&
+   intel_panel_use_ssc(dev_priv)) {
DRM_DEBUG_KMS("using SSC reference clock of %d kHz\n",
  dev_priv->vbt.lvds_ssc_freq);
return dev_priv->vbt.lvds_ssc_freq;
@@ -8842,7 +8821,7 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
*intel_crtc,
struct drm_connector_state *connector_state;
struct intel_encoder *encoder;
uint32_t dpll;
-   int factor, num_connectors = 0, i;
+   int factor, i;
bool is_lvds = false, is_sdvo = false;
 
for_each_connector_in_state(state, connector, connector_state, i) {
@@ -8862,8 +8841,6 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
*intel_crtc,
default:
break;
}
-
-   num_connectors++;
}
 
/* Enable autotuning of the PLL clock (if permissible) */
@@ -8917,7 +8894,7 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
*intel_crtc,
break;
}
 
-   if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2)
+   if (is_lvds && intel_panel_use_ssc(dev_priv))
dpll |= PLLB_REF_INPUT_SPREADSPECTRUMIN;
else
dpll |= PLL_REF_INPUT_DREFCLK;
-- 
2.4.3

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


[Intel-gfx] [PATCH 0/8] Clean up ironlake clock computation code

2016-03-14 Thread Ander Conselvan de Oliveira
Hi,

I dropped the patch that deletes the LVDS downclocking code and rebased
the other patches.

Cc: Ville Syrjälä 

Ander Conselvan de Oliveira (8):
  drm/i915: Remove checks for clone config with LVDS in ILK+ dpll code
  drm/i915: Merge ironlake_get_refclk() into its only caller
  drm/i915: Fold intel_ironlake_limit() into clock computation function
  drm/i915: Call g4x_find_best_dpll() directly from ILK+ code
  drm/i915: Simplify ironlake reduced clock logic a bit
  drm/i915: Don't calculate a new clock in ILK+ code if it is already
set
  drm/i915: Remove PCH type checks from ironlake_crtc_compute_clock()
  drm/i915: Simplify ironlake_crtc_compute_clock() CPU eDP case

 drivers/gpu/drm/i915/intel_display.c | 167 +--
 1 file changed, 60 insertions(+), 107 deletions(-)

-- 
2.4.3

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for Prepare dpll for async. (rev2)

2016-03-14 Thread Patchwork
== Series Details ==

Series: Prepare dpll for async. (rev2)
URL   : https://patchwork.freedesktop.org/series/3914/
State : failure

== Summary ==

Series 3914v2 Prepare dpll for async.
http://patchwork.freedesktop.org/api/1.0/series/3914/revisions/2/mbox/

Test core_auth:
Subgroup basic-auth:
incomplete -> PASS   (ilk-hp8440p)
Test gem_ctx_param_basic:
Subgroup invalid-ctx-set:
incomplete -> SKIP   (ilk-hp8440p)
Test gem_exec_basic:
Subgroup basic-render:
incomplete -> PASS   (ilk-hp8440p)
Subgroup gtt-blt:
incomplete -> SKIP   (ilk-hp8440p)
Test gem_exec_parse:
Subgroup basic-rejected:
pass   -> INCOMPLETE (byt-nuc)
Test gem_mmap_gtt:
Subgroup basic-read-no-prefault:
incomplete -> PASS   (ilk-hp8440p)
Subgroup basic-small-copy:
incomplete -> PASS   (ilk-hp8440p)
Test gem_ringfill:
Subgroup basic-default-child:
incomplete -> PASS   (ilk-hp8440p)
Subgroup basic-default-s4:
incomplete -> SKIP   (ilk-hp8440p)
Test kms_addfb_basic:
Subgroup clobberred-modifier:
incomplete -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
pass   -> INCOMPLETE (bsw-nuc-2)
incomplete -> PASS   (byt-nuc)
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (bsw-nuc-2)
pass   -> DMESG-WARN (hsw-brixbox)
Subgroup basic-plain-flip:
incomplete -> PASS   (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-b:
incomplete -> PASS   (ilk-hp8440p)
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS   (hsw-gt2)
pass   -> INCOMPLETE (byt-nuc)
Subgroup nonblocking-crc-pipe-c:
incomplete -> SKIP   (ilk-hp8440p)
Subgroup read-crc-pipe-a:
pass   -> INCOMPLETE (byt-nuc)
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (hsw-gt2)
Test kms_psr_sink_crc:
Subgroup psr_basic:
incomplete -> SKIP   (ilk-hp8440p)
Test kms_sink_crc_basic:
skip   -> INCOMPLETE (byt-nuc)
Test pm_rpm:
Subgroup basic-pci-d3-state:
dmesg-warn -> PASS   (hsw-brixbox)
Subgroup basic-rte:
dmesg-warn -> PASS   (snb-dellxps)

bdw-nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2total:185  pass:148  dwarn:1   dfail:0   fail:0   skip:35 
byt-nuc  total:194  pass:151  dwarn:4   dfail:0   fail:1   skip:34 
hsw-brixbox  total:194  pass:171  dwarn:1   dfail:0   fail:0   skip:22 
hsw-gt2  total:88   pass:83   dwarn:0   dfail:0   fail:0   skip:4  
ilk-hp8440p  total:194  pass:125  dwarn:5   dfail:0   fail:1   skip:63 
ivb-t430stotal:194  pass:169  dwarn:0   dfail:0   fail:0   skip:25 
skl-i5k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-i7k-2total:194  pass:171  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5total:194  pass:183  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:194  pass:159  dwarn:1   dfail:0   fail:0   skip:34 

Results at /archive/results/CI_IGT_test/Patchwork_1587/

10e4a34b0d08030f2287405c855f42afbc568f46 drm-intel-nightly: 
2016y-03m-14d-07h-22m-53s UTC integration manifest
e6d2d7b22762ab67d6b7aeb306a404e241b94f65 drm/i915: Add locking to pll updates, 
v2.
5719b18d0fdf850dc972d46bc6d17b9a5f94a4e5 drm/i915: Move pll power state to crtc 
power domains.
b9c930663eb083354d7ce3b0e6379d38412bd006 drm/i915: Perform dpll commit first, 
v2.
1d8b01dcba8a50dfc6a5f25280e1251ca06e40d0 drm/i915: Use a crtc mask instead of a 
refcount for dpll functions, v2.

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


[Intel-gfx] [PATCH v2 (rebased) 4/4] drm/i915: Add locking to pll updates, v2.

2016-03-14 Thread Maarten Lankhorst
With async modesets this is no longer protected with connection_mutex,
so ensure that each pll has its own lock. The pll configuration state
is still protected; it's only the pll updates that need locking against
concurrency.

Changes since v1:
- Rebased.
- Fix locking to protect all accesses. (Durgadoss)

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 25 +++--
 drivers/gpu/drm/i915/intel_dpll_mgr.h |  2 ++
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index a9084c7c3a36..e730b2001c07 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -89,14 +89,16 @@ void intel_prepare_shared_dpll(struct intel_crtc *crtc)
if (WARN_ON(pll == NULL))
return;
 
+   mutex_lock(>lock);
WARN_ON(!pll->config.crtc_mask);
-   if (pll->active_mask == 0) {
+   if (!pll->active_mask) {
DRM_DEBUG_DRIVER("setting up %s\n", pll->name);
WARN_ON(pll->on);
assert_shared_dpll_disabled(dev_priv, pll);
 
pll->funcs.mode_set(dev_priv, pll);
}
+   mutex_unlock(>lock);
 }
 
 /**
@@ -113,14 +115,17 @@ void intel_enable_shared_dpll(struct intel_crtc *crtc)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_shared_dpll *pll = crtc->config->shared_dpll;
unsigned crtc_mask = 1 << drm_crtc_index(>base);
-   unsigned old_mask = pll->active_mask;
+   unsigned old_mask;
 
if (WARN_ON(pll == NULL))
return;
 
+   mutex_lock(>lock);
+   old_mask = pll->active_mask;
+
if (WARN_ON(!(pll->config.crtc_mask & crtc_mask)) ||
WARN_ON(pll->active_mask & crtc_mask))
-   return;
+   goto out;
 
pll->active_mask |= crtc_mask;
 
@@ -131,13 +136,16 @@ void intel_enable_shared_dpll(struct intel_crtc *crtc)
if (old_mask) {
WARN_ON(!pll->on);
assert_shared_dpll_enabled(dev_priv, pll);
-   return;
+   goto out;
}
WARN_ON(pll->on);
 
DRM_DEBUG_KMS("enabling %s\n", pll->name);
pll->funcs.enable(dev_priv, pll);
pll->on = true;
+
+out:
+   mutex_unlock(>lock);
 }
 
 void intel_disable_shared_dpll(struct intel_crtc *crtc)
@@ -154,8 +162,9 @@ void intel_disable_shared_dpll(struct intel_crtc *crtc)
if (pll == NULL)
return;
 
+   mutex_lock(>lock);
if (WARN_ON(!(pll->active_mask & crtc_mask)))
-   return;
+   goto out;
 
DRM_DEBUG_KMS("disable %s (active %x, on? %d) for crtc %d\n",
  pll->name, pll->active_mask, pll->on,
@@ -166,11 +175,14 @@ void intel_disable_shared_dpll(struct intel_crtc *crtc)
 
pll->active_mask &= ~crtc_mask;
if (pll->active_mask)
-   return;
+   goto out;
 
DRM_DEBUG_KMS("disabling %s\n", pll->name);
pll->funcs.disable(dev_priv, pll);
pll->on = false;
+
+out:
+   mutex_unlock(>lock);
 }
 
 static struct intel_shared_dpll *
@@ -1742,6 +1754,7 @@ void intel_shared_dpll_init(struct drm_device *dev)
for (i = 0; dpll_info[i].id >= 0; i++) {
WARN_ON(i != dpll_info[i].id);
 
+   mutex_init(_priv->shared_dplls[i].lock);
dev_priv->shared_dplls[i].id = dpll_info[i].id;
dev_priv->shared_dplls[i].name = dpll_info[i].name;
dev_priv->shared_dplls[i].funcs = *dpll_info[i].funcs;
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.h 
b/drivers/gpu/drm/i915/intel_dpll_mgr.h
index 89c5ada1a315..fba8cd36ce0a 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.h
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.h
@@ -113,6 +113,8 @@ struct intel_shared_dpll_funcs {
 };
 
 struct intel_shared_dpll {
+   struct mutex lock;
+
struct intel_shared_dpll_config config;
 
unsigned active_mask; /* mask of active CRTCs (i.e. DPMS on) */
-- 
2.1.0

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


[Intel-gfx] [PATCH v2 (rebased) 0/4] Prepare dpll for async.

2016-03-14 Thread Maarten Lankhorst
With the conversion of the driver to support async updates dpll state
can no longer be updated in place.

dpll->config still contains the committed state, while concurrent access
is protected by dpll->mutex.

This is a resend because ander's patch series got a conflict which required
a rewrite of the patches.

Maarten Lankhorst (4):
  drm/i915: Use a crtc mask instead of a refcount for dpll functions,
v2.
  drm/i915: Perform dpll commit first, v2.
  drm/i915: Move pll power state to crtc power domains.
  drm/i915: Add locking to pll updates, v2.

 drivers/gpu/drm/i915/i915_debugfs.c   |  4 +--
 drivers/gpu/drm/i915/intel_display.c  | 54 
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 58 +--
 drivers/gpu/drm/i915/intel_dpll_mgr.h |  4 ++-
 4 files changed, 66 insertions(+), 54 deletions(-)

-- 
2.1.0

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


[Intel-gfx] [PATCH v2 (rebased) 2/4] drm/i915: Perform dpll commit first, v2.

2016-03-14 Thread Maarten Lankhorst
Warn for the wrong mask in enable only. Disable will have the wrong mask now
because the new state is committed before disabling the old state.

Changes since v1:
- Use crtc_mask (Durgadoss)
- Rebase.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c  | 5 ++---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f8f02ec201b7..17d07a729cc0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13536,7 +13536,8 @@ static int intel_atomic_commit(struct drm_device *dev,
}
 
drm_atomic_helper_swap_state(dev, state);
-   dev_priv->wm.config = to_intel_atomic_state(state)->wm_config;
+   dev_priv->wm.config = intel_state->wm_config;
+   intel_shared_dpll_commit(state);
 
if (intel_state->modeset) {
memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
@@ -13588,8 +13589,6 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_modeset_update_crtc_state(state);
 
if (intel_state->modeset) {
-   intel_shared_dpll_commit(state);
-
drm_atomic_helper_update_legacy_modeset_state(state->dev, 
state);
 
if (dev_priv->display.modeset_commit_cdclk &&
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index e5f67efec32d..213862e8cd04 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -156,7 +156,7 @@ void intel_disable_shared_dpll(struct intel_crtc *crtc)
if (pll == NULL)
return;
 
-   if (WARN_ON(!(pll->config.crtc_mask & crtc_mask)))
+   if (WARN_ON(!(pll->active_mask & crtc_mask)))
return;
 
DRM_DEBUG_KMS("disable %s (active %x, on? %d) for crtc %d\n",
-- 
2.1.0

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


[Intel-gfx] [PATCH v2 (rebased) 1/4] drm/i915: Use a crtc mask instead of a refcount for dpll functions, v2.

2016-03-14 Thread Maarten Lankhorst
This makes it easier to verify correct dpll setup with only a single crtc.
It is also useful to detect double dpll enable/disable.

Changes since v1:
- Rebase on top of Ander's dpll rework.
- Change debugfs active to a mask.
- Change enabled_crtcs and active_crtcs to unsigned.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |  4 ++--
 drivers/gpu/drm/i915/intel_display.c  | 43 +--
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 35 +++-
 drivers/gpu/drm/i915/intel_dpll_mgr.h |  2 +-
 4 files changed, 43 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d67ab7130c0f..f8fd30bd75bf 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3208,8 +3208,8 @@ static int i915_shared_dplls_info(struct seq_file *m, 
void *unused)
struct intel_shared_dpll *pll = _priv->shared_dplls[i];
 
seq_printf(m, "DPLL%i: %s, id: %i\n", i, pll->name, pll->id);
-   seq_printf(m, " crtc_mask: 0x%08x, active: %d, on: %s\n",
-  pll->config.crtc_mask, pll->active, yesno(pll->on));
+   seq_printf(m, " crtc_mask: 0x%08x, active: 0x%x, on: %s\n",
+  pll->config.crtc_mask, pll->active_mask, 
yesno(pll->on));
seq_printf(m, " tracked hardware state:\n");
seq_printf(m, " dpll:0x%08x\n", pll->config.hw_state.dpll);
seq_printf(m, " dpll_md: 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5a95dcf68df1..f8f02ec201b7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12973,7 +12973,7 @@ check_shared_dpll_state(struct drm_device *dev)
for (i = 0; i < dev_priv->num_shared_dpll; i++) {
struct intel_shared_dpll *pll =
intel_get_shared_dpll_by_id(dev_priv, i);
-   int enabled_crtcs = 0, active_crtcs = 0;
+   unsigned enabled_crtcs = 0, active_crtcs = 0;
bool active;
 
memset(_hw_state, 0, sizeof(dpll_hw_state));
@@ -12982,15 +12982,15 @@ check_shared_dpll_state(struct drm_device *dev)
 
active = pll->funcs.get_hw_state(dev_priv, pll, _hw_state);
 
-   I915_STATE_WARN(pll->active > hweight32(pll->config.crtc_mask),
-"more active pll users than references: %i vs %i\n",
-pll->active, hweight32(pll->config.crtc_mask));
-   I915_STATE_WARN(pll->active && !pll->on,
-"pll in active use but not on in sw tracking\n");
+   I915_STATE_WARN(pll->active_mask & ~pll->config.crtc_mask,
+"more active pll users than references: %x vs %x\n",
+pll->active_mask, pll->config.crtc_mask);
 
if (!(pll->flags & INTEL_DPLL_ALWAYS_ON)) {
-   I915_STATE_WARN(pll->on && !pll->active,
-"pll in on but not on in use in sw tracking\n");
+   I915_STATE_WARN(!pll->on && pll->active_mask,
+"pll in active use but not on in sw tracking\n");
+   I915_STATE_WARN(pll->on && !pll->active_mask,
+"pll is on but not used by any active crtc\n");
I915_STATE_WARN(pll->on != active,
 "pll on state mismatch (expected %i, found %i)\n",
 pll->on, active);
@@ -12998,16 +12998,17 @@ check_shared_dpll_state(struct drm_device *dev)
 
for_each_intel_crtc(dev, crtc) {
if (crtc->base.state->enable && 
crtc->config->shared_dpll == pll)
-   enabled_crtcs++;
-   if (crtc->active && crtc->config->shared_dpll == pll)
-   active_crtcs++;
+   enabled_crtcs |= 1 << 
drm_crtc_index(>base);
+   if (crtc->base.state->active && 
crtc->config->shared_dpll == pll)
+   active_crtcs |= 1 << 
drm_crtc_index(>base);
}
-   I915_STATE_WARN(pll->active != active_crtcs,
-"pll active crtcs mismatch (expected %i, found %i)\n",
-pll->active, active_crtcs);
-   I915_STATE_WARN(hweight32(pll->config.crtc_mask) != 
enabled_crtcs,
-"pll enabled crtcs mismatch (expected %i, found %i)\n",
-hweight32(pll->config.crtc_mask), enabled_crtcs);
+
+   I915_STATE_WARN(pll->active_mask != active_crtcs,
+"pll active crtcs mismatch (expected %x, found %x)\n",
+pll->active_mask, active_crtcs);
+   

[Intel-gfx] [PATCH v2 (rebased) 3/4] drm/i915: Move pll power state to crtc power domains.

2016-03-14 Thread Maarten Lankhorst
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c  | 6 +++---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 17d07a729cc0..dd76df70c62a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5276,6 +5276,9 @@ static unsigned long get_crtc_power_domains(struct 
drm_crtc *crtc,
mask |= BIT(intel_display_port_power_domain(intel_encoder));
}
 
+   if (crtc_state->shared_dpll)
+   mask |= BIT(POWER_DOMAIN_PLLS);
+
return mask;
 }
 
@@ -15729,9 +15732,6 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
 
DRM_DEBUG_KMS("%s hw state readout: crtc_mask 0x%08x, on %i\n",
  pll->name, pll->config.crtc_mask, pll->on);
-
-   if (pll->config.crtc_mask)
-   intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
}
 
for_each_intel_encoder(dev, encoder) {
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 213862e8cd04..a9084c7c3a36 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -135,8 +135,6 @@ void intel_enable_shared_dpll(struct intel_crtc *crtc)
}
WARN_ON(pll->on);
 
-   intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
-
DRM_DEBUG_KMS("enabling %s\n", pll->name);
pll->funcs.enable(dev_priv, pll);
pll->on = true;
@@ -173,8 +171,6 @@ void intel_disable_shared_dpll(struct intel_crtc *crtc)
DRM_DEBUG_KMS("disabling %s\n", pll->name);
pll->funcs.disable(dev_priv, pll);
pll->on = false;
-
-   intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
 }
 
 static struct intel_shared_dpll *
-- 
2.1.0

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


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

2016-03-14 Thread Hans de Goede

Hi,

On 13-03-16 20:36, Rob Clark wrote:

On Fri, Mar 11, 2016 at 5:07 AM, Timo Aaltonen  wrote:

29.02.2016, 16:47, Hans de Goede kirjoitti:

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

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

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


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

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


I'd be awfully tempted to call that NOTABUG.. I mean, it would fail in
same way if you had a .conf that tried to force ati ddx on a system
without a radeon card..


Ack, as for the modesetting driver only working when using the systemd-logind
integration and not when running the old way, that needs someone to look into
it.

I've put this on my todo list, but I'm not sure when I'll get around to it.

Regards,

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


[Intel-gfx] Updated drm-intel-testing

2016-03-14 Thread Daniel Vetter
Hi all,

New -testing cycle with cool stuff:
- two-stage wm updates for ilk-style platforms (Matt)
- more wm work and fixes from Maarten
- more work on rotated framebuffers to prep for rotated nv12 (Ville)
- more dc fixes (Imre)
- various execlist patches from Tvrtko
- various clock cleanups for gmch from Ville
- extract intel_dpll_mgr.c and refactor shared dpll code (Ander)

Happy testing!

Cheers, 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 2/2] drm/i915: Restrict usage of live status check

2016-03-14 Thread Jani Nikula
On Fri, 11 Mar 2016, Shashank Sharma  wrote:
> [ text/plain ]
> This patch restricts usage of live status check for HDMI detection.
> While testing certain (monitor + cable) combinations with various
> intel  platforms, it seems that live status register is not reliable
> on some older devices. So limit the live_status check from VLV onwards.
>
> This fixes a regression introduced in:
> commit 237ed86c693d8a8e4db476976aeb30df4deac74b
> Author: Sonika Jindal 
> Date:   Tue Sep 15 09:44:20 2015 +0530
> drm/i915: Check live status before reading edid

This is in v4.4, which means the fix will need to be backported too, so
please send a patch fixing the bug *first*, instead of depending on an
optimization patch.

BR,
Jani.


>
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index b523a2f..ca1fb57 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1397,6 +1397,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
> force)
>   enum drm_connector_status status;
>   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct drm_device *dev = connector->dev;
>   bool live_status = true;
>   unsigned int try = 8;
>  
> @@ -1404,14 +1405,21 @@ intel_hdmi_detect(struct drm_connector *connector, 
> bool force)
> connector->base.id, connector->name);
>  
>   intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
> - live_status = intel_digital_port_connected(dev_priv,
> - hdmi_to_dig_port(intel_hdmi));
> - while (!live_status && try--) {
> - msleep(10);
> +
> + /*
> + * The live status register doesn't work reliably with certain
> + * cables/monitors, on old platforms. So restrict the live status
> + * check to be applied from VLV onwards.
> + */
> + if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
>   live_status = intel_digital_port_connected(dev_priv,
>   hdmi_to_dig_port(intel_hdmi));
> + while (!live_status && try--) {
> + msleep(10);
> + live_status = intel_digital_port_connected(dev_priv,
> + hdmi_to_dig_port(intel_hdmi));
> + }
>   }
> -
>   intel_hdmi_unset_edid(connector);
>  
>   if (intel_hdmi_set_edid(connector, live_status)) {

-- 
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] [PULL] topic/drm-misc

2016-03-14 Thread Daniel Vetter
On Wed, Mar 09, 2016 at 10:56:46AM +0100, Daniel Vetter wrote:
> Hi Dave,
> 
> I expect this to be the final drm-misc pull for 4.6:
> - color manager core patch from Lionel - i915 side is ready too, but will
>   only land in 4.7, but I figured it's better to land this earlier for
>   better coordination with other plane stuff (like alpha/blending) going
>   on.
> - more mode_fixup dummy func removal from Carlos (I think that's all now).
> - atomic connector stealing fixes Maarten (maybe this time around, Maarten
>   added testcases for it to igt too).

Color manager patch from Lionel needed some fixup. And somehow the 2nd
pull request got lost, so third time's the charm ;-) I've thrown the SAD
extraction patch from Ville on top for this one.
-Daniel

The following changes since commit 44ab4042178bd596275927ea050980aa4257581b:

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

are available in the git repository at:

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

for you to fetch changes up to c1f415c9acb5877c408d9311eb837d7d50636a68:

  drm: atomic helper: do not unreference error pointer (2016-03-13 19:39:54 
+0100)


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

Lionel Landwerlin (3):
  drm: introduce pipe color correction properties
  drm: fix blob pointer check
  drm: atomic helper: do not unreference error pointer

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

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

Ville Syrjälä (1):
  drm/edid: Extract SADs properly from multiple audio data blocks

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix MST audio enabling

2016-03-14 Thread Jani Nikula
On Fri, 11 Mar 2016, Ander Conselvan De Oliveira  wrote:
> [ text/plain ]
> On Fri, 2016-03-11 at 17:37 +0200, Ville Syrjälä wrote:
>> On Fri, Mar 11, 2016 at 05:33:06PM +0200, Ander Conselvan de Oliveira wrote:
>> > Commit 3d52ccf52f2c ("drm/i915: start adding dp mst audio") erroneously
>> > added a check for MST encoder to ilk_audio_codec_enable instead of the
>> > hsw+ equivalent. That causes the HDMI path to be used, resulting in a
>> > wrong register value.
>> > 
>> > Cc: Libin Yang 
>> > Cc: drm-intel-fi...@lists.freedesktop.org
>> > Fixes: commit 3d52ccf52f2c ("drm/i915: start adding dp mst audio")
>> > Signed-off-by: Ander Conselvan de Oliveira <
>> > ander.conselvan.de.olive...@intel.com>
>> > ---
>> >  drivers/gpu/drm/i915/intel_audio.c | 6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> > b/drivers/gpu/drm/i915/intel_audio.c
>> > index 30f9214..f5fccf7 100644
>> > --- a/drivers/gpu/drm/i915/intel_audio.c
>> > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> > @@ -329,7 +329,8 @@ static void hsw_audio_codec_enable(struct drm_connector
>> > *connector,
>> >tmp = I915_READ(HSW_AUD_CFG(pipe));
>> >tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
>> >tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
>> > -  if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
>> > +  if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
>> > +  intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
>> 
>> Humm. I thought had I asked all of these to be changed to has_dp_encoder.
>> I wonder if I imagined it or if I was just ignored.
>
> Ah, yes. Libin sent a patch to fix the same bug and you asked for that [1] and
> even R-b the follow up version even though it didn't use it everywhere. But it
> looks like Daniel didn't merge it since he wanted all uses converted to
> has_dp_encoders.

We want the minimal fix first now because by bikeshedding we let the bug
slip to v4.5, and we need cc: stable on this.

BR,
Jani.


>
> [1] https://patchwork.freedesktop.org/patch/68902/
> [2] https://patchwork.freedesktop.org/patch/69525/
>
>
>> 
>> >tmp |= AUD_CONFIG_N_VALUE_INDEX;
>> >else
>> >tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
>> > @@ -476,8 +477,7 @@ static void ilk_audio_codec_enable(struct drm_connector
>> > *connector,
>> >tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
>> >tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
>> >tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
>> > -  if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
>> > -  intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
>> > +  if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
>> >tmp |= AUD_CONFIG_N_VALUE_INDEX;
>> >else
>> >tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
>> > -- 
>> > 2.4.3
>> > 
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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